Mann oh Mann, manchmal bist du echt schwer zu verstehen. Ich würde gerne schnell antworten, aber ich brauche mehrere Minuten, um zu kapieren, was du meinst. (
sorry), wenn ich es überhaupt kapiere.
Eventmanager hat geschrieben:[...]
Erste Frage zu prim und core. Generell ist wohl konsens sowenig zwischen prim- und core herumzuwurscgteln, aber betrifft das auch reine Event-Cells, oder nur Sachen wo ne Sample-Clock oder ähnliches verwendet werden muss?
(???) Nach einer (realen) Dusche und ca. 15 Minuten habe ich es gerafft:
Also: Ist es sinnvoll, so wenig wie möglich zwischen der primary-Ebene und core-Ebene zu wechseln? (sorry, ich muss die Frage zunächst mal für mich selbst sortieren.
)
Ja es ist sinnvoll, und zwar insbesondere auch bei reinen primary events. Der Grund ist das unterschiedliche Initialisierungsverhhalten und zwar in den einfachsten Fällen. Die primary-Ebene kann im Gegensatz zur core-Ebene selbständig events von Panelelementen und Konstanten erzeugen. In core gibt es als einzige Quelle die SampleRateClock SRC. Alle anderen Quellen stammen von den CoreCell-Eingängen ab. Core-Konstante erzeugen keinen event!
Core unterscheidet im Gegensatz zu primary nicht zwischen audio-events (SRC-synchronisierte events) und events, die über das primary-GUI über die Eingänge importiert werden.
Ein häufiger Wechsel zwischen primary und core kann zum Beispiel bewirken, dass durch die zwischengeschalteten primary-Makros eventuell zusätzliche events in die folgenden CoreCells gelangen, die nicht erwünscht sind oder einer anderen Synchronisation unterliegen. Bei überschaubaren Ensembles, die vor allem unkritisch gegenüber GUI-event-Initialisierungen sind, wird das keine große Sache sein.
Die Frage ist natürlich, warum man überhaupt zurück zu primary wechseln soll, wenn man eh schon vorhat, Berechnungen in core vorzunehmen. Nun, die Berechnungen in primary sind verglichen mit den Möglichkeiten in core (64-bit Rechengenauigleit) ohnehin schon arg beschränkt. Bei einfachen Berechnungen mag das unwichtig sein, aber ich kann dir gerade an dem Beispiel des fuzzy-Vergleichs grundlegende Unterschiede aufzeigen, die ein völlig unterschiedliches Verhalten nach sich ziehen.
Will man ernsthaft in die Core-Programmierung für große Projekte einsteigen, dann ist die strikte Trennung von GUI-Bearbeitung (in primary) und Signalverarbeitung (in core) absolut Pflicht. Primary verwendet man dann nur als Datenquelle aus dem GUI und zur Anzeige (EventTables, numerische Anzeigen etc.).
Man umgeht dann Schwierigkeiten bei der Initialisierung.
Es gibt eine wundervolles kleines essay (siehe Anhang) von Max zum Thema threads in Reaktor - einfach zu lesen und eindrucksvoll.
huh.jpg
Ich zähle 5 Dup Fit Macros...
wo? wieso 5?
der Unterscheid zwischen I(nterger) und und non-I (ergo float) ist schon klar, ebenfalls die Toleranzversion, aber was unterscheidet die anderen beiden Varianten?????
also: bitte lieber langsamer, dafür aber verständlicher schreiben, wenn möglich mit einem kleinen screenshot, wie du es ja weiter unten machst, damit ich weiß, worüber wir reden.
Übrigens kannst du die angefügeten screenshots direkt an der passenden Textstelle einfügen und im Beitrag anzeigen, indem du ...
im Beitrag anzeigen.jpg
...kurz anklickst.