Deutsches Reaktor Forum

Hallo,

das Programmieren von Core Macros ist schon sehr nett (weil super nachvollziehbar...)

Wenn man mal mit Pure Data oder MAx/MSP z.B. gearbeitet hat, dann passiert ja alles auf einer so feingranularen Ebene wie der Core-ebene... Also als Umsteiger auf Reaktor ist hier schonmal vieles logisch...

Ich denke, dass es auch sinn macht, zusammengehörige Baugruppen In Macros zu Bündeln... Zur Frage:

Macht es eigentlich Sinn, immer ein Core-Objekt innerhalb eines Macros zu programmieren? So wären ja schonmal alle dazugehörigen PAnelelemente mit einem Rahmen zusammengefasst... Zusätzlich ist es doch übersichtlicher, oder? Was meint ihr?

Beste Grüße,
HGH

hgh hat geschrieben:Hallo,

das Programmieren von Core Macros ist schon sehr nett (weil super nachvollziehbar...)

Wenn man mal mit Pure Data oder MAx/MSP z.B. gearbeitet hat, dann passiert ja alles auf einer so feingranularen Ebene wie der Core-ebene... Also als Umsteiger auf Reaktor ist hier schonmal vieles logisch...

Ich denke, dass es auch sinn macht, zusammengehörige Baugruppen In Macros zu Bündeln... Zur Frage:

Macht es eigentlich Sinn, immer ein Core-Objekt innerhalb eines Macros zu programmieren? So wären ja schonmal alle dazugehörigen PAnelelemente mit einem Rahmen zusammengefasst... Zusätzlich ist es doch übersichtlicher, oder? Was meint ihr?

Beste Grüße,
HGH

Hallo hgh
da gehe ich noch viel weiter: ich strukturiere alle meine Ensembles mit mehreren Makro und core-Makro-Ebenen. Da muss man natürlich seinen eigenen Stil finden.
Hier mal ein Beispiel bei meinem modular x Projekt: Auf dem Panel habe ich (in diesem Fall) einzelne Funktionsgruppen (hier Oszillatoren, LFOs, Mixer, Filter etc) auf dem Panel durch eine entsprechende Hintergrundgrafik voneinander abgegrenzt. Es geht natürlich auch weniger aufwändig einfach durch entsprechende Rahmenanzeige.
Innerhalb der Struktur behalte ich diese Makros bei. Es geht aber mehrere Stufen tief: Hier habe ich strikt (für alle entsprechenden Makros) dieselbe Struktur gewählt: Initialisierungen, das Panel (Regler, Schalter etc.) und die eigentliche Applikation. Diese kann ein reines Primary-Makro sein oder auch eine CoreCell oder sogar ein Gemisch von beiden. Ich bin zwar ein starker Vertreter der Core-Ebene, doch gibt es einige Dinge in Primary, die es leider in Core (noch) nicht gibt (Iterationen zum Beispiel).
Schauen wir mal in die Applikation des LFO 4 hinein: Auch innerhalb der CoreCell halte ich mehrere typische Makros bereit; zum Beispiel den Empfang der Paneldaten über einen Bus (siehe partials framework), der zugeführten Audiosignale (die Eingänge) und die interen Datenverarbeitung (hier ein phasenfester LFO mit fünf Phasen): usw. Ich habe hier zum Teil mehrere Ebenen übersprungen.

Eine Strukturierung durch Makros ist in meinen Augen unabdingbar, um ein pflegeleichtes Ensemble zu erhalten, insbesondere, wenn man es erweitern möchte oder es von vorne herein umfangreich geplant ist.
Wie man die Strukturierung vornimmt, ist, wie oben schon gesagt, der persönliche Stil.

ciao herw

Super,

vieeelen Dank für die Antwort
Gruß,
hgh