der MODULAR

[herw]

Die Version 2 des RUHR ist jetzt seit einigen Wochen draußen und kommt offenbar gut an. Die Ladezeit ist nun extrem kurz und das Abspeichern geht ebenfalls flott.
Ich war fleißig und habe einige neue Container (für ELBE, EMSCHER und MODULAR X framework) gebastelt:
SCA 3 und SCA 4: zwei kleine Versionen eines linearen Verstärkers

SCA 3.jpg

SCA 4.jpg

SC e MIX4: ein Signal gesteuerter 4-fach Mixer

SC e MIX 4.jpg

Ein ADSR mit midi delay:

ADSR 2.jpg

und eine Signal gesteuerte Version, mit der alle Komponenten dynamisch verändert werden können:

SC ADSR.jpg

[herw]

Filter SCF 3, ein Resonator

SCF 3.jpg

Filter SCF 4, Pro 52-Filter

SCF 4.jpg

ein LFO mit fünf phasenfesten Schwingungen

LFO 4.jpg

und den Nullphasen-Oszillator für eine Sinusschwingung

ZP-osc SIN.jpg

[herw]

zwei neue Effekte:
FLANGER

FLANGER.jpg

und ein Modul von Stephan Schmitt: CABINET

CABINET.jpg

[herw]

ein kleines Testensemble kommt morgen in die Testphase.
Ich habe hier einen neuen Container auf Anraten von Phil Durrant (sowari) erstellt: VOICE SPREAD.
In Abhängigkeit eines spread-Reglers werden die einzelnen Voices auf das Stereo-Panorama verteilt. Gehört habe ich es noch nicht, aber ich denke es wird gut klingen.

Clipboard 1.jpg

[herw]

Heute habe ich ein kleines Ensemble für externe Audioquellen zusammengestellt; es ist der Vorläufer von EMSCHER und ist im wesentlichen für Gitarristen gedacht.

Clipboard 1.jpg

Ich habe zunächst mal nur getestet ob die Signalwege funktionieren. Neu sind die Container EXT IN; nichts besonderes, einfach nur die Einbindung der externen Quelle in den modular.
Dann habe ich erst mal getestet, ob die Effektgeräte damit richtig arbeiten. - kein Problem.
Interessanter sind die beiden daneben stehenden Container:
ENVELOPE FOLLOWER erzeugt eine mehr oder weniger kontinuierliche Hüllkurve des Audiosignals.
Diese kann dann im folgenden SCHMITT TRIGGER in ein Gatesignal umgewandelt werden.
Ich habe das Gatesignal in einen normalen ADSR geleitet. Das funktioniert auch, aber es erwies sich als unpraktisch, dass das Gatesignal zum Beispiel beim Sprechen über ein Mikrofon schnell wieder geschlossen wird. Hier sind also einfach Triggerkurven (Decay oder Attack-Decay) viel praktischer.
Ich entwickle gerade parallel dazu entsprechende CoreCells aus der Core-ADSR-Hüllkurve. Das klappt auch schon gut, muss nur noch ein wenig im Design angepasst werden.
Schön wäre natürlich noch ein AudioToMidi-Container; da muss ich aber noch einige Zeit investieren.

Ich bin sehr zufrieden.

[herw]

modular x framework steht kurz vor der Vollendung. Gerade ist die Betaphase eingeleitet. Ende September könnte ein gutes Datum sein.

modular x framework.jpg

ciao herw

[Rampensau]

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

[herw]

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.

[sellotape]

Die Sache mit dem Bus finde ich sehr interessant! Ich bastel mir gerade eine Anzeige für meinen Synth der von dem momentan bewegten Regle Namen, Wert und Einheit ausgibt und dein Bus scheint mir da wie geschaffen zu sein. Also werd ich mich mal dran setzen um das ganze zu verstehen. =)
Rießen Respekt auf jeden Fall für das gesamte Projekt! Wirklich Wahnsinn was da an Arbeit drin steckt und wie du das alles umgesetzt hast. Klarer Kandidat für die R6 Factory Library!

[herw]

Die Sache mit dem Bus finde ich sehr interessant! Ich bastel mir gerade eine Anzeige für meinen Synth der von dem momentan bewegten Regle Namen, Wert und Einheit ausgibt und dein Bus scheint mir da wie geschaffen zu sein. Also werd ich mich mal dran setzen um das ganze zu verstehen. =)
Rießen Respekt auf jeden Fall für das gesamte Projekt! Wirklich Wahnsinn was da an Arbeit drin steckt und wie du das alles umgesetzt hast. Klarer Kandidat für die R6 Factory Library!

Der Bus ist das Ergebnis der Studien zu partials framework von Max Zagler.
An R6 glaube ich nicht mehr, abzusehen ist, dass nach und nach zu R5.9.9 übergegangen wird und dann die letzte Version (kostenlos R6) genannt wird. Mir gefallen die kleinschrittigen (kostenlosen) Verbesserungen.
Ich vermute eher, dass ein (gewünschtes) R6 ganz anders heißen wird und einen Neuansatz schafft. Oder man springt von Version 5.9.9 auf 6.5.
herw

[wehkah]

Die Sache mit dem Bus finde ich sehr interessant! Ich bastel mir gerade eine Anzeige für meinen Synth der von dem momentan bewegten Regle Namen, Wert und Einheit ausgibt und dein Bus scheint mir da wie geschaffen zu sein. Also werd ich mich mal dran setzen um das ganze zu verstehen. =)
Rießen Respekt auf jeden Fall für das gesamte Projekt! Wirklich Wahnsinn was da an Arbeit drin steckt und wie du das alles umgesetzt hast. Klarer Kandidat für die R6 Factory Library!

Der Bus ist das Ergebnis der Studien zu partials framework von Max Zagler.
An R6 glaube ich nicht mehr, abzusehen ist, dass nach und nach zu R5.9.9 übergegangen wird und dann die letzte Version (kostenlos R6) genannt wird. Mir gefallen die kleinschrittigen (kostenlosen) Verbesserungen.
Ich vermute eher, dass ein (gewünschtes) R6 ganz anders heißen wird und einen Neuansatz schafft. Oder man springt von Version 5.9.9 auf 6.5.
herw

Hast dazu Geheimwissen? Was meinst Du mit. "An R6 glaube ich nicht mehr" . Wird Reaktor abgeschafft? Ich hoffe doch nicht, das wäre ja absolut kagge.

[herw]

Die Sache mit dem Bus finde ich sehr interessant! Ich bastel mir gerade eine Anzeige für meinen Synth der von dem momentan bewegten Regle Namen, Wert und Einheit ausgibt und dein Bus scheint mir da wie geschaffen zu sein. Also werd ich mich mal dran setzen um das ganze zu verstehen. =)
Rießen Respekt auf jeden Fall für das gesamte Projekt! Wirklich Wahnsinn was da an Arbeit drin steckt und wie du das alles umgesetzt hast. Klarer Kandidat für die R6 Factory Library!

Der Bus ist das Ergebnis der Studien zu partials framework von Max Zagler.
An R6 glaube ich nicht mehr, abzusehen ist, dass nach und nach zu R5.9.9 übergegangen wird und dann die letzte Version (kostenlos R6) genannt wird. Mir gefallen die kleinschrittigen (kostenlosen) Verbesserungen.
Ich vermute eher, dass ein (gewünschtes) R6 ganz anders heißen wird und einen Neuansatz schafft. Oder man springt von Version 5.9.9 auf 6.5.
herw

Hast dazu Geheimwissen? Was meinst Du mit. "An R6 glaube ich nicht mehr" . Wird Reaktor abgeschafft? Ich hoffe doch nicht, das wäre ja absolut kagge.

Ich habe absolut kein Geheimwissen, sondern schließe das aus der kurzen Abfolge von Miniupdates, die mittlerweile herausgekommen sind.
Ich finde es gut, dass es ständig Verbesserungen gibt bzw. dass lange liegengebliebene Bugs nach und nach beseitigt werden.
Was mich zu der Schlussfolgerung veranlasst, dass man bei 5.9.9 aufhört, ist die Tatsache, dass wir uns nach und nach den höheren Teilnummern nähern.
Klar man könnte das nächste Update R5.7.2 und dann R5.7.3 usw nennen. Nun die Sprünge waren aber 5.5, 5.61, 5.6.2, 5.7, 5.7.1 die letzten in relativ kurzer Zeit. Wenn es so weiter geht, dann sind wir bald bei den höheren Zehnteln. Was dann? Unmöglich ist ein Majorupdate von R5.9 auf R6.0. Mindestens müsste es dann R6.5 heißen, damit man die Kostenpflichtigkeit auch erklären kann; d.h. es müssten dann schon wirklich durchgreifende Neuerungen da sein.
Ich könnte mir auch vorstellen, dass man REAKTOR eine etwas andere Zielrichtung gibt, so dass man es gar nicht mehr REAKTOR nennt, um anzudeuten, dass da etwas Neues entsteht. Natürlich hoffe ich, dass die vielen Wünsche (vor allem bzgl. Core) noch erfüllt werden.
Aber alles sind Kaffesatzleserei und Spekulationen; macht aber Spaß

Man muss, wie ich schon anderswo geschrieben habe, NI ein großes Lob machen, dass sie ihr Flaggschiff so in Ordnung bringt.
Wenn man mal R5.5 und R5.7.1 miteinander vergleicht, dann sind da Welten dazwischen, die den Namen R6 schon längst verdient hätten. So gab's alles umsonst.
Ich möchte das aber hier nicht weiter diskutieren, da es zum Thread nicht passt. Spekulationen kann man in den anderen Threads weitertreiben.

ciao herw

PS: REAKTOR „abschaffen” kann man ohnehin nicht, denn wir sind ja da

[herw]

geschafft: modular x ist in der User Library.

Falls es Fragen und Vorschläge gibt dann schreibt im Thread : modular x Netzwerk.

ciao herw