LINEARE STEUERKURVEN

[Rampensau]

schön nachvollziehbar. Ich bin noch einen Schritt weitergegangen, und habe Fehlbedienung ausgeschlossen. Somit sind nun Startpunkte möglich, die kleiner als der Endpunkt sind.

AkleinerB.JPG

Das habe ich mal in die Datei "Decay-04mod.ens" eingepflanzt, aber ich wette, du hast ne schlankere Lösung dafür.

Außerdem habe ich mich nochmal über die Anzeige hergemacht. Es zählt jetzt genau den Bereich ab, der in die Table geschrieben wird. Im Ensemble "Decay-04mod.ens" zählt es bis 882, bei einer Erhöhung von 0.001pro Tick. Im Ensemble "Modifikation2.ens" zählt es bis 441, bei einer Erhöhung von 0.0005 pro Tick.
Weitere Mods in "Modifikation2.ens":

Mod2.JPG

- weitere Anzeige für die Anschlagsstärke
- Die Umrechnung zum Anteil für die Anschlagsstärke musste ich komplett umkrempeln. Man kann die Anschlaggstärke also komplett umdrehen, ausschalten oder so lassen wie sie ist! Meine vorherige Lösung war irgendwie Quatsch!
- getrennte Umschalter für die Anschlagsschlagsabhängigkeit der Zeit und Amplitude.
- KeyOn-Umschalter: Die Steuerkurve ist nur "aktiv", solange Gate gehalten wird. (so verhält sich jedenfalls die Primary-Decay-Kurve, irgendwas haben die sich bestimmt dabei gedacht)
- Die Dauer der Steuerkurve erweitert auf 31 Sekunden (nur zur Deckung meines eigenen Bedarfes)

Die beiden Ensembles kann man hier laden

[herw]

[...]
- KeyOn-Umschalter: Die Steuerkurve ist nur "aktiv", solange Gate gehalten wird. (so verhält sich jedenfalls die Primary-Decay-Kurve, irgendwas haben die sich bestimmt dabei gedacht)
[...]

das ist nicht immer sinnvoll, zum Beispiel, wenn die Steuerkurve von einem Sequenzer getriggert wird. Hier würde ich meine Lösung vorziehen.
Die Universalität der Decay-Kurve für abfallende und ansteigende Kurven, habe ich mir ganz ähnlich vorgestellt; heute war allerdings Gartenarbeit angesagt, insofern bist Du mir zuvorgekommen
Deine Lösung ist aber einfach und zweckmäßig, auch raffiniert, indem du A und B in ihrer Bedeutung (niedrigster, höchster Wert) vertauschst. Die Abbruchbedingung lässt Du unangetastet und multiplizierst am Ausgang mit dem +/- Faktor. Das gefällt mir allerdings nicht im Hinblick auf die geplante Erweiterbarkeit; ein Vertauschen der Parameter A und B zieht dann zusätzliche Abfragen mit sich. Das kannst du aber nicht vorhersehen; mein Konzept mit mehreren Phasen entwickle ich wahrscheinlich morgen. Im Kopf habe ich das ganze schon.

ciao herw

[herw]

Übrigens fällt mir auf, dass die Umlaute in deinem Bildschirmausdruck durch Fragezeichen ersetzt sind (z.B. beim Makro „Änderungsrate” ; ich habe mein Ensemble mit dem Mac erstellt; sind die Zeichensätze in der Reaktordarstellung nicht kompatibel?

[Rampensau]

Übrigens fällt mir auf, dass die Umlaute in deinem Bildschirmausdruck durch Fragezeichen ersetzt sind (z.B. beim Makro „Änderungsrate” ; ich habe mein Ensemble mit dem Mac erstellt; sind die Zeichensätze in der Reaktordarstellung nicht kompatibel?

Sie kommen bei mir jedenfalls schon als Fragezeichen an. Ich ändere die Zeichen mal manuell und lade das Ensemble nochmal hoch. Dann wissen wir, ob beim Mac wenigstens die Win-Zeichensätze dargestellt werden.

Das mit der Erweiterung habe ich mir letzte Nacht noch einfacher vorgestellt. Bin zwar teilweise zum Ziel gekommen, aber die Struktur war danach ein Graus und richtig funktioniert, hat das nicht. Jetzt bin ich echt gespannt, wie du das lösen wirst.

Aber ich bin auf ne coole Idee gekommen, wie ich den Breakpoint-Phasen-Oszillator (Casio CZ-Serie) ressourcenfreundlicher als in meiner jetzigen Version verwirkliche... Soon

[herw]

Decay 22.jpg

Um auch eine ansteigende Steuerkurve zu kontrollieren, habe ich die Abbruchbedingung des Rampenloops erweitert.

Decay 23.jpg

Deine Lösung ist ähnlich und auch elegant; wie ich oben schon erwähnte, möchte ich meine Abbruchbedingung auch für exponentielle Kurven benutzen, daher habe ich die Ausgabe des Speichers nicht durch eine Multiplikation verändert.
Ich unterscheide die beiden Fälle aufsteigend/absteigend durch das Vorzeichen der schon berechneten Änderungsrate d. Davon abhängig unterschreitet (fallende Kurve) bzw. überschreitet (steigende Kurve) der Speicher irgendwann einmal den Endwert B bzw. B'=Trg·B und bricht so die Rampe ab.

Decay 24.jpg

Hier ist das Ensemble

Decay-05.ens.zip

Ich habe übrigens die Anzeige der AudioTable nach deinen Vorschlägen geändert; d.h. man muss jetzt nicht mehr die Properties ändern.
Man kann sich die logische Verneinung ersparen, aber ich wollte dieses Modul einfach mal verwenden.

Decay 25.jpg

ciao herw

[herw]

Im Prinzip könnte man mit zwei solcher Module eine mehrphasige Steuerkurve konstruieren:
Durch einen GateOn-Event erzeugt man eine steigende Rampe, die am Ausgang durch eine stückweise lineare Funktion eine Umrechnung vornimmt; durch den GateOff-Event kann man nun eine weitere Rampe starten und wiederum durch eine stückweise lineare Funktion beenden.
Überträgt man dieses Verfahren auf andere Kurvenformen, dann wird die Berechnung (pro Sample-Tick) immer Rechenpower-intensiver, z.B. bei exponentiellem Verlauf. Der Anschluss an verschiedene Kurvenformen muss umständlich berechnet werden, damit es eine stetige Funktion (ohne Sprung) gibt.
Daher wähle ich nicht diesen Weg.
Vielmehr verwende ich ein ähnliches Verfahren, wie das ADSR-Core-Makro:
Alle Phasen der Steuerkurve benutzen mehrere Speicher gemeinsam, zunächst mal ähnlich wie in unserer Decaykurve einen Speicher für den momentanen Ausgabewert (hier im Makro loop). Da ich ein universelles Makro schaffen möchte, muss ich Startwert A und Zielwert B verwalten, ebenso die Änderungsphase.
Damit diese Parameterspeicher zur passenden Phase gewählt werden, erhält jede Phase eine Nummer. Ist eine Phase beendet, so werden durch einen Event die Parameter der nächsten Phase geladen und die neue Rampe startet. Die erste Phase wird durch den GateOn-Event in Gang gesetzt; danach folgen beliebig viele Phasen, bis durch den GateOff-Befehl der zweite Teil mit beliebig vielen Phasen die Steuerkurve beendet. Das ADSR-Modul in Core funktioniert im Prinzip ähnlich, nur dass hier die Zahl der Phasen auf Attack (linear), Decay (exponentiell fallend) und Release (exponentiell fallend) beschränkt sind. Außerdem kann der ADSR-Generator nur positive Werte annehmen.

Decay 26.jpg

Das Prinzip werde ich zunächst an einer linearen Attack-Release-Kurve zeigen:

Decay 27.jpg

[herw]

ON-Phasen und OFF-Phasen

Eine Steuerkurve wird in der Regel durch zwei (Teil-) Events gesteuert, zum Beispiel einem Gate-Event: es gibt eine ON-Phase (Gate>0) und eine OFF-Phase (Gate=0).
Steuerkurven lassen sich nun durch diese beiden Basis-Events starten und ausschalten, wobei starten und ausschalten nicht nur als linearer Ablauf gedacht, sondern durchaus mehrere verschiedene Phasen mit automatischem Ablauf erzeugen können.
Wie schon erwähnt, wollen wir uns aber zunächst an diesen einfachsten Fall zweier Phasen heranwagen.
Der grobe Aufbau wird nun erweitert; die Bedien- und Ableseelemente werden auf der primary-Ebene erfasst, die Verarbeitung der Daten erfolgt wieder ausschließlich in der core-Ebene.


L1_L2-01.jpg

L1_L2-02.jpg

Beide Phasen erhalten ein Start- und ein Ziellevel. Normalerweise sind dabei das Ziellevel L1B der ersten Phase und das Startlevel L2A der zweiten Phase identisch. Ich habe hier (etwas luxuriös) für beide Phasen L1B und L2A angegeben.
T1 und T2 geben jeweils die Zeitdauer der Phasen an.

[herw]

Ich habe die Panelelemente doch noch vereinfacht; es war etwas lästig, jeweils gleiche End- und Startlevel der beiden aufeinander folgenden Phasen einzustellen. Daher habe ich mich an den Mehrfach-Ramp-Envelopes der primary-Ebene orientiert und jeweils nur die Ziellevel einstellbar gemacht:

2-ramp-env01.jpg

Obwohl mir der prinzipielle Aufbau vom ADSR-Modul her bekannt ist, habe ich doch in den letzten Tagen meine Mühe gehabt, alle Trigger-Events und clocks richtig anzuordnen.
Manchmal denkt man auch einfach falsch.

Wie in den obigen Posts beschrieben, gibt es unterschiedliche Auffassungen über die Laufzeit einer Phase: umfasst die Laufzeit die Zeit, die für ein Werte-Intervall von A nach B ablaufen soll? Geht die Velocity ein oder soll die Zeit immer gleich sein auch bei unterschiedlichen Velocity-Werten.
Soll es einen Unterschied machen, ob das Intervall von A nach B klein oder groß ist oder soll die Zeit auf ein Intervall von 0 bis 1 zum Beispiel genormt sein?
Am Ende habe ich mich entschlossen, wie ein unbefangener Nutzer zu denken (das ist eigentlich immer richtig):

Die Steuerkurve soll stückweise linear sein. Man stellt das jeweilige Ziellevel ein und startet beim Ziellevel der vorangegangen Phase. Darauf bezieht sich auch die Zeitrechnung. Die Velocity wirkt auf alle Ziellevel, also beeinflusst (verkürzt) sie auch die jeweilige Laufzeit.

Ohne eine klare Zielgebung verzettelt man sich in ständig wechselnden Varianten, insbesondere dann, wenn das Makro noch nicht richtig funktioniert.
An der obigen Abbildung kann man erkennen, dass es nun funktioniert.

[herw]

Schauen wir mal ins Innere des 2-ramp-env core-Makros:

2-ramp-env02.jpg

Eine klare Gliederung in vier Makros, deren Aufgabe klar scheint. Verwirrend sind auf den ersten Blick für ungewohnte REAKTOR-Programmierer die vielen Latch-Ein- und Ausgänge.
Kaum ein anderes Modul aus der Standard-Library von REAKTOR benutzt dermaßen viele gemeinsame Speicher wie das ADSR-Modul.
Wagt man sich einmal hinein, erkennt man, wie schön einfach ein von mehreren Modulen gemeinsam benutzter Speicher ist.

Die Aufgabe des obersten Makros ist klar: es stellt die aus einem Gate-Event ermittelten Werte zur Verfügung, die Anschlagsdynamik (VelocityOn-Wert, den GateOn- und den GateOff-Event.
GateOn und GateOff-Events werden zum Start der beiden Phasen benötigt und dienen nur als Trigger. Die Velocity wird bei der Berechnung von Zeitintervallen benötigt; so weit so gut.
Nun zum wichtigsten Makro, dem loop.

2-ramp-env03.jpg

Warum ein loop? Nun in ihm werden im Wesentlichen die momentanen Ausgabewerte (val) der Steuerkurve gespeichert (gelbe Rahmen) und weiterverarbeitet (Aufaddieren der Änderungsrate d, blauer Rahmen). Das Makro EoP (end of phase, grüner Rahmen) beendet den Loop und gibt den Zielwert B an den Speicher.
Typisch für diesen Loop und alle Audio-verarbeitenden CoreCells ist die Taktung durch die SampleRate-Clock SR-C. Sie stellt sicher, dass alle Berechnungen (logisch) zeitgleich
ablaufen. Bei meinen Versuchen habe ich versehentlich Zielwert und d nur durch einen Gatetrigger getaktet und habe mich gewundert, dass der Loop nie ans Laufen kam.
Die Reihenfolge der Abbruchbedingung und der Zuweisung der neuen Änderungsrate traten in vertauschter Reihenfolge auf (bedingt durch die Steuerung von außen, so dass die Abbruchbedingung immer erfüllt war.
Alle Parameter (hier Änderungsrate d und Zielwert B) müssen vor dem SampleRate-Tick zur Verfügung stehen und werden erst dann gleichzeitig weiterverarbeitet, ein wichtiger Fehler, der von mir trotz einiger Erfahrung in der Eventverarbeitung doch volle Aufmerksamkeit fordert.
Ein Blick noch in das Makro EoP:

2-ramp-env04.jpg

Es fragt ab, ob es sich um eine steigende oder fallende Steuerkurve handelt (d>0 steigend, d<0 fallend) und ob der Zielwert B erreicht wurde. In einer ersten Version habe ich beide Kriterien nacheinander abgefragt, bis ich bemerkte, dass man sie zu einer Abfrage zusammenfassen kann, indem ich nach der Differenz des aktuellen Wertes (val) zum Zielwert B frage. Bei einer steigenden Steuerkurve (d>0) wird der loop weitergeführt, solange der aktuelle Wert val kleiner als der Zielwert B ist, also die Differenz val-B negativ ist; bei einer fallenden Steuerkurve dagegen ist d<0 und der loop wird weitergeführt, solange der aktuelle Wert val größer als der Zielwert B ist, also die Differenz val-B positiv ist. Das Produkt von d und val-B ist, solange der loop laufen soll, also immer negativ oder 0 (falls zufälligerweise val exakt B trifft). val wird an den Ausgang X übergeben.
Sobald der Zielwert - in welcher Richtung auch immer - überschritten wird, wird der Wert val an den Ausgang B gegeben und in der Schleife exakt auf B gesetzt.
Zu beachten ist, dass die Signum-Funktion nur für positive Werte +1 liefert während sie sonst -1 ausgibt. Die CoreMakro-Beschreibung ist da nicht ganz korrekt (siehe im Unterforum Kernschmelze).

Machen wir nochmals einen kurzen Abstecher in das ADSR-Makro:

2-ramp-env05.jpg

Ich habe die entsprechenden Bestandteile mit der gleichen Farbe gekennzeichnet.
Die Änderungsrate heißt dort b (blaue Rahmen, der Parameter a ist der Faktor, den man bei exponentiellem Verlauf als Wachstumsfaktor berücksichtigt). Die Abfrage ist etwas anders gestaltet (Überschreiten eines Wertes t), was wegen der Gestalt der ADSR-Kurve (nur nicht-negative Werte) vorgegeben ist. Auch hier erkennt man die gemeinsame Clock C (SR-C. wurde von außerhalb eingebunden).

[herw]

Nun zu den Makros Phase 1 und Phase 0.

2-ramp-env06.jpg

Beide sind identisch aufgebaut, erhalten nur andere Parameterwerte.
Im Innern passiert nicht viel:

2-ramp-env07.jpg

Aus der eingestellten Zeit T und den Start- und Zielwerten A und B wird die Änderungsrate d berechnet, wie auch schon in eine der ersten Posts erwähnt.
Er wird wie auch die Werte A und B in die gemeinsamen Speicher mit dem Trigger GateOn bzw. GateOff eingetragen. Die Anschlagsabhängigkeit wirkt sich nur auf die gespeicherten Start- und Zielwerte aus nicht auf die Änderungsrate. Dies erscheint mir „natürlich”.
Mit dem GateOn-Event werden durch das Modul Phase 1 die entsprechenden Werte für den Loop erreichbar. Beim GateOff-Event entsprechend die des Moduls Phase 0.
Damit ist unsere einfache 2-ramp-env-Steuerkurve lauffähig.
Mit verschiedenen Start- und Zielwerten lassen sich auch andere Steuerkurven erstellen:

2-ramp-env08.jpg

Hier ist das zugehörige Ensemble:

2-Ramp-env-1.ens.zip

[herw]

das Ziel ist ereicht: es gab viele kleine Probleme zu lösen, aber nicht unlösbar.

multi-Ramp-env-01.jpg

[herw]

Im letzten Abschnitt soll nun die angestrebte lineare Steuerkurve mit acht Phasen erstellt werden. Ich orientiere mich da an der Casio-CZ5000-Steuerkurve. Ich definiere allerdings für die GateOn-Phase und die GateOff-Phase jeweils vier Abschnitte, insgesamt also acht Phasen. Das Konzept ist aber so gestaltet, dass jeder sehr leicht die Anzahl jeweils variieren kann.
Das Hauptmodul, nämlich der loop bleibt wie er ist: es wird eine Änderungsrate addiert, bis ein bestimmter Zielwert über- oder unterschritten wird. Alle Phasen müssen einen ständigen Zugriff auf den aktuellen Ausgabewert haben, um einen Anschlusswert beim Start der Phase festlegen zu können.
Die Phasen aus dem letzten Beispielensemble werden nun in ihren Zugriffsmöglichkeiten präzisiert. Wichtig war mir, dass alle Phasen auf dasselbe Makro zurückgreifen; dadurch ist es ein leichtes, noch mehr Phasen einzubauen:

multi-Ramp-env-02.jpg

Ich habe hier einige der Makros ausgeblendet, man muss sich also acht solcher Makros nebeneinander vorstellen.

[herw]

Im Ensemble hat sich vom Aufbau her nichts geändert, es sind lediglich mehr Eingangsparameter hinzugekommen. Jede Phase erhält nur noch die Zeitdauer und das Ziellevel als Parameter.

multi-Ramp-env-03.jpg

Persönlich ärgerlich finde ich bei solchen Parameterübergaben die Vielzahl der Eingänge. Ein Eventbus wäre hier viel praktischer, und zwar einer, der alle (!) Panelparameter über eine Leitung an die CoreCells übergibt. Ich habe das zwar schon mal prinzipiell gelöst, es ist aber trotzdem nicht wirklich elegant. Ich hoffe da auf REAKTOR 6, dass NI sich etwas einfallen lässt (addressierte Parameter). Da es sich hier „nur” um 16 Parameter handelt, habe ich den Einbau mal weggelassen. In einer öffentlichen Version in der User-Library würde ich einen Eventbus anlegen wollen.

[herw]

Zu den Parametern jeder Phase müssen nur noch Trigger-Events zugeführt werden: GateOn zum Starten der ersten vier Phasen, GateOff zum Starten der vier nächsten Phasen; der Parmeter velocity? legt nur fest, ob die Steuerkurve anschlagsabhängig sein soll oder nicht; die Amplitude wird mit der velocity multipliziert.
nun zum Phasenmodul:

multi-Ramp-env-04.jpg

Im Gegensatz zu den Phasen des letzten Ensembles gibt es zusätzlich noch einen gemeinsamen Speicher: phase. Hier wird die Nummer der aktuellen Phase gespeichert. Dies ist notwendig, um eine Abbruchbedingung durch einen Trigger zu ergänzen. Immer dann, wenn der Endwert der aktuellen Phase erreicht ist (der loop stellt dies durch Wertzuweisung sicher), wird die Phasennummer geändert und ein Starttrigger für die nächste Phase gesetzt. Die Phasen, die nach den GateOff-Event folgen, werden rückwärts gezählt, in unserem Fall von 4 bis 1; die Phasen, die durch den GateOff-Event gestartet werden von -4 bis -1. Beide Phasenreihen enden mit der Nummer 0.
Ob das praktisch ist oder man auch einfach von 1 bis 8 durchzählt, weiß ich noch nicht. Irgendwie habe ich das Gefühl, dass man das mal ausnutzen könnte. Entscheidend ist aber lediglich, dass jede Phase eindeutig identifizierbar ist.
In NI's ADSR-Modul gibt es einen ähnlichen Ansatz, hier heißt der gemeinsame Speicher s (Status?); die Attackphase hat die Nummer 2, Decay 1 und Release 0.

multi-Ramp-env-05.jpg

Die Übergabe von der Attack- zur Decayphase erfolgt hier aber durch einen Trigger im loop. Das ist bei mehreren Phasen, wie in unserem Beispiel, meiner Ansicht nach nicht sinnvoll. Aber ich möchte hier nicht darauf weiter eingehen.

[herw]

Schauen wir uns nun ein Makro phase an:

multi-Ramp-env-06.jpg

auffällig sind die vier gemeinsamen Speicher d (Änderungsrate), B (Zielwert), val (momentaner Ausgabewert) und phase (aktuelle Phasennummer).
Die Änderungsphase wird wie auch schon in den früheren Versionen aus dem Anfangswert A, dem Zielwert B und der Zeitdauer T berechnet. Die Anschlagsabhängigkeit wird über den velocity-Wert vel berücksichtigt. Im Gegensatz zu den vorangegangenen Versionen wird als Startwert A der Zielwert der vorangegangenen Phase übernommen (read-Modul am latch-Eingang val). Abhängig vom Trigger-Event trg werden den Speichern d, B und phase die neuen Werte zugewiesen; d wird berechnet, B bzw. B' liegt als anschlagsabhängiger Wert vor und die Phase phase wird als Konstante von außen eingespeist.
Das ist einleuchtend und einfach.
Die Hauptsache passiert dann wohl im Modul set next phase. Der Name sagt alles: es wird der Trigger-Event für die folgende Phase ermittelt.

multi-Ramp-env-07.jpg

Im Wesentlichen wird durch ein AND-Modul abgefragt, ob die Phase überhaupt reagieren soll und ob der Zielwert B' mit dem aktuellen Wert schon übereinstimmt. Ist die Bedingung erfüllt, ist die Phase abgeschlossen. Damit kann der Speicher phase um 1 erniedrigt (in den Release-Phasen um 1 erhöht) werden und ein Trigger-Event an die nachfolgende Phase übergeben werden.
Das ist (fast) alles.

Steve Jobs würde noch sagen: „one more thing”.
Es gibt einen kleinen Knackpunkt in der Abfrage, nämlich dann, wenn der aktuelle Wert val und der Zielwert B' identisch sind. Dann würde die Phase sofort zur nächsten übergehen. Das ist aber nicht der Sinn einer solchen Steuerkurve.
Daher habe ich noch ein kleines Modul eingebaut:

multi-Ramp-env-08.jpg

Es fragt ab, ob Startwert und Zielwert übereinstimmen und addiert zum Startwert einen kleinen Wert, so dass die Schleife trotzdem läuft. Der Wert 0,005 ist so klein, dass es für Steuersignale sicherlich keine hörbaren Änderungen gibt. Ich gebe aber zu, dass es ein Kompromiss ist. Ich kann mir auch eine exakte Lösung vorstellen; das würde aber den Rahmen sprengen und habe ich deshalb hier nicht aufgenommen.

Ja damit ist alles erreicht, es fehlt nur noch das Ensemble:

multi-Ramp-gen.ens.zip