eventbus

[herw]

Ich bin gerade einer ganz heißen Sache auf der Spur: wie bekommt man mehrere event-Signale, die eigentlich parallel laufen, in einen Bus hinein und wieder hinaus?
Erste Versuche sind jetzt erfolgreich. Ich schicke die Signale zweier LFOs in eine Eventleitung hinein und kann sie auch anschließend wieder aufdröseln.
Diese Aufdröselung geschieht im Moment noch durch eine Werteabfrage; ich möchte es aber durch die Angabe der Quelle erreichen. Wenn das einmal klappt, dann kann man sich die ganzen umständlichen Modulationsmatrizen sparen und hat nur noch einen Bus, auf den die Events "aufspringen" und aus dem sie auch wieder "aussteigen" können.



Der LFO 1 schwingt mit 0,2Hz und dem Werteintervall [2;4], der LFO 2 mit 0,5Hz und dem Werteintervall [-1;1].
Als Ausgabe habe ich hinter der Aufdröselung Meter-Module gewählt mit einem Wertebereich von jeweils [-1;5]. Der Eventwatcher direkt hinter dem Bus zeigt, wie die Werte aus beiden Eventquellen fein säuberlich der Reihe nach aufgenommen werden (Source1 des eventwatchers). Source2 zeigt jeweils die Werte des LFO 1 nach der Aufdröselung an, Source3 diejenigen des LFO 2.
Wichtig an diesem Versuch ist erst mal, zu erkennen, ob REAKTOR die Werte beider Quellen korrekt der Reihe nach aufnimmt.



Jetzt möchte ich noch erreichen, dass die Adresse der entsprechenden Quelle mitgesendet wird, so dass dadurch die Eventsignale getrennt werden. Danach sollen sogar noch polyphone Eventsignale übertragen werden.

ciao herw

[herw]

gelöst!!!

es klappt

Es gibt nur zwei parallele Busse, einen für die Nummer der eventquelle und einen für die events. Die Empfänger greifen sich die passenden Werte heraus.



Der Eventwatcher und die Meteranzeigen zeigen jeweils die passenden Werte der zugehörigen Quelle an.



Jetzt versuche ich mich an der polyphonen Version!

[herw]

Damit die Tragweite des Busses etwas deutlicher wird, habe ich das Testensemble mal etwas erweitert.



Ich habe nun drei Eventquellen gewählt: zwei LFOs (Source 1 und Source 2 mit den Regler F1 und F2 zur Einstellung der Frequenz) und einen einfachen Regler (Source 3).
Alle drei Quellen werden in dieselben beiden Busse eingespeist (ein Bus für die Übertragung der Quellnummer und ein Bus für die eigentlichen Eventsignale).
Auf der Empfängerseite kann ich nun eine der drei Quellen auswählen und führe sie der entsprechende Meteranzeige zu.
Im Eventwatcher sieht man sehr schön, wie die Werte der Auswahl 1 und 3 empfangen werden. Auch die Reglerwerte (source 3) werden richtig erkannt (Auswahl 2), sind aber im Eventwatcher nicht zu erkennen, da beim screenshot dessen Wert schon längst vorbeigerauscht ist (Die LFOs senden mit ControlRate also 400Hz ihre Werte kontinuierlich aus).

Die Struktur habe ich verändert, damit die Idee klar wird:



Oben links erkennt man die drei Event-Quellen. Sowohl die Quellnummer, wie auch der zugehörige Event werden über Send-Module an den Bus (rechts) übergeben. Ergänzt man eine Eventquelle, so muss man auch nur ein Einsteigen-Modul mit zwei receive-Modulen ergänzen. Der Vorteil ergibt sich, wenn man viele Quellen benutzt. Der Aufwand beim Bus ist immer derselbe (man vergleiche andere Matrix-Konzepte, die schnell zu einem Drahtverhau werden). Hier habe ich noch eine starke Idee im Kopf, um auch das noch zu vereinfachen; Krümelmonster ahnt sicherlich schon was ich meine .
Auf der Empfängerseite ist das ganze genauso einfach. Die gewünschte Quelle kann man sich zum Beispiel mit dem Drehknopf oder anderen Panelelementen aussuchen. Jeder Empfänger wählt nur diejenigen Daten aus dem Datenfluss aus, die für ihn relevant sind.

[herw]

es klappt auch polyphon: ich habe über einen Signalbus sowohl 2 LFOs und polyphone MidiPitch-Werte eingespeist und auch wieder herausfiltern können

[toxonic]

uhhh....
hört sich ja sehr cool an, hab's noch net ganz geschnallt! würde mich interessieren, was in den corecells steckt!

[herw]

uhhh....
hört sich ja sehr cool an, hab's noch net ganz geschnallt! würde mich interessieren, was in den corecells steckt!

noch ein Geheimnis! Aber so viel sei verraten: wenn das jemand sieht, wird er sich schämen, nicht schon lange selbst darauf gekommen zu sein! Es sind nur einfachste Module und für jeden sofort zu durchschauen. Alles hängt nur von einer einzigen winzigen wohl bekannten Idee ab.

Übrigens der BUS ist nun auf die trivialste Version geschrumpft!


D.h. wenn ich eine Quelle ergänze, habe ich die Merge-Module des Busses nur zu erweitern und zwei wire zu ziehen !! - mehr nicht! Ich staune selbst, dass es so einfach ist.
Ein wenig Geheimniskrämerei sei mir gegönnt.


ciao herw

[helmsklamm]

ups, bin grad mit halben bein am see, klingt aber aüusserst spannend, werd mir das mal abends gemütlich reinziehen.

[herw]

ups, bin grad mit halben bein am see, klingt aber aüusserst spannend, werd mir das mal abends gemütlich reinziehen.

gemütlich ist noch nicht, solange ich es noch nicht veröffentliche. Eine wichtige Erweiterung ist nämlich nun: wie kann ich verschiedene Modulationsquellen zusammenfassen, so dass sie einen Modulationseingang steuern? Einfaches Addieren geht dann nicht mehr, sondern ich muss die Änderungen verwalten.

Da ist also noch etwas Fleißarbeit nötig, aber im Prinzip dürfte es funktionieren, wie bei der MOD-MATRIX, nur eben nicht mit so vielen Kabeln, sondern nur noch zweien.
Trotzdem ist es schon mal schön, einen Bus zu haben.

[herw]

ich hab eine IDEE!!!! es ist wirklich nicht so schwer, man muss nur alle Ideen richtig sortieren!
Der Bus gibt alle events mit der passenden Adresse weiter. Man muss nur statt der eigentlichen events deren Änderung weitergeben. Jedes Ziel findet nun seine Änderungen und gibt sie aufsummiert weiter. Das ist es!

ciao herw

[herw]

Der Trick liegt natürlich beim Einspeisen in den BUS und beim Herausfiltern der Informationen aus dem BUS.
Ich bin gerade dabei, einen Testaufbau zu konstruieren. Wenn das gelingt, dann ist der eventbus und die additive Modulation neu erfunden.

ciao herw

[helmsklamm]

Wenn das gelingt, dann ist der eventbus und die additive Modulation neu erfunden.

ciao herw

sei doch nich immer so schrecklich bescheiden;)


ich überleg grad nach nen praktischen nutzen für mich: nehmen wir an, ich hab 10 modulationsqeuellen, von denen ich eine auswählen möchte. bislang löse ich das übern router vorm ziel. da ich mehere ziele habe, die aus unterschiedlichen qeullen gespeist werden wollen, benötige ich ebnsoviele individuelle router.
das wir deine lösung nicht vereinfachen, oder?

es kann jedoch vorkommen das ich hinundwieder mehrer qeullen auf ein ziel mappen möchte. für diese enventualität ist obiges router-system nicht ausgelegt und eine alle-möglichkeiten-berücksichtigende verdrahtung ist ganz schön strippig.
frage: mit deinem bussystem dann nicht mehr?

[herw]

...
es kann jedoch vorkommen das ich hinundwieder mehrer qeullen auf ein ziel mappen möchte. für diese enventualität ist obiges router-system nicht ausgelegt und eine alle-möglichkeiten-berücksichtigende verdrahtung ist ganz schön strippig.
frage: mit deinem bussystem dann nicht mehr?

GENAU!!! (jedenfalls hoffe ich es). Die Idee ist schon faszinierend und ich bin voller Mut und Zuversicht. Ich sehe jedenfalls keinen Hinderungsgrund. Es ist vor allem für jeden leicht anwendbar (erweiterbar), wirklich ohne Harfe.
Trotzdem bevorzuge ich nach wie vor die Lösung des Modular mini, da dort ja ausschließlich audio-Signale als Modulationssignale benutzt werden.
Mit events ist ein solcher Bus viel einfacher zu realisieren.
Aber gib mir noch einige Tage Zeit, ich will alles super bugfrei machen.

[helmsklamm]

na gut, noch 2 tage aufschub;)

[herw]

na gut, noch 2 tage aufschub;)

das geht in keinem Fall, da die nächsten drei Tage nur kurze Arbeitspausen haben.

Aber beim Laufen kann ich dann abends gut drüber nachdenken. Ich bin selbst gespannt, was man damit alles anstellen kann: es gibt keinen eventloop aber core ist zwingend erforderlich und natürlich hole ich alles aus der Kiste, was mit send, receive und ic-send zu machen ist.

Eine interessante Anwendung könnte eventuell sein (nur so ein kurzer Gedanke), Instrumente mit verschiedenen Voice-Zahlen direkt verbinden zu können.
Lasst Euch mal was einfallen. Der Bus prägt jedem Event eine Zieladresse oder Sourceadresse auf, ganz wie man möchte. D.h.man kann die ankommenden Daten dann ignorieren oder auswerten, man kann auch mehrere Quellen gleichzeitig verwenden. Z.B. laufen dann LFO-Daten und Hüllkurven-Daten und Midi-Pitch-Daten über ein und denselben Strang in Echtzeit - naja ganz nicht, da ja events immer sequentiell abgearbeitet werden, aber es gibt keinen nach außen erkennbaren Verzug, das habe ich in einem Testaufbau problemlos realisieren können. Es ist schon irre, was REAKTOR alles schafft.
Der Bus kann über send und receive überall hingeschickt werden. D.h. er ist direkt auch in entferntesten Winkeln der Struktur abrufbar. Selbstverständlich kann man mehrere Busse gleichzeitig erzeugen und alles geht auch polyphon, keine Beschränkung auf feste Voice-Zahlen.

ciao herw

[helmsklamm]

he, der termin war nicht ernst gemeint - lass dir alle zeit.
ich tauch sowieso gleich wieder n paar tage ab:-)

ich bin zwar kein freund von der send/recieve matrix (wegen peaks - siehe andern fred) aber wenn mit deeiner technik die strippenersparniss so enorm ist, wie ichs mir grad ausmale, werd ich wohl üb er meinen schatten springen.