Rampensau hat geschrieben:Krass!..
Brauchbar wären noch ein paar Dummy-Container, in die man eigene Algorithmen für Oszillatoren, Filter, Hüllkurven, etc. einfügen kann. Bsp: Oszillator.. Dieser hätte dann die üblich verdächtigen Schnittstellen (P, A, W, Out, Snc, usw.), sodass man auch beliebige bspw. Primary-Oszillatoren auf einfache Weise, d.h. ohne großartig die Software zu modifizieren, in den Modular einbetten könnte.
Grüße
Benni
Das ist nur schwer zu vermitteln. Eventuell mache ich dazu mal einen Beitrag als Ergänzung. Trotz der Standardisierung ist das nur für einige wenige interessant, da man schon in die Struktur eingreifen muss. Natürlich gibt es ein Kochrezept, aber man kann nicht beliebige Standards vorgeben.
Alleine der Aufbau mit den vorgefertigten Containern ist sicherlich im Prinzip einfach. Aber man muss bereit sein, die unweigerlich auftretenden Fehler zu finden und entsprechend danach zu suchen.
Obwohl ich nun schon mit modular x seit eineinhalb Jahren arbeite, mache ich immer wieder dieselben Anfängerfehler. Mittlerweile weiß ich, wo ich suchen muss und kann sogar an der Art des Fehlers erkennen, was falsch läuft. Vermeiden lässt sich das allerdings wohl nicht, da man immer wieder ungeduldig und zu schnell arbeitet.
Die Eigenkonstruktion ist insofern mühsam, da man sich in den prinzipiellen Aufbau der Datenübermittlung hineindenken muss und auch den Aufbau im Panel. Wissen über partials framework ist notwendig.
Was ich machen kann, ist eine Analyse eines fertigen Containers mit der Beschreibung der notwendigen Einstellungen und ein Grundgerüst. Das findet man auch in der ersten Version in der Form von Leercontainern. Das ist auch vorgesehen für eine zweite Version.
Zunächst mal muss man sich aber mit dem Konzept modular x erst anfreunden. Es wird sicherlich viele Frustrierte geben, die nicht sorgfältig arbeiten und nicht den Biss haben, ein angefangenes Ensemble bis zum Ende durchzuführen.
Auch die Ungeduld ist schwer in den Griff zu bekommen. Ich habe natürlich große Modularsynthesizer im Kopf . Doch brauche ich immer wieder das Training um Routine zu bekommen. Ich kann im Prinzip einen großen Modular in drei Stunden zusammenbasteln. Ob er dann aber auch gleich funktioniert und, ob er gut aufgebaut ist, ist dann wieder auf einem anderen Blatt Papier.
Um zu deiner Anfrage zu kommen: ja ich werde ein entsprechendes Kapitel oder einen Beitrag hier bringen, aber zunächst muss ich die Belastbarkeit eines so offenen Systems erkunden (ertragen?).
Ich bin selbst gespannt, wie es ankommt und aufgenommen wird. Preset-User werden es nicht gutheißen, weil sie sich ja einarbeiten, Zeit investiern und auch noch ein Tutorial lesen müssen
.
herw
PS: übrigens kannst Du selbst einen Standard-Container, wie zum Beispiel einen Filter umbauen:
Im Filter-Container SCF 1 (siehe im Ensemble RUHR) wie auch in allen anderen Containern gibt es die eigentliche Anwendung im Makro application (mal core, mal primary).
container 1.jpg
Von außen erhält dieses über den Bus {pnl} die Informationen der Regler und sonstigen Bedienelemente
container 3.jpg
und entschlüsselt sie in der core cell
Container 2.jpg
Solange also die Position und die Anzahl der Ein- und Ausgänge nicht verändert wird, ist alles normale REAKTOR-Programmiererei. Es lohnt sich mal sehr unterschiedliche, aber einfache Container zu vergleichen (SCA 1, ADSR 1, OSC 1). Auch ein Blick in die Makros init container und die inputs und Outputs liefern durch bloßen Vergleich die Idee. Meistens ändern sich nur zwei Konstante. Das ist der Vorteil dieses standardisierten Systems.
PSPS: Jetzt habe ich schon quasi das zweite Tutorial angefangen; aber das muss erst mal genügen.