MODULAR X Netzwerk

Hier soll es ausschließlich um Arbeiten zu neuen und alten Ensembles gehen.

Moderator: herw

Antworten
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: MODULAR X Netzwerk

Beitrag von 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
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Benutzeravatar
pavel
synthesist
Beiträge: 52
Registriert: 16. Dezember 2013, 15:49

Re: MODULAR X Netzwerk

Beitrag von pavel »

:shock: freut mich den fortschritt zu sehen!
Eventmanager
synth doctor
Beiträge: 271
Registriert: 25. Juni 2013, 15:26

Re: MODULAR X Netzwerk

Beitrag von Eventmanager »

herw hat geschrieben: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?
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: MODULAR X Netzwerk

Beitrag von herw »

Eventmanager hat geschrieben:[...]
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
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: MODULAR X Netzwerk

Beitrag von 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.
::kaffee:: ::kaffee:: ::kaffee::

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
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Benutzeravatar
pavel
synthesist
Beiträge: 52
Registriert: 16. Dezember 2013, 15:49

Re: MODULAR X Netzwerk

Beitrag von 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!
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: MODULAR X Netzwerk

Beitrag von 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
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Thala
meister
Beiträge: 149
Registriert: 1. Oktober 2015, 14:36

Re: MODULAR X Netzwerk

Beitrag von Thala »

herw hat geschrieben: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?
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: MODULAR X Netzwerk

Beitrag von herw »

Thala hat geschrieben:
herw hat geschrieben: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
synth doctor
Beiträge: 218
Registriert: 6. April 2011, 20:31
Wohnort: Wiesbaden

Re: MODULAR X Netzwerk

Beitrag von Quietschboy »

Hey hey, hier ist ja gerade mal wieder "richtig was los" im dt Forum ! :D
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 :roll: , 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
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Quietschboy
synth doctor
Beiträge: 218
Registriert: 6. April 2011, 20:31
Wohnort: Wiesbaden

Re: MODULAR X Netzwerk

Beitrag von 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
synth doctor
Beiträge: 271
Registriert: 25. Juni 2013, 15:26

Re: MODULAR X Netzwerk

Beitrag von Eventmanager »

Quietschboy hat geschrieben:
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 :roll: , 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
meister
Beiträge: 149
Registriert: 1. Oktober 2015, 14:36

Re: MODULAR X Netzwerk

Beitrag von Thala »

herw hat geschrieben: 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
synth doctor
Beiträge: 271
Registriert: 25. Juni 2013, 15:26

Re: MODULAR X Netzwerk

Beitrag von 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
synth doctor
Beiträge: 218
Registriert: 6. April 2011, 20:31
Wohnort: Wiesbaden

Re: MODULAR X Netzwerk

Beitrag von Quietschboy »

Eventmanager hat geschrieben: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.
Eventmanager hat geschrieben: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.
Eventmanager hat geschrieben: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.
Eventmanager hat geschrieben: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.
Eventmanager hat geschrieben: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
Antworten