CPU-Last reduzieren: automatische Modul-Deaktivierung

[Quietschboy]

Der Switch verursacht Artefakte ohne dass seine Audio-Ein- und Ausgänge verbunden sind.

Hallo 128bpm!
Ja der Switch ist schon ein ziemlich extrovertierter Kandidat. Will sich immer in den Vordergrund stellen. Er kann halt aber auch immer!
Aber das kann man auch als nützliche Eigenschaft nutzen, wenn man sein Ensemble auf das Re-Initialisierungsverhalten testen möchte. Einfach einen Switch in die Struktur würfeln und draufdrücken. Denn der Switch löst immer ein Re-Init aus. Auch wenn er mit nichts verbunden ist. Die Re-Initialisierung findet global im gesamten Ensemble statt.

Mit der automatischen Deaktivierung von Primary-Strukturen hast du dir für deinen Start ja einen ganz schönen Happen rausgesucht. Aber gut so!
Wenn du die Logik deines Tests ein klitzekleinwenig umdrehst, funktioniert es auch tadellos. Aber leider nur fast! Es gibt zwar keine Knackser mehr, alle Noten werden richtig gespielt, aber es gibt ein anderes, grundsätzliches Problem. Ich möchte allerdings Herwig jetzt nicht dazwischen schiessen.
Bleib dran, 128Bpm! Du hast ein für Reaktor-Builder wichtiges Thema herausgefordert.
Mark

[Quietschboy]

Steuert man das Switch-Modul nicht über das GUI, sondern intern aus der Struktur heraus so arbeitet es absolut Sample-genau, dies habe ich bereits getestet.

ähm, ok, kannst du den Test mal hier anhängen? Mich würde interessieren, was du da genau getestet hast, bzw. mit "Sample-genau" meinst.

[Quietschboy]

OK, da ich frühestens übermorgen Abend wieder Zeit habe und jetzt gerade "dran" bin,gebe ich doch jetzt schon mal meinen Senf ab:
Bei der Untersuchung Herwig´s Test (1.01 herw3 Aussetzer) hatte ich mich einmal im Kreis gedreht und es ist letztendlich nur die dauerhafte Aktivierung des Pitch-Moduls, die die Sache zum laufen zu bringt.

Aber worauf ich hinaus möchte ist dies:

Switch Re-Init Delay_.jpg

Bei einer gespielten Note geben Gate und Pitch die entsprechenden Werte aus. Die Hüllkurve wird gestartet und der OSC bekommt seinen Pitch. Allerdings hat das erstmal noch keinen Effekt, da zunächst der Switch geschaltet werden muss um den OSC zu aktivieren.
Im ACEW kann man sehen, dass die durch das Schalten des Switch aufgerufene Reinitialisierung erst 2400 Samples später passiert!!!!
Es wird "re-init" im ACEW angezeigt (durch den Switch hervorgerufen!) und die impliziten Konstanten Gate und Pitch feuern erneut ihren Wert. Das ist gut so und auch so von dem Entwickler gedacht, denn erst jetzt ist ja der OSC aktiv. Die Hüllkurve sollte neu gestartet werden (tut sie das?) und der OSC kann jetzt auch den neu gesendeten Pitch-Wert erkennen. Aber, wie gesagt, die re-init findet erst sehr spät nach der gespielten Note, bzw. dem Triggern des Switch statt. In diesem Fall waren es 50 Millisekunden! Die Latenz variiert hier. Manchmal sind es bei mir auch nur 480 Samples / 10ms.

Ein absolutes No-Go also

Wer sich versichern möchte, dass das auch für das Audiosignal hinter dem Switch gilt, kann sich auf recht einfache Weise mithilfe des ACEW helfen.
Der ACEW kann nämlich mit ein paar Handgriffen auch zur Analyse von Audio oder anderen schnellen Streams dienen.
Dazu gleich mehr

[Quietschboy]

Audio-Analyse mit ACEW

Um den ACEW fit für Audio zu machen, muss man erstmal in die Core Cell des ACEW einsteigen und einen In-Port auf Audio umstellen.
Ich nehme hier den Port 3.
Port 1 und 2 bleiben weiterhin für Pitch und Gate aus dem obigen Post bestehen.

ACEW Audio in.jpg

Ausserhalb zocke ich das Signal vom Switch OutPort:

Switch Audio Out.JPG

Praktischerweise ist das Audiosignal am Switch konstant 0 wenn er auf den unsichtbaren Eingang geschaltet ist (Off-Zustand).

Die Frage ist ja, ab welchem Zeitpunkt, in relation zur eingespielten Note, haben wir ein Audiosignal am Switch Ausgang?
Würde das Audiosignal ungefiltert in den ACEW "Sensor" (Core Macro) fließen , hätten wir kaum eine Chance irgendetwas Brauchbares auslesen zu können, da der Speicher und die Tabelle des ACEW in einem Wimpernschlag voll sind. Insofern muss eine kleine Filterstruktur her.
Den Filter gilt es in die Core Cell des ACEW vor das "ACEW Sensor" Core Macro einzubauen. Warum hier? Weil Core keinen Unterschied zwischen Audiostreams und Primary Events macht (stimmt nicht zu 100%, aber jetzt egal)). Audio wird in Core "greifbar".
Der Audiowert in inaktivem Zustand ist ja schonmal definitiv Null. Das ist sehr gut.
So brauchen wir also nur den ersten Wert ungleich Null und schon haben wir einen Trigger.
Ungleich Null als Vergleich reicht leider aber noch nicht ganz aus, da wirklich NUR das erste echte Audiosample des OSC angezeigt werden soll.
Die Lösung sieht so aus:

Audio Filter ACEW.JPG

Ungleich Null Vergleich. Wenn Ja, dann 1 ansonsten 0. Hintendran ein Dupletten Filter.
Hier das Ergebnis. Diesmal sind´s 1920 Samples Latenz:

ACEW AUdio Ergebnis.jpg

ACEW selbst bietet auch noch Möglichkeiten zur Filterung aus der Struktur heraus. Sprich per Events. Man kann ihn ein und ausschalten lassen oder auch Buffer und/ oder TimeStamp resetten. Nebenbei bemerkt.

ACEW Controls.jpg

[Quietschboy]

Das die Re-Init mit einer solchen Verzögerung auftritt ist mir auch neu. Hier haben wir es allerdings auch mit einer echten "Echtzeit-Anforderung" zu tun.
Möglicherweise gibt es hier Parallelen zu dem Re-Init, welches auch zeitverzögert nach einem Ensemble-Load-Init auftritt.
Die "runden" Zeiten der Verzögerungen finde ich ebenso auffällig, kann es aber nicht einordnen.

[128bpm]

Hi Quietschboy,

auch dir gilt Dank für deinen Input, so sollst auch du einen würdigen Platz in meine Memoiren erhalten

Sorry, wenn ich nicht immer gleich auf alles eingehen kann. Ich brauche einiges an Zeit um den ganzen Input von euch zu verarbeiten...

Steuert man das Switch-Modul nicht über das GUI, sondern intern aus der Struktur heraus so arbeitet es absolut Sample-genau, dies habe ich bereits getestet.

ähm, ok, kannst du den Test mal hier anhängen? Mich würde interessieren, was du da genau getestet hast, bzw. mit "Sample-genau" meinst.

Meine Ursprüngliche Überlegung dazu war die, dass ein Switch womöglich nicht dafür gedacht ist umfangreich moduliert zu werden. In der Regel wird er mittels Maus über das GUI aktiviert und deaktiviert. Da mir die Arbeitsweise von Reaktor noch nicht detailliert bekannt ist, wollte ich wissen ob der Switch überhaupt in Echtzeit und auf das Sample genau reagiert. Rein theoretisch bräuchte er dies ja nicht, wenn ich ihn mittels Maus über das GUI steuer. Eine Maus wird meines Wissens nach maximal einmal pro ms abgefragt und das Reaktor-GUI wird nur rund 25 mal in der Sekunde aktualisiert.

Das man Reaktor auch über MIDI fernsteuern kann, kam mir in diesem Augenblick nicht in den Sinn. Das lag wohl daran, dass ich nur ein billiges, reglerloses MIDI-Keyboard habe und mein Musik-Equipment seit jeher nur mit der Maus bediene... aber wie auch immer...


Der Test ergab auf jeden Fall, dass die Switches auf das Sample genau reagieren. Der Testaufbau sah dabei vereinfacht wie folgt aus:

Ein Sinus-OSC wurde, ohne AMP-Hüllkurve, an den Eingang eines Switches angeschlossen. Der Switch wurde mittels IC Send-Verbindung von einem Reaktor-internen Sequenzer an- und ausgeschaltet. Das entstandene Signal wurde in der DAW aufgezeichnet und auf sein Timing hin geprüft. Der Switch reagierte dabei, sowohl beim Aktivieren, als auch beim Deaktivieren auf das Sample genau.

Dabei konnte ich allerdings ein Fading feststellen. Die Samplewerte sprangen nicht unmittelbar auf den Maximalwert bzw. auf 0. Beim Aktivieren des Switches wurde das Signal ca. 4-5 Samples lang eingeblendet, beim deaktivieren wurde es ca. 17 Samples lang ausgeblendet.
Das Einfaden könnte eventuell noch von der OSC-Schaltung her kommen, man weiß halt nicht was im OSC passiert, aber das Ausfaden müsste wohl definitiv vom Switch her kommen.


Ich habe gerade ein neues Test-Ensemble zusammengebastelt, da ich das alte nicht gespeichert habe... Von Timing kann in diesem Ensemble nun nicht mehr die Rede sein. Das muss man nicht verstehen... auch das Fading ist nun verschwunden... ich fühle mich leicht verarscht
Den Test im Vorhergehenden Ensemble kann ich leider nicht rekonstruieren. Das habe ich in einem Ensemble konstruiert, welches es so in der Form jetzt nicht mehr gibt.

Nach diesem Test steht für mich aber fest, dass man sich auf das Timing eines Switches nicht verlassen kann und wenn ich mir deine Ergebnisse noch anschaue, dann kann man wohl davon ausgehen, dass der Switch wirklich an die GUI-Clock gekoppelt ist... Da war meine ursprüngliche Überlegung gar nicht so verkehrt.

No Timing.png

Hier das Ensemble zum testen.

Switch_DAW_Timing-Test.png

Switch_DAW-Timing-Test.zip

[herw]

[...]
Der Test ergab auf jeden Fall, dass die Switches auf das Sample genau reagieren. Der Testaufbau sah dabei vereinfacht wie folgt aus:

Ein Sinus-OSC wurde, ohne AMP-Hüllkurve, an den Eingang eines Switches angeschlossen. Der Switch wurde mittels IC Send-Verbindung von einem Reaktor-internen Sequenzer an- und ausgeschaltet. Das entstandene Signal wurde in der DAW aufgezeichnet und auf sein Timing hin geprüft. Der Switch reagierte dabei, sowohl beim Aktivieren, als auch beim Deaktivieren auf das Sample genau.

Dabei konnte ich allerdings ein Fading feststellen. Die Samplewerte sprangen nicht unmittelbar auf den Maximalwert bzw. auf 0. Beim Aktivieren des Switches wurde das Signal ca. 4-5 Samples lang eingeblendet, beim deaktivieren wurde es ca. 17 Samples lang ausgeblendet.
[...]

Leider kenne ich deinen externen Testaufbau nicht, kann also nicht beurteilen, woran du erkennst, dass das Switchen Sample-genau passiert oder versetzt ist. Die Zeitübersicht einer DAW-Leiste finde ich sehr ungenau, da man einzelne Sampleticks nicht erkennen kann. Du sprichst von 4-5 Samples bzw. 17; eventuell reden wir hier von verschiedenen Dingen? Liest du diese an der angezeigten Wellenform ab, zählst also die Wellenberge der angezeigten Wellenform?

Eine Reinitialisierung durch einen Switch finde ich generell problematisch. Das Ein- und Ausschalten innerhalb von Core über die SamplerateClock lässt sich viel besser kontrollieren.
Wird dein Ensemble denn dermaßen umfangreich, dass sich ein Deaktivieren überhaupt lohnt? Oder soll hier nur eine externe Audioquelle automatisiert (über die SongPosition-Clock) ein- und ausgeschaltet werden?

[herw]

Den Zeitpunkt (gemessen in Samplerateticks) des Umschaltens kannst du im ACEW an der Re-Initialisierung erkennen:

Bild 10.png

Ich benutze eine REAKTOR-SampleRate von 44100Hz.

[128bpm]

Leider kenne ich deinen externen Testaufbau nicht, kann also nicht beurteilen, woran du erkennst, dass das Switchen Sample-genau passiert oder versetzt ist. Die Zeitübersicht einer DAW-Leiste finde ich sehr ungenau, da man einzelne Sampleticks nicht erkennen kann. Du sprichst von 4-5 Samples bzw. 17; eventuell reden wir hier von verschiedenen Dingen? Liest du diese an der angezeigten Wellenform ab, zählst also die Wellenberge der angezeigten Wellenform?

In Cubase kann man die Zeitleiste im Sample-Editor auf Samples umstellen und in jedes Sample so weit hinein zoomen bis man einzelne Samples erkennt. Diese kann man dann auch einzeln bearbeiten.

zoom.png

[herw]

aha, muss ich in Logic auch mal ausprobieren
Möchtest du noch auf die Aussetzer aus deinem ersten Beispiel eingehen oder ist das jetzt eher unwichtig geworden?

PS: ui geht in Logic auch - nicht schlecht.

[128bpm]

Möchtest du noch auf die Aussetzer aus deinem ersten Beispiel eingehen oder ist das jetzt eher unwichtig geworden?

Das hat sich derzeit erstmal erledigt, da ich die Primary-Ebene jetzt nur noch für das GUI und das Zusammenführen von Core-Zellen nutze.

Bin gerade dabei fleißig Core Makros zu erstellen Hab schon meine eigene Clock, einen Zähler mit Reset-Funktion und Maximalwert (der Zähler springt bei Erreichen des Maximalwerts zurück auf 1) und diverse kleine Mathe-Macros... Als nächstes folgt ein eigener Core-Sequenzer und verschiedene Hüllkurven

[herw]

Möchtest du noch auf die Aussetzer aus deinem ersten Beispiel eingehen oder ist das jetzt eher unwichtig geworden?

Das hat sich derzeit erstmal erledigt, da ich die Primary-Ebene jetzt nur noch für das GUI und das Zusammenführen von Core-Zellen nutze.

sehr weise

Bin gerade dabei fleißig Core Makros zu erstellen Hab schon meine eigene Clock, einen Zähler mit Reset-Funktion und Maximalwert (der Zähler springt bei Erreichen des Maximalwerts zurück auf 1) und diverse kleine Mathe-Macros... Als nächstes folgt ein eigener Core-Sequenzer und verschiedene Hüllkurven

[Quietschboy]

Das Timing des Switch hat mich ja nicht locker gelassen. Ich habe deinen Test, 128Bpm, etwas verändert und das Audiosignal mit dem Reaktor Recorder aufgezeichnet und in Soundforge (Wave-Editor) angeschaut.

Switch_DAW-Timing-Test Mark2.jpg

Die Teststruktur habe ich so geändert, dass auch CR und DCLK als Trigger für den Switch dienen können. Das geschaltete Audiosignal ist nun lediglich eine digitale 1.
ACHTUNG das Ensemble bei runtergedrehter Lautstärke öffnen, weil es gibt keinen Ein/Aus Schalter dafür (ausser dem Reaktor Schalter)! Vollausschlag Gleichstrom! Schwingspulenkilller!

Na das Ergebnis ist auf jeden Fall, dass der Switch tatsächlich an die DCLK gekoppelt ist. Sprich, triggert man den Switch (z.B. IC Send), so wird beim nächsten DCLK-Tick geschaltet und die Re-Init ausgeführt. Danach stolpert die DCLK mal kurz und gibt einen verfrühten Tick aus um sich dann wieder zu fangen, wenn auch möglicherweise etwas verschoben.
Hier ein Shot aus Soundforge beim "Einschalten" des Switch:
Im oberen, linken Audiokanal die DCLK mit kurzen Strichen, das Triggerevent mit einem mittel-langem Strich und das lange "Schaltevent", also die DCLK + das Re-Init event vom Selector.
Im unteren Teil seht ihr den Audioausgang des Switch, also das Ergebnis der Core Cell "einfach nur 1".
Als Trigger kam die Control Rate mit 25Hz zum Einsatz. Da sie im Gegensatz zur DCLK aber tatsächlich mit exakt 25Hz rennt ist sie asynchron zur DCLK. Die DCLK läuft hier schwankend mit um die 21Hz.

SF Switch Verhalten.jpg

Wieder was gelernt. Danke 256Bpm!
PS: kein Fade In oder Fade Out...
PS2: Triggert man den Switch per DCLK, wird erst beim nächsten DCLK-Tick geschaltet.

Switch_DAW-Timing-Test Mark2.zip

[128bpm]

Gute Arbeit

Jetzt stellt sich die Frage, ob die anderen Panel-Elemente auch an die DCLK gebunden sind. Wenn ja, wären die ganzen IC Send-Verbindungen ziemlich grob gerastert.

Wieder was gelernt. Danke 256Bpm!

Regel mal die BPM wieder runter sonst wird mir ganz schwindlig

[herw]

Gute Arbeit

Jetzt stellt sich die Frage, ob die anderen Panel-Elemente auch an die DCLK gebunden sind. Wenn ja, wären die ganzen IC Send-Verbindungen ziemlich grob gerastert.
[...]

naja, heißt ja nicht ohne Grund DisplayClock
Aufpassen muss man noch zusätzlich, dass es zum Beispiel einen Unterschied macht, ob man beispielsweise einen NotePitch oder Gate mit Hilfe der Computertastatur oder eines Midikeyboards auslöst.
Mich tangiert das aber eigentlich nicht sonderlich; ich denke darüber gar nicht nach, sondern benutze das Display für unkritische, genauer zeitunkritische, Eingaben.
Ansonsten konzentriere ich mich darauf, was denn Alles so in core möglich oder nicht möglich ist; da verlasse ich mich auf die SR-C bzw. CR-C.