MODULAR X Netzwerk

[herw]

immer wieder viel Kleinarbeit.
Ich habe nochmals den Clock-Generator ausprobiert. Dabei fiel mir auf, dass zwei unabhängig laufende Clocks (mit verschiedenen Gecshwindigkeiten) eigentlich musikalisch nicht sinnvoll sind, denn man möchte ja schon, dass sie nicht unkontrolliert versetzt sind oder gar auseinander laufen.
Also habe ich mich nochmals hingesetzt und überlegt. Ich benutze nun eine gemeinsame Clock und behalte aber die unterschiedliche Intervalleinteilung (1/4, 1/3 - Note etc.) bei. Dadurch stelle ich sicher, dass die Clock-Gates sinnvoll asynchron laufen, sich aber andererseits auch wieder synchron treffen können.
Natürlich kann man nicht immer alle Anwendungsmöglichkeiten voraussehen, aber es gibt grundsätzliche Entscheidungen:

_.png

Dadurch, dass die Tempowahl für die untere zweite Clock wegfällt, konnte ich mir den Luxus eines Shuffle-Reglers leisten.

ciao herw

[pavel]

freut mich den fortschritt zu sehen!

[Eventmanager]

In der Corecell werden die empfangenen bundles dann wieder entpackt ...
[attachment=1]

Bundles vermisse schon arg in R5, naja, lange kanns ja nicht mehr daueren.
Warum haste nicht einfach n Modulo hinter die erste clock gehängt und mit ungeraden, triolischen (oder wie auch immer) Werten bestückt? Da läuft doch auch alles "asynchron" und trifft sich wieder?

[herw]

[...]
Warum haste nicht einfach n Modulo hinter die erste clock gehängt und mit ungeraden, triolischen (oder wie auch immer) Werten bestückt? Da läuft doch auch alles "asynchron" und trifft sich wieder?

Ich habe die Clock aus den REAKTOR Blocks transferiert. Da war dies der einfachste Weg. Die Länge der Noten (1/4, 1/3, etc.) werden aus einer Tabelle ausgelesen. Dies wird in einen Ramp-Oszillator als Faktor übergeben:

_.png

[herw]

endlich!

die Clock:

clk_1_small.png

Der Container enthält zwei Clocks mit einem gemeinsamen Tempo. Man kann zwischen einem vom Modul selbst erzeugten Tempo und dem von REAKTOR vorgegebenen Tempo wählen (Schalter intern/extern). Das Tempo beschreibt die Anzahl der Clock-Signale einer Viertelnote (bpm).
Man kann die Notenlänge umschalten: 1/1, 1/2, 1/3, 1/4, 1/6, 1/8, 1/12, 1716, 1/24, 1/32, 1/48 und 1/64. Die letzten Werte sind nur sinnvoll, wenn das Tempo entsprechend langsam ist. Beide Clocks können dabei verschiedene Notenwerte annehmen, so dass sich interessante Clock-Muster ergeben. Gleichzeitig kann ein reset-Signal nach 0..128 steps ausgegeben werden. Das Clock-Signal selbst ist ein Gate-Signal (g-clk). Durch den Shuffle-Regler kann man die Clock grooven lassen. Dabei wird abwechselnd das Signal verlängert und verkürzt. Dies ist mein Lieblingsparameter.

und der Sequenzer:

sseq_1_small.png

Der Sequenzer war in der Entwicklung äußerst bockig und für mich sehr schwer zu realisieren, da ich überhaupt keine große Erfahrung mit Sequenzern habe. Zwar habe ich einiges aus dem modular RUHR entnehmen können, doch habe ich alles an REAKTOR 6 angepasst, das einer Neukonstruktion gleich kam.
Ursprünglich sollten nur steps mit pitch, velocity und gate ausgegeben werden, ohne jegliche besondere Funktionen, lediglich Aktivierung und Deaktivierung eines Steps als einziges „Feature”.

Das war schon kompliziert genug. Natürlich habe ich auf den Sequenzer aus RUHR geschielt, und so wurden nach und nach doch mehr Wünsche als geplant realisiert.
Für einen einfachen Sequenzer ist diese Version schon ziemlich ausgefuchst. Wegen der zweifachen Clock habe ich auch hier zwei gleiche Sequenzer in den Container gesteckt.
Man erkennt auf der linken Seite die Kontrolleinheiten. Der Start- und Stop-Schalter (Dreieck) ist klar dominierend. Über den Eingang s/s kann man die Sequenzer auch durch externe Gate-Signale (z.B. Midi-gate) an- und abschalten. Die Sequenzer werden über den g-clk-Eingang „angetrieben”. Das kann das Clock-Signal aus dem nebenan liegenden Clock-Container geschehen oder auch durch andere Quellen, zum Beispiel einem LFO oder anderen Logiksignalen. Das habe ich so universell gestaltet, dass auch noch nicht entwickelte Container dort ihr Signal abliefern können. Unter dem Start/Stop-Schalter kann man die Richtung der Sequenz wählen:
----> : nach rechts laufend,
<---- : nach links laufend,
<<->> : pendelnd mit Wiederholung an den Enden,
<---> : pendelnd ohne Wiederholung an den Enden und
rnd : Zufallsausgabe

Rechts oben in der Kontrolleinheit wird die Anzahl der Steps eingegeben und über offset der Startpunkt gesetzt. Wählt man zum Beispiel 9 steps und setzt offset auf 7, so wird die Sequenz in der Reihenfolge 8, 9, 10, 11, 12, 1, 2, 3, 4 durchlaufen.
Man kann die Sequenzer durch einen reset Taster manuell zurücksetzen. Dies kann sowohl für beide Sequenzer einzeln oder über einen gemeinsamen Taster erfolgen; oder eben extern durch ein reset-Signal zum Beispiel durch die Clock.
Da der Sequenzer polyphon ist, können die einzelnen Stimmen über den detune-Regler leicht verstimmt werden bis zu einem Halbton, was natürlich schon sehr schräg klingt. Eine wirkliche Polyphonie bekommt man durch einen weiteren Container, der zu den Ausgabewerten zum Beispiel noch Midi-Pitch-Werte addiert. Außerdem kann man zwischen den ausgegebenen Pitchwerten gleiten (glide).
Im rechten Teil liegen die Einstellungen für Pitch und Velocity und die Aktivierungsschalter für Steps und glide.
Auf der Ausgabenseite rechts werden neben pitch, velocity und gate auch die Eingangswerte für start/stop, reset und g-clk weitergegeben, falls man mehrere Stepsequenzer hintereinander schalten möchte.

Aus der Einfachversion ist schon eine Luxusversion geworden.

Nun geht es normal weiter, was heißt, dass alle andere Container an REAKTOR 6 angepasst werden müssen. Der Sequenzer war bisher die größte Herausforderung und letztlich habe ich mich damit mehr als ein Jahr herumgequält.


noch ein kurzer Einblick in die Struktur:

klare Trennung der Stepverwaltung und der Ausgabewerte

core-struktur1.png

man kann erahnen, welche Logik-Probleme bei den verschiedenen Eingabe-Parametern zur Clocksteuerung zu lösen waren

core-struktur2.png

hier mal das Makro für die pitchwerte

core-struktur3.png

[pavel]

Sehr vielversprechend. Mit dem erworbenen Komplete Upgrade freu ich mich jetzt natürlich umso mehr!
Wird aber wahrscheinlich noch ein Weilchen dauern oder?

Danke für die Einblicke!

[herw]

Beispiele für FM-modulation:

das Format des Containers muss noch in die neue Version umgewandelt werden. Er wird dadurch kompakter.

_.png

ciao herw

[Thala]

Was mich richtig genervt hat, ist dieser (unsinnige) „bug”, dass eine corecell, die man öffnet, einzeln compiliert wird, ohne dass die Umgebung beachtet wird. Das hatte zum Beispiel zur Folge, dass dieses einfache Makro über mehrere Stunden (!) zickte, ohne dass ich auf diesen „bug” kam.
Beim Entwickeln einer event-corecell ist es normal, dass man im Innern zwischendurch auf die Kabel schaut und die Werte erhaschen will. Nur dass dann durch das Compilieren an den Eventeingängen nicht die erwarteten Werte liegen sondern 0! Es hat mich ca. sechs Stunden gekostet, bis mir dieses abstruse Verhalten wieder einfiel:
Wenn man also eine Event Corecell verändert und die Kabelwerte überwachen möchte (auch mit Eventwatcher), dann muss man kurz Reaktor deaktivieren und wieder aktivieren, damit das gesamte Ensemble compiliert wird. Erst dann sind alle Eingänge auch von außen richtig gesetzt.
arggh

ciao herw

omg...
ist dieser zustand immer noch aktuell?

[herw]

Was mich richtig genervt hat, ist dieser (unsinnige) „bug”, dass eine corecell, die man öffnet, einzeln compiliert wird, ohne dass die Umgebung beachtet wird. Das hatte zum Beispiel zur Folge, dass dieses einfache Makro über mehrere Stunden (!) zickte, ohne dass ich auf diesen „bug” kam.
Beim Entwickeln einer event-corecell ist es normal, dass man im Innern zwischendurch auf die Kabel schaut und die Werte erhaschen will. Nur dass dann durch das Compilieren an den Eventeingängen nicht die erwarteten Werte liegen sondern 0! Es hat mich ca. sechs Stunden gekostet, bis mir dieses abstruse Verhalten wieder einfiel:
Wenn man also eine Event Corecell verändert und die Kabelwerte überwachen möchte (auch mit Eventwatcher), dann muss man kurz Reaktor deaktivieren und wieder aktivieren, damit das gesamte Ensemble compiliert wird. Erst dann sind alle Eingänge auch von außen richtig gesetzt.
arggh

ciao herw

omg...
ist dieser zustand immer noch aktuell?

Ich denke ja; es gibt sicherlich Gründe dafür. Mark (Wadewitz aka Quietschboy) weiß sicherlich einen Grund.

[Quietschboy]

Hey hey, hier ist ja gerade mal wieder "richtig was los" im dt Forum !
Leider kann ich euch nicht sagen, warum kein "Full Init" des kompletten Ens passiert, wenn eine Core Cell geändert wird. Aber es wird ja schon seinen Grund haben.
Aber jetzt wisst ihr ja, dass es grundsätzlich besser ist das Ens nach Änderungen und vor dem Debuggen komplett zu initialisieren (Audio Off/On).

Ich habe eben nochmal in meine Initialiserungstabelle für R6.0.4 reingeschaut, und wenn das alles so stimmt, was ich da mal rausgefunden haben will , initialisiert Primary durchaus wenn man eine Core Cell ändert.
D.h. solange die geänderte Core Cell NUR mit Werten aus Primary und aus sich selbst gefüttert wird ist alles gut.

Sobald aber die geänderte Core Cell Werte von einer ANDEREN Core Cell bezieht, gibt es ein Problem.
Warum?
Na die OBC-Speicher (Latches, Arrays) und Werte an Moduleingängen werden ja auch resettet (genullt) und erhalten aber von der vorhergehenden Core Cell keine aktuellen Werte, da diese ja NICHT initialisiert. Würde die vorhergehende Coer Cell allerdings auch NUR Werte von Primary DIREKT weiterverarbeiten, sprich ohne Latches, etc, also nur direkter Mathekram, so würde die Cell die Primary Events als berechnete Werte durchreichen und die geänderte Core Cell bekäme so ihre benötigten Werte zur Initialisierung. Hört sich vielleicht kompliziert an, ist aber eigentlich ganz einfach.
Trotzdem: lieber einem mehr händisch voll initialisieren.

Ich hänge hier nochmal die Tabelle als PDF an. Den Sachverhalt habe ich "structure edit in Core" genannt. siehe ganz rechts, dunkelblau.
Grüße, Mark
PS: PDF-Uploads sind hier nicht erlaubt... hmpf...dann halt zip

[Quietschboy]

Ähm, für die Theoretiker:
Eigentlich dürfte sich das Problem einzig und allein auf nicht-feuernde Konstanten und bei R5 Legacy Cells auch auf SR.C Quellen beschränken. Also für die Core Cells, die nicht geändert wurden.
100 pro sicher bin ich mir allerdings nicht.

[Eventmanager]

Ich habe eben nochmal in meine Initialiserungstabelle für R6.0.4 reingeschaut, und wenn das alles so stimmt, was ich da mal rausgefunden haben will , initialisiert Primary durchaus wenn man eine Core Cell ändert.
D.h. solange die geänderte Core Cell NUR mit Werten aus Primary und aus sich selbst gefüttert wird ist alles gut.

Danke für die Tabelle, Was meinst kann man die auf R5 übetragen, an den modulen selbst und tief unter der Haube hat sich doch kaum was geändert, oder doch?

[Thala]

Der Sequenzer war bisher die größte Herausforderung und letztlich habe ich mich damit mehr als ein Jahr herumgequält.

wow... und ich wäre fast durchgedreht beim erstellen dieses Cores:

http://www.reaktor-forum.de/viewtopic.php?f=14&t=1109

ich leide mit dir!

[Eventmanager]

Ich geh mal davon aus, lieber Quietschboy, dass in deiner sehr nützlichen Tabelle (nochmal danke) X für ja steht und leere Felder nein bedeuten. Ferner das ein switch in der GUI (bspw. FX EIN-schalten/ AUS-machen den gleichen INIT-prozess hervorruft, wie dein structur-edit).
Eine Art "init" fehlt allerdings in der Übersicht und zwar der init nach stop/start der Master-clock. Doch, doch, das ruft ne Art Iniitialisierung hervor:
Ich Meine ganzen Knöppe, Buttons, Listen... hängen an diversen Snap-Arrays und sind per se auf "Snap isolted" gesetzt, sie bekommen ja einen von 64 möglichen (sub-snap) Werten vom Snap-Array.
Das Snap Array iriteriert nicht beim schnöden Snapshot-Wechsel, idR klingen meine Presets nach schnöden Snapsho-Wechsel komplett anders als gespeichert. Ein FX an/aus ((also gleichbedeutend mit Structure-Edit) löst das Problem manchmal, aber nicht immer. Ein simples start/stop jedoch "debuggt" das zuverlässig.

Kein Plan was da genau passiert, aber scheinbar initialisiert stop/start auf ne Weise, die sauber die snap-arrays iteriert, nach start/stop sind alle 64 Sub-snap-Werte wieder sauber an ihrem gespeicherten Platz.iRgend ne Art Init muss also die master-clock ausgeben.

[Quietschboy]

Ich geh mal davon aus, lieber Quietschboy, dass in deiner sehr nützlichen Tabelle (nochmal danke) X für ja steht und leere Felder nein bedeuten.

Richtig.

Ferner das ein switch in der GUI (bspw. FX EIN-schalten/ AUS-machen den gleichen INIT-prozess hervorruft, wie dein structur-edit).

ja, Switch drücken verursacht ein structure edit in Primary. Erkennst du ja auch daran, dass Strukturteile hart deaktiviert, bzw. aktiviert werden. Ein structure edit in Core verhält sich aber anders, siehe Tabelle.

Eine Art "init" fehlt allerdings in der Übersicht und zwar der init nach stop/start der Master-clock.

Findest du in der Tabelle unter den Full Inits. Ich hab es "Re-Power" genannt. (wg. aus- einschalten). Oder meinst du die Initialisierung, die auf einen "SR Change" folgt? Egal, diese beiden Initialisierungen verhalten sich in R6 endlich gleich.

Das Snap Array iriteriert nicht beim schnöden Snapshot-Wechsel, idR klingen meine Presets nach schnöden Snapsho-Wechsel komplett anders als gespeichert. Ein FX an/aus ((also gleichbedeutend mit Structure-Edit) löst das Problem manchmal, aber nicht immer. Ein simples start/stop jedoch "debuggt" das zuverlässig.

Da würde ich mal in´s blaue hinein sagen, dass irgend ein (Initialisierungs-)wert nicht im Snap gespeichert wird. Bei Snapabruf fehlt dieser Wert.

Kein Plan was da genau passiert, aber scheinbar initialisiert stop/start auf ne Weise, die sauber die snap-arrays iteriert, nach start/stop sind alle 64 Sub-snap-Werte wieder sauber an ihrem gespeicherten Platz.iRgend ne Art Init muss also die master-clock ausgeben.

Snap Arrays iterieren bei allen Initialisierungsarten. Allerdings, und vielleicht ist dass ja deine Stolperfalle, erst Post-Init!. Sprich erst nach allen Konstanten, Potis, Listen, etc