MODULAR X Netzwerk

[pavel]

Hut ab.. ich wäre schon längst am

Bei der Komplexität des Projektes wäre ich aber eh schon längst am

Weiterhin gutes Gelingen!

[herw]

Hut ab.. ich wäre schon längst am

Bei der Komplexität des Projektes wäre ich aber eh schon längst am

Weiterhin gutes Gelingen!

danke; es geht eigentlich immer irgendwie weiter. Im Moment baue ich noch ein feature ein, dass bei einem Bypass tatsächlich die nicht benötigte Signalverarbeitung auch wirklich abgeschaltet wird. Wenn man es mehrmals einbaut, dann wird auch dies zur Routine. Ich bemühe mich, bei ähnlichen Containern auch das Innere möglichst gleich zu gestalten:
hier mal ein Vergleich von chorus und delay
chorus

chorus.jpg

delay

delay.jpg

[herw]

so langsam werden auch die patches komplexer

komplex.jpg

[Eventmanager]

Waren das vorher kommentarlose Abstürze? Die Protokoll-Datei zum Support mit der Bitte dir die letzten Zeilen zu klartexten.

Obwohl ich nur Bahnhof verstehe: Respekt Mann!

[herw]

Waren das vorher kommentarlose Abstürze? Die Protokoll-Datei zum Support mit der Bitte dir die letzten Zeilen zu klartexten.

Obwohl ich nur Bahnhof verstehe: Respekt Mann!

ja die Abstürze lieferten nur anschließend ein Protokoll, mit dem ich natürlich nichts anfangen konnte. Das ganze passierte am Wochenende; da ich einen etwas direkteren Draht zu NI hab, habe ich das an den Projektleiter gemailt. Die Projektgruppen sind allerdings immer sehr beschäftigt, so dass ich eigentlich erst sehr spät eine Antwort erhoffe, wenn überhaupt. Wichtiger ist eher, dass solche Abstürze überhaupt gemeldet werden, da sie oftmals Krücken aufdecken, durch die man durch gezielte Tests das Programm verbessern (stabilisieren) kann.
Die Fehlermeldung ergab sich persönlich durch systematisches Aufspüren der Fehlerquelle; da habe ich auch Glück gehabt, dass es eine Fehlermeldung gab. Das war für mich beruhigend, es lag also nicht primär an meiner Entwicklung. Den Workaround mit der dazwischen geschalteten read-Anweisung habe ich auf gut Glück und ein bisschen auch mit Überlegung herausgefunden. Nach und nach versteht man die „Denkweise” des Compilers.
Es gilt immer wieder mal auch rätselhafte Abstürze aufzuklären, insbesondere bei ungewöhnlichen (und eher seltenen) Core-Speicherverknüpfungen. Diese werden sehr genau untersucht, damit REAKTOR äußerst stabil bleibt. Da ist das Team nach meiner Einschätzung sehr pedantisch und genau.
ciao herw

[herw]

ein kleiner, aber wichtiger Zwischenschritt:
nach langen Versuchen ist es mir gelungen, dass die Initialisierung von polyphoner Signalverarbeitung (poly SVA) und monophoner Signalverarbeitung (mono-SVA) ohne Eingriff durch den User automatisch erfolgt. Ein wichtiger Schritt, die Modularität so einfach wie möglich zu gestalten.
Polyphone und monophone Container (im Wesentlichen Effekte) vertragen sich nicht in einer einzigen CoreCell. Damit die Zuweisung von Parametern (Regler, Taster etc.) korrekt erfolgt, muss jeder Container eine Nummer zugewiesen werden, ebenso den Ein- und Ausgängen.
Die Nummerierung erfolgt automatisch beim Starten des Instruments über einen Eventbus. Der Eventbus übergibt seine Daten sowohl an die poly-SVA als auch an die mono-SVA.
Dabei werden die Daten von Container zu Container übergeben und entsprechend der im Container benutzten Ein- und Ausgänge erhöht. Soweit so gut, nur irgendwann kommt man an den letzten polyphonen Container; und wie übergibt man nun aus der CoreCell den Datenbus an die monophone CoreCell? Da es sich um AudioCoreCells handelt, gibt es keinen Eventausgang. Einzelne getriggerte Events lassen sich über Geralds AudioEventAusgang übergeben, eine Nachricht per Bus dagegen nicht.
Also musste ich bisher die nötigen Daten (Containerzahl C#, Ausgangszahl O# und Eingangszahl I#) des letzten poly-Containers einzeln abfragen und mir außerhalb der CoreCell ausgeben lassen.

bild_1.jpg

Diese Werte habe ich dann als Konstante für die mono SVA eingetragen. Nicht schlimm, aber extrem Benutzerunfreundlich, da ich es oft vergaß und mich wunderte, dass mein modular nichts verstand und die falschen Verknüpfungen erstellte.
Nun, es gibt einen Trick: beim Start eines modulars werden über den Bus mehrere Initialisierungsnachrichten geschickt:
die erste ist für die Nummerierungen der poly Core-Container, dann die Panels (primary-Container) und noch einiges. Die zweite Nachricht ist nur für die Primary-Container gedacht und führt dieselben Nummerierungen durch wie die Core-Initialisierung.
Ich konnte also hinter dem letzten polyContainer auf Primary-Ebene die Werte C#, O# und I# abfragen.
Soweit so gut, jetzt musste ich nur die Werte in den Bus einschleusen. Das ist nicht einfach, da der Bus ja auf dem partials framework basiert und somit in Core-Ebene streng das Gleichzeitigkeitaxiom beachtet („Alle Events, die aus ein und derselben Quelle entstehen, sind als gleichzeitig anzusehen und werden entsprechend verarbeitet.”).
Wenn ich nun aus der primary-Initialisierung die Daten C#, O# und I# isoliere und direkt wieder in den Bus einfügen möchte (als Nachricht), dann überschreiben sie beim nötigen merge-Modul die ursprünglichen Daten, zerstören also die Initialisierungsnachricht.
Da es in core keine order-Module und keine Iteration gibt, muss eine neue Nachricht erzeugt werden. Doch woher kommt dann der auslösende Trigger und erfolgt er zum richtigen Zeitpunkt?

Es gibt aber einen Trick. Direkt hinter der primary-Intialisierungsnachricht schicke ich eine Dummie-Nachricht (id,3,C#,O#,I#) mit den Werten C#=O#=I#=0. Gelangt nun die primary-Initialisierung an den letzten poly-Container, dann werden aus ihr die Daten für C#, O# und I# extrahiert und zwischengespeichert. Gelangt nun anschließend die Dummienachricht an denselben Container, dann kann ich die aktuellen Werte C#, O# und I# überschreiben und mit einem Merger einfädeln.
Diese Nachricht wird dann nur von der mono-SVA empfangen:

bild_2.jpg

Im Bild sieht man , wie die primary-Nachricht (mit dem Identifier 0) die Werte abfragt. Wegen der strikten Reihenfolge gelangt als nächstes die Dummienachricht (mit dem identifier -6) in die Zelle und trägt die Werte ein.
Es ist hier klar ein Vorteil, wenn alle Nachrichten über einen einzigen Bus geführt werden.
Nun sieht es also so aus:

bild_3.jpg

sehr klar und einfach.
Interessanterweise ist dies für mich immer ein Kennzeichen, dass eine Lösung (wenn sie denn funktioniert) die optimale Version erreicht hat.

Ich finde es einfach herrlich, wenn REAKTOR immer wieder zu solchen Optimierungen auffordert.

[herw]

Bastelstunde

bild1.jpg

[herw]

sehr viele Probleme grundsätzlicher Art waren in der Zwischenzeit zu lösen:
Es gab große Schwierigkeiten mit dem Compiler, der lange OBC-Verkettungen irgendwann nicht mehr akzeptiert. Daher musste die Verkettung sternförig angelegt werden. Eine weitere Schwierigkeit war der hohe CPU-Verbrauch. Max hat mir sehr geholfen, beide Probleme zufriedenstellend zu lösen.

Jetzt gehe ich an das erste neue Ensemble (ELBE).

elbe.jpg

Der Charakter soll bestimmt sein durch durch Phasen-Modulation, zero-phase-Oszillatoren und Rauschgeneratoren. Es wird drei Racks groß sein.

oszillatoren.jpg

ciao herw

[herw]

Kleinarbeit:

lfo_1_v4.jpg

eine etwas sture Arbeit, aber nötig. Alle Container werden nun einheitlich ausgestattet, d.h. alle relevanten core-Makros müssen ersetzt werden.
In primary müssen alle hints erneuert bzw. überprüft werden. Aber es geht voran.
Ich kann immer mal wieder eine Viertelstunde für einen Container herausschlagen. Sehr zufrieden bin ich mittlerweile mit dem CPU-Verbrauch. Ab und an entdecke ich versteckte CPU-Fresser, so zum Beispiel lief im Container NOISE das Makro 808 laufend mit sechs Oszillatoren! Die SR.C war sehr tief versteckt. Nun kann ich sie abschalten, wenn sie nicht benötigt wird.

[herw]

Das war ein gehöriges Stück Arbeit:
Der Oszillator SCO 6 ist ein Oszillator, der dem Prinzip der Frequen- und Phasen-Modulation (YAMAHA) folgt.
Er lag in der Version 3 vor (nicht veröffentlichtes framework), musste also erstmal umgeschrieben werden. Es gibt sehr viele Parameter:

sco_6.jpg

Auf der linken Seite sieht man die üblichen Parameter zur Modulation von Pitchwerten und der Pulsweite der Rechteckschwingung.
Auf der rechten Seite ist es interessant: Man kann die Frequenz in feinen Schritten um einen bestimmten Faktor multiplizieren oder dividieren (ratio).
Mit der Synchronisation mehrerer solcher Oszillatoren erreicht man, dass bei einer gegenseitigen Modulation immer derselbe Klang erzeugt wird.
Man kann die ratio modulieren.
Zusätzlich kann die Phase entweder fest oder moduliert eingestellt werden.
Und der Clou ist die Möglichkeit, eine feste Frequenz zu addieren. Insbesondere kann der Oszillator noch als LFO benutzt werden, da man die Grundfrequenz durch einen Button auf 0 setzen kann. Die Fixfrequenz bleibt dabei erhalten und kann in einem großen Rahmen geändert werden (auch audio-Frequenzen).
Insgesamt ist dieser Oszillator vom Feinsten. Die Anpassung hat auch entsprechend gedauert: drei Tage (!).

ciao herw

[herw]

neue Oszillatoren:

neue_oszillatoren.jpg

Neben den Rauschgeneratoren ergänze ich zwei Geiger-Oszillatoren (SCO 7 und SCO 8) und die schon bekannten SCO 3 (Subharmonischer Oszillator) und SCO 5 (Zero-phase-Oszillator).
Auf die Geigeroszillatoren bin ich sehr gespannt. Ich habe sie in einem Testaufbau schon ausprobiert. Ist der Pitch sehr niedrig (bis -120), dann gibt es nur sehr selten einen einzelnen Impuls; p=0 entspricht ca. 8Hz, p=-120 dagegen 0,008Hz also im Schnitt ca. innerhalb von 2 Minuten.
Man kann mit dem Parameter random einstellen, ob die Impulse völlig regelmäßig kommen oder zufällig verteilt sind. Das ist vor allem interessant, wenn dieser Parameter moduliert wird. Mit der Dynamik kann man kontrollieren, ob der Wert maximal sein soll (-1/+1 bzw. 1) oder ebenfalls ein Zufallswert.
Die drei Ausgänge stellen entweder bipolare oder unipolare Werte zur Verfügung. Der dritte Ausgang ist ein FlipFlop dessen Werte (-1/+1) bzw. (0/1) immer abwechselnd kommen. Mit dem Gateeingang kann dieser Ausgang resettet werden.
Das passende Core-Makro basiert auf einem Vorschlag von Dietrich Pank (NI).
ciao herw

[herw]

elbe_v0-l.jpg

[herw]

test_geiger.jpg

Geiger 1.mp3

Der Geiger-Oszillator moduliert lediglich Pitch der Oszillatoren oder sendet Trigger-Signale zum Hüllkurvengenerator.

ciao herw

[herw]

Nachdem ich mich nebenbei mal mit dem Core-Geiger-Oszillator beschäftigt habe (interessant vor allem bei sehr niedrigen Frequenzen), habe ich mich um die core-Umsetzungen der Oszillatoren SCO 5 (zero-Phase-Oszillator) und SCO 3 (subharmonischer Oszillator) gekümmert. Manchmal gibt es kleine Überraschungen, aber letztlich alles lösbar. Interessant war die unerklärliche Tatsache, dass man nicht einfach Regler kopieren kann. Sie ließen sich partout nicht aktivieren, also musste ich neue Regler einsetzen. Die Ursache ist mir nicht klar; wahrscheinlich liegt es an der Änderung in den Properties (neu eingeführte Feinregulierung). Das ist eine ziemliche Falle.
Naja, das war mir schon bekannt, also gingen meine Korrekturen in diese Richtungen. Die Alpha-Version für ELBE kommt näher. Jetzt fehlt eigentlich nur noch die Signalgesteuerte Hüllkurve und dann gebe ich das an „meine” Alphatester Phil Durrant und Mark Wadewitz.
Sie können dann Einfluss nehmen an der Zusammenstellung der Komponenten und eventuelle Ergänzungen. Ich freue mich, wenn ich ELBE vorstellen kann.
ciao herw

[herw]

Offenbar ist im Moment ein Sommerloch! Es gibt wenig Beiträge.
Daher schreibe ich mal ein wenig über mein Projekt.
In den letzten (Urlaubs-) Wochen habe ich das grundsätzliche Konzept stark vereinfachen können. Ich habe über das Multidisplay, das die Kabel anzeigt, ein Mausfeld gelegt. Beim Anklicken eines Outputs und eines Inputs frage ich gleichzeitig die Koordinaten des Anklickpunktes ab. Ich habe die Anordnung der Aus- und Eingangsbuttons etwas eingeschränkt, so dass sie minimal im Abstand von 12 Pixeln angeordnet werden dürfen. Das ist sogar enger als in den bisherigen Anordnungen. Auch wenn man nicht ganz zielgenau trifft, werden die richtigen passenden Koordinaten übersandt. Das hat für mich und den möglichen Selbstgestalter von modular-ensemble den Vorteil, dass man sich nicht um die Lage der Ein- und Ausgänge, ja noch nicht einmal um die Lage der verschiedenen Container kümmern muss - eine starke Vereinfachung. Es ist also im Prinzip möglich, in einem vorhandenen Ensemble die Container nachträglich beliebig hin und her zu schieben, ohne in die einzelne Struktur eines Containers eingreifen zu müssen. Die Snapshots müssen natürlich neu angelegt werden, da die Kabelverbindungen ja mit abgespeichert werden.
Ich stelle das gerade um. Am Aussehen der Ensemble hat sich nicht viel geändert, daher gibt's hier kein Bildchen. In der Struktur gibt es starke Vereinfachungen, aber dazu mehr, wenn es sich lohnt zu berichten. Ich arbeite regelmäßig und mit schnellem Erfolg. Im Herbst gibt's dann neue und interessante Ensembles.

ciao herw