MODULAR X Netzwerk

[herw]

Morgen werde ich ich an den einfachen Oszillator 1 herangehen; auch hier wird das Panel auf eine schmale Breite des LFOs angelegt, denn es soll ja nur ein einfacher Oszillator sein.

geht doch
schon geschehen - früher Vogel fängt den Wurm

sco1.png

[herw]

31 Dezember 2015

modular_4-2015-12-31.png

Guten Rutsch!

[pavel]

Es geht voran! Danke dir auch!

[herw]

Es geht voran!

ja

monophon.png

Die Hintergrundfarbe habe ich etwas heller gewählt, da man sonst am Bildschirm zu sehr die Helligkeit erhöhen müsste.
Die monophonen Effekt-Container bekommen zusätzlich einen grünen „Anstrich”.

[herw]

Heute ist ein wichtiger Tag. Auch wenn ich bisher nur einfache Container fertig gestellt habe; es ist ist immer wieder ein spannender Augenblick, wenn die Kabelverbindungen nicht nur auf dem Bildschirm erscheinen, sondern wenn die Signale auch wirklich ankommen und ich zum ersten Male auch Töne höre.
Im polyphonen Bereich kann ich das mit dem Oszilloskop gut prüfen. Der monophone Part (Effekte und Ausgang) ist dagegen eine Hörprobe.
Natürlich kenne ich diese Prozedur schon von den anderen Versionen, trotzdem ist immer ein Bangen dabei: wird auch alles funktionieren?
Wenn das dann wirklich klappt, kann ich zur Routine übergehen.
Die letzten Tage waren in dieser Hinsicht sehr anstrengend. Paneldesign ist zwar ganz schön, aber auch immer sehr nervig und unglaublich Zeit raubend. Das liegt natürlich auch an meiner Pedanterie, mit der ich am Design feile.
also Daumen gedrückt.
ciao herw

[herw]

audio.png

[herw]

Nach mehreren Monaten, habe ich es endlich geschafft, eine Clock für meine zukünftigen Sequenzer zu erstellen.

_b03.png

Ich habe mich damit sehr schwer getan, da ich unbedingt die Clock aus den Util-Blocks benutzen wollte. Sie ist sehr schön programmierbar, vor allem im Wechsel von interner und externer Clock. Ich musste den Block zunächst mal verstehen und dann meinen modular-Bedürfnissen anpassen.
Ich habe ihn aber auch gleich erweitert, so dass er nicht nur 1/4, 1/8, 1/16 usw. Noteneinteilungen ermöglicht, sondern auch noch 1/1, 1/2, 1/3, 1/6, 1/12, 1/24, und 1/48.
Der gezeigte Container enthält zwei Clocks. Der Shuffle-Modus ist hier aus Platzgründen nicht möglich. Eine weitere Clock mit Shuffle ist aber sehr leicht realisierbar, da ich nur einen weiteren Regler benötige; intern ist diese Möglichkeit schon eingebaut. Auch eine weitere große Version mit vier Clocks werde ich für komplexe Sequenzer bauen.
Jetzt kommt als Nächstes der eigentliche Sequenzer. Ich hoffe es gibt dort keine Schwierigkeiten, da ich die Funktionalität wohl komplett aus RUHR übernehme. Zunächst ist gedacht an einen Doppelsequenzer mit 12 Steps.

[herw]

Die Neugestaltung des Sequenzers macht sehr viel Spaß. Es gibt viele kleine Details zu lösen, aber ist alles in absehbarer Zeit machbar. Ich kann auch noch einige Vereinfachungen in der Primary-Ebene (Aktivierung und Nichtaktivierung einzelner Steps) und der Core-Ebene (Verwaltung der mehrfachen Parameter) einbauen.
Hier ein erster optischer Eindruck:

_b01.png

Die Aktivitätsanzeigen haben ich bewusst groß gewählt, damit man im Livebetrieb schnell einen optischen Eindruck gewinnt. Mit dem großen Button werden die Pitch und Gate-Steps geschaltet mit den darunter liegenden die Glidefunktion aktiviert. Das habe ich mir aus der Bento Box 8 Steps abgeschaut. Die Deaktivierung ist sinnvoll, wenn die Pitch-Sprünge sehr groß sind.
Die Anordnung ist kompakt aber immer noch gut zu handhaben. Wenn man alle Parameter nur dieses Containers zusammenzählt, dann kommt man auf weit über 100. Ohne partials Framework wäre die Verkabelung ein Horror.

[pavel]

Sieht vielversprechend aus. Freut mich auch, dass du wieder (sogar mit Spaß - wie auch sonst..) voran kommst!

Solangsam könnte NI mal mit dem neuen Komplete um die Ecke kommen.. dann könnte ich mich vermutl. auch endlich mal zu V6 durchringen..
die Blocks reizen mich schon sehr.. und sowas in die RIchtung in 5 selbst zusammen zu schustern.. für mich unmöglich..

[herw]

[...]
Solangsam könnte NI mal mit dem neuen Komplete um die Ecke kommen.. dann könnte ich mich vermutl. auch endlich mal zu V6 durchringen..
die Blocks reizen mich schon sehr.. und sowas in die RIchtung in 5 selbst zusammen zu schustern.. für mich unmöglich..

Ja das Warten auf Komplete kostet Nerven, wenn man auf bestimmte Teilprodukte wartet. Natürlich ist es ärgerlich, wenn man gerade eines der Produkte zusätzlich gekauft hat (mir ist es mit Action Strikes passiert) und dann einige Monate später in Komplete oder Komplete Ultimate erscheint. Wenn du viele Produkte von Komplete nutzt ist abzuwägen, ob sich die vorzeitige Anschaffung von zum Beispiel R6 für einen persönlich lohnt.
Wenn du viel mit REAKTOR entwickelst, dann ist der Sprung auf R6 enorm. Es ist ein Spiel, darauf zu warten. Wie viele Monate werden es sein? Bei einem Dreivierteljahr ist die Rechnung einfach: etwa 10€ pro Monat(99€ Update-Preis). Auf den Zug hätte man im August letzten Jahres ohne Weiteres aufspringen können, da sehr schnell klar war, dass Komplete zunächst erst mal nicht erscheinen wird. Nun wartet man Monat für Monat vergeblich und die Rechnung wird gefühlt immer schlechter. Wie viel ist einem eine zusätzliche Ausgabe von 99€ wert?
Wenn man dann später Komplete updated und genügend neue andere Versionen erscheinen (auch vielleicht spezielle REAKTOR Instrumente, die man dann erhält), dann sind 99€ zusätzlich zwar ärgerlich und eine Lehre für die Zukunft, bringen aber doch sofortigen Frohsinn. Aber ich mache hier viel zu viel Reklame für NI.
Wenn wir nicht so ein kleines Forum wären (was ich sehr schön finde), dann gäbe es jetzt sicherlich eine hitzige Diskussion darüber.
Ich für meinen Teil warte zum Beispiel auf ein neues Audiointerface gerne auch von NI oder von expert sleepers, um endlich Hardware und Software zu verknüpfen. Da warte ich aber bis zum Ende des Jahres, obwohl es schon Lösungen gibt.
Naja, letztlich läuft es darauf hinaus, ob man die 99€ gerne ausgibt, sofort loslegen kann und sich eventuell über einen schlechten Deal (Komplete lässt vielleicht nur noch wenige Monate auf sich warten) nicht zu sehr ärgert.

ciao herw

PS: zur Weiterentwicklung des modulars siehe die nächste Post

[herw]

Sieht vielversprechend aus. Freut mich auch, dass du wieder (sogar mit Spaß - wie auch sonst..) voran kommst!
[...]

Ja, so langsam komme ich wieder in die Gänge (im wahrsten Sinn des Wortes nach zwei Hüftoperationen).
Gestern bin ich bald an der Verdrahtung der Panelelemente des Sequenzers verzweifelt. Dass es sich um 108 Elemente handelt, ist nicht unbedingt erschreckend, doch muss man trotz partials framework irgend wann einmal alle Drähte zusammenfassen und wieder aufdröseln. Dabei benötigt man auf der primary-Seite Multiplexer und auf core-Seite router. Beides liegt vorbereitet für 30 Quellen vor. So habe ich Erweiterungen erstellt für bis zu 128 Quellen, eine langweilige aber uch nicht allzu anstrengende Arbeit.
Nun wollte ich Empfangsseite (core) die Übertragung der Werte testen und bekam schon gleich zu Beginn einen Übertragungsfehler (container an/aus), also ganz grundlegende Sache, die bei allen anderen Containern klaglos funktionierte.
Erst nach ca. drei (gefühlten sechs) Stunden kam ich auf den Fehler.
Da es sich um so viele Quellen handelte, habe ich zunächst mal nur die ersten 16 abgefragt; gesendet wurden aber alle. Der Router auf der Empfangsseite fragt die Quelladressen binär ab durch eine bitweise-Und-Verknüpfung:

_b01.png

Die Und-Verknüpfung mit 15 (binär gleich 1111) wurde hier aber auch mit Zahlen größer als 15 gefüttert; so liefern die 3 und die 18 dasselbe Ergebnis. Beim Testen bin ich bald verzweifelt, bis mir nach drei Stunden das binäre Licht aufging und mich die falschen empfangenen Werte nicht mehr wunderten.
So kam ich um die übergroßen Multiplexer und Router herum:

_b02.png

Auf der Empfangsseite arbeite ich anstelle von Routern mit Adressfenstern (hier Datenadressbereich 1 bis 6), was zwar mehr Abfragen benötigt, aber dafür viel übersichtlicher ist. Da es sich ja um keinen Audiostream handelt, fallen die zusätzlichen Vergleiche wohl nicht ins Gewicht.

_b03.png

[herw]

und so sieht es verallgemeinert aus:

_b01.png

Zunächst schreibe ich alle empfangenen Werte in ein Speicherfeld. Partials framework liefert mir automatisch den Index [] und den Wert $.
Nun frage ich die einzelnen Zellen ab und benutze dazu das oben erwähnte Adressfenster. Bei einer so großen Anzahl an Daten lohnen sich entsprechende Makros:

_b02.png

Ich gebe als Parameter die Anzahl # der in Frage kommenden Adressen und den Basisindex min an. Da ich alle Makros in Serie anordne, bietet es sich hier an, den Maximalindex automatisch berechnen zu lassen. Der wird dann auch gleich über +min an das folgende Makro weitergegeben. Ich bin ja im Grunde faul
Einen Router benötige ich dann natürlich schon, aber nicht mit erschlagend vielen Ausgängen.
Ich kann nun alle Unterbereiche aneinanderhängen und das entsprechende Bündel an den Ausgang übergeben.

_b03.png

Weit in der Applikation ist die Abfrage sehr einfach: ich hole mir das Teilbündel, hier control 1:

_b04.png

Und habe durch den bundle-Entpacker sofort alle Parameter zur Verfügung.
Oder noch einfacher mit Bundle-Distribution (natürlich in tiefer liegenden Ebenen:

_b05.png

@ pavel: die core-bundles sind einfach äußerst praktisch

[herw]

aber es gibt natürlich noch eine andere Lösung heute bin ich kreativ

[herw]

und jede Menge Nerven; Mark (quietschboy) hat mir sein neues Debugging-Tool zur Verfügung gestellt. Nachdem ich mich beim Anschluss ziemlich dämlich angestellt habe, habe ich es ausführlich für die core-Ebene testen können - phantastisch, sehr schnell zu händeln.

Ich konnte tatsächlich das routing vereinfachen:

_b01.png

_b02.png

[herw]

In der Corecell werden die empfangenen bundles dann wieder entpackt ...

_b01.png

... und dort erst in einem Array gespeichert:

_b02.png