CPU-Last reduzieren: automatische Modul-Deaktivierung

[128bpm]

Hi Community,

seit Anfang des Jahres beschäftige ich mich intensiv mit Reaktor. Ich will in den nächsten Jahren ein größeres Projekt mit vielen individuellen Soundmodulen umsetzen. Dabei war mir von Beginn an klar, dass die CPU-Auslastung zum Problem werden könnte und so kam mir die Idee, automatische Schalter zu integrieren. Aktuell bin ich leider noch nicht wirklich über die Idee hinaus, aber ich will mein Vorhaben hier trotzdem schon einmal vorstellen.

Mir ist in Reaktor nur ein Modul bekannt, welches in der Lage ist andere Module zu deaktivieren, so dass diese keine CPU-Last mehr erzeugen. Es handelt sich um das Switch-Modul aus der Primary-Ebene. Dieses Modul lässt sich über ein IC Send fernsteuern. 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. Meiner Idee steht also grundsätzlich erst einmal nichts im Weg.

Jetzt gilt es nur eine Schaltung zu entwickeln welche über einen bestimmten Zeitraum hinweg prüft, ob an einem Audio-Ausgang dauerhaft der Wert Null anliegt. Wenn dies der Fall ist sendet die Struktur ein Event an das IC Send-Modul, welches das entsprechende Switch-Modul umschaltet und somit die gewünschte Struktur deaktiviert.
Eingeschaltet wird diese Struktur dann entweder über ein ankommendes Gate-Signal (wenn es sich bspw. um einen OSC handelt) oder aber über ein eingehendes Audio-Signale (wenn es sich um einen Audio-Effekt handelt).

Klar beansprucht eine solche Schaltung auch die CPU, aber bei mittelgroßen und großen Schaltungen lohnt sich dies sicher. Des weiteren braucht man sich nicht mehr um das manuelle Aktivieren und Deaktivieren von Bereichen zu kümmern.


Wie gesagt, mehr als die Idee steht bis jetzt noch nicht, aber sobald ich erste Schaltungen entwickelt habe werde ich sie hier zur Verfügung stellen.

Gruß
128bpm

[herw]

Hi Community,

seit Anfang des Jahres beschäftige ich mich intensiv mit Reaktor. Ich will in den nächsten Jahren ein größeres Projekt mit vielen individuellen Soundmodulen umsetzen. Dabei war mir von Beginn an klar, dass die CPU-Auslastung zum Problem werden könnte und so kam mir die Idee, automatische Schalter zu integrieren. Aktuell bin ich leider noch nicht wirklich über die Idee hinaus, aber ich will mein Vorhaben hier trotzdem schon einmal vorstellen.

Mir ist in Reaktor nur ein Modul bekannt, welches in der Lage ist andere Module zu deaktivieren, so dass diese keine CPU-Last mehr erzeugen. Es handelt sich um das Switch-Modul aus der Primary-Ebene. Dieses Modul lässt sich über ein IC Send fernsteuern. 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. Meiner Idee steht also grundsätzlich erst einmal nichts im Weg.

Jetzt gilt es nur eine Schaltung zu entwickeln welche über einen bestimmten Zeitraum hinweg prüft, ob an einem Audio-Ausgang dauerhaft der Wert Null anliegt. Wenn dies der Fall ist sendet die Struktur ein Event an das IC Send-Modul, welches das entsprechende Switch-Modul umschaltet und somit die gewünschte Struktur deaktiviert.
Eingeschaltet wird diese Struktur dann entweder über ein ankommendes Gate-Signal (wenn es sich bspw. um einen OSC handelt) oder aber über ein eingehendes Audio-Signale (wenn es sich um einen Audio-Effekt handelt).

Klar beansprucht eine solche Schaltung auch die CPU, aber bei mittelgroßen und großen Schaltungen lohnt sich dies sicher. Des weiteren braucht man sich nicht mehr um das manuelle Aktivieren und Deaktivieren von Bereichen zu kümmern.


Wie gesagt, mehr als die Idee steht bis jetzt noch nicht, aber sobald ich erste Schaltungen entwickelt habe werde ich sie hier zur Verfügung stellen.

Gruß
128bpm

Ja das Sparen von CPU ist eine immer wieder auftauchende Idee. IC-Sends sind ein möglicher Ansatz, siehe zum Beispiel das Ensemble RUHR. Nur angeschlossene Module verbrauchen CPU-Last. Durch die IC-Send Steuerung eines Switches wird der Signalweg unterbrochen und belastet so die CPU nicht. In diesem Beispiel wird durch Anschluss oder Lösen einer Kabelverbindung auf dem Bildschirm mit Hilfe von IC-Send eine Datenleitung an- und ausgeschaltet. Das kann man auch sogar nur für benutzte Voices gestalten. Im englischen Forum hat dort vor einigen Jahren auch mal jemand so etwas vorgestellt, ich meine sogar schon zu Zeiten von REAKTOR 4. Mit IC-Send arbeite ich nicht mehr gerne, da sie einen unnötigen Bug haben, der große Projekte nervt. Beim Kopieren und Einfügen, also dem schnellen Ändern einer entsprechenden Struktur wird die Reihenfolge der einzelnen IC-Send-Einträge innerhalb und außerhalb von Makros unterschiedlich behandelt. Das heißt, größere Strukturen lassen sich nur umständlich pflegen.
Auf der Core-Ebene kann man einfach durch eine Logik die SampleRate-Clock für einzelne Makros unterbrechen. Das kann man sogar so gestalten, dass man auf einer Audioleitung nur einzelne Events durchlässt und sonst ausschaltet. Du findest entsprechende Module in der Core Library unter CLK Bundle zum Beispiel CLK Bundle/XR Gate. Das probiere ich seit einigen Jahren aus und klappt sehr komfortabel.

Letzten Endes habe ich die Erfahrung gemacht, dass sich nur in einfachem überschaubaren Rahmen, also mehr durch geschaltete Switches, sei es durch IC-Send oder Abschalten der Clock, CPU-Last sparen lässt. Dynamisch ist das eher Augenwischerei, da man bei Gebrauch der entsprechenden Datenleitung doch wieder die volle CPU-Last benötigt.
Übrigens es gibt noch andere Ausschaltmöglichkeiten, z.B. über Audiotables, wenn ich mich recht erinnere.
Ich verwende eigentlich mehr Zeit, um unnötige CPU-Last zu entdecken und dann entsprechend eine Struktur so zu verändern, dass sie generell sparsamer ist. Das bringt für meine Projekte mehr. Zum Beispiel könnte man darüber nachdenken, für bestimmte Bereiche (LFO, langsame Hüllkurven etc.) die ClockRate zu reduzieren. Im Ensemble Monark findest du einen solchen Ansatz im Makro Panel/Monark/Monark/Volt/Preaparation/Adept Smoth Clock:

REAKTOR Smoth Clocks.png

Daher mag ich zum Beipiel Projekte von Tim Exile überhaupt nicht. Seine Ensembles sind musikalisch immer sehr attraktiv, auch wenn sie für meinen persönlichen Geschmack nicht geeignet sind. Die CPU-Last dagegen ist furchtbar. Man glaubt, auf der ganzen musikalischen Welt gibt es nur seinen Supercomputer, der nur für seine Projekt da ist. Wenn ein Ensemble an die 80% geht, muss der Entwickler etwas falsch gemacht haben, oder muss die übernächste Prozessor-Generation abwarten. Naja das gehört vielleicht hier nicht her.

Vielleicht hast du ja noch neue Ideen, es wäre spannend, von deinen Versuchen und Ergebnissen zu hören. Kleine Testensembles bringen in dieser Hinsicht viel. Ich versuche nochmal, im englischen Forum den entsprechenden Thread zu finden, aber das wird nicht leicht.

[herw]

ah hab's doch schnell gefunden: I just figured out ... (by Jay Dizzle)

mal ganz kurz hineingeschaut in sein Ensemble (post #8): Er überprüft, ob in einer gate-Leitung für zum Beispiel eine Hüllkurve ein 0 Signal vorliegt:

REAKTOR SRC Gate Jay Dizzle.png

Da das Gate-Signal polyphon ist, funktioniert das Ganze für jede Voice.
Leider ist der Thread teilweise etwas kontrovers (auch noch zu meinen hitzigen Zeiten ), trotzdem interessant, die Einschätzungen anderer dazu zu lesen.

Nebenbei bemerkt, ist das Überprüfen auf Gleichheit (in diesem Fall 0) für Audioanwendungen problematisch.
Zum einen kann es ja in einer Audioanwendung durchaus sinnvoll sein, dass ein Signalwert über längere Zeit (mehrere Sampleticks) 0 ist und trotzdem andere events auslösen soll, zum Anderen erreichen manche Audiosignale den Wert 0 nie exakt (man denke an exponentiell fallende Hüllkurven), d.h. eine Abfrage auf Gleichheit 0 würde nie greifen, auch unter Umständen wegen der begrenzten Rechengenauigkeit unserer Computer.
Das hängt aber natürlich davon ab, welche Datenleitungen du unterbrechen möchtest und durch welche konkreten Events diese ausgelöst werden sollen. Du hattest in oberen Threadstart auch ein Gate-Event angeführt. Das ist also nach Jays Vorschlag auch ohne IC-Sends möglich.
Die Lösung von Jay Dizzle über polyphone Gatesignale ist sicherlich machbar. Ob es so viel bringt, müsste man jeweils testen.
Interessant ist auch das Datum des Threadstarts vom 26. Mai 2006, also ein Jahr nach der Veröffentlichung von REAKTOR 5, bald zwölf Jahre her.

[128bpm]

Wieder einmal danke für deine hilfreichen Beiträge. Wenn das so weiter geht erwähne ich dich noch in meinen Memoiren

Dieses WE schaff ich es wohl nicht mehr auf deine Beiträge einzugehen. Auch bin ich ja blutiger Anfänger, und so besteht meine Reaktor-Welt derzeit ausschließlich aus unzähligen Großbaustellen. Entsprechend werde ich wohl auch eher nach und nach, mit kleinen Häppchen daher kommen, als mit ausschweifenden Abhandlungen

Aber Ideen habe ich viele und das Ziel ist gesetzt.

In diesem Sinne, schönes Wochenende

[128bpm]

Ich habe ein wenig herum experimentiert. Leider ist Reaktor nicht so von meinem Vorhaben überzeugt


Der Aufbau sieht wie folgt aus:

Ein Gate-Event triggert sowohl eine Hüllkurve, als auch ein IC Send-Modul. Das IC Send-Modul schaltet darauf hin einen Switch ein, welcher einen OSC aktiviert.

Der AMP-Hüllkurven-Ausgang wird in dB umgerechnet und dann wird über ein Compare/Equal-Modul bestimmt ab welchem dB-Wert ein OFF-Event an das IC Send-Modul gesendet wird.

Das Gate-Signal und das OFF-Event aus der Hüllkurve werden in ein Merge-Modul geschickt und gelangen so beide in das IC Send-Modul.
Aber genau dieses Merge-Modul verträgt sich nicht mit der IC Send / Switch-Kombination. Reaktor verursacht bei einer solchen Konstellation in unregelmäßigen, unvorhersehbaren Intervallen CPU-Peaks welche zu Artefakten führen. Diese Peaks treten sogar dann auf, wenn das Switch-Modul gar nicht mit anderen Modulen verbunden ist.


Außerdem hat die Schaltung aktuell das Problem, dass manchmal Noten verschluckt werden.

[128bpm]

Ich konnte die Struktur noch etwas optimieren. In der Testphase der letzten 30 Minuten waren die CPU-Peaks mit dieser Schaltung nicht zu rekonstruieren, was aber noch nicht unbedingt etwas zu bedeuten hat.

Nach wie vor besteht jedoch das Problem, dass manchmal Noten verschluckt werden. In 95 % der der Fälle geschieht dies bei einer sehr kurzen Release-Zeit und sehr schnell gespielten Noten.

Die Frequenz des A to E Perm-Moduls habe ich drastisch reduziert, auf 0,5 Hz. Eine höhere Abtastung des OFF-Events ist gar nicht erforderlich. Im Gegenteil, die Schaltung funktioniert so besser.

[herw]

Ich habe ein wenig herum experimentiert. Leider ist Reaktor nicht so von meinem Vorhaben überzeugt


Der Aufbau sieht wie folgt aus:

Ein Gate-Event triggert sowohl eine Hüllkurve, als auch ein IC Send-Modul. Das IC Send-Modul schaltet darauf hin einen Switch ein, welcher einen OSC aktiviert.
[...]

Du hast in diesem Beispiel noch das Gate-Signal auch beim NoteOff auf 1 geschaltet. Dadurch wurde nochmals kurzfristig der Schalter geöffnet. Wahrscheinlich gab's beim NoteOff immer einen Knackser? Das hast du im zweiten Beispiel durch einen Separator gefiltert.
Hat es denn jetzt eine Verringerung der CPU-Last gebracht (Test mit der Einstellung auf 100 voices)?
Übrigens was für eine Art Peakser hast du denn gehabt? Diese einfache Schaltung kann keine CPU-Peakser verursachen, da wird ja fast nichts gebraucht. Oder waren es Knackser im Audiosignal?

PS: Du kannst übrigens die Bilder in den Text direkt einbinden. Dafür gibt es nach dem Hochladen einen kleinen Button, der das Bild an die aktuelle Schreibposition schiebt.
Damit Mit-Diskutierer keine Zeit zum Nachbauen verschwenden müssen, wäre es lieb, wenn du das Ensemble, wenn nötig, mit hoch lädst. Du musst es allerdings vorher komprimieren (zip-file). Es wird dann ans Ende deiner Post gestellt. Insbesondere ist nicht erkennbar, was du zum Beispiel im Makro AHDSR genau versteckt hast. Das Drumherum (Eingaben für die Envelope-Zeiten, Oszilloskop, oder ist es doch die Envelope-Primary-Anzeige?) müsste man dann noch extra Einbauen und verleitet andere nicht zum Mitdenken
Also: reduziere dein Ensemble zur Diskussion auf das Allernotwendigste und lade es hier hoch. Eine Fehlersuche ist übrigens auch beim eigenen Experimentieren das Ratsamste.

Beim Nachlesen deiner vorletzten Post fiel mir auf, dass du von verschluckten Noten sprichst. Womit spielst du die Noten ein: mit dem Computer-Keyboard oder einer Miditastatur, legato oder mit isolierten vollständigen Gate-Events; benutzt du im Envelope-Makro eine Corcell?

[128bpm]

Hi herw,

hier ist erst mal die verbugte Struktur. Der Switch ist nur über Internal Connections verbunden. Die Audio-Ein- und Ausgänge des Switch-Moduls liegen frei und doch kommt es zu Artefakten wenn eine Note angeschlagen wird. Das ist sehr seltsam.

Die Knackser kommen nicht von den Synth-Einstellungen, da die Sine-Wave immer mit Phase 0 startet.

Switch-Bug.jpg

cpu-switch Bug.zip

[128bpm]

Insbesondere ist nicht erkennbar, was du zum Beispiel im Makro AHDSR genau versteckt hast.

Da habe ich nichts versteckt, das ist die Standard-Env aus der Primary-Library: Library > LFO, Envelope > AHDSR

Beim Nachlesen deiner vorletzten Post fiel mir auf, dass du von verschluckten Noten sprichst. Womit spielst du die Noten ein: mit dem Computer-Keyboard oder einer Miditastatur, legato oder mit isolierten vollständigen Gate-Events; benutzt du im Envelope-Makro eine Corcell?

Ich spiele die Noten über eine MIDI-Tastatur ein. Das Phänomen des Notenverschluckens tritt regelmäßig beim schnellen nicht-legato-Spiel auf, wenn die Hüllkurven-Release-Phase sehr kurz ist. Dann kann man in der Struktur auch oft beobachten, dass der Switch aktiv ist, nicht aber der OSC...

Hier mal noch die letzte Version aus Post #6

cpu-switch V1.01.zip

[herw]

Insbesondere ist nicht erkennbar, was du zum Beispiel im Makro AHDSR genau versteckt hast.

Da habe ich nichts versteckt, das ist die Standard-Env aus der Primary-Library: Library > LFO, Envelope > AHDSR

Beim Nachlesen deiner vorletzten Post fiel mir auf, dass du von verschluckten Noten sprichst. Womit spielst du die Noten ein: mit dem Computer-Keyboard oder einer Miditastatur, legato oder mit isolierten vollständigen Gate-Events; benutzt du im Envelope-Makro eine Corcell?

Ich spiele die Noten über eine MIDI-Tastatur ein. Das Phänomen des Notenverschluckens tritt regelmäßig beim schnellen nicht-legato-Spiel auf, wenn die Hüllkurven-Release-Phase sehr kurz ist. Dann kann man in der Struktur auch oft beobachten, dass der Switch aktiv ist, nicht aber der OSC...

Hier mal noch die letzte Version aus Post #6

cpu-switch V1.01.zip

ok - ich habe mal etwas getestet. Zunächst lasse ich den Sinustongenerator durch NotePitch setzen, damit man etwas hört. Die Laptoplautsprecher bringen nämlich 50Hz nicht. Falls dich dann die Verstimmung stört (durch die Addition von 50Hz ist die Tonreihe nicht mehr rein), dann lösche einfach die Konstante 50Hz.

Bild 1.png

Dann habe ich im Envelope-Makro das einfache primary AHDSR-Modul gewählt, da die sehr komfortable Core-Version für eine oberflächliche Untersuchung etwas komplizierter zu behandeln ist, daher zunächst mal nur die grundsätzliche Funktionsweise.
Zunächst habe ich den Schalter überbrückt. Es gibt nämlich verschiedene Knacksgeräusche, die eine unterschiedliche Herkunft haben, daher zunächst mal der allereinfachste Fall.
Wenn man jetzt die Attackzeit auf ca. A=0.1ms setzt, dann H=0.1ms, D=1ms, R=0.1ms und (wichtig) Sustain auf 1, dann handelt es sich quasi nur um eine An-Aus-Hüllkurve geschaltet durch MidiGate.
Beim GateOn-hört man den Ton, beim GateOff deutlich ein Knacksen. Das rührt daher, dass die Schwingung des Oszillators abrupt auf Null gesetzt wird. D.h. es gibt einen Sprung vom aktuellen Oszillatorwert auf Null und das hört man als Knacksen.
Du kannst das mal mit Hilfe einess Rechteckoszillators gut hören:

Bild 2.png

Ich habe hier den Pitcheingang auf -300 gesetzt. Damit schwingt der Oszillator innerhalb der Rechengenauigkeit des Programms mit annähernd 0Hz. Der Eingang f mit hier 1Hz gibt also ziemlich genau die Schwingungsfrequenz vor. Wenn du genau hinhörst, dann wirst du feststellen, dass das erste Knacksen etwas leiser ist; der Sprung ist durch die Synchronisation ja auch nur halb so groß von 0 auf +1.
Wenn man nun eine Taste drückt, hört man deutlich das „Schwingen” durch ein Knacksen beim Wechsel von -1 zu +1 und umgekehrt. Ab etwa 25Hz erkennt unser Ohr das als Brummton an. Wir halten also fest: ein abrupter Schwingungsprung erzeugt ein Knacksen.
Eine einfache Hüllkurve mit sehr kurzer Releasephase und noch bestehender Amplitude erzeugt beim Loslassen der Taste immer einen Knackser. Verändere nun mal die Attackzeit auf ca. 400ms, die Decayzeit auf 2ms und Sustain auf Null. Du hörst das Anschwellen des Tons und dann den schnellen Abfall durch die Decayzeit. Bei 2ms akzeptiere ich das als keinen Knackser mehr sondern schon als „Ausklang”. D.h. man benötigt eine vernünftige Ein- und Ausschwingzeit. Bei stark verzerrten Klängen wird man dagegen diesen Knackser nicht hören, da das eigentliche Audiosignal schon kratzig genug klingt und man den Knackser gar nicht bemerkt. Bei einem Sinuston ist das schon deutlich hörbar.

Es ist schon spät (23:00Uhr) und ich hatte heute Nachmittag eine anstrengende Bandprobe, so dass ich morgen weiter schreibe.
Fall du aber ungeduldig bist, dann lasse das Audiosignal wieder über den Switch laufen. Mit A≈400ms und R≈2.7ms und Sustain S=1 kannst du aber vielleicht schon die zeitweiligen Aussetzer erklären. Allerdings solltest den ACEW einbauen. Er registriert das Ein- und Ausschalten. Du wirst auch dann manchmal Aussetzer bemerken. Wenn du den Sinustonoszillaotr durch den Rechteckoszillator ersetzt, wird die Ursache hoffentlich klar.

Bild 3.png

[128bpm]

Hi herw,

ja, dass schnelle Hüllkurven Knackser verursachen weiß ich, aber die Artefakte die ich in diesem Fall meine stammen nicht von der Hüllkurve. Probier mal das Ensemble cpu-switch Bug aus. Der Switch verursacht Artefakte ohne dass seine Audio-Ein- und Ausgänge verbunden sind. Trennt man die IC Send-Verbindung verschwinden diese Knackser.

Ich werde mir mit diesem Switch wohl nicht mehr einig und habe für mich jetzt auch entschieden all meine Schaltungen ausschließlich über Core zu entwickeln. Die Primary-Ebene nutze ich nur noch für das GUI und die Zusammenführung der Core-Zellen.

Dein Verweis auf den SR.C-Router ist dabei Gold wert!! Vielen Dank nochmals für den Link!

[herw]

Ja und jetzt geht es an's Eingemachte.
Ich habe dein Beispielensemble mal sehr stark vereinfacht, damit man den Blick auf das Wesentliche nicht verliert. Und da du mit gutem Beispiel vorangegangen bist und das passende Ensemble hoch geladen hast, mache ich es genauso natürlich mit dem Hintergedanken, dass Andere die Analyse ohne großen Aufwand nachvollziehen können.

cpu-switch V1.01 herw3 Aussetzer.ens.zip

Ich beschreibe mal nur den Inhalt:

Bild 4.png

Ich habe zunächst den Siunsoszillator durch einen Rechteckoszillator ersetzt und die Tonhöhe wird durch das MidiPitch-Modul bestimmt. Als Hüllkurvengenrator habe ich direkt den Primary AHDSR-Generator gewählt mit den passenden Reglern für die Phasenzeiten und den Sustain. Ich habe keine Umrechnung in Millisekunden durchgeführt, da es hier im Wesentlichen nur um kurz oder lang geht.
In den Properties des Hüllkurvengenerators findet man die Erklärung der logarithmischen Skala. Für die mitlesenden Neueinsteiger: Fährt man mit der Maus über die Eingänge bekommt man ein Kontextmenu:

Bild 5.png

Ich habe den Reglerbereich noch etwas erweitert; der Startwert -20 bedeutet also eine Zeit von 0,1ms.
Die gesamte Struktur habe ich in ein Instrument gepackt, so wie es das Handbuch vorsieht.

Dann habe ich noch Marks ACEW als Analysemodul und oben eine geheimnisvolle unsichtbare numerische Anzeige ergänzt.

[herw]

Es gibt drei wichtige Funktionsteile in der Schaltung (sorry 128bpm, ich ergänze das mal für diejenigen „Faulen” die den Thread nicht von vorne verfolgen wollen.):

• orange : Ein IC-send ist mit dem Switch gekoppelt, so dass dieser ferngeschaltet werden kann.
• blau: Das Steuersignal des IC-send erfolgt vom Merge-modul und einem Stepfilter
• grün: Ein AtoE Perm fragt alle 2 Sekunden den Ausgabewert der Hüllkurve ab und gibt beim Vergleich mit -120db=1·10^-6 den evntuellen Ausschaltbefehl an das IC-Send und damit an den Switch weiter.
  Über das Merge-Modul wird der der Schalter durch einen GateOn-Event wieder umgestellt.

Gleich beim Start des Ensembles bemerkt man, dass die Abfrage ständig läuft und alle zwei Sekunden einen (logischen) Vergleichswert ausgibt. Hier sieht man sehr schön, dass die Anzeige „Env” bei der Analyse völlig wertlos ist, da sie zwar eine Änderung angibt, jedoch die eigentlichen Events verbirgt. Wer will, kann ja mal die Frequenz der Abfrage auf 100Hz erhöhen, um zu sehen, dass auch der Buffer des ACEW in 10 Sekunden vollläuft und die Anzeige bei 1024 Einträgen endet. Naja, wer will schon 1024 Werte einsehen? Also bitte wieder auf 0,5Hz zurücksetzen und RstAll drücken, damit der Buffer wieder leer ist jund wir mehr als sechs Minuten Zeit haben
.

[128bpm]

Bei deiner Modifikation muss man das NotePitch-Modul noch mit einem Numeric-Readout, welches "Always Active" ist, verbinden. Andernfalls wird das NotePitch-Modul nicht immer rechtzeitig aktiviert und am P-Eingang des OSCs liegt der Wert 0 an.

[herw]

Bei deiner Modifikation muss man das NotePitch-Modul noch mit einem Numeric-Readout, welches "Always Active" ist, verbinden. Andernfalls wird das NotePitch-Modul nicht immer rechtzeitig aktiviert und am P-Eingang des OSCs liegt der Wert 0 an.

gut erkannt, aber der Begriff „rechtzeitig” ist falsch. Genau darauf wollte ich hinaus.
Für die Anderen: Man aktiviert im Menu Options/Debug Structure Enable Wire Debugging und schaut sich mit der Maus die Verbindung zwischen NotePitch und dem Oszillator an. Da beim Tastendruck zunächst der Schalter geöffnet wird, gibt es einen re-init, das den letzten Wert des NotePitch an den Oszillator sendet, der mit etwa 8Hz vor sich hin knattert (P=0 entspricht ca. 8Hz). Der Anschluss einer numerischen Anzeige an NotePitch stellt dagegen sicher, dass bei einem eintreffenden Gate-Event der Schalter geöffnet wird und somit der Oszillator aktiviert ist. Das funktioniert aber nicht immer!

Bild 7.png

Beispiel: Setze A=H=R=-20, D=40 und S=0. Drücke nun eine Taste auf dem Keyboard (es geht auch mit der QWERTZ-Tastatur z.B. Q) und halte den Ton gedrückt. Nach gut zwei Sekunden wird der Oszillator deaktiviert und wird ausgeschaltet. Lass umgehend Q los und drücke es erneut. Man hört nichts und der Oszillator bleibt deaktiviert. D.h. es gibt trotzdem einen Aussetzer.
Erst, wenn man die Taste etwas länger ungedrückt hält und dann wieder Q drückt, gibt es wieder einen Ton.
D.h. die Ursache der Aussetzer ist wo anders zu suchen, nämlich beim Step-Filter.

Übrigens wirst du bemerkt haben, dass das primary A to E Perm - Modul immer einige Samplesticks hinterherhinkt, also nicht exakt im zwei-Sekunden-Takt arbeitet, sondern einige Samples länger.
Eine entsprechende Core-Cell ist dagegen exakt:

Bild 8.png

Bild 9.png