svn+ssh://yourname@icemserv.folkwang-hochschule.de/icemserv-snd/morb

Da sind dummerweise 2 Repositories gelanded. Bitte das mit grossem M auschecken.

Worüber wir uns einig sind(?)

1. jeder kann per MORB an einem vernetzten Laptopensemble teilnehmen und seine Teilnahme auch wieder beenden
2. jeder Teilnehmer kann Daten zur Verfügung stellen(Server) und Daten von anderen verwenden (client)

Daraus folgt m.E. serverseitig:

1. jeder muss beim Eintritt in ein Ensemble abfragen können, wer welche Daten zur Verfügung stellt (Aus Serversicht: Jeder Server muss bei Eintritt eines neuen Teilnehmers diesem seine Dienste bekanntmachen)
2. jeder muss beim Eintritt in ein Ensemble den anderen mitteilen, welche Daten er zur Verfügung zu stellen gedenkt.
3. Sollten sich individuelle Konfigurationsänderungen ergeben, die dazu führen, dass Daten nicht mehr zur Verfügung stehen oder neue Daten erzeugt werden, muss dies auch allen Beteiligten mitgeteilt werden.

Und clientseitig:

1. jeder kann die Daten eines Servers abonnieren. Ihm werden bei der Entstehung neuer Daten diese dann mitgeteilt.

Vorschlag für eine Implementation

Vorüberlegungen

Ein (nicht M)ORB kann auf klassische Remote Procedure Calls abgebildet werden. Der Client fragt den Server nach den Daten, der Server liefert, damit ist die Transaktion beendet. Aus Sicht der Anwendung wurde lediglich eine lokale Prozedur aufgerufen, der dazwischen liegende Netzwerklayer ist transparent.

Dieser Ansatz führt bei unserem Modell nicht weiter, denn der Client will die Daten, wenn sie anfallen, sobald als möglich haben, ohne überflüssigerweise Abfragen starten zu müssen, die nichts bringen, wenn sich die Daten nicht verändert haben. Wir müssen also von einem Abfrage- oder Pull-Modell zu einem Abonnement- oder Push- modell.

In diesem ist das Entstehen eines neuen Datensatzes beim Server für den Client ein Event, auf das er eine Reaktion definieren kann, ähnlich dem lokalen Eintreffen eines MIDI- oder OSC Ereignisses.

Die zunächst geplanten Plattformen (Max/MSP und ChucK) bieten von sich aus ein Datenflussmodell, dass ein solches Eventhandling “von Hause aus” bietet oder sogar paradigmatisch darauf basiert (Max).

Bleibt, pragmatische Lösungen für den unteren (Netzwerk-)layer zu finden.
Auch hier hilft das RPC Modell nicht weiter, denn jeder RPC Call stellt eine 1:1-Verbindung zwischen einem Server und einem client dar.

Dies abgebildet auf ein 1:N Abonnement Modell bedeutet, dass der Server für jeden seiner Dienste eine Liste von Abonnenten unterhält, und jeden dieser Abonnenten beschickt, sobald neue Daten entstehen. In einem Netzwerk, wo mittels geeigneter Hardware (Switches) bei einer 1:1 Verbindung die volle Bandbreite zur Verfügung steht, wäre dieser Ansatz wahrscheinlich der Netz-ökonomischste. Da der Funkkanal eines WLAN Netzes jedoch ein geteiltes Medium ist (siehe hier ), und wir ja kabelarm arbeiten wollen, entfällt dieser Vorteil, und wir können uns etwas anderes überlegen. Ausserdem müsste der Server möglicherweise jede Datenveränderung mehrmals (an jeden client einmal) versenden, was die Serverlast erhöht.

Broadcasting, bei dem alle alles mithören müssen, führt auf der anderen Seite zu einer überflüssigen Last auf dem client.

Lösungsvorschlag

Ein möglicher Kompromiss wäre eventuell IP-Multicasting (siehe hier )

Da die Multicast Adressen netzwerkübergreifend gleich sind, wäre insbesondere der Beitritt zu einem MORB Ensemble ohne weitere Netz-Infrastruktur (Dhcp-server etc.) möglich.

Das ganze könnte so aussehen:

1. es gibt einen Multicast Kanal, für die Verwaltung des Gesamtensembles. den müssen alle hören. Quasi MORB Broadcast
2. jeder Teilnehmer erhält einen Multicast Kanal auf dem er seine Daten senden kann.
3. Jeder Teilnehmer erfragt auf dem Broadcast Kanal die anderen Teilnehmer, deren Multicast Adresse und die von ihnen angebotenen Services
4. er reserviert eine der noch freien Multicastadressen für sich und teilt den anderen über den Broadcastkanal seine Dienste und seine Multicast Adresse mit.
5. Ein Client, der einen Dienst abonnieren möchte, teilt dies dem Server mit und tritt der Multicastgruppe bei. Er erhält dann alle Daten von diesem Server und muss die, die ihn interessieren ausfiltern. Dies kann per OSC-Routing passieren, wie von J.Schmidt vorgeschlagen.
6. Ein Server, der einen Abonnementwunsch erhält, zählt mit, wieviel cients diesen Dienst abonnieren. Solange der Zähler größer 0 ist, sendet der Server bei neuen Daten diese, eingebettet in eine entsprechende OSC Nachricht über seinen Multicast Kanal. Alle clients hören dort mit, der Server braucht nur einmal zu senden.
7. verläßt ein Client das Ensemble oder konfiguriert sich um, muss er sich von allen Diensten abmelden.
8. Nicht ordnungsgemäßes Abmelden sollte durch Heartbeating oder fehlgeschlagenes (speziellen MORB-) Pinging erkannt werden und die Abonnements entsprechend gecancelled werden.

…more to come… please comment

Spezifizierung des MORB-Protokolls

Konstellationen
Es gibt eigentlich nur zwei grundlegende Konstellationen

1. Daten zu MORB
2. Daten vom MORB

Im ersten Fall Daten zu MORB werden Daten generiert und an das MORB-System gesendet.
Typen der Generierung Interface produziert Daten (Midi-Controller, iPod, Joystick, Tastatur, WEE)

Strukturgeneratoren: Unterprogramme des Environments (FLEM/JMX), die Daten erzeugen (Listen, Trigger, Kontroll-Envelopes), um Parameter automatisiert zu steuern (Amplitude, Frequenz)

Im zweiten Fall Daten vom MORB werden Information vom MORB abgeholt und interpretiert
Typen der Interpretation
Audiogenerator oder -modulator empfängt die Daten und wendet sie auf den angegeben Parameter an

ein in Reihe geschalteter Strukturgenerator verarbeitet die Daten und gibt sie weiter

Für die Registrierung der Metadaten
ID : Benutzer(Source) : Generatortyp : Generatorname : Datentyp

Daten des Brokers (Welche Daten gehen von wem zu wem)
Benutzer (Source) : Benutzer (Target) : Generatorname/ID

Daten-Stream (Object-Message)
Benutzer (Source) : Generatorname/ID : Parametername : Value
als OSC Message könnte das so aussehen /jschmidt/sinus/amp/0.3

Generator-Anfrage (Request)
Der Benutzer (Target) wählt einen Eintrag vom Broker aus
Diese Einträge könnten durch ein Dropdown-Menü angezeigt werden, in dem alle Generatoren aufgelistet werden

Use-Cases
1.Anmelden an Broker
Benutzer startet seine Umgebung (FLEM/JMX), MORB wird aktiviert und prüft auf weitere Instanzen im Netz. Gibt es schon vorhandene Registrierungen, so werden diese mit aufgenommen und der neue Benutzer mit eingetragen.
2.Generator-Anfrage (Request)
Wird einem Interpeter ein Generator zugewiesen, so wird diese Konstellation im MORB festgehalten
3.Verteilen der Daten
Der Broker wird anhand der Requests die Daten an alle registrierten Benutzer schicken, die sich über die Generator-Anfrage beim Verteiler gemeldet haben.

im Wintersemester 2008/09 schlugen mich zwei Gruppen von Studierenden am ICEM für den „Preis für besonders gute Lehre“ der Studierendenschaft vor, und verbanden diesen Vorschlag mit einer Projektidee, die mit dem möglichen Preisgeld realisiert werden soll.
Die eine Projektidee, FLEM (Folkwang Laptop Ensemble), entstand aus der Beschäftigung mit SLork, dem Stanford Laptop Orchestra (http://slork.stanford.edu/). Hier stand die Entwicklung autarker Laptopstationen inklusive Lautsprecher und Verstärker, sowie diverser Eingabesensoren entstehen, die unabhängig von Stromnetz- und anderen Infrastrukturen an jedem Ort zusammen agieren können.
Der zweiten Projektidee, JMX (Johannes‘ MaX ??) liegt ebenfalls die Idee von live miteinander spielenden Rechnersystemen zu Grunde, jedoch gingen die Studierenden hier ein eher von einer Client/Server-Architektur aus, bei der ein zenraler Soundserver für die Klangsynthese verantwortlich ist, der von den anderen beteiligten Rechnersystemen parallel gesteuert wird.
Beiden Ansätzen ist gemein, dass menschliche Spieler die jeweiligen Systeme live und in Echtzeit steuern, und damit quasi Mitglieder eines rechnerbasierten Ensembles werden.
Um nun nicht allein das eine Projekt 1:1 umzusetzen und das andere zu lassen, sondern eine gemeinsame Basis zu schaffen, auf der möglichst beide Projekte umzusetzen sind, entstand nach einigen Diskussionen mit den Studierenden die Idee zu MORB

Idee

Egal, ob es sich um das egalitäre FLEM oder das hierarchisch organisierte JMX handelt, in beiden Fällen muss jeder der Beteiligten wissen, was die jeweils anderen an Möglichkeiten zur Klangsteuerung und -generierung anbieten, und muss ihnen wiederum seine Fähigkeiten mitteilen.
Darüberhinaus soll jeder Beteiligte Mitteilungen über Änderungen eines anderen Beteiligten „abonnieren“ können, um seinerseits darauf reagieren zu können.
Drittens sollen zu jedem Zeitpunkt neue Beteiligte hinzukommen und andere sich verabschieden können (Jam-Session)
Da die Beteiligten Gruppen unterschiedliche Basissoftware einsetzen möchten (FLEM: ChucK, JMX: Max/MSP) soll diese Kommunikation plattformunabhängig erfolgen
Wir haben es hier also mit einem dynamischen verteilten System zu tun, dessen Beteiligte jederzeit Struktur und Zustand (oder Teile davon) ändern können, und jede Änderung für alle Beteiligten transparent ist.

Name

Da die Anforderungen von Ferne an eine Softwaretechnik erinnern, die unter dem Namen Object Request Broker bekannt ist, lag der Name „Musical Object Request Broker“, also MORB nahe.

Anschaffungen

Für FLEM:

1. Kleine, transportable, variabel konfigurierbare Lautsprechersysteme (evtl. Eigenbau)
2. Batteriebetriebene Verstärker nebst Batterie/Akku
3. kleine Audio-Interfaces mit USB/Firewire Stromversorgung

Für JMX:

1. Ein oder mehrere dedizierte Serversysteme auf Mac Basis
2. geeignete Mehrkanalige Interfaces

Für Alle:
Geeignete Sensorik, Remote Controls, zusätzliche Effektoren (Ipod Touch, Arduino etc.)