"Primary/switch"-Ersatz (Relais mit Schalter)

[saXist]

Ich möchte meine 40*40 Schalt-Matrix auf CoreCell umbauen,
(1) weiss aber nicht genau wie ich den "Primary/switch" ersetzen kann. In der Core-BA habe ich keine Infos gefunden.

ZZ. experimentiere ich mit dem Lösungsansatz; "CoreCell-Macro/Router", der über einen "Compare" von einem "Primary/Button" zum Umschalten angesteuert wird. Beim "Compary" liegt am unteren Eingang konstant "0" an. Es funktioniert nicht!
Leider wird das Signal vom "Button" nicht weiter gereicht. Wenn ich am oberen "Compare"-Eingang abwechseln eine konstante "1" oder "0" anlege, klappt´s einwandfrei!

Koppeln würde ich die Signale über den "Core/Mixer 2…4" statt dem "Primary/mixer". Davon würden dann 40 Stück (40 Ausgänge) kaskadiert.

(2) Hat das in meinem Fall überhaupt Vorteile, von Primary auf Core um zu stellen?

[KlangRaum]

stell die schaltung mal hier ein..... sonst kann man nix dazu sagen....

[saXist]

Mein CoreCell-Versuch einen Schalter zu simulieren (Bilder der Ebene 2 mit 3 vertauscht) ;

090919_Struktur_Schalter_CoreCell.jpg (29.17 KiB) 488-mal betrachtet

Die Schaltung sollte wie folgt funktionieren;
1- Schalter ist auf "0" > Lampe "Öffner" leuchtet, Lampe "Schliesser" ist aus
2- Schalter auf "1" schalten > Lampe "Schliesser" leuchtet, Lampe "Öffner" ist aus
3- Schalter auf "0" > L"Öffner" wieder ein, L"Schliesser" geht aus
usw.

So funktioniert´s aber zur Zeit;
1- Schalter "0" > L."Öffner" leuchtet, L"Schliesser" ist aus
2- Schalter "1" > L"Öffner" bleibt an, L"Schliesser" geht auch an
3- Schalter "0" > keine Veränderung der Lampenzustände (siehe 3), ab jetzt bleiben beide L. immer an
Theoretisch MÜSSTE die Schaltung funktionieren. Wenn ich im Core-Macro, statt "Trigger" eine Konstante "0" oder "1" etc. einsetze schalten die Ausgänge wunderbar um! Sobald ich aber von Aussen eine konstante "0"/"1" eingebe, kommt der Fehler wie oben beschrieben. Es muss also an dem Übergang "Trig" IN das Core-Macro liegen.

[herw]

jaaa!! ein herrliches Beispiel, wie logisch ein Computer denkt!

Ebene 3: Deine Konstante 1 sendet zu Beginn einmalig eine 1 (global reset). D.h. am com-Eingang liegt immer der Wert 1 an. Der Com-Eingang (Ebene 2) ist als audio-Eingang definiert, also nehme ich mal an, dass später dort audio-Signale eingeschleift werden sollen.
Der Schalter führt in den Eingang Trig; ich nehme weiterhin an, dass es sich eigentlich nicht um einen Trigger handeln soll, sondern wie bei einem Schalter üblich zwei stabile Werte angenommen werden (siehe Deine Beschreibung zur gewünschten Funktionsweise).

Der Schalter sendet zu Beginn (global-reset) ebenfalls einen Wert und zwar 0. Daher ist die Funktionsweise tatsächlich auch zu Beginn korrekt.

Nun erfolgt das Umschalten: wie erwartet leuchtet die Lampe "schließen" auf. Warum sollte nun die andere Lampe erlöschen?. Sie hat keinen entsprechenden Null-Wert erhalten! Im umgekehrten Fall bleibt nun auch die Schließen-Lampe aktiviert, da sie ja auch nur den Wert 1 empfangen kann.
Interessant ist natürlich, was passiert, wenn das Eingangssignal am com-Eingang ein Audiosignal ist. Dann bleibt in demjenigen Zweig, der nicht aktiviert ist, der letzte Audiowert erhalten, während nun im anderen Zweig das Audiosignal verarbeitet wird.

Sicherlich möchtest Du testen, ob der jeweilige Zweig wirklich ausgeschaltet wird.
Ich würde die Schaltung anders testen: speise beim Com-Eingang ein einfaches Audiosignal ein (Dreiecksschwingung) und schließe an die Ausgänge den rechten bzw. linken Ausgangskanal an. Nun müsste beim Umschalten mal der linke oder der rechte Kanal zu hören sein.

Wie man Audiosignale in Core an- und ausschaltet, kannst Du im Handbuch anschaulich lesen: „wir bauen einen Audio-Schalter”.

ciao herw

PS: Dass die Schaltung beim Einsetzen der Konstanten funktioniert, liegt daran, dass Du beim Schließen der Verbindungen in der Struktur wiederum einen global-reset erzeugst und damit auch mal die Werte 0 bzw. 1 sendest.

[saXist]

Die Konstant 1 ist nur für diesen Test angesetzt. Dort wird später ein Audioeingang sein! Und die Lampen werden später als Audio-Ausgang ausgelegt sein. Diese Schaltung sollte, über einen Button gesteuertes "Relais", emulieren. D.h. das die Ein- und Ausgänge ÜBERHAUPT keinen einfluss und/oder Kontakt zu der Steuerung haben DARF.

Wenn ich dich, herw, richtig verstanden habe, ist der CC-Router für diesen Fall ungeeignet.
Die beiden Augänge sollten, je nach Button-Zustand "0/1" hin und her kippen. Also entweder Router-Ausgang "unten" (von mir als Schalter-Öffner verstanden) __ODER__ Router-Ausgang "oben" (von mir als Schalter-Schliesser verstanden).

Welches Macro gibt es in CoreCell, welches eine Relais (ferngesteuereter Schalter) nachbilden kann?
In dem Handbuch-Artikel "Schalter" werden auch Router verwendet.

Welchen Vorteil hat CoreCell überhaupt bei meinen Massen-Schalter/Mixer-Kombinationen gegenüber der Pimary-Ebene, wenns mal funktioniert?

[herw]

[...]

Wenn ich dich, herw, richtig verstanden habe, ist der CC-Router für diesen Fall ungeeignet.
Die beiden Augänge sollten, je nach Button-Zustand "0/1" hin und her kippen. Also entweder Router-Ausgang "unten" (von mir als Schalter-Öffner verstanden) __ODER__ Router-Ausgang "oben" (von mir als Schalter-Schliesser verstanden).
[...]

der CC-Router ist völlig in Ordnung; die von Dir geteste Umgebung zeigt genau das was du haben möchtest, nur musst Du auch wirklich ein Audiosignal anlegen und nicht mit Lampen sondern den Audiokanälen testen.
Warum liest Du nicht das Kapitel im Handbuch über den AudioCore-Schalter? Er macht genau das was Du selbst bauen möchtest.

ciao herw

[saXist]

Ich habe mir noch mal des Artikel "Audio-Schalter" durch gelesen - und - wieder nichts! verstanden. Es habdelt sich um einen Eingangswahlschalter, der mit Speicherelementen "Read/Write" aufgebaut ist.

Für mich einfach zu kompliziert! Nachbauen ohne Verstand ist auch nicht mein Ding.
Daher frage ich mich immer noch, warum der "Router" mit Eventsignalen (Dauersignalen ohne Nulldurchgänge) nicht zurecht kommt?
Es sollte doch möglich sein, einen einfachen Wechsler, der über seinen Schaltzweig signaltypunabhängig schaltet, auf zu bauen.
Ich vergleiche es mit einem Elektroschalter (in the realworld ; sobald der Schalter auf den Schliesser umschaltet, bekommt der Öffnerzweig keine Spannung, somit würde "die Lampe" aus gehen - auch ohne "global-reset"-Bit - ist ja kein Speicher...

Wenn ich es richtig verstehe, kann über einen Audio-Port ohne weiteres ein Events geführt werden (mit dem Nachteil der höheren CPU-Last, durch eine höhere Taktrate), aber nicht anders herum.

[toxonic]

Daher frage ich mich immer noch, warum der "Router" mit Eventsignalen (Dauersignalen ohne Nulldurchgänge) nicht zurecht kommt?

das hat erstmal nix mit den nulldurchgängen im audiosignal ansich zu tun (und event signale sind keine(!!!) permanenten signale, deswegen heissen sie "events"(ereignis)), sondern damit, das ein audiosignal ein permanenter datenstrom ist. wenn dein schalter umschaltet, sollte normalerweise an dem ausgang, welcher zuletzt aktiv war, der letzte wert vor dem umschalten anliegen. wenn das vorher die konstante 1 war, wird auch weiterhin die konstante 1 am ausgang anliegen. liegt ein audiosignal mit amplitude 1 an, wird der wert irgendwo zwischen -1 und 1 sein - nicht zwingenderweise 0. prinzipiell lässt sich das schon machen, du musst bloss deiner corecell beibringen den wert am jeweiligen ausgang auf einen anderen wert zu setzen, also z.b. 0. das könntest du z.b mit einem zweiten compare modul machen.
btw, ich finde diese logik bei reaktor übrigens nicht ganz einleuchtend. in anderen programmen wird ein audio ein-/ausgang immer in samplerate berechnet, d.h. normalerweise sollte tatsächlich der wert auf 0 springen, sobald der datenstrom abbricht, weil dann eben wieterhin ein signal am ein-/ausgang anliegt, aber eben eines mit 0 amplitude. aber naja, wenn man's weiss....

test.jpg (13.62 KiB) 441-mal betrachtet

[herw]

Ich habe mir noch mal des Artikel "Audio-Schalter" durch gelesen - und - wieder nichts! verstanden. Es habdelt sich um einen Eingangswahlschalter, der mit Speicherelementen "Read/Write" aufgebaut ist.

Für mich einfach zu kompliziert! Nachbauen ohne Verstand ist auch nicht mein Ding.
Daher frage ich mich immer noch, warum der "Router" mit Eventsignalen (Dauersignalen ohne Nulldurchgänge) nicht zurecht kommt?
Es sollte doch möglich sein, einen einfachen Wechsler, der über seinen Schaltzweig signaltypunabhängig schaltet, auf zu bauen.
Ich vergleiche es mit einem Elektroschalter (in the realworld ; sobald der Schalter auf den Schliesser umschaltet, bekommt der Öffnerzweig keine Spannung, somit würde "die Lampe" aus gehen - auch ohne "global-reset"-Bit - ist ja kein Speicher...

Wenn ich es richtig verstehe, kann über einen Audio-Port ohne weiteres ein Events geführt werden (mit dem Nachteil der höheren CPU-Last, durch eine höhere Taktrate), aber nicht anders herum.

Wie ich oben schon sagte, Du musst auch „aus”-Events senden, sonst passiert nichts. Das „Ausschalten” eines Core-Zweiges heißt noch nicht, dass auch ein entsprechendes Event gesendet wird. Daher leuchten nach einmaligem „Umschalten” die Lampen selbstverständlich immer noch.

Ich habe Dir mal ein kleines Ensemble für einen Wechselschalter gebaut.

Wechselschalter.gif (1.68 KiB) 411-mal betrachtet

Wechselschalter.ens.zip

(3.63 KiB) 22-mal heruntergeladen

Der Trick besteht darin, dass beide Lampen über ein Merge-Modul mal das Audiosignal und mal das Eventsignal empfangen.

Wechselschalter Strukur.gif (5.4 KiB) 402-mal betrachtet

ciao herw

[toxonic]

auch eine variante.

[herw]

:D auch eine variante.

is was für Elektriker, die ihre Stereoanlage ins Lichtnetz einspeisen wollen .
Ich hatte gar nicht bemerkt, dass Du mit einer ganz ähnlichen Idee währenddessen geantwortet hattest - witzig, wie ähnlich die Lösungen sind.

[toxonic]

so führen nicht alle, aber doch viele wege nach rom.
by the way, hättest du dir nicht den zweiten router sogar sparen können? hab's nicht ausprobiert, aber erscheint mir erstmal logisch....

[herw]

so führen nicht alle, aber doch viele wege nach rom.
by the way, hättest du dir nicht den zweiten router sogar sparen können? hab's nicht ausprobiert, aber erscheint mir erstmal logisch....

arrrggg - Tomaten auf den Augen - na klar: den zweiten Ausgang des oberen Routers direkt in den unteren Merger führen.

ciao herw

[saXist]

ahhh - verstehe!
wenn man(n) sich erst mal von der Logik des elektrischen Stromfluss entkoppelt und in der Datenstrom-Netzwerken denkt, verschwindet auch ein grosser Teil des Schleiers...
Die Logikprüfung mir Lampen ist mir nach wie vor lieber als Zustandsprüfungen mit Audiosignalen.

Ich habe in der Zwischenzeit die 40*40-Matrix in Primary erweitert, habe auch dort leichte Fehllogiken festgestellt, werde aber
EURE Varianten ausprobieren!

Matrix-Variante 32*32 ports;

090918_Struktur_Matrix_32x32.jpg (60.13 KiB) 380-mal betrachtet

Mal sehen wie das später in core arbeitet.

[herw]

ahhh - verstehe!
wenn man(n) sich erst mal von der Logik des elektrischen Stromfluss entkoppelt und in der Datenstrom-Netzwerken denkt, verschwindet auch ein grosser Teil des Schleiers...
Die Logikprüfung mir Lampen ist mir nach wie vor lieber als Zustandsprüfungen mit Audiosignalen.

Ich habe in der Zwischenzeit die 40*40-Matrix in Primary erweitert, habe auch dort leichte Fehllogiken festgestellt, werde aber
EURE Varianten ausprobieren!

Matrix-Variante 32*32 ports;


Mal sehen wie das später in core arbeitet.

Ein Drahtverhau von mehr als zehn Leitungen schreckt mich prinzipiell ab und ab da denke ich über Alternativen nach.
Interne Verbindungen, wie schon oben angedeutet, sind hier das Zauberwort.
In AudioCore wird dein Ansatz nicht anders aussehen, das Problem ist hierbei die Verschaltung innerhalb von Core, da das „Problem” (der „Segen”) der Gleichzeitigkeit von Berechnungen hinzukommt.

ciao herw