MODULAR X Netzwerk

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

Moderator: herw

Re: MODULAR X Netzwerk

Beitragvon herw » Sa 21. Mai 2016, 09:46

In der Corecell werden die empfangenen bundles dann wieder entpackt ...
_b01.png
_b01.png (18.55 KiB) 1678-mal betrachtet

... und dort erst in einem Array gespeichert:
_b02.png
_b02.png (16.66 KiB) 1678-mal betrachtet
Benutzeravatar
herw
moderator
 
Beiträge: 2978
Registriert: Mo 13. Mär 2006, 18:28
Wohnort: Dortmund

Re: MODULAR X Netzwerk

Beitragvon herw » So 19. Jun 2016, 19:06

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
_.png (121.44 KiB) 1642-mal betrachtet

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

ciao herw
Benutzeravatar
herw
moderator
 
Beiträge: 2978
Registriert: Mo 13. Mär 2006, 18:28
Wohnort: Dortmund

Re: MODULAR X Netzwerk

Beitragvon pavel » Fr 24. Jun 2016, 20:59

:shock: freut mich den fortschritt zu sehen!
Reaktor 5.9.3 R1344
Benutzeravatar
pavel
synthesist
 
Beiträge: 51
Registriert: Mo 16. Dez 2013, 15:49

Re: MODULAR X Netzwerk

Beitragvon Eventmanager » Sa 25. Jun 2016, 11:04

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?
Eventmanager
meister
 
Beiträge: 173
Registriert: Di 25. Jun 2013, 15:26

Re: MODULAR X Netzwerk

Beitragvon herw » Sa 25. Jun 2016, 16:25

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
_.png (13.04 KiB) 1609-mal betrachtet
Benutzeravatar
herw
moderator
 
Beiträge: 2978
Registriert: Mo 13. Mär 2006, 18:28
Wohnort: Dortmund

Re: MODULAR X Netzwerk

Beitragvon herw » Di 13. Sep 2016, 08:05

endlich!

die Clock:
clk_1_small.png
clk_1_small.png (28.04 KiB) 1435-mal betrachtet

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
sseq_1_small.png (242.21 KiB) 1435-mal betrachtet

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
core-struktur1.png (90.03 KiB) 1435-mal betrachtet

man kann erahnen, welche Logik-Probleme bei den verschiedenen Eingabe-Parametern zur Clocksteuerung zu lösen waren
core-struktur2.png
core-struktur2.png (69.83 KiB) 1435-mal betrachtet

hier mal das Makro für die pitchwerte
core-struktur3.png
core-struktur3.png (50.54 KiB) 1435-mal betrachtet
Benutzeravatar
herw
moderator
 
Beiträge: 2978
Registriert: Mo 13. Mär 2006, 18:28
Wohnort: Dortmund

Re: MODULAR X Netzwerk

Beitragvon pavel » Mi 14. Sep 2016, 07:40

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!
Reaktor 5.9.3 R1344
Benutzeravatar
pavel
synthesist
 
Beiträge: 51
Registriert: Mo 16. Dez 2013, 15:49

Re: MODULAR X Netzwerk

Beitragvon herw » Do 15. Sep 2016, 20:17

Beispiele für FM-modulation:

das Format des Containers muss noch in die neue Version umgewandelt werden. Er wird dadurch kompakter.
_.png
_.png (425.25 KiB) 1372-mal betrachtet

ciao herw
Dateianhänge

[ Gebe QuickTime-Datei wieder ] fm.mp3 [ 2.2 MiB | 1372-mal betrachtet ]

Benutzeravatar
herw
moderator
 
Beiträge: 2978
Registriert: Mo 13. Mär 2006, 18:28
Wohnort: Dortmund

Re: MODULAR X Netzwerk

Beitragvon Thala » Fr 9. Jun 2017, 10:39

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?
Thala
synthesist
 
Beiträge: 83
Registriert: Do 1. Okt 2015, 14:36

Re: MODULAR X Netzwerk

Beitragvon herw » Sa 10. Jun 2017, 11:38

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.
Benutzeravatar
herw
moderator
 
Beiträge: 2978
Registriert: Mo 13. Mär 2006, 18:28
Wohnort: Dortmund

Re: MODULAR X Netzwerk

Beitragvon Quietschboy » Sa 10. Jun 2017, 23:11

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
Dateianhänge
Initialization R6.0.4 V3.zip
(51.34 KiB) 20-mal heruntergeladen
Quietschboy
meister
 
Beiträge: 145
Registriert: Mi 6. Apr 2011, 20:31
Wohnort: Wiesbaden

Re: MODULAR X Netzwerk

Beitragvon Quietschboy » Sa 10. Jun 2017, 23:26

Ä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.
Quietschboy
meister
 
Beiträge: 145
Registriert: Mi 6. Apr 2011, 20:31
Wohnort: Wiesbaden

Re: MODULAR X Netzwerk

Beitragvon Eventmanager » So 11. Jun 2017, 10:06

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?
Eventmanager
meister
 
Beiträge: 173
Registriert: Di 25. Jun 2013, 15:26

Re: MODULAR X Netzwerk

Beitragvon Thala » So 11. Jun 2017, 12:36

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:

viewtopic.php?f=14&t=1109

ich leide mit dir!
Thala
synthesist
 
Beiträge: 83
Registriert: Do 1. Okt 2015, 14:36

Re: MODULAR X Netzwerk

Beitragvon Eventmanager » Mo 12. Jun 2017, 10:09

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.
Eventmanager
meister
 
Beiträge: 173
Registriert: Di 25. Jun 2013, 15:26

VorherigeNächste

Zurück zu PROJEKTE

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast

cron