der MODULAR

[Illya F.]

Also nur mal so als Zwischenmeldung. Ich bin jetzt ja hauptsächlich (wenn ich denn etwas mache) mit dem bunten Modular am basteln und stelle fest, das ich gerne Klänge aus zwei Strängen baue. Also beispielsweise zwei normale OSC mit einem Paar welches einen Ring/AM Sound macht zu mischen. Dabei stelle ich fest, das ich mich meist ein wenig verstricke, da ich dazu gerne noch ein Pärchen an OSCs für einen FM Klang dabei hätte. Schon klar das nicht jeder so komplexere Klänge bauen will, aber mit 6 Oszillatoren wäre so ein System schon fast perfekt denke ich. Vier sind gut, aber mit 6 wäre das wirklich besser. Man muss die ja nicht nutzen, aber wer kann und will macht das dann doch.

Bin jedenfalls immer noch begeistert von den Möglichkeiten und froh, dass das nicht mit einer Modmatrix gemacht ist, sondern so mit Stippen ziehen, da verliert man auch nicht so schnell den Überblick, bzw. fällt es mir leichter auch nach Tagen da wieder in ein Patch einzusteigen.

[herw]

Also nur mal so als Zwischenmeldung. Ich bin jetzt ja hauptsächlich (wenn ich denn etwas mache) mit dem bunten Modular am basteln und stelle fest, das ich gerne Klänge aus zwei Strängen baue. Also beispielsweise zwei normale OSC mit einem Paar welches einen Ring/AM Sound macht zu mischen. Dabei stelle ich fest, das ich mich meist ein wenig verstricke, da ich dazu gerne noch ein Pärchen an OSCs für einen FM Klang dabei hätte. Schon klar das nicht jeder so komplexere Klänge bauen will, aber mit 6 Oszillatoren wäre so ein System schon fast perfekt denke ich. Vier sind gut, aber mit 6 wäre das wirklich besser. Man muss die ja nicht nutzen, aber wer kann und will macht das dann doch.

Bin jedenfalls immer noch begeistert von den Möglichkeiten und froh, dass das nicht mit einer Modmatrix gemacht ist, sondern so mit Stippen ziehen, da verliert man auch nicht so schnell den Überblick, bzw. fällt es mir leichter auch nach Tagen da wieder in ein Patch einzusteigen.

Das freut mich; es wird mit Sicherheit auch ein größeres Modularsystem geben. Interessant wird es vor allem, wenn verschiedene Attackphasen gewählt werden auch mit kurzen Verzögerungen.
Du kannst auch ein wenig in diese Richtung mit dem Greyhound experimentieren. Dort gibt es sechs Oszillatoren. Ich habe dort eine Modulationsmatrix gewählt. Allerdings sind hier aus prinzipiellen Gründen alle Modulationsquellen Event-Quellen. Die Klangmöglichkeiten sind deutlich verschieden vom Modular.

ciao herw

[herw]

Nach einigen Wochen des Nachdenkens über die Konzeption des modular und auch nach intensivem Überdenken der grundsätzlichen Struktur habe ich nun den Entschluss gefasst, den modular neu aufzulegen.

Folgende Richtung weisende Gedanken sind die Leitlinien:

• die Struktur muss pflegeleichter sein: das Prinzip, die Daten in Datenströmen sowohl zur Grafik wie auch zur „Schaltzentrale” (Send-Receive wird von IC-Send gesteuert) wird überarbeitet. Da es sich bei diesen Datenströmen um reine Eventsignale handelt, die zudem nicht zeitkritisich sind, bietet es sich an, sie über nur wenige Leitungen zu übermitteln. Ich probiere im Moment zwei Alternativen aus:
  
  • gemeinsame Eventtabellen, oder/und
    adressierbare Datensignale.
  Beides ist sehr interessant und ist auch schon in wichtigen Vorexperimenten erfolgreich (siehe auch Experimente zum Eventbus in anderen Threads)
• Grafische Aspekte müssen nicht verändert werden, die geradlinigen Kabel haben sich bewährt, wenn mir auch hängende Kabel besser gefallen (übersichtlicher bei mehreren überlappenden Kabeln). Die Bedienelemente sollen nur noch die Standardelemente verwenden. Zwar war es sehr schön, Sonderformen der Regler (Rechts-/ Links, Doppelklick etc.) herzustellen, doch habe ich den Eindruck, dass sie zu kompliziert zu bedienen sind. Daher werden zum Beispiel Grob- und Feineinstellungen von zwei Reglern statt einem eingeführt. Alle Bedien- und Anzeigeelemente werden auf den angebotenen Standard zurückgeführt. In Konsequenz benutze ich keine Maus-Areas mehr: sie sind nicht midifizierbar und daher für den Benutzer als Teil von Bedienelementen nutzlos. Ich verwende sie nur noch für Ensemble-interne Schaltvorgänge (Umschalten von Panel-Ansichten zum Beispiel). Den Workaround zur Midfizierbarkeit über die Panelansicht B hat wohl niemand entdeckt oder praktiziert.
• Ob das Ziel erreicht werden kann, die Modulstrukturen so einfach zu gestalten, dass jeder erfahrene User seinen eigenen modular aus einem Pool fertiger Module zusammenstellen kann, ist noch nicht vorhersehbar, werde ich aber anstreben. D.h es werden mehr Module angeboten als dann in einem zusammengestellten Ensemble wirklich eingebaut werden. Für mich selbst werde ich dann verschiedene Varianten anlegen.
• Die Modulbibliothek soll in die Richtung erweitert werden, dass sie neue Module anbietet, die in der Standardbibliothek nicht vorhanden sind: zum Beispiel Hüllkurven mit exponentieller Attackphase (Filter reagieren viel aggressiver), Module mit den neuen Oszillatoren (zerophase Oszillatoren aus den core additions).

Als Zeitaufwand setze ich ein halbes Jahr an, so dass möglichst noch vor Jahresende 2010 das erste neue Modulsystem veröffentlicht wird. Es wird mehrere Varianten geben: das Einstiegsensemble m1 mit einem Rack und den üblichen Grundmodulen, dann jedoch auch mit zwei und drei Racks. Ein Großvariante mit sechs Racks ist auch geplant, insbesondere um einfach mal die Leistungsfähigkeit des Rechners und von REAKTOR zu testen.

Ich hoffe, dass die einzelnen Bauschritte so einfach angelegt werden können, dass (zumindest für mich) die Zusammenstellung alternativer Modulare eine Sache von maximal zwei Stunden sein wird.

Bei wichtigen Zwischenergebnissen werde ich hier in Bild und Text berichten.

ciao herw

[herw]

Mein erster Blick geht auf die Paneldarstellung der Kabel. Sie bleibt erhalten. Der Trick, wie man das Multipicture-Modul immer im Hintergrund hält, funktioniert perfekt; jedes Modulfeld hat ein fast gänzlich transparentes Hintergrundbild (hier der Rahmen mit dem grauen Texthintergrund). Dadurch bleibt bei jedem Mausklick auf ein Modulfeld immer das Rack aktiv und das Multipicture-Modul im Hintergrund.
Was ich geändert habe, ist die Wahl des Aus- bzw. Eingangs: Im Gegensatz zur aktuellen Version habe ich die Maus-Areas durch Buttons ersetzt (hier schon mit einem neuen Skin).

Wires und Buttons.jpg

Das Kabel ist noch durch nur eine Linie dargestellt. Ich werde die Dicke auf vier Teillinien vergrößern.
Der Ausgangs-Button ist im Bild grau dargestellt und arbeitet lediglich als Trigger. Der Eingangsbutton dagegen ist als Toggle eingestellt (blau (cool) und rot (hot)) zur Kennzeichnung des Belegungszustands. Die Farbbelegung ist in der Abbildung noch nicht korrekt.

[Illya F.]

Das hört sich ja prima an. Toll, freue mich schon darauf.

[herw]

ja ich auch; ich bin auch schon fleißig und im Urlaub habe ich viel Muße. Hier gibt's dann keine Meldungen, da ich im wahrsten Sinne des Wortes Funkstille haben werde.
Das Konzept der Datenübermittlung wird ganz neu aufgebaut; es wird dann, wenn überhaupt, nur noch ganz wenige Kabelverbindungen der Module (ich nenne sie nun Container) geben. Da in R5.5 die internen Verbindungen wesentlich einfacher zu verwalten sind, hoffe ich die Container wirklich so stark normieren zu können, dass man in kurzer Zeit ein verändertes System aufbauen kann. Ob das sogar soweit gehen soll, dass es jeder kann weiß ich noch nicht - mal sehen.
Die Verwaltung der Kabel ist im Moment meine Aufgabe. Die Idee bleibt dieselbe, wie gesagt die Übermittlung der Adressen und Kabeleigenschaften soll stark reduziert werden. Vielleicht kann ich alles auf einen Datenstrom über interne Verbindungen reduzieren. Dazu brauche ich aber etwa noch vier Wochen. Das ist im Moment sehr spannend. Das muss sehr sorgfältig geschehen, da hiervon das Funktionieren des gesamten Systems abhängt. Deshalb siehst du auch auf der vorangegangenen Post nur die Ein- und Ausgangsbuchsen. Die eigentliche Gestaltung der Container ist ja in den letzten Versionen ausgiebig getestet. Die Überfrachtung von Panelelementen mit Eigenschaften (Rechts-, Links- Doppelklick auf MausAreas) hat sich nicht bewährt und ist für die meisten User eher abschreckend.
D.h. ich möchte die Bedienung so einfach gestalten, dass jeder, der das System zum ersten Mal sieht, sofort loslegen kann, ohne komplizierte Anleitungen lesen zu müssen.

Wenn Du ein spezielles System favorisieren möchtest, dann kannst du ja mal, wenn es denn aktuell wird, einen Systemvorschlag machen etwa so : ich habe gerade bei Döpfer mir ein System zusammengestellt, mir fehlt aber der Platz und das Geld; es sollte dem Monsteraufbau, der auf der Seite ??? dargestellt ist, entsprechen und zusätzlich hätte ich gerne noch acht Spezialoszillatoren und achja fünf parallel laufende Sequenzer, deren Stepfolgen nach einem ganz bestimmten Algorithmus selbständig neue Sequenzen erzeugen...

ciao herw

[herw]

Den Urlaub habe ich intensiv genutzt, um das neue Containersystem in Angriff zu nehmen. Auch wenn die Testcontainer noch nicht fertig gestellt sind, so zeichnet sich doch mit Sicherheit schon ab, dass ich es schaffen werde, dass jedermann sich sein eigenes Modularsystem innerhalb küzester Zeit zusammenstellen kann, und zwar so einfach, dass er sich nur

• die passenden Container aussucht,
• diese auf dem Panel plaziert und
• über lediglich zwei (!) Leitungen zu einer Kette miteinander verknüpft.

D.h. wenn man weiß, welche Container das System erhalten soll und wo sie angeordnet werden sollen, dann dürfte das in 5 Minuten erledigt sein!!!

ciao herw

[herw]

Die Verbindung der einzelnen Container und Racks erfolgt nur über zwei Datenstränge:
Bus {B} übermittelt bei der Initialisierung die Größe der Ensemble-Oberfläche und alle relevanten Daten der Container und des Interface (Anzahl der Ein- und Ausgänge der Container). Bei jeder Übergabe werden die absoluten Koordinaten der Container neu berechnet und daraus die absoluten Koordinaten der Ein- und Ausgänge bestimmt. Insgesamt werden diese Daten über eine einzige Leitung übermittelt. Bei der Konstruktion muss sich der User nur um die Verbindung der beiden Busse kümmern - ein Kinderspiel.
Der Bus {B} wird tatsächlich nur beim Start des Ensembles benötigt. Interessant ist, dass alle Berechnungen unabhängig von der Größe des Ensemble ohne direkten Eingriff durch den User erfolgen.

Datenfluss racks.gif

Der Bus {w} übermittelt nur die Nummer des aktuellen Ausgangs. Er dient als Trigger, der alle relevanten Daten an die Grafik übermittelt und den zugeordneten Receive-Kanal, den eigentlichen Audiokanal, entsprechend schaltet. Im gezeigten Bild würde dies einem Ensemble mit sechs Racks entsprechen. In dieser Anordnung würde es knapp drei 17-Zoll-Bildschirme ausfüllen.
Alle Container übermitteln ebenfalls in einer Kette dieselben Daten. Im folgenden Bild habe ich nur wenige Container eingefügt, d.h es würde noch nicht voll belegt sein.

Datenfluss Container 6.jpg

Am Ende der Kette steht ein globales Speicherfeld, auf das alle Interfaces zugreifen können.
Die gezeigten Abbildungen dienen nur zu Veranschaulichung und sind in dieser Entwicklungsphase nur teilweise funktionsfähig.

ciao herw

[herw]

Der Block-Datenstrom {B}

• im Kopf des Blocks der Identifier 0 (id=0) und die Anzahl der Daten (#=14)
• fortlaufende Nummer R# des Racks (beginnend unten links) nach oben folgend bis zum Überschreiten der Gesamt-Ensemblehöhe, dann nach rechts
• Nummer C# des Containers; Nummerierungsschema wie bei den Racks
• Rastergröße Ey des Ensembles in y-Richtung
• Rastergröße Ex des Ensembles in x-Richtung
• aktuelle Rackkoordinate Ry1 oben in y-Richtung hinter dem aktuellen Rack
• aktuelle Rackkoordinate Ry0 unten in y-Richtung des aktuellen Racks
• aktuelle Rackkoordinate Rx1 rechts in x-Richtung hinter dem aktuellen Rack
• aktuelle Rackkoordinate Rx0 links in x-Richtung des aktuellen Racks
• aktuelle Containerkoordinate Cy1 oben in y-Richtung hinter dem aktuellen Container
• aktuelle Containerkoordinate Cy0 unten in y-Richtung des aktuellen Containers
• aktuelle Containerkoordinate Cx1 rechts in x-Richtung hinter dem aktuellen Rack
• aktuelle Containerkoordinate Cx0 links in x-Richtung des aktuellen Containers
• fortlaufende Anzahl der Ausgänge O#
• fortlaufende Zahl der Eingänge I#

Insgesamt werden also in diesem sequentiellen Datenblock 16 Daten weitergegeben. Um dies alles hat sich der User nicht zu kümmern, er muss lediglich die zwei Kabel für die Datenströme ziehen - sehr einfach, für mich als Entwickler allerdings nicht.

Vielleicht wundert sich mancher, warum die Reihenfolge der Koordinaten (insbesondere Ry1, bzw. Cy1 vor den anderen Daten) genau so gewählt wurde. Nun, das liegt an der möglichen Anordnung der Racks bzw. Container. Bevor die neuen Koordinaten berechnet werden, muss kontrolliert werden, ob eine neue Rack- bzw. Containerspalte erzeugt wird; siehe hierzu die unten stehende Abbildung. Dies hängt allein von Ry1 bzw. Cy1 ab. Also müssen diese Daten vor den anderen Koordinaten vorliegen, um korrekte Zuweisungen zu erhalten. Dies ist einer der Fallstricke, bei einer sequentiellen Datenverarbeitung. Gleichzeitigkeit gibt es im Computer nicht (wirklich). Dies hat mich einen ganzen Tag Entwicklung gekostet. Ich habe dies in meinem Arbeitsbuch ausführlich notiert; wenn ich mir vorstelle, ich sollte dies vielleicht nach zwei Wochen Unterbrechung wieder rekonstruieren, käme ich kaum zu einer Weiterentwicklung, sondern müsste mühsam alles gedanklich rekonstruieren.

Das erste Ensemble wird zwei übereinander liegende Racks besitzen, um die Datenübergabe zu testen. Dies entspricht in etwa der Größe des MODULAR m1. Größere Ensembles sind dann aber kein Problem mehr.
Bei der Übergabe der Daten als Block berücksichtige ich (vorsichtshalber), dass diese erst dann erfolgt, wenn alle Daten berechnet wurden. Dies geschieht durch einen Zwischenspeicher (geordneter Ringbuffer).
Manche Racks können durchaus auch kleinere Containerformate übernehmen, so dass auch Zwischengrößen möglich sind; hier mal ein kleiner erster Eindruck:

Rackbeispiel.gif

Oszilloskope oder eventuell auch eine Tastatur können somit ohne Probleme direkt in das Rack übernommen und auch beliebig positioniert werden.

[herw]

In den letzten Tagen habe ich das Einfügen von Containern und den korrekten Datenfluss zwischen ihnen getestet. Obwohl ich immer das Gefühl hatte, dass es klappt, musste ich doch viele Fallstricke meistern, damit auch wirklich alle Eventualfälle berücksichtigt werden. Das Ziel dieses Tests war es, eine größere Anzahl von Racks (2x2) mit jeweils drei Containern anzuordnen. Die Container sollten dabei sowohl in der Höhe, wie auch in der Breite unterschiedlich sein. Bei der automatischen Berechnung der jeweiligen lokalen Ursprungskoordinaten muss der Container selbständig erkennen, wo er sich im Rack befindet, d.h. aus der Anordnung in der Sequenz der Container muss das Intialisierungsmakro eines Containers aus den Daten seines Vorgängers die absoluten Koordinaten berechnen. Dabei kann es sein, dass die Container in einem Rack übereinander angeordnet sind,also so klein sind, dass das Rack in der Höhe noch nicht ausgefüllt ist, oder dass ein Container die oberste Rackhöhe erreicht hat und dann wieder unten im Rack rechts daneben angegeordnet ist. Da der User sich mit so etwas überhaupt nicht beschäftigen soll, müssen alle Eventualitäten vorausgedacht werden.
Dass auch Container mit einer kleineren Höhe zugelassen werden, ist ein großer Vorteil der neuen Version. Wenn ich also einen Container mit nur zwei Reglern und einem Ein- und Ausgang benötige, dann ist es pure Platzverschwendung, wenn ich dafür die volle Höhe des Racks benutzen müsste.
In der nachfolgenden Abbildung zeige ich ein Rack (es ist links oben im Gesamtensemble), das zwei kleinere Container übereinander gestapelt hat und ein sehr großen Container rechts daneben.

Datenfluss Container 7.jpg

Die drei Eventwatcher dienen zur Kontrolle, ob die Daten richtig übergeben wurden.
Jeweils wurden alle 16 Werte weitergegeben und verändert. Interessant sind hier die Zeilen 11-14. Die Datenwerte zu 12 und 14 geben den Koordinatenursprung (links-unten) eines Containers an und 11 und 13 die Ecke rechts-oben. Die Werte sind keine Pixelwerte sondern, wie schon sehr viel weiter oben erklärt, Rasterwerte, die das 4-Pixelraster im GUI von REAKTOR verwenden. Der kleine Container links unten füllt natürlich noch nicht die Rackhöhe von 90 aus, daher wechseln die x-Werte (Zeilen 13, 14) nicht. Die vertikale Position dagegen wechselt von [120,90] auf [180,120] (Zeilen 11, 12). Der dritte Container schließlich füllt das Rack nach rechts auf. Er erkennt, dass die Rackspalte gefüllt ist und setzt seinen Usprung entsprechend.
Berücksichtigt werden muss auch die Position des jeweiligen Racks. Dies erfolgt nach demselben Schema.

Ich bin sehr zufrieden, dass es nun klappt. Auch wenn ich bei der ersten Veröffentlichung zunächst wohl nur Container mit einheitlicher Höhe benutzen werde, ist es natürlich schön, diese Option schon vorbereitet zu wissen. Ich bin auch sehr zufrieden mit dem reibungslosen Einfügen der Container in die Kette. Es ist wirklich kinderleicht und schnell.

Die nächste Testphasen werden wohl nicht so schwierig sein, da sie Teile der Daten auswählen und auswerten, aber nicht wieder in den Bus einspeisen:

• Übergabe der Werte an den globalen Speicher
• Berechnung der Daten des Interface (Aus- und Eingänge)
• Datenstrom eines gewählten Kabels
• Grafikausgabe

Wenn diese Testphasen abgeschlossen sind, ist das Ensemble mit den Panel-Kabeln vollständig vorbereitet und dann kann das Erstellen der Container beginnen.

[herw]

Hi,
ich wollte mal wieder etwas berichten.

Wie immer liegt der Teufel im Detail: die Intialisierung einer Eventtable, die durch einen Eventbus programmiert wird, kann schon unangenehm sein. Beim Einschalten des Ensembles werden die Kabeldaten (Koordinaten und gewählter Ausgang) richtig initialisiert und auch im Anschluss bei Wahl eines neuen Ausgangs und Eingangs entsprechend überschrieben. Doch möchte ich, dass die Daten bei der Wahl eines neuen Kabel auch erhalten bleiben. Nun werden ja nach dem Konzept des Modulars durch eine neue Kabelverbindung receive-Module geschaltet. Receive-Module wiederum entsprechen Schaltern und lösen eine Intialisierung aus, wodurch der Speicher wieder mit den Anfangsdaten überschreiben wird. D.h ich musste den Initialisierungsevent abblocken. Es hat mit einem kleinen Core-Modul geklappt.

Nun werden beim Anklicken der Ausgänge und Eingänge die richtigen Daten gesendet und zwischengespeichert.

interface.jpg

Man sieht hier wie Ausgänge und Eingänge auf den gemeinsamen Speicher RAM zugreifen. Das Konzept, den gemeinsamen Speicher als Eventtabelle zu realisieren ist einfach und erspart eine Unmenge an Kabeln. Alle Eventtabellen sind Clients einer einzigen Tabelle und insofern ist jede Veränderung direkt überall abrufbar.

Da ich schon in einem früheren Ensemble die Darstellung der Kabel auf dem Bildschirm auch mit größeren Panels überprüft habe, steht nun der Abschluss an und ich muss beides in Einklang bringen.
Ich hoffe, ich finde so viel Zeit, dass es in spätestens zwei Wochen steht.

[herw]

Je länger ich in diesem Projekt arbeite, desto überzeugter bin ich von dem Konzept der Eventbusse. Es basiert in Teilen auf den Ideen von Max Zagler, einem der Entwickler von PRISM. Die Idee , die hinter den Eventbussen steckt ist, dass man mit Hilfe der Kabel in der Reaktorstruktur lediglich den Datenfluss kenntlich macht, ohne dass die übersandten Daten im einzelnen durch viele Kabel dargestellt werden. Dies schafft Übersicht, erfordert aber auch in vielen Teilen eine starke Disziplin. Das Konzept ist leider (noch) nicht auf Core beschränkt; das wäre ein großer Wunsch von meiner Seite aus; insofern muss ich häufig die primary- und core-Ebenen wechseln. Letztlich zeigen sich trotz einiger Schwierigkeiten immer wieder klar Vorteile für ein solches Vorgehen für den Strukturaufbau. Das Denken in Datenströmen ist ungemein erleichternd, wenn man über die Anzahl der übersandten Daten und deren Aufbau keinen Gedanken verschwenden muss.

Immer wieder entwickle ich „nebenbei” nützliche kleine Makros, die ich dann öfters mit verwerten kann. So baue ich parallel zum eigentlichen Ensemble ein Grundgerüst für den Modular auf.

[herw]

Nach und nach räume ich die Makros auf. Sobald der Datenfluss klar ist, werden einfache Makros gebildet, um Verarbeitungsabschnitte zusammenzufassen. Zum Beispiel ist die Datenübergabe der Aus- und Eigänge geklärt. Um später einfach neue Module zu entwickeln, habe ich nun die Bedienelemente jeweils in ein Makro gepackt:

outs und ins.jpg

Die Übergabe im Makro out's data to RAM ist fertig, die entsprechende Übergabe der Daten der Eingänge will ich heute abschließen.

RAM.jpg

Hier wurde beispielsweise gerade im RAM abgespeichert (Eventwatcher von oben nach unten lesen):
Gesamtzahl der Ausgänge: 2
gewählter Ausgang : 2
Koordinaten des Ausgangs: (y|x)=(4|1)
Koordinaten des Eingangs (dunkelblau): (y|x)=(15|6)
RGB-Farben: die Zahlen -1, 0 und 1 haben noch keine Bedeutung
Status des Eingangs ausgeschaltet: -1

Der Datenfluss ist klar. Ich muss die Daten zweimal verarbeiten, zuerst müssen diese im RAM abgespeichert werden (dies geschieht entsprechend den Ausgängen) und danach muss ein Event zum Schalten des Receive-Kanals und an die Grafik gesendet werden. Das „danach” hat mir einiges Kopfzerbrechen verursacht, da ich wirklich sicherstellen muss, dass alle nötigen Daten zuvor im RAM abgespeichert sind. Bei einfachen Eventsignalen ist dies kein Problem; man kann einfach ein Ordermodul verwenden. Werden die Daten jedoch in einem Stream als Block verschickt, muss dieser Stream zunächst mal wirklich abgearbeitet und dann ein zweites mal verarbeitet werden. Dies geschieht durch Zwischenspeicherung in einem Ringbuffer (siehe Ausführungen einige Posts oberhalb).

[herw]

Jetzt geht es an die Kabel. Da ich ja schon vor ein paar Wochen Vorexperimente gemacht habe, greife ich das Testensemble wieder auf, um mir auch durch Vergleich mit dem modular m1 den Datenfluss klar zu machen. Auch hier möchte ich konsequent den Datenfluss über Datenblöcke gestalten. Ein kleines testensemble beschäftigt sich nur mit dem Datentransport und der Darstellung auf dem Bildschirm.

Kabeltest.jpg

Wie man sieht, ist das erste Kabel erfolgreich gezogen: durch Anklicken eines Eingangs wird es an- und abgeschaltet. Die Transparenz lässt sich auch nachträglich ändern.
Ich habe hier mal vier kleine Multidisplays gewählt (je 200x100px entspricht 50x25 Rasterpunkten), um zu sehen, ob die Anschlüsse von einem Multidisplay zum nächsten stimmen. Die Umrandungen werden natürlich später verschwinden. Das Kabel besteht nun auch wieder aus vier Linien. Die beiden Buchsen habe ich vorübergehend durch halbtransparente ersetzt, um zu sehen, wo die Linien genau enden.
Eine ärgerliche Klippe hatte ich bei der Datenübertragung der Transparenz zu umschiffen: Der Datenbus war zunächst auf Ganzzahl-Werte eingerichtet. Nun ist die Transparenz der einzige Event , der vom Typ Float ist. Also musste ich überall die entsprechenden Voreinstellungen ändern: bei den Ein- und Ausgängen von Core-Makros kann man dies leicht erkennen. Es gab aber eine ganz gemeine Falle: Ich benutze gerne Quickbusverbindungen die man innerhalb von Core-Makros leicht erstellen kann. Wenn sie zum Beispiel aus einem integer-Eingang entstanden sind, dann sind diese Quickbus-Verbindungen auch vom Typ integer. Ändert man nun den entsprechenden Ausgang auf float-Typ, dann ändert sich nicht automatisch auch die Quickbus-Verbindunng - gefährliche Falle.
Ohnehin werde ich bei der entgültigen Fertigstellung alles mögliche auf kleinste hin prüfen (müssen).

Da jetzt der Test wie gewünscht verlief, werde ich nun darangehen, das eigentliche modular-Grundgerüst aufzubauen. D.h. ab jetzt bin ich aus den Testphasen heraus und erstelle M1, M2 und M4 gleichzeitig mit Leermodulen. Die Nummer gibt jeweils die Anzahl der Racks an.
Zum Ausprobieren werde ich dann Module herstellen, die nur Ein- und Ausgänge besitzen.

Ich bin gespannt.

[Illya F.]

Au fein, das du schon so weit bist. Freue mich schon darauf.

So wie ich das verstehe, könnten wir dann (wenn man das selbst hin bekommt) dann nachher auch selber Module entwickeln, richtig? Ich meine das so: Ich nehme mir eines deiner Module und nutze dann die schon vorhandene "Anschlüsse", aber wurschtel mir das "Innenleben" dann selbst zurecht.

Vielleicht kannst du ja später, so etwas wie 1-2 Basismodule basteln, die eventuell dann eben X Eingänge haben, welche per Kabel mit den anderen Modulen verbunden werden können, also ganz normal wie jetzt auch, zuzüglich X Modulationseingängen (falls das da anders läuft) und X Drehreglern. Da du da ja drinsteckst und ich eben nicht, kann ich nun nicht sagen wie sinnvoll das wäre, oder wie "einfach" du das uns nicht so versierten Nutzern machen kannst, aber vielleicht ist so etwas ja möglich. Leider kann ich mich damit momentan nicht auch noch beschäftigen, da ich wieder einmal mit CSound ein wenig herum wurschtel und ich mich da nicht auch noch mit Reaktor beschäftigen kann, beides zusammen ist mir einfach zu viel momentan.

Letztendlich wollte ich auch nur Bescheid sagen, dass ich natürlich hier mitlese. Wirklich Feedback kann ich dir ja leider nicht geben. Was ich aber oben erwähnte, also diese Art von Basismodul(en), halte ich für eine gute Idee, weil dann hätte man auch die Möglichkeit sich seine eigenen Module da mit "ins Rack zu basteln", also Granulardelay etc.

Vielleicht so eines wie hier. Da hätte man dann einfach einen Eingang und Stereo out. Man könnte ja dann auch alles herausnehmen was man dann nicht braucht, also löschen. Ob das sinnvoll ist musst du aber entscheiden. Ich bin kopfmäßig momentan ganz woanders und muss da erst einmal meinen Kram gebacken bekommen, da ich den für meine nächsten musikalischen Geschichten brauche.

Reaktor-Basismodul1.jpg