Physical Modelling

[Rampensau]

Hallo liebe Reaktorfreunde,

ein tolles Forum ist das hier. Ein paar nützliche Ding habe ich hier schon als stiller Mitleser in Erfahrung gebracht.
Ich bin seit einem guten halben Jahr mit dem Programm beschäftigt und kann jetzt schon Sachen machen, die ich schon immer machen wollte. Soviel vorerst zu mir.

http://www.brothers-in-music.de/Klangsy ... ing_HH.pdf

Ich habe hier was tolles gefunden und gehe das gerade ein bisschen durch.. Viel verstehen tue ich da nicht, aber ein paar nützliche Sachen konnte ich wenigstens abosrbieren. Habe mir zum Beispiel gerade die ersten beiden Wellenleiter gebaut.
Soweit funktionieren sie ganz gut. Ich muss noch schauen, ob das chromatisch gestimmt ist, also "alle meine Entchen kann man durchaus in allen Lagen erkenn.
Nur eine Frage hätte ich erstmal:
Die Arbeit bezieht sich auf Reaktor 2.x und da kommen Module vor, die es ja so nicht mehr gibt. Das Delay-Modul habe ich zum Beispiel schon also "eingerahmten" Pfeil nach links enttarnt.
Und da ist dieses kleine Modul zB auf Seite 71 beschriftet mit einer -1. Ist das einfach nur ein Invertierer, sprich -x?

Vielen Dank im Vorraus
Benni

[herw]

Hallo liebe Reaktorfreunde,

ein tolles Forum ist das hier. Ein paar nützliche Ding habe ich hier schon als stiller Mitleser in Erfahrung gebracht.
Ich bin seit einem guten halben Jahr mit dem Programm beschäftigt und kann jetzt schon Sachen machen, die ich schon immer machen wollte. Soviel vorerst zu mir.

http://www.brothers-in-music.de/Klangsy ... ing_HH.pdf

Ich habe hier was tolles gefunden und gehe das gerade ein bisschen durch.. Viel verstehen tue ich da nicht, aber ein paar nützliche Sachen konnte ich wenigstens abosrbieren. Habe mir zum Beispiel gerade die ersten beiden Wellenleiter gebaut.
Soweit funktionieren sie ganz gut. Ich muss noch schauen, ob das chromatisch gestimmt ist, also "alle meine Entchen kann man durchaus in allen Lagen erkenn.
Nur eine Frage hätte ich erstmal:
Die Arbeit bezieht sich auf Reaktor 2.x und da kommen Module vor, die es ja so nicht mehr gibt. Das Delay-Modul habe ich zum Beispiel schon also "eingerahmten" Pfeil nach links enttarnt.
Und da ist dieses kleine Modul zB auf Seite 71 beschriftet mit einer -1. Ist das einfach nur ein Invertierer, sprich -x?

Vielen Dank im Vorraus
Benni

Hallo Benni,

ein interessanter Link, den ich noch nicht kannte.
Ich habe insbesondere mal die hinteren Seiten überflogen. Leider sind die Abbildungen im Browser zu klein, um die einzelnen Module erkennen zu können. Vielleicht hilft ja da ein richtiger Ausdruck. Da ich die Version R2.3 besitze, könnte ich alle Module benennen und die Entsprechungen in R5, wenn diese größer wären. -1 ist sicherlich ein Inverter; den gibt es nach wie vor in PrimaryLevel und in Core. Ich würde sowieso an deiner Stelle versuchen, die Schaltungen direkt in core zu realisieren; siehe dazu insbesondere die Bemerkung im letzten Abschnitt auf Seite 117.
Henri Hagenow ist (freier?) Mitarbeiter von NI (siehe Danksagung im R5 Handbuch). Insofern könnte man mal versuchen, ob man nicht an neuere Schaltungen kommt. Wenn Du googlest, findest Du schnell eine Seite zu seinen Musikprojekten und dort auch seine eMail-Adresse.

ciao herw
achja :


PS: ah mit adobe reader kann man die Abbildungen gut erkennen; da findet man auch rechts die Formel, wobei diese nur die Identität darstellt, da sie nur t=t liefert; ich denke aber, dass das Gleichheitszeichen in dem Fall eine Zuweisung -> sein soll (Aufsplittung von t in zwei Anteile)

physical modelling S71.gif

Quelle: http://www.brothers-in-music.de/Klangsy ... ing_HH.pdf S.71
Hier ist mal die Umsetzung der Abbildung von Seite 71 in eine CoreCell in R5:

physical modelling1.gif

[herw]

Die weiteren Ausführungen sind sehr detailliert; ich hoffe die Makros sind alle vollständig, so dass man das nachbauen könnte. Ich werde mich da wohl mal hineinknieen.
Hier ist noch ein altes Interview mit Henri Hagenow.
Wichtig ist in diesem Zusammenhang natürlich in der user library : Acoustring v2.2 By Kristian Thom
und dazu das Klangerlebnis

ciao herw

[Rampensau]

Hallo Herw,
danke für die fixe Antwort. Den Acoustring habe ich auch schon angespielt, tue mich aber immer schwer, die Struktur fertiger Ensembles zu verstehen.
Deswegen habe ich mich noch gar nicht getraut, den mal unter die Lupe zu nehmen. Werd ich mal machen.

Das Geigenmodell habe ich nicht komplett implementiert bekommen, da für mich nicht verständlich beschrieben ist, wie die Makros integriert werden.
Habe es irgendwie auf gut Glück probiert. Irgendwie kamen auch Streicher raus, aber die Parametrisierung war mir dann trotzdem noch eher unklar.
Den ß- Regler, der ja zwischen zwei Zuständen regeln und die Impulsposition auf der Saite simulieren soll, steuert in meinem Modell eher die Tonhöhe. Ihn habe ich dann so gestimmt, dass auf C3 auch ein C klingt und durch eine Konstante ersetzt. Der "Nut"-regler heißt bei mir Decay.
Der Fractionalator hat bei mir scheußlich geklungen und dessen Integrierung wird auch nicht genau beschrieben.
Welche Werte die Regler ausgeben sollen, wird auch nicht überall beschrieben. Ich befürchte sie werden alle in den Formeln ausgedrückt, die ich nicht lesen kann.

Trotzdem habe ich erstmal, was ich wollte. Ich habe mir aus dem bidirektionalen Wellenleiter für ein Synth-projekt einen Resonator gebaut, der per Impulsgenerator oder Geiger-Oszillator den Audioinput ausließt und diesen mit den gestimmten Delays, was grob beschrieben die Wellenleiter sind(glaube ich), resoniert.
Das Ganze soll dann zum Originalsignal zumischbar sein, was ich dann einfach per Crossfade mache. Coole Streicher und "Saitenhiebe" gibt er jedenfalls schon her.
Witzig finde ich ja, dass durch den Geigeroszillator Geigenklänge zu prodzuieren sind.

Auf Seite 117 wird die Skriptabfolge angesprochen. Ist das in Core anders??
Jedenfalls bin ich gerade dabei, das, soweit ich kann, in Core zu implementieren. Habe erstmal die ganzen Delays durch corebasierte "4p" delays ausgetauscht. Und ich glaube, es funktioniert irgendwie besser. Und ist es nicht eine Idee, die Delays durch Diffusordelays auszutauschen. Die haben soweit ich weiß nen Allpass integriert. Das gibt bei solchen Sachen doch bestimmt interessante Auswirkungen.

Spielt es hierbei eigentlich eine Rolle, welche Genauigkeit die Coremodule besitzen. Ich habe einfach mal den groben Teil auf 64Bit gestellt.
Das P to F Modul spuckt beispielsweise bei 32 Bit schon vollkommen "falsche" Werte aus. Bei Default habe ich nicht mal ein 440Hz auf dem A. Was ja auf Primary-Level nicht anders ist. Merkwürdig ist, dass ich den Unterschied nur kaum wahrnehme.

[herw]

[...]
Auf Seite 117 wird die Skriptabfolge angesprochen. Ist das in Core anders??
Jedenfalls bin ich gerade dabei, das, soweit ich kann, in Core zu implementieren. Habe erstmal die ganzen Delays durch corebasierte "4p" delays ausgetauscht. Und ich glaube, es funktioniert irgendwie besser. Und ist es nicht eine Idee, die Delays durch Diffusordelays auszutauschen. Die haben soweit ich weiß nen Allpass integriert. Das gibt bei solchen Sachen doch bestimmt interessante Auswirkungen.

Spielt es hierbei eigentlich eine Rolle, welche Genauigkeit die Coremodule besitzen. Ich habe einfach mal den groben Teil auf 64Bit gestellt.
Das P to F Modul spuckt beispielsweise bei 32 Bit schon vollkommen "falsche" Werte aus. Bei Default habe ich nicht mal ein 440Hz auf dem A. Was ja auf Primary-Level nicht anders ist. Merkwürdig ist, dass ich den Unterschied nur kaum wahrnehme.

Der Artikel basiert auf der Version R2. Bis R4 konnte (musste) man nur auf primary level arbeiten.
In core (seit R5) gibt es den Begriff der Gleichzeitigkeit; eine CoreCell reagiert auf einen gemeinsamen ankommenden Event so, als ob danach alles gleichzeitig geschieht. D.h. alle Folgerechnungen liefern nur ein Ergebnis (im Gegensatz zu primary level, wo es eine Unmenge an Nachfolgeevents gibt).
In komplexen Ensembles, wie denen des PhysicalModelling muss genau beachetet werden auf welchen Event wann reagiert wird. Insofern muss die Rechenverarbeitung gut organisiert werden, so dass man nicht einen (sample-genauen) Versatz hat. Dies trifft insbesondere dann zu, wenn es sich um Audioevents handelt, die ja meistens Berechnungen zu einem vorangeangenen Event anstellen.
In Core ist das alles viel überschaubarer und logischer in der Abfolge.

zur Rechen-Genauigkeit: wenn es um Umrechnungen für Tonhöhen in Frequenzen geht, wähle ich grundsätzlich die höchste Rechengenauigkeit.
Für einfache Oszillatoren ist das nicht so wichtig. Wenn es jedoch um das Zusammenspiel und Beeinflussung mehrerer Audioquelllen geht (FM z.B.), dann bringen kleine errechnete Verstimmungen ganz andere Ergebnisse.

ciao herw