amp modulation mit 4 Eingängen

[MvKeinen]

Hallo Leute!

hab hier schon viel rumgelesen und bin einiges schlauer geworden

bei meinem projekt T1 (fm/sinusshaping-sequencer) steck ich fest bei einem essenziellen Punkt.

ich will einen VCA mit bis zu 2 envs und 2 lfos steuern. Die summe dieser modulationen soll den bereich [0...1] nicht verlassen klar. die lfos [-1...1] transponiere ich mit einem x*y+y (y=0.5) in den bereich [0...1] Das find ich bei amp modulation sinnvoller. die 4 Modulationsamounts soll allerdings bipolar sein.
jetzt will ich mit einer einzigen modulation natürlich den ganzen bereich abdecken können.

das heisst der wertebereich der Amounts einzelner modulationen ist von der summe der beträge der anderen 3 abhängig.

sobald ich das aber kreuzweise verdrahte gibts nen eventloop.

bis zu einer summe=1 der modulationen soll alles normal laufen. wenn sie jedoch 1 überschreitet soll jeder amountregler nur seinen verhältnismäßigen anteil an der gesamtmodulation besitzen. hab schon unzähliges mit seperatoren versucht ich komm grad nicht weiter,,,

was kann man da machen?

Danke schonmal

[MvKeinen]

lustig, nachdem ich das hier in worte fassen musste ist mir ne teillösung eingefallen.

das klappt jetzt ganz gut im positiven bereich

betätigt man die regler sieht man, dass ihr output (numeric) sich abhängig von allen reglern verhält.

wo muss ich jetzt ansetzen um das bipolar hinzukriegen?

wie krieg ich die rundungsfehler weg? Order? oder muss ich da bei mousereso und num steps was beachten?

wichtig: alle modulationen auch lfo schwingt von 0..1

der modulationsamount soll aber von -1...1 gehen.

mir raucht das hirn

[MvKeinen]

ich glaub ich habs

jetz muss ich das nurnoch in meine sämtlichen modulationen reinpflanzen und ausprobieren

[herw]

ich glaub ich habs

jetz muss ich das nur noch in meine sämtlichen modulationen reinpflanzen und ausprobieren

sieht logisch aus; ich würde diese Struktur aber unbedingt in core programmieren, denn sie erzeugt in primary eine Unmenge an zusätzlichen events; ganz davon abgesehen könnte die Struktur davon abhängig sein, in welcher Reihenfolge Du die Strippen gezogen hast (ein Nachteil von primary).
Ob es letzlich immer so funktioniert, wenn man LFOs anklemmt, kann man so nicht beurteilen. Ich denke, solange es keine logischen Abfragen gibt, die eventuell nur von einem Event abhängen, müsste es eigentlich funktionieren. In jedem Fall würde ich die gesamte Struktur Schritt für Schritt durch das event history makro (macro\building blocks\displays) kontrollieren. Du musst unter Umständen bedenken, dass es unterschiedliche Arten der Events gibt: ein Regler schickt seinen Event irgendwann, wenn er entsteht, ein LFO schickt seine Events mit der subclock der sample rate clock, also zu genau definierten Zeitpunkten. Wahrscheinlich hat es hier keine Auswirkungen. Ich weiß ja nicht, wie du die Modulationen einsetzt, aber ich würde Spezialfälle testen:
z.B. alle vier Quellen sind LFOs derselben Frequenz, synchronisiert, unsynchronisiert, von verschiedenen Quellen kommend, von einer Quelle kommend etc.
In jedem Fall sind die angezeigten „falschen” Werte definitiv keine Rundungsfehler, sondern haben ihre Ursache in der Verarbeitungsreihenfolge der events:
Wenn Du die Einzelausgänge und die Summe mal mit dem event history makro untersuchst, wirst du sehen, dass die Reihenfolge der Events nicht so geschieht, wie die Struktur es vorgaukelt.

overpole.jpg

und

overpole2.jpg

ciao herw

PS: nachdem ich einen der Regler mal schnell bewegt habe, (Regler 1 konstrant auf 1, Regler 2 von 0 auf 1), bin ich der Überzeugung, dass diese Struktur so in primary nicht funktioniert. Unbedingt muss der jeweilige Zeitpunkt der gleichzeitigen Triggerung aller Werte Aufmerksamkeit geschenkt werden. Dies geht in core einfacher. Beachte auch die Initialisierungsreihenfolge: der Treashhold wird mittendrin ausgelöst. Zuvor gelangen alle Originalwerte der Regler an die event-value makros, erst danach die eventuell zu verändernden Werte. Das Schalten des Treahshold moduls muss wirklich die letzte Aktion sein und damit den Haupttrigger liefern, nachdem alle anderen Berechnungen zuvor erfolgten.

overpole3.jpg

[MvKeinen]

super erstmal danke für die Antwort. Ich versteh noch nicht alles. Was core betrifft bin ich noch etwas hilflos. werde aber diese gelegenheit nutzen um den Einstieg zu versuchen.

wenn ich das richtig verstanden hab, sollte wohl der seperator umschalten bevor die 4 werte herausgegeben werden. ist auch logisch. Damit am ausgang nichts mehr passiert wenn die neue formel in kraft tritt.

das einzige was mir einfällt um die rheienfolge der berechnungen zu bestimmen ist "order". Das probier ich erstmal. Ansonsten versuch ich mich mal in basis core und werde weiterhin ein blockdiagramm der Modulationsverknüpfungen des T1 anfertigen.

hab am beispiel des threads mal wieder gesehen, dass einen der zwang eine problematik in worte zu fassen fast immer einen schritt nach vorn bedeutet.

mann!! wenn das klappen würde könnten jahrelange reaktorarbeit in ganz neuem glanz erstrahlen

das makro das ich haben will soll die Modulationstiefe verschiedener Quellen im eingestellen Verhältnis zueinander organisieren.

[herw]

...

das makro das ich haben will, soll die Modulationstiefe verschiedener Quellen im eingestellen Verhältnis zueinander organisieren.

ist schon klar, und darin liegt auch die Falle, siehe die falsch errechneten Werte bei schnellen Reglerbewegungen.
Die Problematik der verschiedenen Eventarten direkt (von Reglern, Konstanten) und audio-based-events (vom LFO, ADSR etc. bzw. speziell vom AtoE-Modul) sind in diesem Zusammenhang fundamental problematisch.
Du musst unbedingt die Eventreihenfolge mit dem Event-history-Modul untersuchen. Das ist sehr interessant, wenn du für solche Grundversuche offen bist. Dann solltest du dir die Zeit nehmen, eine eigenes vereinfachtes Experimentierensemble zu erstellen, das nur diesen Aspekt der Eventreihenfolge betrachet, auch wenn es dich vielleicht einen Monat kostet; du gewinnst in jedem Fall durch das Wissen über core. Das ist ein schönes Diskutierthema im Forum.
Die Umwandlung deiner Idee in Core ist für die gezeigte Struktur sehr lohnend. Wenn ich das richtig einschätze, wird es auf einen abschließenden Trigger hinauslaufen, der in core einfach zu realisieren ist.

ciao herw

[MvKeinen]

ich hab jetzt angefangen das mit core zu realisieren. Ist nicht so schwer wie ich dachte. bisher hat mich die hoffnungslose unübersichtlichkeit mancher corezellen abgeschreckt, wenn man jedoch ein eigenes macht, scheint das alles nicht so schwer zu sein. meine bisherige lösung basiert auf ner menge CTL relay- cells. Könnte sein, dass ich zu umständlich denke aber bisher funktioniert es pefekt. wenns fertig ist werd ich es hier posten.

vielen dank für die hilfe.

[MvKeinen]

das ding hier schläft nicht ein, ich muss nur etwas länger ausholen als ich dachte und nochmal die core Literatur durcharbeiten. hab jetzt aber ENDLICH einen einstieg in Core geschafft und merke langsam die ganzen vorteile. Ich nenns mal Geschmeidigkeit

Bin an einer wichtigen Stelle steckengeblieben: die Addition von Modulationshüben mit verschiedenen Vorzeichen. da ich für die Berechnung der maximalen Tiefe der einzelnen Modulationen die Beträge der anderen addieren muss bleibt bei gegenpoliger Modulation von ab 2 quellen zu wenig Spielraum übrig. Das problem liegt aber nicht unbedingt in der Umsetzung sondern eher in der eigenen Festlegung auf die gewünschte Funktionalität. Dazu baue ich grad ne Einfachsimulation der praktischen Umgebung um erstmal herauszufinden was ich überhaupt will bzw. was musikalisch ist. Und immer wenn ich bei Reaktor irgendwo feststecke hat es sich als gut erwiesen einen ganz anderen Teilaspekt des Projektes weiterzuentwickeln, weil sich die Lösung dann oft in einem anderen Kontext entwickelt. Daher sitze ich grade am Sequencer der wie soll es anders sein auch einige Problematiken mit Gleichzeitigkeit hat.

deswegen Noch ne Frage zu:

.....ich würde diese Struktur aber unbedingt in core programmieren, denn sie erzeugt in primary eine Unmenge an zusätzlichen events; ganz davon abgesehen könnte die Struktur davon abhängig sein, in welcher Reihenfolge Du die Strippen gezogen hast (ein Nachteil von primary).

die "Unmengen zusätzlicher Events" interessiert mich hier: Meinst du die Value Module an deren Eingängen ja ne Menge Events anliegen die aber keine Funktionalität haben? (Da nicht getriggert bzw. durchgelassen) Sind solche anordnungen grundsätzlich zu vermeiden wenn Möglich? Ist es so, dass durch den Zwang unter Primary die Rheienfolge der Events zu ordnen ne Menge passiert was den Rechner belastet aber in der Rechnung unterdrückt werden muss?

Danke und Gruss

p.s.: hab hier noch ein schönes tutorial gefunden über das thema event processing in primary. sehr gut und einfach erklärt.

http://ruinwesen.com/support-files/Reak ... ial.06.pdf

[herw]

[...]

die "Unmengen zusätzlicher Events" interessiert mich hier: Meinst du die Value Module an deren Eingängen ja ne Menge Events anliegen die aber keine Funktionalität haben? (Da nicht getriggert bzw. durchgelassen) Sind solche anordnungen grundsätzlich zu vermeiden wenn Möglich? Ist es so, dass durch den Zwang unter Primary die Rheienfolge der Events zu ordnen ne Menge passiert was den Rechner belastet aber in der Rechnung unterdrückt werden muss?

Danke und Gruss

[...]

die Idee, value-module zu nehmen ist grundsätzlich richtig, da man die Gleichzeitigkeit bzw. die geordnete Abfolge von Events dadurch fördert. Nur geht das in Core viel einfacher. CPU-belastend sind allerdings Events so gut wie niemals, solange man nicht events mit sample-Frequenz hineinschickt. Es geht mir bei meiner Argumentation immer um die Übersichtlichkeit und Nachvollziehbarkeit von Strukturen. Unser Denken ist eben auf Gleichzeitigkeit aufgebaut und daher ist das Programmieren in Core wesentlich „natürlicher”.
Es gibt auch in Core viele Events, die eigentlich nicht zu einer Ausgabe von Daten führen sollten. Deshalb benutzt man sehr häufig die Latch-Module.
Deren Wert habe ich auch lange Zeit unterschätzt. Mittlerweile halte ich sie in vielen Schaltungen für absolut notwendig.

ciao herw

[MvKeinen]

so ich glaub ich habs geschafft.

Jedenfalls so, dass es so funktioniert wie ich das will. Es kann sein, dass meine Lösung etwas umständlich ist, vielleicht sogar peinlich. Aber egal, immerhin meine erste Core Entwicklung....
Tips wie es besser geht sind äußerst willkommen.

Ich hab mal einen Versuchsaufbau gebaut.

reaktorsrceen4.jpg

2 Sequenzer (Basierend auf dem Roux von Peter Dines) steuern jeweils eine Envelope wobei die Gatezeit immer genau ein Step lang ist. (Ne Lösung wo man per Step mit einem weiteren Event Table die Gatelänge einstellen kann hab ich schon ist aber für den Versuchsaufbau nicht nötig. Hier geht es ja nur um die getrennte Ansteuerung zweier Envs)
Regelbar ist hier die Steplänge und drunter die Länge der Sequenz

als weitere Modquellen fungieren 2 lfos wobei der zweite vom ersten gesynct werden kann. Der Frequenzregler von lfo2 wird zu dem des ersten addiert. So schwingen beide bei lfo2(add)=0 genau gleichschnell. Unter source kann man noch statt des lfos den Sequencer wählen, wobei hier nur das controlsignal des Serquenzers (ohne envs) hereinkommt

Alle 4 Modulationen werden durch die Regler Depth 1-4 zwischen -1 und +1 geregelt.
"Master" regelt die Grundeinstellung der (in diesem Fall) Lautstärke. Zu diesem Wert werden alle Modulationen addiert bzw. subtrahiert.

Die angezeigten Werte unter den Depthreglern zeigen den eingestellten Wert (Knobvalue) die rechts daneben (Calc Depth) zeigen die tatsächliche Auswirkung auf die Modulation (Numeric readout), also den gemäß der Regeln berechneten Wert.

Hier nochmal die Regeln:

- der Wertebereich ist 0...1
- Die positiven Modulationen teilen sich gemäß ihrer individuellen Tiefe (Depth) den Bereich zwischen dem eingestellten Masterwert und 1
- Die negativen Modulationen teilen sich gemäß ihrer individuellen Tiefe (Depth) den Bereich zwischen 0 und dem eingestellten Masterwert.
- lfos schwingen von 0...1

reaktorsrceen6.jpg

Bereich A: hier wird die Summe der Beträge der negativen Modulationen berechnet (Betrag, weil ich hier positive Werte brauche)
Bereich B: hier wird die Summe der positiven Modulationen berechnet
Bereich C (Von oben bis ganz unten): hier werden die tasächlichen Modulationstiefen berechnet.
Bereich D: hier gibt es noch eine Verschiebung des Wertebereiches falls es sich um einen lfo handelt.

Ich weiss, dass es stressig sein kann, sich da reinzudenken aber was mir beim ersten Blick auffällt ist, dass es ne Menge Clt Relays sind und man sich überlegen sollte ob man die nicht mit etwas anderem ersetzen sollte.

Jetzt kann man am Ensemble schön sehen, dass sich alle Regler so verhalten wie sie sollen. wenn Master=0 ist gibt es keine negativen Modulationen, wenn Master =1 ist keine positiven. Wenn die summe gleichpoliger Modulationstiefen über eins ist Skalieren sie sich gegenseitig.

Jau, vielen Dank ohne den Thread hätt ichs nicht geschafft. Trozdem bin ich ein wenig stolz auf die Lösung auch wenn das vielleicht so manchem wie Kinderkram vorkommen mag.

Was mir vor allem geholfen hat ist die Ausformulierung der Problematik (steckt ja auch Formel drin in dem Wort)

So, jetzt sagt bitte nicht, dass es schon eine corecell gibt die genau das macht
und wenn, gelernt hab ich ne mange dabei.

Seht ihr die Notwendigkeit daran weiterzuarbeiten, bzw. gibt es überhaupt ne elegantere CPUschonendere Lösung?
Seht ihr da nen Fehler drin? Wirds Probleme geben, wenn ich die Corecell (Ohne die Graphischen Elemente) bis zu 20 mal in meinen T1 verwende?