Primary/Core Frage

[rachMiel]

> herw, from Reaktor User Forum: i would like to hear, how you want to use the combination of primary and core.

Ich möchte mir Primary und Core als Muttersprachen von Reaktor vorstellen, mit dem Ziel, durch fließende Unschaltung zwischen ihnen zu sprechen (Ensembles zu bilden). Der genaue Grund, warum ich mich für die eine oder andere entscheiden würde, hängt von der Situation ab. Ich könnte ein Primary Makro benutzen, weil es sich gut anhört und einfach anzuwenden ist. Ich könnte ein Core Makro benutzen, weil ich damit bequemer auf die Sample-Clock-Ebene zurückkehren könnte.

Die wichtigsten Dinge, die ich vermeiden möchte, wenn ich mich zwischen Primarz und Core bewege, sind eine Klangverschlechterung (Klicks, Artefakte, geringere Qualität usw.) und ein erheblicher Rechenaufwand (computational overhead).

[herw]

> herw, from Reaktor User Forum: i would like to hear, how you want to use the combination of primary and core.

Ich möchte mir Primary und Core als Muttersprachen von Reaktor vorstellen, mit dem Ziel, durch fließende Unschaltung zwischen ihnen zu sprechen (Ensembles zu bilden). Der genaue Grund, warum ich mich für die eine oder andere entscheiden würde, hängt von der Situation ab. Ich könnte ein Primary Makro benutzen, weil es sich gut anhört und einfach anzuwenden ist. Ich könnte ein Core Makro benutzen, weil ich damit bequemer auf die Sample-Clock-Ebene zurückkehren könnte.

Die wichtigsten Dinge, die ich vermeiden möchte, wenn ich mich zwischen Primarz und Core bewege, sind eine Klangverschlechterung (Klicks, Artefakte, geringere Qualität usw.) und ein erheblicher Rechenaufwand (computational overhead).

Hallo rachmiel und wiederum
Das mehrfache Wechseln zwischen primary und core ist meistens nicht sinnvoll. Insbesondere ein Test mit 100 Stimmen und Vergleich ähnlicher Strukturen in primary und core (siehe dein Vorschlag im englischen Forum) bringt nichts.
Abgesehen davon, dass, wie dort erwähnt, die Initialisierungen aus primary dann mehrfach die Struktur beeinflussen können (abgesehen von der unsäglichen Abhängigkeit, wie Kabel in primary erstellt wurden (Gleichzeitigkeit ist verletzt)) ist ein Vergleich nur bedingt möglich, da ja in primary komplexe Module nur als Blackbox verfügbar sind, während man in core bis tief in die Struktur eingreifen kann.
Ich kann nichts zu den Sample-modulen des primary sagen, da ich mich damit nicht beschäftige.
Ich benutze in meinen Ensembles (die eigentlich nur auf dem modular framework basieren) primary ausschließlich für das GUI. Da von dort nur einfache events kommen, lasse ich der Einfachheit halber auch core cell einfließen, wenn es um Berechnungen und den eventbus aus partials framework betrifft. Core wird ausschließlich durch die eintreffenden Initialisierungsevents aus primary bedient und erzeugt selbst keine events. Ein sehr großer Vorteil ist die Geichzeitigkeit der Berechnungen. Alle events, die aus einer Quelle stammen, werden als gleichzeitig behandelt, was in primary absolut nicht gilt und dort sehr hinderlich ist.
wenn du mehr über Initialisierungen lesen möchtest, dann ist die Initialisierungstabelle von Mark ein absolutes Muss, genauso wie die Benutzung seines ACEWs für primary und core. Ein sicheres Analysemodul gibt es nicht. Ohne ACEW gäbe es das modular framework nicht.
Alle (audio-) Signalverarbeitungen packe ich in eine einzige Corcell, was einen CPU-Vorteil bringt, ganz davon abgesehen, dass sich die Strukturen viel besser lesen und pflegen lassen.
Eigene Filter, Oszillatoren und Hüllkurven zu erstellen, sind eine echte Freude.
Da die Corecell in der Regel polyphon ist, braucht man natürlich für die Effekte noch eine zusätzliche monophone corecell. Insofern muss ich core kurzzeitig verlassen.
Natürlich hat core auch Nachteile: keine Iteration (nur über einen allerdings einfachen Trick mit einer primary Schleife (siehe partials framework)), keine Order (wegen der Gleichzeitigkeit), kein Voice-Management (FromVoice, ToVoice, Voice-Shift). Ich hoffe immer noch, dass Vadim Zavalishin sich mal dahinter klemmt.
Trotzdem komme ich mit dieser strikten Trennung sehr gut zurecht. Die Kommunikation aus der Corecell heraus ins primary ist manchmal etwas tricky. Zum Beispiel musste ich für die Anzeigeelemente eines Sequenzers aus core zu primary schon einen Trick anwenden (shared eventtable), um nicht ein Kabelwirrwarr zu erzeugen.
Ein weiterer Vorteil innerhalb einer großen Corecell ist die Verbindung mit Feldern, die sich in Core sehr einfach über viele Makros einbinden lassen.

Für mein Arbeiten mit core hat sich als großer Vorteil erwiesen, dass sich die Denkweise mit events im Kopf Eins-zu-Eins in core übertragen lässt.

Ich bin, wie viele wissen, ein großer Fan von Core; geht es um richtig komplexe Vorgänge, dann ist man dort am besten aufgehoben. Beschäftigt man sich einige Zeit mit Core, dann wünscht man sich die Vorteile auch für primary.

Ich lese gerade nochmals deine Post durch: „Ich könnte ein Core Makro benutzen, weil ich damit bequemer auf die Sample-Clock-Ebene zurückkehren könnte.”
Warum willst du auf die Sample-Clock-Ebene in primary zurück? Selbstverständlich gibt es in core die sample-Clock und noch viel mehr und lässt sich wesentlich einfacher handhaben.

ciao herw

PS: Am besten, du probierst ein einfaches Projekt aus, wie du es dir in der gemischten Form primary/core vorstellst, dann können hier sicherlich Einige hier darauf antworten und Tipps geben.

[rachMiel]

herw, vielen Dank für die umfassende Antwort! Ich muss darüber nachdenken, werde morgen antworten.

Nur eins jetzt ... du fragst warum ich auf die Sample-Clock-Ebene in primary zurück will. Ein Beispiel: Sample-Clock genauen Steuerung der Samples, die das Beat-Lookup-Modul ausgibt.

[herw]

herw, vielen Dank für die umfassende Antwort! Ich muss darüber nachdenken, werde morgen antworten.

Nur eins jetzt ... du fragst warum ich auf die Sample-Clock-Ebene in primary zurück will. Ein Beispiel: Sample-Clock genauen Steuerung der Samples, die das Beat-Lookup-Modul ausgibt.

achso; wie gesagt ich kenne mich mit dem sample-Bereich von REAKTOR überhaupt nicht aus.