MODULAR X Netzwerk

[herw]

nun einige weitere neue Container im Testensemble 2:

Test 2.jpg

Neben den schon bekannten Containern der Version 2, die ich ja auch testen muss, kommen neu hinzu:
- SC ADSR
- PSK OSC
- MIDI Controller

und natürlich jetzt auch ein größeres Ensemble mit zwei Racks.

ciao herw

[herw]

Beim Testen muss ich noch manchmal um die Ecke denken. Nachdem ich die Kabelebene erfolgreich getestet habe, geht es an die Audioverbindungen. Dort kam es zu falschen send-receive-Verknüpfungen. Der Fehler war nicht einfach zufinden. Das Prinzip des Audiobusses ist, dass immer abwechselnd ein event-send und ein audio-send in den receive Listen auftauchen.
Alle receive-Listen sind gleich aufgebaut. Bei der Kontrolle stellte ich fest, dass 5 sends als event-sends angesehen wurden, obwohl es audio-sends sein mussten. Also musste ich nach Modulausgängen suchen, die zwar in der Applikation events liefern, aber noch nicht zu audio-events umgewandelt wurden: es waren zwei MIDI- und ein CONTROL-Container. Nun funktioniert es. Ich muss mich erst mal an das Prinzip und die Tücken des audio-Busses gewöhnen.

ciao herw

PS: gestern habe ich mal wieder mein DOEPFER-System A-100 an meine PA angeschlossen und musste leider feststellen, dass einer der Hochtöner wohl defekt ist. Also erst mal zu meinem Musikgeschäft meines Vertrauens und die Reparatur veranlasst. Ich glaube, ich muss mal beim Ausprobieren neuer Patches (sowohl hardware als auch software) etwas vorsichtiger mit dem Lautstärekregler umgehen. Meine Nachbarn werden es mir auch danken; 325 Watt sind kein Pappenstil . Um überhaupt etwas zu hören, musste ich mir leider auch einen neuen Kopfhörer anschaffen. Nach gefühlten 20 Jahren war das mal fällig.

[herw]

Die neuen phase-shift-keying-Oscillatoren funktionieren nach einigen Änderungen der Modulationsbereiche sehr gut. Etwas aufpassen musste ich bei der Modulation mit Rechteck- und Sägezahnschwingungen. Dort wurden plötzlich leicht Amplituden von 50 erreicht, was natürlich zu einer absolut starken Übersteuerung führte. Die Ursache liegt wohl darin, dass dann für einen Sampletick der Rückschritt im Phasenoszillator fehlt. Ich habe den Ausgang einfach nach oben und unten geklippt. Jetzt ist es sehr gut nutzbar. Die sehr kleine Einteilung von 0,005 beim Frequenzverhältnis führt zu sehr feinfühligen Klangveränderungen:

PSK-osc.jpg

Freunde des DX7 werden sich freuen
Schon in der letzten Teststunde konnte ich mit nur zwei Oszillatoren eine große Anzahl sehr verschiedenartiger Klänge erzeugen. Im Bild moduliert ein Dreieckoszillator eine Sinusschwingung.

ciao herw

[herw]

Natürlich hat mich diese Übersteuerung nicht ruhen lassen. Nach vier Stunden habe ich das Problem erkannt und nun komplett gelöst. Der Hase lag im Pfeffer bei der Definition der Phasenmodulation. Als gar nichts mehr so war, wie ich es mir vorstellte, half die pure Mathematik.
In GeoGebra habe ich mir zunächst mal die Funktionen , die durch Phasenmodulation entstehen, angesehen:
Carrier:Modulator = 1:1

FM 1.jpg

Carrier:Modulator = 1:3

FM 2.jpg

.

Als das perfekt auch REAKTOR ausgab, musste ich noch klären, wie man die Phasengleichheit der Oszillatoren erreicht, damit es nicht bei jedem neuen Ton eine Klangveränderung gibt. Das erreicht man durch einen Gate-Event, der die Oszillatoren zurücksetzt. Allerdings klappte das nicht, bis ich entdeckte, dass ich zwei dup-Filter hintereinander gesetzt hatte und dann natürlich nur beim Starten des Ensembles die Oszillatorschwingungen überhaupt zurückgesetzt wurden.
Dann noch die Phasenverschiebung der Oszillatoren. Bei den ersten Versuchen gab es immer ein ordentliches Kratzen, nach einer entsprechenden Normierung gelang es aber auch.
Gestern habe ich mich noch über ein Knacksen beim Einsetzen der Schwingung geärgert. Jetzt klingt alles super sauber. Auch die anderen Wellenformen klappen nun perfekt:
Carrier: Sinus, Modulator: Rechteck
Carrier:Modulator = 1:4

FM 3.jpg

ciao herw

[lindeman]

Beeindruckende Arbeiten!

[herw]

Beeindruckende Arbeiten!

danke, wenn ich denn mal auch Zeit hätte, es weiterzutreiben. Dieses nur phasenweise Arbeiten an REAKTOR ist sehr hinderlich. Ich müsste mal eine durchgehende Periode von vier Monaten haben, in der ich mich nur auf RETOR konzentrieren könnte.
ciao herw

[herw]

Nach unendlich lang erschienener Zeit traue ich mich mal wieder an mein eigenes Konzept. Im letzten Jahr habe ich verstreut einige Tests gemacht. Ich bin mit dem Audio-Bus nicht mehr zufrieden. Die Idee ist zwar sehr raffiniert, doch erscheint mir der Aufwand mit gekoppelten send-receive-Verknüpfungen viel zu aufwändig.
Die Version 3 (nicht veröffentlicht) hat, wie vorher beschrieben, eine überzeugende Lösung für die Kabelverwaltung gebracht. Shared eventtables sind für solche isoliert übertragenen Informationen wie Koordinaten etc. sehr gut geeignet und gut getestet. Diesen Teil kann ich ohne Bedenken übernehmen.
Der Audio-Part, also die eigentliche Klangerzeugung, und die Übertragung der Audiosignale haben mich dagegen nie ganz überzeugt.
Vor allem die Unzulänglichkeit der send-receive-Verknüpfungen und deren umständliche Verwaltung - auch zur Verwirrung mancher user, die selbst einen modular erstellen wollen - hat mich immer wieder auf's Neue geärgert.
Man könnte auch Verkabelungen über AudioTables realisieren. Das ist im Prinzip machbar, kostet aber wie schon einmal woanders erwähnt, viel CPU-Last. Eine Alternative ist die Verwaltung aller Audiosignale in einer einzigen AudioCoreCell. Die Verknüpfungen geschehen über ein Array:

aus_der_zwischenablage2.jpg

Das hat den Vorteil, dass bei einem Snapshotwechsel überhaupt kein GlobalReset erfolgt, da keine send-receive-Verknüpfungen erstellt werden, also keine Switches mehr vorhanden sind. Die Umschaltung erfolgt nur über einen Wechsel der Indizes des CoreArrays.
Allerdings gibt es auch hier ein Problem: Da sich alle Audio-Module nun in einer einzigen CoreCell liegen, sind sie auch immer aktiv. Aber auch dafür gibt es eine (wohl bekannte) Lösung: alle Clocks, die irgendwelche Audioprozesse steuern sind abschaltbar. Das erfordert zwar einen zusätzliche Button im Panel jedes Containers, andererseits wird aber auch die CPU-Last bei jedem Snapshot auf das nötige Minimum reduziert.
Ich werde mich nun nach und nach wieder einlesen und diese (Version 4) weiterentwickeln.

ciao herw

[herw]

Nachdem ich mich gegen die AudioTables entschieden habe, habe ich mich auch gegen die EventTables entschieden. Das ganze Framework erscheint mir zu undurchschaubar, da es keine klaren Regeln gib, wie sich die EventTables, wenn mit synchronen Events gearbeitet wird, eigentlich aktualisieren. Gibt es eine Reihenfolge?
Ich habe das Konzept der Version 2 (realisiert im Ensemble RUHR) wieder übernommen und nur eine kleine Änderung vorgenommen. Es kommt nur eine zusätzliche Komponente bei der Initialisierung hinzu: da jedes Panelelement eine Adresse hat muss der Container ebenfalls eine Nummer bekommen. Dieses Konzept erscheint mir am einleuchtendsten: Jede Datenübertragung bekommt eine eindeutige Adresse (Containernummer und Panelelement). Das ist klar und überzeugend.
Mich erstaunt immer wieder bei solchen Entscheidungen, dass die Klarheit einer Aussage für mich das entscheidende Moment ist. Ich habe dann ein gutes Gefühle, dass meine Ideen realisierbar sind.

grobplanung_modular_x_4.jpg

Leider habe ich wenig Zeit, so dass ich immer nur Stunden (Minuten?) pro Woche daran arbeiten kann. Aber ich habe ein gutes Gefühl, dass die Version 4 gut sein wird. Es dauert eben nur ein wenig. Aber was soll's: NI bekommt es ja in neun (!) Jahren nicht gebacken, von Version 5 zur Version 6 zu wechseln; kleiner Seitenhieb gegen NI, obwohl ich weiß, dass sie immens an Neuerungen arbeiten, wenn auch nicht klar ist, wann es denn vielleicht mal zur Version 6 oder sonst etwas reicht.

[Quietschboy]

Das ganze Framework erscheint mir zu undurchschaubar, da es keine klaren Regeln gib, wie sich die EventTables, wenn mit synchronen Events gearbeitet wird, eigentlich aktualisieren. Gibt es eine Reihenfolge?

Hattest du diesen Thread hier beachtet? Es geht um shared event tables während der Initialisierung und deren Reihenfolge. Interessant wird es ab Post17:
http://www.native-instruments.com/forum ... em.218833/

Ich habe das Konzept der Version 2 (realisiert im Ensemble RUHR) wieder übernommen und nur eine kleine Änderung vorgenommen

Heißt das, du wirfst das Core Array für das Routing doch wieder über Board?

gruß, mark

[herw]

Das ganze Framework erscheint mir zu undurchschaubar, da es keine klaren Regeln gib, wie sich die EventTables, wenn mit synchronen Events gearbeitet wird, eigentlich aktualisieren. Gibt es eine Reihenfolge?

Hattest du diesen Thread hier beachtet? Es geht um shared event tables während der Initialisierung und deren Reihenfolge. Interessant wird es ab Post17:
http://www.native-instruments.com/forum ... em.218833/

Ich habe das Konzept der Version 2 (realisiert im Ensemble RUHR) wieder übernommen und nur eine kleine Änderung vorgenommen

Heißt das, du wirfst das Core Array für das Routing doch wieder über Board?

gruß, mark

nein core array will ich in jedem Fall in die Version 4 aufnehmen. Die primary audiotables oder auch den audiobus werde ich als Alternative nicht mehr erwägen.
Die shared eventtables habe ich nur benutzt, um event-Daten über große Wege zu verteilen. Das geht einfacher mit dem Bussystem vom Partials framework. Es war ein interessanter Test, der auch perfekt funktionierte (obwohl ich diesen Initialisierungen nicht über den Weg traue). D.h. Ich werde in primary gänzlich auf tables verzichten.
Letztendlich ist dieser Transportweg schlecht pflegbar, ständiges Schreiben und Auslesen der Eventtables, obwohl nur wenige Werte selten gebraucht werden. Der Aufwand lohnt nicht.
Das Neue der Version 4 ist der Versuch, die Container in eine audio core cell zu packen und über ein core array zu verknüpfen, d.h. ich möchte die send-receive-Verknüpfungen nicht mehr benutzen, da sie immer einen global reset verursachen. Der ungemeine Vorteil der send-Module ist, dass sie die vorgeschaltete Struktur automatisch ausschalten, wenn keine Verbindung zu einem receive besteht.
Dies muss ich in einer corecell emulieren, indem ich alle entsprechenden Clocks ausschalte (ohne global resets). Das geschieht allerdings im Moment nicht automatisch; darüber muss ich wohl noch lange nachdenken. D.h ich müsste eine Verwaltung schreiben, die registriert, ob ein Container angeschlossen ist oder nicht, also ob an irgendeinem Ausgang eines Containers irgend ein Ziel angehängt ist. Im Moment begnüge ich mich mit einer manuellen Lösung. Alle entsprechenden Strukturen muss ich dann so umschreiben, dass die SR-Clock abschaltbar ist (etwas lästig, aber auch wieder nicht so schlimm). Man könnte eine solche Verwaltung dadurch erstellen, dass man beim Lösen eines screenkabels verlangt, dass die Verbindung sowohl vom Kabeleingang als auch vom Kabelausgang gelöscht werden muss; im Moment ist es nur ein Rechtsclick auf einen Eingang. Könnte man überlegen, ist aber fehleranfällig, wenn ein fremder Nutzer es ungenau behandelt - alles sehr kompliziert.
ciao herw

[Quietschboy]

OK, und jedes Modular-Modul hat dann 2 Container? Einen für die Panel Elements/Kabel in Primary und einen in Core für die eigentliche Audioberechnung und -routing?

[herw]

OK, und jedes Modular-Modul hat dann 2 Container? Einen für die Panel Elements/Kabel in Primary und einen in Core für die eigentliche Audioberechnung und -routing?

genau, der Panelcontainer hat lediglich eine Eventbus-Verbindung, die audiocore-container eine Adresse, den Eventbus und die sternförmige Verbindung zum Audio-Array (siehe Post vom 9. Mai 2014).

[Quietschboy]

OK, und jeder "Ausgang" eines Core Containers schreibt in eine festgelegte Array-Zelle (Index)?
Für "Eingänge" von Containern wird dann je nach Kabelverbindung ganz modular die Array-Zelle des entsprechenden "Ausgangs" per SR ausgelesen?

Soweit easy, den Rest wollte ich mir nicht antun müssen (lässt mich aber trotzdem nicht kalt )

Ich hoffe für dich, du kommst ohne Feedback aus Core heraus zu den Panel Elements aus...ich kann deinen Ärger von neulich gut nachvollziehen.
Falls du doch PEs aus Core ansteuern mußt würde das doch zumindest einen weiteren Bus bedeuten. Mit einem einzigen, weiteren {b}-Kabel würde es gehen, wenn [],# und values in einen Ringbuffer geschrieben, dieser über SR ausgelesen und nach Primary übertragen würden. Wie es auch im ACEW gelöst ist. Also es würde gehen, wenn die Core Container auch über die IDs der PEs ihres Primary Pendants bescheid wissen.
Ganz schön vertrackt, ich bin seeeehr gespannt, wie du das alles löst.

[herw]

OK, und jeder "Ausgang" eines Core Containers schreibt in eine festgelegte Array-Zelle (Index)?
Für "Eingänge" von Containern wird dann je nach Kabelverbindung ganz modular die Array-Zelle des entsprechenden "Ausgangs" per SR ausgelesen?

Soweit easy, den Rest wollte ich mir nicht antun müssen (lässt mich aber trotzdem nicht kalt )

Ich hoffe für dich, du kommst ohne Feedback aus Core heraus zu den Panel Elements aus...ich kann deinen Ärger von neulich gut nachvollziehen.
Falls du doch PEs aus Core ansteuern mußt würde das doch zumindest einen weiteren Bus bedeuten. Mit einem einzigen, weiteren {b}-Kabel würde es gehen, wenn [],# und values in einen Ringbuffer geschrieben, dieser über SR ausgelesen und nach Primary übertragen würden. Wie es auch im ACEW gelöst ist. Also es würde gehen, wenn die Core Container auch über die IDs der PEs ihres Primary Pendants bescheid wissen.
Ganz schön vertrackt, ich bin seeeehr gespannt, wie du das alles löst.

naja es geht; aus der CoreCell heraus gibt es nur zwei notwendige Anwendungen: ich muss in jedem Fall aus der polyphonen AudioCoreCell zu primary wechseln, um die monophonen Effektcontainer anzusteuern. D.h. es gibt in jedem Fall eine polyphone und eine monophone AudioCorecell.
Informationen, die wieder nach draußen an das Panel gehen, gibt es nur sehr wenige: Levelmeter und Oszillographen müssen mit Audiosignalen versorgt werden. Das könnte ich mir sparen, wenn core direkt Panelelemente aus der Core-Ebene heraus versorgen könnte. Da ich ja nicht weiß, wie viele Panelelemente ich versorgen muss, gebe ich die mögliche Anzahl vor. In der Abbildung in der Post vom 11. Juni siehst du, dass acht Leitungen von der CoreCell zurück in das GUI-Makro verlaufen. Zwei dieser Leitungen soll das GUI des Oszillographen versorgen und die restlichen sechs einen neuen Container, der nur Level anzeigen soll, also quasi ein Messinstrument darstellt. Eine andere Idee habe ich noch nicht.
Natürlich wäre es schöner, wenn die Levelmeter alle im jeweiligen Container sitzen, aber ich kann es nicht herbeizaubern.

ciao herw

[herw]

naja es geht; aus der CoreCell heraus gibt es nur zwei notwendige Anwendungen: ich muss in jedem Fall aus der polyphonen AudioCoreCell zu primary wechseln, um die monophonen Effektcontainer anzusteuern. D.h. es gibt in jedem Fall eine polyphone und eine monophone AudioCorecell.[...]
ciao herw

hmmm - die getrennten CoreCells für mono und poly ärgern mich sehr; darüber habe ich mich schon beim Entwicklerteam beschwert. Es müsste ähnlich wie in primary möglich sein, auf einzelne voices zuzugreifen (vor allem schreibend) und innerhalb einer Corecell auf Mono umschalten zu können.
Das ärgert mich dermaßen, dass ich erwäge, alles in mono zu konstruieren und meine eigene Stimmverwaltung zu konstruieren. Das geht wohl auch, aber ist trotzdem lästig.
Ich muss mich dann auf eine Stimmenzahl festlegen und entsprechend alle internen core-Container vervielfachen. Das Verknüpfungsarray vervielfacht sich entsprechend der Stimmenzahl. Die Auswahl ist dann ein wenig komplexer, aber ich denke beherrschbar.
Ich probiere aus, ob das praktikabel ist. In jdem Fall könnte ich so einzelne Voices auch miteinander verknüpfen. Das Audio-Merge-Modul in Primary ist in core lediglich eine Addition.
Schau'n wir mal. Ich merke schon, das wird eine Arbeit im Urlaub.

ciao herw