Poly Display tut nicht das, was ich will!

[Makrophag]

Hallo!

Im Moment bastel ich mir eine Hüllkurve aus der primary Level 4-Ramp-Hüllkurve, bei der man dann mehr Optionen und optische Kontrolle haben soll. Die Darstellung der Form/des verlaufs hat auch so geklappt, wie ich mir das vorgestellt habe. Praktischer Weise hat diese 4-Ramp-Hüllkurve aber auch noch einen "State" Output, was mich auf die idee gebracht hat, ein "State-Display" zu bauen, dass passend zum Form-Display den aktuellen Hüllkurven-Status für jede Stimmem zeigt (nicht unbedingt hilfreich, aber es sieht lustig aus und auf diese Weise lernt man ja Reaktor besser kennen).
In meinem angehängten Ensemble könnt ihr das testen (es kommt noch kein Ton, aber ihr seht wie die Displays arbeiten). Dann werden ihr merken, dass das Sate Display äusserst ungern in der Attack-Phase startet, obowohl die Hüllkurve offensichtlich in dieser Phase ist (wenn man Attack etwas höher einstellt, sieht man das am "Result"-Meter und an der Transparenz im State-Display). Ich weiß nicht, wo der Fehler liegt, ich vermute es hat irgendwas mit der Reihenfolge der Signale in meinem State-Display zu tun, oder mit der Core-Cell, die den State der Hüllkurve prüft und demensprechend Werte an das Display gibt. Ich weiß, es ist immer schwer sich in fremde Sachen reinzudenken, aber wenn ihr Fragen habt, beantworte ich sie gerne.

Bitte, hat irgendjemand eine Idee, was der Fehler ist und wie eine Lösung aussehen könnte (wenn an anderer Stelle ein Fehler auftaucht, dafür bin ich auch zu haben!!!)?

Danke schonmal im vorraus für eure Mühe!

[herw]

Hallo!

Im Moment bastel ich mir eine Hüllkurve aus der primary Level 4-Ramp-Hüllkurve, bei der man dann mehr Optionen und optische Kontrolle haben soll. Die Darstellung der Form/des verlaufs hat auch so geklappt, wie ich mir das vorgestellt habe. Praktischer Weise hat diese 4-Ramp-Hüllkurve aber auch noch einen "State" Output, was mich auf die idee gebracht hat, ein "State-Display" zu bauen, dass passend zum Form-Display den aktuellen Hüllkurven-Status für jede Stimmem zeigt (nicht unbedingt hilfreich, aber es sieht lustig aus und auf diese Weise lernt man ja Reaktor besser kennen).
In meinem angehängten Ensemble könnt ihr das testen (es kommt noch kein Ton, aber ihr seht wie die Displays arbeiten). Dann werden ihr merken, dass das Sate Display äusserst ungern in der Attack-Phase startet, obowohl die Hüllkurve offensichtlich in dieser Phase ist (wenn man Attack etwas höher einstellt, sieht man das am "Result"-Meter und an der Transparenz im State-Display). Ich weiß nicht, wo der Fehler liegt, ich vermute es hat irgendwas mit der Reihenfolge der Signale in meinem State-Display zu tun, oder mit der Core-Cell, die den State der Hüllkurve prüft und demensprechend Werte an das Display gibt. Ich weiß, es ist immer schwer sich in fremde Sachen reinzudenken, aber wenn ihr Fragen habt, beantworte ich sie gerne.

Bitte, hat irgendjemand eine Idee, was der Fehler ist und wie eine Lösung aussehen könnte (wenn an anderer Stelle ein Fehler auftaucht, dafür bin ich auch zu haben!!!)?

Danke schonmal im vorraus für eure Mühe!

ich habe gerade mal hinein geschaut. Ich arbeite auch schon seit längerer Zeit an Hüllkurvengeneratoren, daher interessiert mich dein Beitrag sehr. Ich gehe hier aber nur auf die Hüllkurve ein; eine falsche Anzeige im Polydisplay lässt auf eine falsche Eventverarbeitung der Voices schließen; ich habe aber dort noch nicht hineingeschaut.
Die Idee, die Phasen unter dem eigentlichen Display zu markieren, finde ich gut.
Der Ansatz, aus der Ramp-Kurve eine ADSR-Funktion (hier mit Hilfe einer Potenzfunktion) herzustellen, ist eine von zwei Möglichkeiten; die andere wäre (wie im Core-ADSR) lineares Wachstum durch eine Wachstumsrate (Summand) oder exponentielles Wachstum durch einen Wachstumsfaktor zu erzeugen. Ein Nachteil der Funktionsmethode ergibt sich dann, wenn man (analog) retriggern möchte, d.h. wenn eine Hüllkurve bei jedem Retrigger vom aktuellen Level starten soll: z.B. die Hüllkurve ist in einer Decayphase und soll durch einen retrigger beliebig gestartet werden. Die Attackphase befindet sich dann nicht mehr bei 0, sondern muss den aktuellen Wert übernehmen, im Gegensatz zum digital retrigger, der immer wieder bei 0 startet. Das erfordert lästige Berechnungen; außerdem muss beachtet werden, wie die Anschlagsdynamik verwertet wird. Dies geht aus den Beschreibungen im Handbuch zum 4-Ramp-Generator nicht hervor:
du musst testen, ob die Velocity nur die Amplitude verringert, was zur Folge hat, dass die leisen Gate-Impluse trotzdem zu den gleichen Phasenlängen führt wie harte Anschläge; leise Töne würde man als länger an- und ausklingend empfinden; oder ob bei leichtem Anschlag auch die Phasenlänge mit verkürzt wird.

Die Attackphase entspricht übrigens nicht dem als natürlich empfundenen Verlauf; normal ist eine Sättigungskurve:
Du benutzt z.B. Potenzfunktionen f(x)=x^p (p=power im ensemble), bzw. für die Sättigung durch Exponenten kleiner als 1 entsprechend Wurzelfunktionen; „richtig” wäre aber g(x)=p/(p-1)·(1-p^(-x)).

Envelope.gif

Sorry, dass ich jetzt fast nur auf grundsätzliche Ideen eingegangen bin. Die korrekte Anzeige einer Hüllkurve ist schwierig.

ciao herw

[Makrophag]

Der Ansatz, aus der Ramp-Kurve eine ADSR-Funktion (hier mit Hilfe einer Potenzfunktion) herzustellen, ist eine von zwei Möglichkeiten; die andere wäre (wie im Core-ADSR) lineares Wachstum durch eine Wachstumsrate (Summand) oder exponentielles Wachstum durch einen Wachstumsfaktor zu erzeugen.

Ja, die Potenzfunktion zu benutzen ist eigentlich eher ein Workaround, da ich Hüllkurven in Core noch überhaupt nicht nachvollziehen kann (hatte mal versucht eine zu "zerlegen"), und somit keine Ahnung habe, wie ich eine exponentielle Hüllkurve mit einem "Shape"-faktor versehen kann, der ähnlich arbeitet, wie mein Power-Regler (übrigens habe ich die Erfahrungen gemacht, dass gerade die von NI zur Verfügung gestellte Potenzfunktion im Core-Level etwas widerspenstig ist, viele Fehler gerade bei Werten nahe bei 0). Wobei man den Vorteil eines Ramp-basierten Ansatzes, dass nach der Decay Zeit tatsächlich ein stabiles Level erreicht wird (so wie ich das verstanden habe, sind exponentielle Hüllkurven IMMer iregndwie in Bewegung, auch wenns noch so kleine Werte-Änderungen sind) nicht uasser ahct lassen sollte, finde ich. Je nach Anwendung ist dies durchaus hilfreich (z.B. bei Pitch-Hüllkurven finde ich).

du musst testen, ob die Velocity nur die Amplitude verringert, was zur Folge hat, dass die leisen Gate-Impluse trotzdem zu den gleichen Phasenlängen führt wie harte Anschläge; leise Töne würde man als länger an- und ausklingend empfinden; oder ob bei leichtem Anschlag auch die Phasenlänge mit verkürzt wird.

Das leuchtet ein, habe ich aber noch nicht dran gedacht. Danke!

Die Attackphase entspricht übrigens nicht dem als natürlich empfundenen Verlauf; normal ist eine Sättigungskurve:
Du benutzt z.B. Potenzfunktionen f(x)=x^p (p=power im ensemble), bzw. für die Sättigung durch Exponenten kleiner als 1 entsprechend Wurzelfunktionen; „richtig” wäre aber g(x)=p/(p-1)·(1-p^(-x)).

Meinst du mit natürlich empfundenen Verlauf das Vehalten echter Instrumente? Und die von dir angegebene Formel würde doch dann nur für die Attack-Phase gelten oder? Ich denke ich werde die mal in Excel reinhauen und sehen, was verschiedene 'p's ergeben.


Wie es aussieht habe ich es mir mal wieder einfach gemacht. hehe.

Aber da wir grad bei Hüllkurven Diskussionen sind, hölst du es für notwendig, dass diese mit Audi-Sampleraten arbeiten? Früher habe ich da nicht drauf geachtet und die Hüllkurven häufig auch zu Events konvertiert. Bei LFOs ist Event ja (zumindest laut Primary Level) auch angebracht. Ich finde das eine wichtige Frage, weil CPU Last in Reaktor ja schon eine große Rolle spielt (man kann schnell mal den Rechner überfordern .

[herw]

[...]
Ja, die Potenzfunktion zu benutzen ist eigentlich eher ein Workaround, da ich Hüllkurven in Core noch überhaupt nicht nachvollziehen kann (hatte mal versucht eine zu "zerlegen"), und somit keine Ahnung habe, wie ich eine exponentielle Hüllkurve mit einem "Shape"-faktor versehen kann, der ähnlich arbeitet, wie mein Power-Regler

da muss man einen exponentiellen Regler (Bereich 10^-5 .. 10^+5) erzeugen

(übrigens habe ich die Erfahrungen gemacht, dass gerade die von NI zur Verfügung gestellte Potenzfunktion im Core-Level etwas widerspenstig ist, viele Fehler gerade bei Werten nahe bei 0).

da würde ich erstmal direkt nachschauen, welche Rechengenauigkeit eingestellt ist. Ich nehme grundsätzlich die höchste. Primary ist dann ungenauer.

Wobei man den Vorteil eines Ramp-basierten Ansatzes, dass nach der Decay Zeit tatsächlich ein stabiles Level erreicht wird (so wie ich das verstanden habe, sind exponentielle Hüllkurven IMMer iregndwie in Bewegung, auch wenns noch so kleine Werte-Änderungen sind) nicht uasser ahct lassen sollte, finde ich. Je nach Anwendung ist dies durchaus hilfreich (z.B. bei Pitch-Hüllkurven finde ich).

ja da habe ich lange dran geknobelt, wie man erzwingen kann, dass die exponentiellen Funktionen zu einem definierten Ende führen. Ich habe sie ein klein wenig gedehnt und um den Dehnungsfaktor nach oben oder unten verschoben, damit ich eine gültige Abbruchbedingung (überschreitet oder unterschreitet einen Wert) bekomme. Ist viel Mathematik dahinter aber doch letztlich elegant zu lösen.

du musst testen, ob die Velocity nur die Amplitude verringert, was zur Folge hat, dass die leisen Gate-Impluse trotzdem zu den gleichen Phasenlängen führt wie harte Anschläge; leise Töne würde man als länger an- und ausklingend empfinden; oder ob bei leichtem Anschlag auch die Phasenlänge mit verkürzt wird.

Das leuchtet ein, habe ich aber noch nicht dran gedacht. Danke!

Die Attackphase entspricht übrigens nicht dem als natürlich empfundenen Verlauf; normal ist eine Sättigungskurve:
Du benutzt z.B. Potenzfunktionen f(x)=x^p (p=power im ensemble), bzw. für die Sättigung durch Exponenten kleiner als 1 entsprechend Wurzelfunktionen; „richtig” wäre aber g(x)=p/(p-1)·(1-p^(-x)).

Meinst du mit natürlich empfundenen Verlauf das Vehalten echter Instrumente? Und die von dir angegebene Formel würde doch dann nur für die Attack-Phase gelten oder? Ich denke ich werde die mal in Excel reinhauen und sehen, was verschiedene 'p's ergeben.

nimm lieber das Programm GeoGebra (kostenlos für alle Plattformen), genial übersichtlich und ständig gepflegt; in der Fundgrube findest Du den Link zum downloaden und auch die Hüllkurvenfunktionen, die ich in einem dynamischen Arbeitsblatt (auch als download hier zu haben) erzeuge. Die Exponentialkurve für die Decay und die Releasephase ist viel einfacher: h(x)=p^(-x) (hier noch unendlich auslaufend).

Wie es aussieht habe ich es mir mal wieder einfach gemacht. hehe.

durchaus nicht; ich bin genauso angefangen. Nach und nach lernt man die Tricks und Fallen kennen. Ich arbeite sehr behutsam: zunächst habe ich nur eine lineare Phase in Core erstellt. Dann folgt (im Moment die Umsetzung auf typische Attack, Release und Decay-Phasen (mit verschiedenen Anfangs- und Endpunkten).
Die Abbruchbedingungen und die Übergabe an die nächste Phase müssen wohl überlegt sein.

Aber da wir grad bei Hüllkurven Diskussionen sind, hölst du es für notwendig, dass diese mit Audi-Sampleraten arbeiten? Früher habe ich da nicht drauf geachtet und die Hüllkurven häufig auch zu Events konvertiert. Bei LFOs ist Event ja (zumindest laut Primary Level) auch angebracht. Ich finde das eine wichtige Frage, weil CPU Last in Reaktor ja schon eine große Rolle spielt (man kann schnell mal den Rechner überfordern .

Audioraten muss ich ohnehin in Core nehmen, da ich ja die SampleRateClock benutzen muss. Überfordert wird der Rechner damit sicherlich nicht.

Wenn Du Fragen zum Core-ADSR-Modul hast, können wir das in einem Extra-Thread diskutieren. Ich meine das Modul zu 100% verstanden zu haben. Es ist zwar gut programmiert, aber schlecht zu erweitern (mehr und komplexere Phasenfolgen). Daher muss man das Konzept verändern (wie oben beschrieben).

ciao herw

[Makrophag]

Wow, super. Dann werde ich bei Gelegenheit mal in der Fundgrube stöbern...

Jetzt bin ich aber weit ab von meinem eigentlichen Problem gelandet... Naja werd wohl nochmal den Event-Watcher vergewaltigen müssen und viel viel nachforschen.

(Sonst ist hier im deutschen Forum wohl nicht viel los, kann das sein?)

[herw]

Wow, super. Dann werde ich bei Gelegenheit mal in der Fundgrube stöbern...

Jetzt bin ich aber weit ab von meinem eigentlichen Problem gelandet... Naja werd wohl nochmal den Event-Watcher vergewaltigen müssen und viel viel nachforschen.

(Sonst ist hier im deutschen Forum wohl nicht viel los, kann das sein?)

wir haben wenige User,was aber der Qualität der Beiträge keinen Abbruch tut, ich würde sogar behaupten fördert. Vielleicht solltest du mal in die Websites einiger Mitglieder schauen; du wirst staunen, wer da angemeldet ist.
Wenn man den vielen Unsinn, der in „bedeutenden” Foren verzapft wird, weglässt, bleibt dort nicht viel übrig.
Sachlichkeit und intensive Beiträge sind die Stärke dieses Forums.
Ich finde es gut so.

ciao herw

[Makrophag]

Wollte auch nicht meckern, an Qualifikation fehlt es hier offensichtlioch wirklich nicht!