Code · 330 Tage zuvor
An einem regnerischen Wochenende hab ich als Anfang mal etwas Java Code verbrochen. Kann per svn heruntergeladen werden: (Wer nicht weiss was SVN ist oder kein Java kann muss J.Schmidt, J.Winkler oder mich fragen)
svn+ssh://yourname@icemserv.folkwang-hochschule.de/icemserv-snd/morb
Da sind dummerweise 2 Repositories gelanded. Bitte das mit grossem M auschecken.
— Thomas Neuhaus
Noch mehr Entwürfe · 373 Tage zuvor
Das folgende ist im Wesentlichen eine Zusammenfassung/Umstrukturierung/Ergänzung/Weiterentwicklung von J.Schmidts Artikel Morb Spezifizierung Entwurf I
Worüber wir uns einig sind(?)
- jeder kann per MORB an einem vernetzten Laptopensemble teilnehmen und seine Teilnahme auch wieder beenden
- jeder Teilnehmer kann Daten zur Verfügung stellen(Server) und Daten von anderen verwenden (client)
Daraus folgt m.E. serverseitig:
- 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)
- jeder muss beim Eintritt in ein Ensemble den anderen mitteilen, welche Daten er zur Verfügung zu stellen gedenkt.
- 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:
- 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:
- es gibt einen Multicast Kanal, für die Verwaltung des Gesamtensembles. den müssen alle hören. Quasi MORB Broadcast
- jeder Teilnehmer erhält einen Multicast Kanal auf dem er seine Daten senden kann.
- Jeder Teilnehmer erfragt auf dem Broadcast Kanal die anderen Teilnehmer, deren Multicast Adresse und die von ihnen angebotenen Services
- er reserviert eine der noch freien Multicastadressen für sich und teilt den anderen über den Broadcastkanal seine Dienste und seine Multicast Adresse mit.
- 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.
- 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.
- verläßt ein Client das Ensemble oder konfiguriert sich um, muss er sich von allen Diensten abmelden.
- 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
— Thomas Neuhaus
Morb – Spezifizierung Entwutf I · 376 Tage zuvor
Preludium
MORB stellt eigentlich, jedenfalls so wie wir es implementieren wollen, kein Server-Client-Modell dar. Jedoch ist für mich MORB die logische Einheit, die alle Benutzer miteinander verknüpft und es ist auch das System, das die Anfragen/Verteilung organisiert. MORB wird als Plattform bei jedem Benutzer als Hintergrundprogramm mitlaufen und synchronisiert sich mit allen anderen Instanzen der eingeloggten Benutzer. Trotzdem werde ich in diesem Entwurf von einem Client sprechen, wenn es darum geht, dass ein Benutzer vom MORB (was auch als verteilter Server gesehen werden kann) Daten anfordert.
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.
— Johannes Schmidt
Performance - Parameter · 390 Tage zuvor
Hier die Ergüsse erster Überlegungen, die mir sowieso schon durch das Auftreten im Kopf schwirren. Zum Einen hier einmal eine vielleicht nützliche Aufteilung in 3 verschiedene Versionen von Performance miteinander. Nicht ausgearbeitet, dient dies hier einfach nur als Denkanstoß.
Dann folgen Aufstellungen für a). Die Kommunikation mit Laptops untereinander stellt ja fürs Erste die Priorität dar, b und c beinhalten ja a fürs Erste und sind vielleicht für einen späteren, aber sicherlich nicht unwichtigen Schritt zu bedenken.
a) Laptops untereinander
b) Laptops und andere Gerätschaften (MIDI, elektronische Musikinstrumente)
c) Laptops und akustische Musikinstrumente (auch und vor allem, Stimme)
zu a)
Da möchte ich gerne wissen:
Wer macht
Was
mit Welchem Programm
Wieviele BPM (Angleichung möglich, siehe MIDI?)
Welche Lautstärke (vielleicht eine Art Zeitfenster von den vergangenen Lautstärkeschwankungen, das immer mitwandert, wie weit man sich nach vorne begiebt, natürlich)
Welche FX (davon die Werte)
Welcher Frequenzbereich ( weiteres siehe Lautstärke)
Welcher Rhythmus (nicht nur BPM eben)
Dann: ich möchte darauf reagieren, meine Parameter daran anpassen, die Schnittmenge nehmen, das genaue Gegenteil, etc. pp.
Ich möchte Akzente setzen.
Ich möchte eine Fläche darunter legen.
etc. Dies als einfache Beispiele.
Jeder Parameter sollte einsichtig sein.
______________________________________
Es stellt sich nun die Frage, ob das alles nicht zuviele Informationen sind, die man also gleichzeitig wahrnehmen, verarbeiten muss und dann auch noch darauf reagieren soll, also gleich Drei Sachen auf einmal.
_________________
Das also von mir soweit. Wer Ideen hat, etwas hinzufügen oder grundsätzlich bestreiten möchte, bitte, der Ring ist eröffnet. :-)
— Elisabeth Szwarc
Kommentare [2]
What is MORB · 392 Tage zuvor
Entstehung
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:
- Kleine, transportable, variabel konfigurierbare Lautsprechersysteme (evtl. Eigenbau)
- Batteriebetriebene Verstärker nebst Batterie/Akku
- kleine Audio-Interfaces mit USB/Firewire Stromversorgung
Für JMX:
- Ein oder mehrere dedizierte Serversysteme auf Mac Basis
- geeignete Mehrkanalige Interfaces
Für Alle:
Geeignete Sensorik, Remote Controls, zusätzliche Effektoren (Ipod Touch, Arduino etc.)
— Thomas Neuhaus
Kommentare [2]