Jetzt ist der MODULAR ca. drei Wochen in der User-Library.
Der "Lohn" sind etwa dreihundert Downloads - wenig Kritik/Lob , was allerdings zu erwarten ist, da, wie schon woanders ausführlich diskutiert, die User Library mehr als download-Quelle mit Sammelwert genutzt wird (da will ich mich nicht ausschließen, da ich auch häufig nur einfach für mich interessante Ensembles downloade und dann doch nicht wieder benutze und in der Regel nur selten einen Kommentar hinterlasse).
Einige kompetente und einflussreiche Benutzer des MODULARs haben sich positiv geäußert, was mir zeigt, dass sich für diese die Arbeit lohnt.
Für mich selbst ist der Abschluss des Projektes MODULAR m1 äußerst befriedigend, da ich es geschafft habe, dieses zeitlich nun schon so lange laufende Projekt wirklich zum Abschluss gebracht zu haben. Es entspricht meinen optischen und klanglichen Vorstellungen äußerst stark und mir macht es immer wieder Spaß, damit Musik zu machen.
Was wird die Zukunft sein: nun das Konzept ist so offen, dass ich natürlich weitere Module und größere Ensembles entwickeln werde. Der grundsätzliche Aufbau kann dabei voll übernommen werden.
Das ursprüngliche Ziel, ein Experimentierlabor für letztendlich sehr kompakte Ensembles zu schaffen, ist in den Hintergrund gerückt, habe ich aber dennoch nicht aus den Augen verloren. D.h. ich werde mir bestimmte Patches aussuchen, die ganz bestimmte Klangrichtungen ergeben und diese in kleine Ensembles umstrukturieren, die dann nur einen beschränkten spezialisierten Klangaspekt herausgreifen.
Damit habe ich schon begonnen, lasse mir damit aber auch Zeit und Muße. Ein Testaufbau ist schon in Arbeit. D.h. es werden für diese spezialisierten Ensembles keine Patches nötig sein. Ich versuche nur den Patch (fest verkabelt) nachzubauen und die Panelelelemente auf das nötigste zu reduzieren.
Bei einem solchen Re-Engineering eines solchen Patches ist mir aufgefallen, wo überhaupt die meiste CPU-Belastung entsteht: es ist beim Interface zwischen Primary- und Core-Level und zwar bei den Audioeingängen. Wenn man die Audioeingänge vermeiden könnte und nur Events zulässt, spart man sich einen Großteil der Belastung. Da ist schon die
neue Idee geboren:
Kann man es schaffen, die gesamte Audiosoftware auf Core-Ebene zu belassen und nur vom Panel aus Events dort einzuschleifen?
Gerald (krümelmonster) beschäftigt sich schon lange mit solchen Überlegungen und hat schon riesige Audio-Strukturen (mit mehr als 5000 Modulen) in eine AudioCoreCell gepackt (Reaktor meckert ab einer solchen Größenordnung und verlangt weiteres Nesting durch Makros).
Seine Idee mal weiter gesponnen: ist es günstig, das Primary-Level nur noch für die Panelelemente zu benutzen und den Rest der AudioCoreCell zu überlassen? Für einen Modular ergäbe sich dann allerdings die Notwendigkeit, die vielen Eventquellen (Regler, Schalterpositionen, Patchadressierung, ...) in die AudioCoreCell einszuschleusen. Bei derartig vielen Modulen, wie sie der MODULAR hat, stößt man wieder an Grenzen durch REAKTOR (maximal 40 Eingänge).
Also ist die erste Konsequenz, dass alle Events der Primary über einen Event-Bus eingespeist werden (den gibt es ja bekanntermaßen schon
). Somit bekommt die AudioCoreCell nur einen Event-Eingang und einen Eventausgang, um bestimmte Informationen wieder an das Panel zurückzugeben. Die Patchgrafik kann man so belassen, da sie ohnehin schon nur auf Events zugreift.
Ein wesentlich wichtigeres Problem ist die Audioverarbeitung und die flexible Verschaltung. Gerald hat sich daran schon die Zähne ausgebissen und wir haben auch oft darüber diskutiert. Wie schafft man es, das Audiorouting innerhalb der CoreCell vorzunehmen?
Für den MODULAR heißt das, dass es überhaupt keine internen Verbindungen (durch IC-Send geschaltete Send-Receive-Verbindungen) auf dem Primary-Level gibt. Das hat den positiven Effekt, dass es auch nicht mehr den Initialisierung-Prozess gibt. Wie soll nun das ganze aber beliebig geschaltet werden können? Nun, es muss innerhalb der Core-Ebene eine Verknüpfungsmatrix geben, die beliebige Audioleitungen zwischen Audioquellen und Audiozielen legt. So etwas ist im Moment nur mit einer Audiosignalschaltung möglich (Core-Handbuch Seite 135ff). Hier muss man experimentieren (wieviele Quellen lässt REAKTOR zu?). Ihr seht schon, da hat mich schon wieder der Entwickler-Bazillus infiziert.
Damit stehe ich vor dem „Dilemma”, die weiteren Versionen des MODULARs (MODULAR TS, m2, etc.) noch gar nicht abgeschlossen zu haben und schon wieder an die Zukunft denken zu „müssen”.
Die Konsequenz ist, dass ich nun beim MODULAR in zwei Richtungen arbeiten werde: einerseits Weierentwicklung größerer Ensembles auf der Basis des jetzigen MODULARs, andererseits Neu-Aufrollen des Konzept des MODULARs.
Ich werde also ab jetzt parallel arbeiten. Die „Produktlinie” auf der Basis des m1 wird von Zeit zu Zeit weitere Module und Ensembles herausbringen, daneben wird es irgendwann einmal eine völlige Neukonstruktion geben. Für die zweite Linie setze ich mal eine Entwicklungszeit von 2-3 Jahren an. In der Zwischenzeit wird es hoffentlich dann auch ein REAKTOR 6 geben, so dass dies vielleicht etwas einfacher sein wird. Wenn nicht, nun ich denke dass diese Idee auch in REAKTOR 5 realisierbar ist.
Ich ergänze mal hier ein Blockschaltbild.
modular v5.gif
In der obersten Reihe sieht man den Eventbus, in den sich die Panel der einzelnen Module einreihen. Der Eventbus gibt einerseits seine Informationen an das Grafikmodul (Patches) und die Steuersignale (Regler, Schalerstellungen, Midi) an die AudioCoreCell weiter. Die AudioCoreCell besitzt drei Ausgänge: Die beiden Audioausgänge R und L und Weitergabe von Events an die Panelelemente (Anzeigen). Mit Hilfe des Tricks von Geralds Eventausgang für AudioCoreCells lassen sich die Events wieder an das Panel zurückgeben.
Mit diesem Ausblick schließe ich hier das Projekt; wer möchte, kann ja noch einige Kommmentare schreiben. Ansonsten wünsche ich viel Spaß mit dem MODULAR m1.
ciao herw
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
herw
sowas geht bei mir zuhause eh nicht... ist halt ein typischer altbau, der unter 20 hz inkompatibel wird 
