LINEARE STEUERKURVEN

[herw]

Ziele und Überblick

Ziel dieses kleinen Projektes ist es, sich an lineare Steuerkurven heranzutasten.

Ich möchte mich dabei auf lineare Steuerkurven beschränken, damit dieses Projekt möglichst einfach ist und jedem Anfänger wie auch Fortgeschrittenen die Gelegenheit bietet, eigene Ideen daraus zu entwickeln. Da ich ja sehr häufig hier im Forum anzutreffen bin, sind Anregungen und Fragen ausdrücklich erwünscht. Ich gehe hier bewusst auf einige Details nicht tiefer ein, in der Hoffnung, dass Interesse an weiteren Informationen besteht, die ich dann auch gerne beantworten oder diskutieren werde.
Ich möchte dieses Projekt bis auf die Bedienelemente auf die Core-Ebene beschränken. Wer sich unsicher in Core fühlt, sollte sich nicht scheuen, Fragen zu stellen.

Unter linearen Steuerkurven stelle ich mir speziell einerseits die bekannten Hüllkurven der YAMAHA DX-Serie vor:

Bild01.jpg

wie auch die Rampengeneratoren aus dem primary-Level von REAKTOR 5:

Bild02.jpg

Bild03.jpg

Das erste Zwischenziel dieses Projektes ist die Erstellung einer linearen Decay-Kurve:

Bild04.jpg

[herw]

lineare Decay-Kurve
Um mit dem Thema vertraut zu werden, soll im Folgenden die allereinfachste Form einer Steuerkurve erstellt werden: eine lineare Decay-Kuve.

Decay 01.jpg

Sie besteht aus einem linearen Verlauf, der mit dem Wert 1 startet und nach einer Zeit T bei 0 endet. Die Steuer-Kurve soll durch einen Trigger gestartet werden.
In REAKTOR benötige ich ein Triggersignal Trg z.B. von einem Midibefehl wie VelocityOn oder von einem LFO. Der Ablauf erfolgt dann in einer AudioCoreCell und schließlich die Ausgabe an ein Anzeigemodul. Die Decay-Zeit T soll einstellbar sein. Somit erhalte ich folgende Grobstruktur:

Decay 02.jpg

Das Triggermodul auf Primary-Ebene enthält lediglich einen logarithmischen Regler für die Decay-Zeiten und das Midi-Modul VelocityOn, das das Triggersignal liefert.

Decay 03.jpg

Die Anzeige besteht im Wesentlichen aus einer Audio-Table und zeigt den Verlauf an.
Zum Einstellen geeigneter Zeitdauern für Hüllkurvenphasen ist eine logarithmische Zeitwertsteuerung wesentlich praxisgerechter. Der Wertebereich von -20 bis +80 entspricht einem Zeitbereich von 0,1ms bis 10s.
Die Umrechnungsformel für den Zeitwert z in die Zeit t in Sekunden lautet

Decay 04.jpg

[herw]

Nun zur AudioCoreCell: ein linearer Verlauf wird durch eine Änderungsrate beschrieben, also einem (sehr kleinen) Summanden, der bei jedem SampleRate-Tick zum aktuellen Wert diese Änderungsrate addiert. Da wir einen fallenden Verlauf haben, ist die Änderungsrate negativ.
Damit die Kurve schließlich nach der Zeit T (in Sekunden) bei Null anlangt, muss man die Anzahl der SampleRate-Ticks berechnen. Für die SampleRateRate (SR.R) von z.B. 44100 ist die Änderungsrate also

Decay 06.jpg

.
Will man Sonderwünsche und zukünftige Entwicklungen berücksichtigen, greift man auf die globale Variable SR.R zu und definiert

Decay 07.jpg

Der momentane Wert der Decay-Kurve wird in einem Speicher verwaltet. Der Speicher wird durch den Trigger Trg auf 1 gesetzt, im Anschluss daran wird bei jedem SampleRate-Tick über die SampleRateClock (SR.C) die Änderungsrate addiert wird.

Decay 08.jpg

Sobald der Speicher einen negativen Wert oder Null erreicht, wird der Speicher auf 0 gesetzt:

Decay 09.jpg

[herw]

Hier nun das Ensemble:

Decay 10.jpg

Die Originaldatei enthält als Anzeigeelement eine Audiotable der Größe 882000x1. Damit wächst die Datei auf 3,6MB. Da der Speicherplatz auf dem Server begrenzt ist, habe ich die Audiodatei auf 882x1 verkleinert und komme so auf 16kB!

Decay-01a.ens.zip

Damit ihr auch eine solch schöne Decay-Anzeige bekommt, müsst ihr in den Properties der Audiotable die Größe auf 882000x1 setzen:

Decay 11.jpg

Ich würde die Anzeige gerne auf das nötigste begrenzen (441x110 Pixel), so dass die Dateigröße stark schrumpft. Leider habe ich das noch nie gemacht. Wer mir da unter die Arme hilft, hat etwas bei mir gut. Im Prinzip müsste ich ja nur jeden 2000. Tick erfassen, um dieselbe Anzeige zu bekommen.

[herw]

Anschlagabhängigkeit
Ich habe diese einfache Decaykurve als Einstieg gewählt, da man an ihr sehr gut alle wichtigen Aspekte einer Steuerkurve darstellen kann.
Zunächst gehe ich auf die Anschlagabhängigkeit ein. Das Midi-Modul VelOn, das wir als Trigger benutzen, können wir gleichzeitig auch als Informatonsquelle für die Anschlagsstärke (velocity) verwenden. Mit einem Button schalten wir um.
Es gibt nun zwei grundsätzlich verschiedene Möglichkeiten des Einbaus.
Der erste Gedanke geht dahin, einfach die Ausgangswerte mit der velocity zu multiplizieren:

Decay 12.jpg

Im Diagramm sehen wir, wie beim Einschalten der Anschlagsabhängigkeit die Steuerkurve bei dem entsprechenden Wert startet. Die eigentliche Dauer der Steuerkurve bleibt gleich.

Decay 13.jpg

Würde man die Steuerkurve zur Lautstärkeregulierung benutzen, würde ein Ton auch bei leichtem Anschlag genauso lange ausklingen. Dies kann gewünscht sein oder auch nicht.
Möchte man dagegen die Zeitdauer T vom Anschlag abhängig machen, setzt man den temporären Speicher z.B. auf den Anschagswert:

Decay 14.jpg

Die Kurve startet auch beim Anschlagswert, verringert sich aber mit derselben Änderungsrate, wie die anschlagsunabhängige Kurve, sie endet also mit einer geringeren Zeitdauer T.

Decay 15.jpg

Je nach Anwendung wählt man eine der beiden Methoden.

[herw]

Hier sind die beiden Ensembles:
Bitte beachtet, dass ihr nach dem Laden die Kapazität der AudioTable von 882x1 wieder auf 882000x1 setzt.

Decay-02a.ens.zip

Decay-02b.ens.zip

Ich muss noch nachreichen, wie die Umschaltung auf Anschlagsabhängigkeit geschieht:

Decay 16.jpg

[Rampensau]

Ich hätte einen Alternativvorschlag für die Anzeige. Die lässt sich zwar nicht so schön beschreiben, aber das nötigste zeigt sie an, wenn man die Table mit nem XY-Feld austauscht und die X-Position durch 882000 teilst.

Oder du teilst einfach die Schreibpostion für die Table provisorisch durch 2000. Für eine elegantere Lösung lässt sich die Struktur ja noch weiter verändern.

Anzeige2.JPG

Außerdem hatte ich Probleme, nur die Zeit T vom Anschlag abhängig zu machen. Dazu musste ich dann ins Primary, um den Trigbefehl zu ordnen, sodass der Anschlag zuerst T beeinflusst und dann die Hüllkurve triggert.

Dynamik.JPG

Versuch ich das in ein und der selben Corezelle zu lösen, dann verhaspelt sich die Kurve und fällt ins Bodenlose!
Naja, im Primary gehts dann ja, dank des Event Orders..

Später würde mich neben deinen Ausführungen noch interessieren, wie man mehrere Kurvenphasen loopt. Ein einfaches Decay zu loopen, ist ja nicht das Problem. Das wäre ja ein abfallender Sägezahn. Aber selektives Loopen mehrerer Phasen wäre geil!Mit BPM-Synchronisation und Teilern. Also mal eine so richtig übertrieben aufgerüstete Kurve!
Absynthmäßig... Ich weiß, sowas gibt es ja bereits in der Werkslibrary unter den Building Blocks. Aber selbstbauen ist doch irgendwie schicker.

Und bei der Casio CZ Serie kann man einstellen, wieviele Phasen (bis zu 8), die Hüllkurve durchläuft. Zudem kann man eine dieser Phasen als Sustainpegel festlegen. Du kennst ja die Anleitung!
http://manuals.fdiskc.com/tree/Casio/Ca ... Manual.pdf
Gibt ganz coole Konturen.

Aber das ist im Moment ja noch zukunftsmusik!
Ist auf jeden Fall interessant hier.. Bitte weitermachen.

[Rampensau]

Meine Modifikation mit Vel->A, Vel->T, Vel->both und bipolarem Velocityanteilsregler und skalierter Anzeige in Hoffnung nichts vorweggenommen zu haben

Modifikation.zip

[herw]

[...]
Später würde mich neben deinen Ausführungen noch interessieren, wie man mehrere Kurvenphasen loopt. Ein einfaches Decay zu loopen, ist ja nicht das Problem. Das wäre ja ein abfallender Sägezahn. Aber selektives Loopen wäre geil!Mit BPM-Synchronisation und Teilern. Also mal eine so richtig übertrieben aufgerüstete Kurve!
[...]

wenn du die erste Post liest, dann ist das Ziel klar: mehrere Phasen. Ich gehe sogar noch weiter: mein Ziel ist es, eine universelle Phase zu schaffen, die man beliebig aneinanderhängen kann; zunächst linear, dann auch exponentiell.
Das Building-Blocks-Modul gefällt mir nicht, da die Struktur und insbesondere die Konstruktion der Grafik eine Zumutung ist: überhaupt nicht nachvollziehbar und nicht erweiter- oder kürzbar. Da gefällt mir die Standardkurve des Core-ADSR um Längen besser von der Idee her gesehen.
Über die grafische Darstellung will ich mir keine großen Gedanken machen, da warte ich lieber erst einmal ab, ob die irgendwann vielleicht erscheinende REAKTOR 6 - Version hier Erleichterung bringt; ansonsten muss man zu viele Klimmzüge machen.

[...]
Außerdem hatte ich Probleme, nur die Zeit T vom Anschlag abhängig zu machen. Dazu musste ich dann ins Primary, um den Trigbefehl zu ordnen, sodass der Anschlag zuerst T beeinflusst und dann die Hüllkurve triggert.

Dynamik.JPG

[...]

Die Verkürzung der Decayzeit T ist doch einfach und elegant im Ensemble decay 02b.ens gelöst. In die primary-Ebene möchte ich aus prinzipiellen Erwägungen nicht zurück.

ciao herw

[Rampensau]

[...]Das Building-Blocks-Modul gefällt mir nicht, da die Struktur und insbesondere die Konstruktion der Grafik eine Zumutung ist[...]

genau mein Reden.

[...]Die Verkürzung der Decayzeit T ist doch einfach und elegant im Ensemble decay 02b.ens gelöst.[...]
ciao herw

sicher?

decay02b.JPG

Du meintest sicher decay 02a.ens. Aber da wird eben beides beeinflusst. Der Startwert und die Zeit! Ich bin mittlerweile auch eher ungern im Primary, aber solange die Schaltung "funzt"...
Ich habe aber jetzt ne bessere Lösung, wie ich das in der Corezelle erledige. Wenn man einfach die Amplitude wieder durch den Velocitywert teilt, steigt sie auf einen Startwert von 1 und nur die Zeit ist anschlagsabhängig.

decay02amod2.JPG

Was mich außerdem stört, ist, dass die Kurve bei Initialisierung(Ich glaube zumindest die Initialisierung sei Schuld) getriggert wird. Also wenn das Ensemble aufgemacht wird, oder eine Verbindung (in Core oder Primary) hergestellt wird.
Die "Tablebeschriftung" wird hingegen nicht von der Initialisierung gestartet. Da muss schon ein manuelles Triggern her.
Was kann man gegen den "Init-Trigger" tun?

[herw]

[...]

[...]Die Verkürzung der Decayzeit T ist doch einfach und elegant im Ensemble decay 02b.ens gelöst.[...]
ciao herw

sicher?

oh da habe ich wohl die Dateien vertauscht.

Du meintest sicher decay 02a.ens. Aber da wird eben beides beeinflusst. Der Startwert und die Zeit!

das war auch meine Absicht, denn das ist ja der Sinn.

[...] Wenn man einfach die Amplitude wieder durch den Velocitywert teilt, steigt sie auf einen Startwert von 1 und nur die Zeit ist anschlagsabhängig.

korrekt! Das wäre dann quasi ein key-Tracking; das habe ich bewusst zunächst außen vor gelassen; aber schön, dass es von Dir kommt .

Was mich außerdem stört, ist, dass die Kurve bei Initialisierung(Ich glaube zumindest die Initialisierung sei Schuld) getriggert wird. Also wenn das Ensemble aufgemacht wird, oder eine Verbindung (in Core oder Primary) hergestellt wird.
Die "Tablebeschriftung" wird hingegen nicht von der Initialisierung gestartet. Da muss schon ein manuelles Triggern her.
Was kann man gegen den "Init-Trigger" tun?

Solche „Probleme” habe ich zunächst mal außen vorgelassen, da ich zunächst das Prinzip aufbauen will. Also versteh bitte die Ensemble nicht als Endprodukte, sondern reine Testaufbauten. Ich werde sie nach und nach ohne Kommentar beseitigen, da sie nicht zum eigentlichen Thema gehören.

ciao herw

PS: bitte weiterhin Fragen, Verbesserungen und Ideen äußern; umso mehr bin ich auch motiviert und aktiv!

[Rampensau]

[...] Wenn man einfach die Amplitude wieder durch den Velocitywert teilt, steigt sie auf einen Startwert von 1 und nur die Zeit ist anschlagsabhängig.

korrekt! Das wäre dann quasi ein key-Tracking; das habe ich bewusst zunächst außen vor gelassen; aber schön, dass es von Dir kommt .

ist doch eher Velocity-Tracking?! Key- bezieht sich ja mehr auf die Tonhöhe. Aber vielleicht schreibst du auch deswegen "quasi"-Tracking.
Aber ich will ja auch nicht klugscheißern.

Solche „Probleme” habe ich zunächst mal außen vorgelassen, da ich zunächst das Prinzip aufbauen will. Also versteh bitte die Ensemble nicht als Endprodukte, sondern reine Testaufbauten. Ich werde sie nach und nach ohne Kommentar beseitigen, da sie nicht zum eigentlichen Thema gehören.

Das ist absolut verständlich.

Und das ist dir vielleicht schon bekannt, aber ich wollte nur mal nen Kniff erwähnen, mit dem man in mehrstimmigen Ensembles stets die aktuelle Stimme in Anzeigen oder Oszilloskope schreiben kann.
Im Moment reagiert die Anzeige bei einem 4-stimmigen Ensemble immer nur auf jede vierte Note(bei Voice-Assign="Oldest).
Um genau zu sein, immer nur auf Stimme 1!

Der Kniff ist, die "Voice-Info" für das "From-Voice"-Modul in ein (polyphones) "Value"-Modul zu schreiben, und mit einem (polyphonen) Gate zu triggern.
Somit wird immer nur die aktuelle Stimme ausgegeben. Dieses Signal kann man jetzt durch einen Event-Voice-Combiner jagen und als monophonen Stimmenindikator in die From-Voice-Module speisen.

Voice.JPG

Gruß

[herw]

[...] Wenn man einfach die Amplitude wieder durch den Velocitywert teilt, steigt sie auf einen Startwert von 1 und nur die Zeit ist anschlagsabhängig.
decay02amod2.JPG

korrekt! Das wäre dann quasi ein key-Tracking; das habe ich bewusst zunächst außen vor gelassen; aber schön, dass es von Dir kommt .

ist doch eher Velocity-Tracking?![...]

ach du Schreck; habe ich mal wieder zu schnell geschrieben. Ich schreibe hier quasi aus der Hand; manchmal steht auch ein Glas Rotwein daneben und nicht nur . Danke für die Korrektur.

Und das ist dir vielleicht schon bekannt, aber ich wollte nur mal nen Kniff erwähnen, mit dem man in mehrstimmigen Ensembles stets die aktuelle Stimme in Anzeigen oder Oszilloskope schreiben kann.[...]

Gruß

klar ist mir das bekannt, bin ja schon ein wenig länger dabei ; das zuständige Modul heißt übrigens FromLastVoice und findet sich in einigen der Ensembles von Eric Wistrand (ew) und bei mir ab und an ebenfalls. Ich mache hier mein Projekt bewusst monophon, da ich möglichst viel Ballast weglassen möchte. REAKTOR ist in der Behandlung der Mehrstimmigkeit einfach so genial, dass man monophone Ensembles fast 1:1 polyphon übernehmen kann. Die Anzeige ist nicht gedacht als ständige Kontrolle (in einem fertigen Ensemble) sondern nur als Messanzeige hier in unserem (monophonen) Projekt. Eine Anzeige in einem umfangreicheren Ensemble stelle ich mir auch nicht als AudioTable (oder xy-Anzeige) vor, sondern als einmalige qualitative Anzeige, wie in den primary-Level-Modulen beim ADSR etc..

Gleich geht's weiter.

ciao herw

[herw]

Start- und Zielpunkte

Betrachten wir die Steuerkurven im ersten Abschnitt, so muss jeder Teilabschnitt von jedem beliebigen Wert starten und in jedem beliebigen Wert enden.

Decay 17.jpg

Die Informationen über den Wertebereich benötigen wir sowohl bei der Berechnung der Zeitdauer, wie auch bei der Speicherverwaltung

Decay 18.jpg

Die Änderungsrate d bezieht sich nun nicht mehr auf den Bereich [1;0] sondern [A,B]. Da ist nur ein wenig Arithmetik nötig:

Decay 19.jpg

Die Änderungsrate wird auf die Differenz A-B durch einen entsprechenden Faktor genormt. Die Veränderung der Änderungsrate kann man übrigens auch bei Anschlagabhängigkeit benutzen (ausprobieren!).
Im Speichermodul muss als Startwert statt 1 nun A gesetzt werden, und die Abbruchbedingung das Unterschreiten von B abfragen:

Decay 20.jpg

Das Ensemble lautet:

Decay-03.ens.zip

.
Das Modul ist natürlich noch nicht gegen „Fehlbedienung” gesichert; so muss der Benutzer beachten, dass A größer oder gleich B sein muss. Aber das soll uns hier noch nicht interessieren.

[herw]

Wir erweitern schließlich noch den Wertebereich der Regler und der Audio-Table auf [-1;1] und erhalten so auch negative Steuerwerte.

Decay-04.ens.zip

Decay 21.jpg

ciao herw