Deutsches Reaktor Forum

Hallo Reaktoren/Innen,
ich wollte meine Schaltmatrix a´la EMS Synthi A auf 64*64 erhöhen, stoße aber im (Normal-) Macro mit 40 Ein- oder Ausgängen an die Grenzen von Reaktor5.
Wie kann ich diese Grenzen überschreiten? Core?
Gruss... fRANK

Das Problem kenn ich gut. Die maximale Anzahl an Core-IO hab ich noch nicht ausprobiert (schätze mal, das es vielleicht auch nicht immer weiter helfen könnte), aber Du könntest mal versuchen mit den „Drahtlosen“ -(Send/Recieve) zu arbeiten und bestimmte Signale die mehrfach innerhalb der Struktur benötigt werden, damit weiter zu routen. Das frisst aber uU. einiges an Performance und kann auch zu einer nervigen Angelegenheit werden, wenn man solche Macros über das Clipboard mehrfach einkopiert und per Hand die Send/Recieve-Zuordnung korrigieren muss, weil Reaktor hier manchmal Alzheimer bekommt.....

Letztendlich ist das sogar ein generelles Problem: Wenn die Komplexität von solchen „Supermacros“ an der 40er-Hürde scheitert, kommt man nicht drum herum, die Schaltung komplett umzustrukturieren. Das kann jedoch -je nachdem wie weit man bereits fortgeschritten ist- in einer Sackgasse enden und die gesamte Schaltung wird am besten von Grund auf neu aufgebaut.

Gruss
Peter

KlangRaum hat geschrieben:Das Problem kenn ich gut. Die maximale Anzahl an Core-IO hab ich noch nicht ausprobiert (schätze mal, das es vielleicht auch nicht immer weiter helfen könnte), aber Du könntest mal versuchen mit den „Drahtlosen“ -(Send/Recieve) zu arbeiten und bestimmte Signale die mehrfach innerhalb der Struktur benötigt werden, damit weiter zu routen. Das frisst aber uU. einiges an Performance und kann auch zu einer nervigen Angelegenheit werden, wenn man solche Macros über das Clipboard mehrfach einkopiert und per Hand die Send/Recieve-Zuordnung korrigieren muss, weil Reaktor hier manchmal Alzheimer bekommt.....

Letztendlich ist das sogar ein generelles Problem: Wenn die Komplexität von solchen „Supermacros“ an der 40er-Hürde scheitert, kommt man nicht drum herum, die Schaltung komplett umzustrukturieren. Das kann jedoch -je nachdem wie weit man bereits fortgeschritten ist- in einer Sackgasse enden und die gesamte Schaltung wird am besten von Grund auf neu aufgebaut.

Gruss
Peter

Die Beschränkung gibt es bei Core-Makros ebenfalls. Eine Schaltmatrix mit vielen Schaltmöglichkeiten sollte man in keinem Fall mehr durch direkte Verkabelungen konstruieren. Die Drahtharfe wird gigantisch. Auch das GUI sollte man sich genau überlegen. Eine 64mal64 Schaltmatrix ist unübersichtlich, auch wenn vielleicht aus historischen Gründen das gewollt ist. PullDown-Menus sind ab einer bestimmten Länge auch nicht gerade wünschenswert, aber zumindest wesentlich Platz sparender. Verkabelungen auf dem Bildschirm sind offenbar nicht jedermanns Sache, obwohl sie sehr praktisch sind.
Es geht dir aber offensichtlich um eine Emulation, daher ist das GUI quasi vorgegeben durch eine Schaltmatrix.

Es gibt zwei Möglichkeiten, die 40-Ports-Grenzen weit zu überschreiten:
Wie Klangraum richtig beschreibt, kann man mit send-receive-Verbindungen im primary-Level das Problem elegant umgehen. Hier gibt es keine Beschränkungen, doch erfordert die Verwaltung eine sorgfältige (logistische) Vorbereitung der gesamten Struktur: welche Art von Informationen sollen eingespeist werden (Event-Signale, Audio-Signale, Steuersignale, monphon, polyphon). Wie werden die Schaltungen gesteuert (IC-Send-Receive !)?
Das erfordert aber einigen programmiertechnischen Aufwand in der Logik.
Eine weitere Möglichkeit besteht in einem Eventbus. Es ist damit möglich, auf einem Port mehrere Informationen „parallel” zu verarbeiten, also zum Beipiel ein LFO-Signal und ein ADSR-Signal und ein Regler-Signal können unabhängig Informationen über dieselbe Leitung schicken. Hier wird ausgenutzt, dass Events immer augenblicklich verarbeitet werden. Gibt man diesen Events ein Kennzeichen mit (verschlüsselte Adresse), kann man diese über eine Leitung einspeisen und durch eine Entschlüsselung wieder trennen. Klingt sehr kryptisch, ist aber einfach realisierbar: zum Beispiel möchte man ein ADSR-Signal und ein LFO-Signal parallel über eine Leitung schicken. Beide Signale haben die Amplitude 1. Addiert man zum ADSR-Signal eine konstanten Wert (zum Beispiel 2), so schwankt das LFO-Signal zwischen -1 und +1, das ADSR-Signal zwischen 2 und 3. Durch einen Comparator und Router kann man die Signale ohne weiteres wieder trennen. REAKTOR ist so schnell, dass man sehr viele Event-Signale auf diese Art und Weise über eine Leitung verschicken kann.
Es gibt hier noch andere Möglichkeiten, zum Beispiel, indem man jeweils durch die Eventquelle zwei Events erzeugt, wobei der eine das eigentliche Wertesignal ist der andere eine Adresse.
Bei Audiosignalen kann man die Send-Receive-Verbindungen nehmen. Ein Audiobus (mehrere Audiosignale parallel auf einer Leitung) ähnlich dem oben beschriebenen Eventbus ist durch unterscheidbare Sample-Rate-Clocksignale möglich (wurde schon mal diskutiert), aber sehr CPU-intensiv und lohnt sich letztendlich nicht.

ciao herw

herw hat geschrieben:...Die Drahtharfe wird gigantisch....

Du sagst es.....
Letztendlich ist dieser Punkt eine der natürlichen Grenzen bei Reaktor - neben der verfügbaren CPU-Leistung

Mit dem Event-Bus nimmst Du mir das Wort ausm Mund, da wollte ich grade eben noch was dazu schreiben, heut Nacht war es mir zu spät. Vielleicht kannst Du das ja übernehmen.

Eines muss ich noch erwähnen: Bei Macros mit umfangreichen Send/Recieve-Ports, die von ihrer Logik wahlweise Audio und Event „transportieren" sollen, gibt es beim einkopieren häufig Zuordnungsprobleme (Siehe Liste in den Properties). Prinzipiell ist es jdoch machbar und eröffnet ganz neue Möglichkeiten im Bereich der Modularisierung. Momentan beschäftige ich mit mit anderen Dingen und habe noch keine endgültige Lösung. Falls jemand über diesen „Fehler“ stolpern sollte, nicht weiter wundern, weder Reaktor noch der PC sind kaputt....
It's not a bug, it's a...... bullshit

Natürlich kommt mein Matrix-Konzept aus der Vergangenheit "EMS lässt grüssen". Es ist aber nicht nur meine Erinnerung die mich dort weiter treibt, viel mehr die Einfachheit und die Logik. Um die Übersicht meiner aktuellen 32*32-Matrix zu bewahren, hinterlege ich bestimmte Ein/Ausgänge farblich.

An die Send/Recieve-Macros hatte ich mich auch mal versucht, habe aber in Live-Einsätzen sehr schnell die Übersicht verloren. Bei mir liefen die Adressierungen fehlerfrei, war aber eine erheblich kleinere Arbeitstabelle als 32*32 Zuweisungen. Um die Adressenübersicht zu behalten hatte ich bei der Konfiguration dieser Send/Recieve-Macros parallel eine Excel-Tabelle laufen.

Um eine schnelle Übersicht zu erhalten, benötigt unser Auge eine klare visuelle Zuordnung, wie eine Matrix oder direkte Verkabelungsoptik, die aber das Gesamtbild schnell überfrachtet. Eine Zuordnung per Text-Zeilen ist meines erachtens NICHT für schnell aber kontrollierte Übersichten geeignet.

Zur Verdeutlichung, hier mal ein Abbild meine EMSAVSplus v2.3;
http://www.befreite-musik.de/images/emsavsplusv230.jpg
Die 32*32-Matrix ist in einem separaten Macro eingebettet und besteht aus 5 Macro-Ebenen. Jetzt wollte ich eine 6te drüber setzen und somit 2Stück 32*32-Macros zu summieren.
Ich könnte die Erweiterung (> 40Ports) auch in das Hauptfenster, das sämtliche Instrumenten-Macros verbindet, einbringen. Diese Unsauberkeit würde aber meiner Programmier-Ethik vollkommen widersprechen.

... fRANK

Ja, das mit der Übersicht und dem „Auge braucht visuelle Zuordnung“ ist so ne Sache...
Deswegen mach ich kein GUI-Design - ich hab mit den Schaltungen schon genug Stress um die Übersicht zu behalten....


Vielleicht mal als Idee: Trenn Dich von einer X mal X Matrix.....

Du hast X Signalquellen und Y Signaleingänge. Bei Send/Recieve brauchst Du eigentlich kein festes Schema in Form einer „echten Matrix“
Du musst Dir nur vorher überlegen, weche Signale unbedingt als Audio verschickt werden müssen und bei welchen ein Event ausreicht. Geschickt eingesetzt kannst Du viel Performance sparen, wenn Steuersignale generell als Event übertragen werden
Dabei gilt folgende Regel: Senderseitig Eventfilter nicht vergessen um gleichartige Events und deren Bearbeitung zu vermeiden und dort wo es Sinn macht, empfängerseitig eine Rampe mit 5-10-20 mSec vorschalten um Signalsprünge ein wenige zu glätten, falls sie hörbar werden und stören könnten.

Bei mir läuft das darauf hinaus, das ich eine Bibliothek benutze, deren Module zb. exakt definierte Ein- & Ausgangssignale und Pegel benutzen. Die Überlegung geht sogar dahin, das ein LFO oder ADSR ohne weiteres seine Signale als Event übertragen kann -bis auf nur wenige Ausnahmefälle.
Herw's Eventbus ist dafür geeignet, ich habe halt nur früher schon ein anderes Konzept verfolgt, sonst hätte ich es genauso gemacht

Ab einer größeren Zahl von Verknüpfungsmöglichkeiten (auch 64 mal 64 sind noch nicht wirklich viel) ist es vorbei mit der Übersichtlichkeit. Jeder Patch ist dann das Ergebnis einer längeren Probiersitzung im Studio. Das gute daran ist, dass man dann den Patch als Snap abspeichern kann.
Insofern müssen eine Matrix, Pulldown-Menu oder auch GUI-Kabel nicht für den Livebetrieb unbedingt direkt übersichtlich sein.
Ich persönlich würde in einem zukünftigen modularen Softsynth sogar zwei bis drei GUI-Ebenen vorsehen:

A die Live-Benutzer Ebene, in der nur die wichtigsten Komponenten abgebildet sind und es nur wirklich wenige Regler und Anzeigeelemente gibt (z.B. in der Größenordnung von KORE 2). Die Regler müssen beliebig allen Reglern des gesamten Ensembles frei zugeordnet werden.

B die Grobstruktur des gesamten Ensembles als Flussdiagramm. Hier wäre es schön, wenn man die einzelnen Komponenten (Module) in der Gesamtheit sehen könnte (auch evnetuell als scrollenden Bildschirm, wenn das Ensemble sehr groß ist.

C die Verknüpfungen zwischen den Modulen sollten in einer dritten Ebene zu sehen sein, entweder wie Du es vorschlägst in einer Matrix (was bei einem großen Modulsystem mit mehreren Hundert Ein- und Ausgängen leicht zu einem sehr großen Schachbrett wird) oder zu einer großen Modulationsliste, die Patchkabel emuliert durch einen Send-Receive Auswahl mit Abschwächern oder, wie ich es bisher gemacht habe, mit einer Verkabelung direkt auf dem GUI der Ebene B.

Hier ist durch Auftrennen ein neuer Thread entstanden: Normierung von Wertebereichen

Wichtig ist vor allen Dingen, dass man das Interface der einzelnen Module unbedingt normiert, wie Klangraum es erwähnt.
Hier gibt es die Möglichkeit, z.B. Werte zwischen -1 und +1 oder -64 und +64 als Maß zu nehmen. Damit man alle Module mit allen Modulen verbinden kann muss man sich über solche „Nebensächlichkeiten” vorher Gedanken machen. Auch muss an die Pflege des Ensembles gedacht werden, was du offensichtlich tust, wenn ich deine Post richtig deute, damit auch ein späteres Erweitern, Ergänzen, Updaten einfach ist.

ciao herw

KlangRaum hat geschrieben:[...] Geschickt eingesetzt kannst Du viel Performance sparen, wenn Steuersignale generell als Event übertragen werden.
Dabei gilt folgende Regel: Senderseitig Eventfilter nicht vergessen um gleichartige Events und deren Bearbeitung zu vermeiden [...]

hmm - das schränkt ein z.B. bei gesendeten Triggerevents (gleicher Pegel!) oder Clocksignalen.

herw hat geschrieben:hmm - das schränkt ein z.B. bei gesendeten Triggerevents (gleicher Pegel!) oder Clocksignalen.

Da haste recht, ist aber ein generelles Problem....

Hallo zusammen,
leider habe ich nicht alles von dem Vorhergeschriebenen verstanden. Meine Essenzen und Probleme im Folgenden;

(1)
Die PullDown-Zuordnung wie es beispielsweise beim Ensemble "CARBON 2", ob mit oder ohne Festverdrahtung, ist mir zu unübersichtlich. Hierbei ist ev. nur noch der Quellenweg (Richtung Ziel), nicht aber rückwärts nachvollziehbar!
Auch währe die Tabelle an jedem Sende-Parameter viel zu lang, um die gleiche Flexibilität wie eine 40*40-Matrix zu emulieren.
(2)
Send/Receive-Module dienen der Übersicht bei komplexen Schaltungen, nehmen aber immer Rechnerkapazität in Anspruch, wobei man sich bei Event-Strecken schnell ungewollt eingeschränkt. Sinn würde diese Art der Verdrahtung tatsächlich nur bei einer praktikablen Matrix-Alternative.
(3)
Ein Instr. in mehrere Ebenen aufzubauen ist äusserst reizvoll. Besonders glücklich und elegant finde ich die "CARBON 2"-Lösung. Sieht aber auf der Programmierebene aber äusserst kompliziert aus.
Ich hatte mein EMSAVSplus testhalber auf 2 Ebenen (Module auf A und Matrix auf B) aufgebaut. Wenn ich aber schnell spielen musste, ist mir die Bedien- und Verbindungsübersicht aber auch hier zeitweise verloren gegangen.
(4)
Nun, da ich erst mal die Matrix auf das Maximum von 40*40 Knoten (40*40 Ports) aufblähen werde, wollte ich in CoreCell einsteigen.
Mein aktueller Primary-Aufbau der Matrix stützt sich auf einen "switch" als Knotenpunkt mit einem anschliessenden "mixer", der mehrere "switch"-Audiosignale letztlich zusammen führt. Dieser Aufbau wird im Anschluss nach belieben über weitere "mixer" kaskadiert. Funktioniert einwandfrei, verschlingt aber auch ordentlich Prozessorkapazität (vermutlich durch die vielen Mixer)!
In der CoreCell-Bedienungsanleitung (=BA) habe ich leider keinen "switch" gefunden, so dass ich diesen aus "Flow/Router", der über einen "Primary-Modul/Button" geschaltet wird herstellen muss. Anschliessend käme zur Bündelung ein "Audio Mix-Amp/Mixer 2…4" in Frage.
??? Habt ihr da eine intelligentere Lösung???
(5)
Mein Problem ist aber auch, das ich nach Rechtsklick ein reduziertes PullDown-Menü habe. Bei mir erscheinen die Menü-Punkt "Expert Macro" und "Standard Macro" nicht.
??? Handelt es sich um eine Reaktor5-Konfigurationseinstellung oder um eine fehlerhafte Reaktor5-Installation???

Nun, da ich erst mal die Matrix auf das Maximum von 40*40 Knoten (40*40 Ports) aufblähen werde, wollte ich in CoreCell einsteigen.

versteif da da nicht zu sehr drauf, denk rechtzeitig über ne konstruktionsalternative nach. core kostet zt immense prozessorzeit....

Ist Core bei Schaltern- und Mixernkaskadierungen vorteilhaft oder nicht?
Ich denke da an "herw´s" Gleichzeitigkeits-Vortrag, weniger bei Schaltern (Router), sondern bei Mixern die ich massenhaft verwende.