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 'CEST/2,0/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 'CEST/2,0/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 'CEST/2,0/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 'CEST/2,0/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 'CEST/2,0/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 'CEST/2,0/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 'CEST/2,0/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 'CEST/2,0/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 'CEST/2,0/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: Performance - Parameter

Performance - Parameter · Feb 14, 11:14 am

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

  1. Vieleicht kann man hier abstrahieren: Z.B.: Jeder kann Steuerungen, Modifizierer und Generatoren zur Verfügung stellen. Steuerungen können auch externe Controller, Generatoren externe Instrumente und modifizierer auch externe Effekte darstellen können, wenn nötig.
    Alle Kategorien, und damit auch externes analysiertes Audio, können Zustandsdaten zur Verfügung stellen, (sinnvollerweise kein Audio, sondern nur relativ low frequency) die man in seinem eigenen Setup verwenden kann.
    Die Frage nach dem Laptop und dem Programm ist dann möglicherweise sekundär.

    Die Zustandsdaten sind dann sicherlich kaum zu verallgemeinern, wenn wir komplexe Generatorentypen (z.B. Rhythmus- oder sonstige Strukturgeneratoren) zulassen wollen, sondern sehr spezifisch. Ob wir Klassen mit gemeinsamer funktionalität bauen wollen/sollen/können, die auf einen mehr der weniger gemeinsamen Datensatz abbildbar sind, müsste noch analysiert bzw. prototypisch ausprobiert werden.

    Bleibe gespannt…

    — Thomas Neuhaus · Feb 16, 10:36 am · #

  2. MORBs Verantwortung…
    Auf der einen Seite werden Daten generiert, auf der anderen interpretiert. Ich hatte MORB bislang so verstanden, dass vor allem Struktur-Daten gemeinsam benutzt, also öffentlich über das Netzwerk zugängig gemacht werden. Ebenso kann auf nicht lokale Generatoren zugegriffen werden – zum Beispiel mittels Struktur-Daten. Für mich ist es erstmal völlig unerheblich, ob es nur ein Laptop, ein Laptop mit Midi-Interface oder ein Laptop mit Instrument und Pitchdetection ist. Damit meine ich, dass Genese und Interpretation der Daten unterschiedlich ist und von dem jeweiligen Umfeld abhängt. MORB soll sich nur darum kümmern, dass Daten bereitgestellt werden (wenn ich sie öffentlich mache und bei MORB anmelde) oder ich mir Daten über MORB abholen kann (und dieser dann für genau diese Verbindung einen Kommunikationsweg etabliert).
    …Kommentar zum zweiten Absatz von Hernn Neuhaus (Der Blog bietet es leider nicht an einen Kommentar zu einem Kommentar zu schreiben…)
    ‘Die Zustandsdaten sind dann sicherlich kaum zu verallgemeinern’ – denke ich auch. Vorschlag: jedes angemeldete Objekt gibt Datentyp (Float, Int, List…) und seine Werte-Range bekannt. Damit hat man leicht die Möglichkeit als Interpret die empfangenen Daten zu reskalieren. Oder alles, was sich im Netz befindet, bewegt sich zwischen 0. und 1. D.h. bei Auswahl eines Strukturgenerators werden diese Metadaten mitgenommen und für lokale Interpretation eingesetzt.

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

Kommentarfunktion für diesen Artikel geschlossen.