Deprecated: Function set_magic_quotes_runtime() is deprecated in /var/www/morb/textpattern/lib/txplib_db.php on line 14

Warning: Cannot modify header information - headers already sent by (output started at /var/www/morb/textpattern/lib/txplib_db.php:14) in /var/www/morb/textpattern/lib/txplib_misc.php on line 1548
 <txp:posted/> ->  Warning: getdate() [function.getdate]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1,0/no DST' instead  on line 1067
 <txp:posted/> ->  Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1,0/no DST' instead  on line 1068
 <txp:posted/> ->  Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1,0/no DST' instead  on line 1104
 <txp:comment_time/> ->  Warning: getdate() [function.getdate]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1,0/no DST' instead  on line 1067
 <txp:comment_time/> ->  Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1,0/no DST' instead  on line 1068
 <txp:comment_time/> ->  Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1,0/no DST' instead  on line 1104
 <txp:comment_time/> ->  Warning: getdate() [function.getdate]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1,0/no DST' instead  on line 1067
 <txp:comment_time/> ->  Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1,0/no DST' instead  on line 1068
 <txp:comment_time/> ->  Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1,0/no DST' instead  on line 1104

Warning: Cannot modify header information - headers already sent by (output started at /var/www/morb/textpattern/lib/txplib_db.php:14) in /var/www/morb/textpattern/publish.php on line 467
MORB: What is MORB

What is MORB · Feb 12, 06:00 pm

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:

  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.)

— Thomas Neuhaus

---

Kommentare

  1. Really a MORB?
    http://www.peuss.com/java/ORBs.php
    Der Autor (Peuss) dieser Seite schreibt, dass ein ORB ein Kapseln von Diensten darstellt, die clientseitig in Anspruch genommen werden. Weiterhin schreibt er auch, dass ORB für eine m:n Konstruktion denkbar ist. Allerdings arbeiten beide Projekte JMX/FLEM nicht mit dem Objekt-Paradigma und ein Strukturgenerator eines anderen Clients ist für mich auch noch kein Dienst. Worauf ich hinaus will… MORB hört sich gut an, weckt aber irgendwie auch hohe Erwartungen. Bislang habe ich das MORB-Projekt so verstanden, dass wir versuchen eine Software zu schreiben, die Kommunikations-Kanäle zwischen einzelnen Benutzern herstellt, um Parameter zu teilen, ohne dabei Daten über die Broadcast-Adresse in den Äther zu schicken

    — Johannes Schmidt · Feb 19, 12:40 am · #

  2. Aber das, was Herr Peuss beschreibt, ist doch genau dass, was wir wollen: Entfernte “Dienste” (etwa die Bereitstellung von Controllerdaten oder Syntheseparametern) lokal nutzen. Und eine m:n Konstruktion ist auch bei uns denkbar, denn jeder der m “Clients” kann beliebige Daten von den n “Servern” anfordern/nutzen und umgekehrt muss jeder der n Server jeden der m Clients bedienen können.

    Inwieweit die höheren Level von JMX oder FLEM objektorientiert sind oder nicht (Ich glaube schon, dass sie das sind, den die unterliegenden Programmierumgebungen legen das sehr nahe, nur kann das mehr oder weniger explizit sein), spielt für den ORB Layer auch keine Rolle, denn der sollte ja schön gekapselt sein, und kann dann intern durchaus einem objektorientierten Designparadigma folgen, selbst wenn die höheren Layers das nicht (oder weniger) tun.

    Wenn bei Herrn Peuss das Addieren zweier Zahlen einen Dienst darstellt, so halte ich einen Strukturgenerator, der seine Parameter zur Verfügung stellt sehr wohl für einen Dienst. Die Komplexität des Dienstes entscheidet nämlich nicht über sein “Dienstsein”.

    und der letzte Satz:

    wir versuchen eine Software zu schreiben, die Kommunikations-Kanäle zwischen einzelnen Benutzern herstellt, um Parameter zu teilen, ohne dabei Daten über die Broadcast-Adresse in den Äther zu schicken

    beschreibt durchaus einen ORB.

    Die Probleme, die wir dabei lösen müssen, sind eher die, dass wir in einem Realtime Environment nicht einfach remote procedure calls absetzen können, weil unsere Prozesse dann blockieren können, sondern wir müssen das in eigenen IO-Threads kapseln. Ausserdem müssen wir von einer “Pull” architektur (Der Server liefert nur wenn er gefragt wird) auf eine “Push” Architektur umstellen (Der Client kriegts, sobald der Server was neues hat.) Das ändert aber auch nichts an der “ORBhaftigkeit” unseres Projekts.

    — Thomas Neuhaus · Feb 25, 09:54 am · #

Kommentarfunktion für diesen Artikel geschlossen.