Deutsches Reaktor Forum

Hallo an alle,

mir sind beim nahezu ahnungslosen Herumpatchen in Primary ein par Fragen zur effektiven Erzeugung und Modulation von Sinus-Tönen in den Sinn gekommen.
Vielleicht kann mir von euch jemand weiterhelfen und Alternativen zu meiner ausprobierten Methode anbieten.

Ziel:
Ein Ensemble zur additiven Klangsynthese auf Mikroebene, sprich gezielte Anpassung und Modulation von Amplitude und Tönhöhe von einer hohen Anzahl an Partials.

Erfahrung:
Zunächst habe ich mir auf Grundlage von diesem Post ein einfaches Ensemble erstellt:
Mit Amplitude = 1 (Verhältnis: Amplitude/n) und Pitch = 0 (Verhältnis: Pitch->Frequenz | Frequenz*n) würde sich bei ausreichendern Anzahl an Schwingungen n in der Grundstellung eine Sägezahnwelle ergeben. Mein Gedanke war es, mit einem INIT-Snap mit einem aktiven Partial zu starten und nach und nach die benötigten "Obertöne" mit gewünschter Amplitude und Frequenz in Abhängigkeit zu jener Sägezahnwelle hinzu zu schalten. Wie zu erkennen ist, steuere ich dabei jedes Partial und dessen Multi-Breakpoint-Envelopes per Stacked Macro an.

Ist natürlich Geschmackssache ob man Lust auf diese Form der additiven Synthese ohne jegliche vorrausgehende FFT-Analyse hat. Aber ich vermute mit einem guten Grundstock an Snapshots, wenn man nicht jedes Mal von Null oder in diesem Fall mit einem Partial beginnen muss, könnte ich mich vermutlich mit dem hohen Grad an Einflussnahme (und damit verbunden, das langwierige Einstellen einzelner Partials) anfreunden.

ABER bei 30 Partials und damit verbundenen 60 M-BP-Envelopes lädt das Ensemble schon recht langsam (Größe bereits ~60MB) und die CPU freut sich ebenfalls über das rege Treiben.
Dieses Ergebnis war nicht ganz wieder meiner Erwartungen, aber dennoch hätte ich mir gewünscht mehr mit der Kombi Sine-Sync und MBP-Env erreichen zu können. Denn am liebsten würde ich natürlich gerne Partials bis hin zu einer vollständigen Sägezahnwelle (auch mit Grundtönen im Bassbereich) und deren Derivate aufsummieren können. Für percussives Material mögen 30 Schwingungen ausreichen, aber für tonalere Sachen höre ich da schwarz..

Gedanken und Fragen:
Ursprünglich wollte ich das Ensemble auf Grund der Vorahnung, dass ich schnell an die Leistungsgrenze stoßen würde, mit einer Sine-Bank realisieren, mangels Verständnis scheiterte dieses Vorhaben aber zunächst. Wäre es überhaupt möglich die Modulationsdaten etlicher MBP-Envelopes über den Partial-Stream [Partial Framework] weiterzugeben? Mir scheint es nämlich, als wäre die Partial-Engine eher für algrorhythmische Modulationen mit entprechender Veränderung bestimmter Parameter gedacht.

Meinem Empfinden nach, sind vor allem die MBP-Envs der Flaschenhals des Ensembles. Könnte man diese gegebenfalls optimieren oder gibt es bessere Alternativen zur gezielten Modulation von Ampl/Frequ? Vielleicht kann man ja (ob Core oder Primary weiß ich nicht) die Modulationsdaten von MBP-Envs speichern und auslesen, sodass nur zwei MBP-Envs für das gesamte Ensemble benötigt werden..
basierend auf einer Audio-Engine laufen die Envs ja vermutlich permanent..

Vielleicht hat/wurde hier ja schonmal jemand (von) ähnliche Gedanken verfolgt

Hallo
vielleicht ist ja das etwas für dich:
AddiZiner v1.0

ciao herw

Danke für den Hinweis!
Wurde auch schon von meinem - also dem von mir in meinem - also dem von mir installierten - Browser installierten - RSS-Reader-Add-on
auf den neuen UL-Upload aufmerksam gemacht Leider konnte ich mit dem Upload bisher eher nichts anfangen..

Der Editor with additive test engine v2.1 von Mike Dalliot scheint eher in die von mir angestrebte Richtung zu gehen,
aber ich muss mir wohl eingestehen, dass ein eigner Ausbau des Editors meine Fähigkeiten bisher übersteigt.

Naja, Not soll ja erfinderisch machen

pavel hat geschrieben:[…]Ziel:
Ein Ensemble zur additiven Klangsynthese auf Mikroebene, sprich gezielte Anpassung und Modulation von Amplitude und Tönhöhe von einer hohen Anzahl an Partials.
[…]

Das Problem ist, dass du dein Ziel sehr hoch gesteckt hast. Das Wissen, dass man mit einer hohen Anzahl an Partials dem Sägezahn zum Beispiel nahe kommen kann, zeigt, dass der mathematische Hintergrund bekannt ist. Das ist eine hohe Schwelle, um an einer Diskussion teilzunehmen. Mein Gedanke geht dann sofort zum Ensemble Prism, in dem mit einer hohen Anzahl an Partials (hunderte) gearbeitet wird. Um das in den Griff zu bekommen, muss auf core zugegriffen werden. Ansonsten endet man im primary schon bei einer Zugriegelorgel (was auch schön ist, aber nicht den Sinn deines Einstiegs trifft).
Um eine relativ hohe Zahl an Partials (und zwar -zig Partials) gescheit verwalten zu können, muss man wiederum auf Max Zaglers „partials framework” zurückgreifen. D.h. es bleibt nicht beim ahnungslosen Herumpatchen, sondern führt zu viel Les- und Experimentierarbeit.
Das soll dich nicht abschrecken, sondern einen Fingerzeig geben, wohin die Reise geht. Hab keine Angst vor partials framework, wahrscheinlich benötigst du nur den Part über das Multiplexing, also wie bekomme ich so viele Hüllkurven-Daten in eine CoreCell hinein? Das ist relativ schnell zu lernen. Falls du tiefer eindringen möchtest, so gibt es ein einfaches Beispiel von Max Zagler selbst.

Ich sehe trotzdem eine Einstiegsmöglichkeit:

Für einen Start in diese Materie kann man das primary Modul Sine x4 und anschließend das Modul Sine Bank verwenden.
Auch wenn du diese Module zunächst wegen des CPU-Verbrauchs der vielen MBP- (MultiBreakPoint-) Hüllkurven zur Seite legst. Warum müssen es unbedingt die MBP-Module sein? Ich finde sie programmiertechnisch zwar beieindruckend, aber man sieht als Normaluser keine Möglichkeit, sie zu vereinfachen. Ich würde hier lieber das normale core-ADSR-Modul nehmen und falls der CPU-Verbrauch zu hoch ist, die (nicht nötige) SampleRateClock auf zum Beispiel 400Hz herunterzusetzen. Das setzt den Verbrauch nämlich fast auf 0. Falls dir nicht geläufig ist, wie man eine reduzierte SamplerateClock erzeugt, so kann ich da in dem Projekt Hüllkurven in den nächsten Tagen ein Beispiel geben.
Wenn ich ein komplexes persönliches Thema beginne, dann erstelle ich mir zunächst mal einen roten Faden, an dem ich mich durch sehr (!) kleine Experimente weiter vortaste. Mir ist dann sofort klar, dass ich mich auf mindestens mehrere Monate (Jahre) Beschäftigung einlasse. Aber dazu ist ja REAKTOR auf der Entwicklerseite da. Vergleiche zum Beispiel die Projekte MoNokl, ACEW etc. .
Unter Umständen zieht man dabei hier einige (wenige) stille Leser mit und bekommt ab und an Tipps.

ciao herw

herw hat geschrieben:Warum müssen es unbedingt die MBP-Module sein?

Es müssen nicht zwangsweise die MBP-Module sein. Im Zentrum meiner Überlegung stand bisher lediglich,
dass ich mir in dem Ensemble den größt möglichen Einfluss auf die gegebenen Hüllkurven-Verläufe ermöglichen möchte.
Leider scheint dieser erste Ansatz sowieso eher weniger pratikabel zu sein,
da die Schritte (Partial für Partial editieren) einfach zu klein und undynamisch sind.

Der ursprüngliche Gedanke dahinter ist der, dass ich "dynamischere" (auf die einzelnen Partials bezogen) und "organischere" (nicht an physikalischen Modellen orientiert) Klänge,
als es mir bisher mit Subtraktiver und FM-Synthese möglich war, erzeugen will.
Morphenden Wavetables, zeitliche Veränderung der Amplitude einzelner FM-Operatoren, Unisono / Detune, Chorus, Phaser, Flanger, Kamm-Filter, Frequency Shifter, Hall, etc.
all dies bringt Dynamik in statische Wellenformen. Jene Elemente - selbst in zahlreicher Kombination untereinander - färben den Klang aber immer in einem bestimmten zeitlichen Muster.
Einerseits ist dies ja eine gewollte Vereinfachung von Prinzipien aus der der Akustik, aber andererseits auch immer ein - zumindest mir - zu starrer Rahmen.

Vielleicht habe ich das Grundprinzip der Klangsynthese nicht verstanden und gehe falsch an die ganze Sache heran,
aber bisher habe ich keinen Software-Synthesizer gefunden, bei dem ich sagen würde, dass ich zum einen klanglich an keine Grenzen stoße
und zum anderen dann auch noch zum Musik machen komme, sprich mich der Sound ausreichend zufrieden stellt, ohne dass ich ewig tweaken und layern muss.

herw hat geschrieben:Mein Gedanke geht dann sofort zum Ensemble Prism, indem mit einer hohen Anzahl an Partials (hunderte) gearbeitet wird.

Habe ich natürlich auch schon angetestet. Ich finde, man hat großen Einfluss auf die Relation der Obertöne, aber deren Amplitude konnte ich bisher noch nicht richtig "animieren".
Und wenn man Rauschen als Exciter-Signal verwendet, hört man das zu deutlich raus.

OT:
Im Zuge meiner prozessor-Engpässe habe ich dann auch schon mal ausgetestet, die SineSync-Module mit hochresonanten Bandpass-Filtern zu ersetzen
und mit einem dynamischen Geiger Osc, der seine Clicks per Seperator zufällig an die BPFs verteilt, anzusprechen.
Aber wie das mit dem Zufall so ist - es ist schwer ihn zu kontrollieren
Theretisch müsste bei einem Gate-On-Event erstmal alle BPs angesprochen werden und erst im weiteren Verlauf zufällig weiter erregt werden.
Außerdem müsste ich zunächst einmal die niedrigste regelmaßige Geiger-Rate pro Frequenz in Abhängikeit zur Resonanz finden, um eine konstante Wellenform zu bewerkstelligen
und dann davon ausgehend, anfangen die zufällige Erregung wieder ins Spiel zu bringen.
Habe die Idee, auch noch nicht ganz aufgegeben, aber sie bedarf sicher noch einiger Experimente..

herw hat geschrieben:Hab keine Angst vor partials framework, wahrscheinlich benötigst du nur den Part über das Multiplexing, also wie bekomme ich so viele Hüllkurven-Daten in eine CoreCell hinein? Das ist relativ schnell zu lernen.

Lässt sich diese Frage dann schlussfolgernd mit Ja beantworten?

pavel hat geschrieben:Wäre es überhaupt möglich die Modulationsdaten etlicher MBP-Envelopes über den Partial-Stream [Partial Framework] weiterzugeben? Mir scheint es nämlich, als wäre die Partial-Engine eher für algrorhythmische Modulationen mit entprechender Veränderung bestimmter Parameter gedacht.

herw hat geschrieben:Wenn ich ein komplexes persönliches Thema beginne, dann erstelle ich mir zunächst mal einen roten Faden, an dem ich mich durch sehr (!) kleine Experimente weiter vortaste. Mir ist dann sofort klar, dass ich mich auf mindestens mehrere Monate (Jahre) Beschäftigung einlasse. Aber dazu ist ja REAKTOR auf der Entwicklerseite da. Vergleiche zum Beispiel die Projekte MoNokl, ACEW, Modular X etc. .
Unter Umständen zieht man dabei hier einige (wenige) stille Leser mit und bekommt ab und an Tipps.

Wäre schön, die Entwicklerseite ließe sich in dem Beschäftigungszeitraum von nur mehreren Wochen mit der Musikerseite verbinden
Vielen Dank, auf jeden Fall für Rat und Tat!

pavel hat geschrieben:[…] Wäre es überhaupt möglich die Modulationsdaten etlicher MBP-Envelopes über den Partial-Stream [Partial Framework] weiterzugeben? Mir scheint es nämlich, als wäre die Partial-Engine eher für algrorhythmische Modulationen mit entprechender Veränderung bestimmter Parameter gedacht. […]

Das Multiplexingsystem ist für Eventquellen gedacht. Es ist überhaupt kein Problem hunderte Daten „gleichzeitig” zu schicken. Das können auch ADSRs und LFOs mit Eventausgängen sein.
Du könntest auch EventTables benutzen. Der Sinn des Multiplexingsystems ist es, sehr sehr vielen Eventdaten über eine Leitung in eine CoreCell zu schicken.

Aber deine Pläne sind schon sehr weitgehend, so dass ich als Leser nur noch begleitende Gedanken loswerden kann.
Wenn du dieses Projekt weiter hier verfolgen willst, dann schiebe ich es ins Subforum „Projekte”.

ciao herw

Danke.

Ich denke, ich werde erstmal wieder weiter im Stillen herumprobieren.
Habe mich jetzt noch mal eingehend mit den Möglichkeiten von Prism beschäftigt
und bin doch zu recht brauchbaren Ergebnissen gekommen.
Das A und B Comb-Pattern Shifting bietet bei größerer Mausresolution doch ein recht großes und fein einstellbares Spektrum an "Partial-Animationen".

hat sich mal wieder bewahrheitet, dass es am Besten ist, keine voreiligen Schlüsse zu ziehen..