Deutsches Reaktor Forum

Ich brauche demnächst ein paar kabelfreie Verbindungen. Und stehe nun vor der Entscheidung die normalen Sends oder deren IC Brüder zu nehmen.
Mir ist nicht ganz klar, wo die Vor- resp. Nachteile der beiden Derivate sind.
Ich sag mal was sie leisten sollen:

- Keine Initialisierungs-, Snapwechschel-, Switch- oder sonstwelche obskuren Event-Trigger. (Recives hängen an einem Merge, das noch anderweitig bedient wird)
- Stepfilter scheidet aber an den Recieves aus, da diese von unterschiedlichen Sends bedient werden, also value-gleicher Neu-Trigger von anderen Quellen muss gewährleistet sein
- Nach Möglichkeit Copy/Paste fähig, mit korrekter Zuordnungsgewähleistung (kann sein das ich die mehrmals brauche, umsortiere, etc.)
- Schlussendlich Stichwort Effizienz: handelt sich zwar nur um ca. 2 Dutzend, aber ich bin halt penibel;)
- Und natürlich Überraschungseier, worauf sollte ich noch unbedingt achten, was mir bislang im Traum nicht einfällt?

Danke

Eventmanager hat geschrieben:Ich brauche demnächst ein paar kabelfreie Verbindungen. Und stehe nun vor der Entscheidung die normalen Sends oder deren IC Brüder zu nehmen.
Mir ist nicht ganz klar, wo die Vor- resp. Nachteile der beiden Derivate sind.
Ich sag mal was sie leisten sollen:

- Keine Initialisierungs-, Snapwechschel-, Switch- oder sonstwelche obskuren Event-Trigger. (Recives hängen an einem Merge, das noch anderweitig bedient wird)
- Stepfilter scheidet aber an den Recieves aus, da diese von unterschiedlichen Sends bedient werden, also value-gleicher Neu-Trigger von anderen Quellen muss gewährleistet sein
- Nach Möglichkeit Copy/Paste fähig, mit korrekter Zuordnungsgewähleistung (kann sein das ich die mehrmals brauche, umsortiere, etc.)

das ist ein entscheidender Knackpunkt! Kopiert man ein Makro, das sends und receives enthält, dann werden die inneren neuen Sends nicht wie bei allen äußeren receives unten an die Liste gehängt sondern nach oben gestellt. Eine schreckliche Inkonsequenz, aber wahrscheinlich für den Compiler notwendig. Ich kreide dies seit Jahren an, NI sieht die Probleme auch, hat aber auch noch kein zufrieden stellendes einfaches Konzept; wahrscheinlich muss man etwas ganz Neues entsprechendes erfinden. Ein workaround ist, dass man in den zu kopierenden Makros die receives zunächst weglässt und am Schluss erst einfügt.

- Schlussendlich Stichwort Effizienz: handelt sich zwar nur um ca. 2 Dutzend, aber ich bin halt penibel;)
- Und natürlich Überraschungseier, worauf sollte ich noch unbedingt achten, was mir bislang im Traum nicht einfällt?

von außen beobachtet kann man dazu gar nichts sagen, zu unterschiedlich sind die möglichen Anwendungen.
Hier die grundsätzlichen Unterschiede:
IC-send sind dafür konzipiert, monophone einzelne Kontrollevents zu senden (intern ist ein stepfilter eingebaut), um zum Beispiel ein Panelelement (knob, switch, auch receive (!)) zu steuern. Sie wirken Ensemble-weit; d.h. können also die Steuersignale auch über verschiedene Instrumente senden und empfangen.
send-receive-Verknüpfungen sind konzipiert, um audio-Signale und event-signale auch polyphon zu übertragen.
Man muss beachten, dass die receive-Liste eines receive-Moduls, das an einen Eventeingang angeschlossen ist, in seiner Liste die audiosignale ignoriert.
Solange du alles „von Hand” benutzt, ist das ziemlich einfach. Anders ist die Sache, wenn du das Umschalten fernsteuern möchtest, zum Beispiel durch einen IC-send, dann musst du dich genau mit der Anordnung der möglichen send-Eingänge auskennen.
Übrigens wenn dich die ständige Neunummerierung beim Einfügen von sends stört, dann kannst du dein ganzes Instrument in ein Makro setzen, als Makro speichern und wieder in eine neues Ensemble laden, dann werden alle sends neu in der Liste nummeriert.
Das Fernsteuern von receives ist sehr schwierig und nur nach langer Erfahrung (Jahre!) zu benutzen, also nichts für den Anfang. Ich benutze in meinem modular 1024 solcher Verbindungen, die von IC-sends über eine eventtable gesteuert werden. Also du bemerkst, dass man da richtig komplizierte Konstrukte entwickeln kann.
Wenn der CPU-Verbrauch keine große Rolle spielt, dann kannst du auch mit shared audio- oder eventtables arbeiten. Auch sie sind global verfügbar (sogar über mehrere Instrumente hinweg) und werden über entsprechende Indizes beschrieben und ausgelesen; cpu-Verbrauch ca. 0,1% pro voice und Tabelle.

Danke

herw hat geschrieben: IC-send sind dafür konzipiert, monophone einzelne Kontrollevents zu senden (intern ist ein stepfilter eingebaut), um zum Beispiel ein Panelelement (knob, switch, auch receive (!)) zu steuern. Sie wirken Ensemble-weit; d.h. können also die Steuersignale auch über verschiedene Instrumente senden und empfangen.

Danke. OK, ich brauchs nur monophon und definitiv simpler als du in deinem Boliden;)
Ob der Steppi nun ein Segen ist - gerade bei Initialisierungen versagt er, aber da scheitert ja das explizite Steppi ebenfalls. Man brauch also explizit einen Steppi hinter dem Recieve.
Copy/Paste (mit Zuweisungserhalt) funzt im Verbund, wird ein einzelnes Element "ausgeschnitten" geht die Zuweisung flöten.
Klone erben keine Zuweisungen.

Man beachte mal folgende kleine Struktur, mehr Steppies und 0-Filter geht wohl kaum, trotzem kommt, selbst wenn beide Button auf Null sind, hinten nach jedem Switch ne 1 an. Erst da explizite filtern nach dem ICR schafft Abhilfe, aber damit auch gleichzeitig Raum für nette Bastelstunden um die ungewellte Filterung im Betrieb zu umgehen....

Das IC S scheint selbst zu initialisieren, keine Ahnung für welchen Fall NI in weiser Vorraussicht solch Blödsinn verzapft
Jut, wenn man das alles weiss und berücksichtigt kann man mit arbeiten, aber bequem und intuitiv geht definitiv anders.

Das erscheint mir sehr übertrieben, aber ich würde mal der Ursache genauer auf den Grund gehen, also an noch mehr Punkten den Eventwatcher hineinsehen lassen.
Mehr kann ich allerdings aus der Schaltung nicht ermitteln, da ich nicht weiß, was du nachweisen oder untersuchen möchtest.
Vielleicht lädst du auch mal diese Schaltungen hoch, da das Nachbauen doch schon Zeit kostet.

ciao herw

Naja, ich hatte zuerst mehr Watcher-Punkte. Daraus resultierte auch mein Gedankenfehler. Direkt hinter dem ersten Merge wird NICHT initialisiert. Deshalb erwartete ich, das das ICS (ungetriggert) ebenfalls still bleibt.
Tut es auch! Nicht das ICS triggert, sondern das ICR gibt den letzen empfangenen Wert erneut aus. Ich habs einfach mal direkt mit nem Knob connected und das ICS gelöscht, da tritt dieses Verhalten ebenso auf.

Unsaubere Laborbedingungen;) fehlerhafte Versuchsanordnung - eindeutig MEIN Verschulden. Tschuldigung!

Andrerseits stellt sich die Frage, warum "das Merge" nicht und das ICR schon initialisiert?

HALT! Schon wieder neue Sültsamkeit.
Mit jeder neuen Verdrahtung am Eventwatcher enstehen andere Init-Trigger. Im Bild triggert das ICR nicht mehr, sobald am Port4 ein Button direkt angeschlossen ist.
Dieser Port gibt übrigens den Wert des Knobs aus, den das ICR hält.
Ist vielleicht der Watcher fehlerhfat?

Eventmanager hat geschrieben:[...]
Ist vielleicht der Watcher fehlerhfat?

ohne weiter ins Detail zu gehen, ja fehlerhaft; diese Version ist nicht die Originalversion; ich benutze entweder den event-watcher v4, den init debugger oder den ACEW 1.0. Alle diese tools sind geprüft und zuverlässig. Andere Version mit eventuellem „Schnickschnack” (zusätzliche Schalter und sonstige Ergänzungen) sind immer mit Vorsicht zu genießen, da man nicht unbedingt den Gestalter kennt und weiß, ob jegliche Intialisierungen getestet wurden.

Der doppelte event ist definitiv falsch.

ciao herw

danke, na dann is ja alle klar.

meinst du diesen mit v4:

Event watcher LED v4.0
By ant stewart

andre v4 finde ich nicht, bei 3.1 sagt die suche schluss???

sind denn der acew und der initdebugger auch für non-core/audio geschichten konzipiert?

Hi Eventmanager!
Der Initdebugger und Eventwatcher sind für Primary geschrieben, denn sie lassen sich ja auch nur in Primary anklemmen
Der Acew stammt aus meiner Feder. Seine ursprüngliche und eigentliche Funktion ist es eine Brücke zu Events in Audio Core Cells zu schlagen. Das tut er sehr gut. Dabei bietet er nebenbei die von mit persönlich beim Eventwatcher vermisste zeitliche Übersicht über alle Eingänge (und inzwischen noch mehr).
Und noch ganz nebenbeier macht er das auch für Primary prima! Er kann auch super mit Init-Events umgehen. lediglich die Eventreihenfolge ist für Primary nicht mehr zuverlässig bestimmbar wie in Core Audio. Dies unterliegt wieder den Primary Regeln, bzw. der Primary-unbestimmtheit (in manchen Fällen). Das Thema muss ich auch noch mal richtig durchkauen. Also wie verändert ein Acew in Primary die Eventreihenfolge?
Der Eventwatcher (oder wars der Initdebugger?) bietet übrigens auch nur eine bestimmte Eventreihenfolge, wenn er IN REIHE in die vorhandene Struktur eingebunden wird (Thru Ports).
Hier der Thread zum ACEW und zur aktuellen Beta 2.0:
http://www.reaktor-forum.de/viewtopic.php?f=11&t=956

Die Einser Verion gibts innder UL
Grüße, Mark

Hi Qiuetschboy,

schön das wir vom Dia- zum Polylog wechseln;-)
Wenn ich das richtig verstehe, ist der ACEW "nur" ein Adapter für den eigentlichen Eventmanager.
So tief steck ich noch nicht in Core um diesen zu benötigen, aber sei schon mal im Vorraus bedankt:)

Du nutzt in deinem Beispiel_ens den EW v 2.0 von Clist. Warum gerade den und nicht den unauffindbaren v4, den herw favorisiert?

Eventmanager hat geschrieben:Hi Qiuetschboy,

schön das wir vom Dia- zum Polylog wechseln;-)
Wenn ich das richtig verstehe, ist der ACEW "nur" ein Adapter für den eigentlichen Eventmanager.
So tief steck ich noch nicht in Core um diesen zu benötigen, aber sei schon mal im Vorraus bedankt:)

Du nutzt in deinem Beispiel_ens den EW v 2.0 von Clist. Warum gerade den und nicht den unauffindbaren v4, den herw favorisiert?

guckst du hier:
Test Equiptment Pack v2.1
Der ACEW ist auch hervorragend für primary!

ciao herw

Eventmanager hat geschrieben: Wenn ich das richtig verstehe, ist der ACEW "nur" ein Adapter für den eigentlichen Eventmanager.

Nein, der ACEW ist ein eigenständiges Messinstrument. Aber er nutzt den "Audio Core Event Output" von Gerald List, um einzelne Events ausneiner Audio Core Cell zu schleusen.