[Autonomie] Faust WS

[martin schitter]

Am 12.04.20 um 11:52 schrieb Gernot Tutner:
> Ich möchte mich im Moment gar nicht zu sehr in FAUST vertiefen. Wir 
> haben am Donnerstag beschlossen, an einem Proof Of Concept für ein WebUI 
> zum Verbinden zweier FAUST-Soundmodule (Generator + Effekt) zu arbeiten.

lieber gernot!

wunderbar, dass du dich offenbar gleich in die praktische arbeit stürzt!

was faust im speziellen betrifft, ist deine zurückhaltung natürlich 
durchaus angebracht. ich empfehle es zwar immer wieder, weil es in den 
low-level gestaltungsmöglichkeiten und der effizienz der resultate weit5 
über das hinausgeht, was andere einfacher zu bedienende modulare 
fertiglösungen bieten bzw. eben wirklich sehr vielfältig nutzbar ist.

im wesentlichen ist aber in unserem fall wichtiger, dass ich die 
gewählten mittel sauber in den kontext der "webaudio"-vorgaben fügen.

dazu gibt's mittlerweile bereits eine ganze menge:

https://github.com/notthetup/awesome-webaudio

es gibt auch seit einigen jahren eine jährliche konferenz, wo viele 
dieser werkzeuge und damit realisierter gestalterischer projekte 
vorgestellt werden bzw. auch in form von videofzeichnungen der vorträge 
und veröffentlichten papers zugänglich ist:

https://webaudioconf.com/

im prinzip gibt es da ohnehein bereits eine ganze menge an fertigen 
lösungen die sich realativ einfach nutzen lässt:

https://tonejs.github.io/
https://flockingjs.org/
http://webaudioplayground.appspot.com/
https://tai2.net/docs/webaudiocomposer/
https://eternal.robcheung.com/
https://github.com/gridsound/daw

https://web-audio-api.firebaseapp.com/
https://github.com/ISNIT0/webaudio-generator

https://github.com/google/audion

usw.

das alles lässt sich ganz ähnlich wie jeglicher anderer inhalt in einer 
webpage ziemlich einfach mit java script bzw. heute natürlich besser 
typescript (https://www.typescriptlang.org/) od. assembly script 
(https://docs.assemblyscript.org/) nutzen.

im prinzip ist diese high-level ebene geradezu unverzichtbar, wenn man 
bspw. auch samples an hand von URLs irgendwoe im netz einbeziehen will, 
was ja zb. faust von sich aus nicht kann etc.

ich finde es nur wichtig, dass das zeug sich tatsächlich in möglichst 
offener weise mit anderem kombinieren bzw. einbetten lässt, statt zu 
große eigene vorgaben und sperrige erweiterungsmöglichkeiten mit sich zu 
bringen. das erscheint mir vor allen dingen auch deshalb wichtig, weil 
ja vieler dieser einfacheren mittel gleich einmal wie in 
casio-taschensynthesizer klingen bzw. einen leicht dazu verführen sich 
in vorgegebenen bahnen der klanggestalt zu verlieren.

ein wichtiges technisches detail, dass ich hier nur einwerfe, weil es 
dir vermutlich durchprobieren der entsprechenden lösungen ohnehin 
unvermeidlich unterkommen wird, betrifft das stichwort: "audioworklet".

dabei handelt es sich um eine erweiterung der webaudio schnittstelle, 
die einige ganz wichtige performance-vorteile bzw. unterschiede 
gegenüber der ursprünglichen standard bzw. der dort üblichen 
prozessierung nutzt. leider basiert das ganze auf einem google 
erweiterungsvorschlag, der bisher nur im chromium zur verfügung steht. 
es gibt zwar einige polyfills, also kompatibilitätslösungen, die das 
ganze ein klein wenig browserübergreifend nutzbar machen, trotzdem 
funktioniert das leider nur bis zu einem gewissen maß. bspw. die viel 
geringere latency und störungsunanfälligkeit gegenüber anderen tasks im 
browser kann man einfach nicht ohne weiters mit den alten mitteln 
bewerkstelligen od. emulieren. aber, wie gesagt, dass ist nur ein 
technisches detail, über das man fast unweigerlich stolpert, weil 
natürlich alle avanciertern lösungen sich gerne dieser inkompatiblen 
variante bedienen.

aber abgesehen von diesem punkt ist webaudio mittlerweile wirklich in 
allen browsern super unterstütz und verfügbar.

ich würde auch bei der entwicklung auch ganz bewusst von den browsern 
als orientierung und kleinsten gemeinsamen nenner ausgehen, und die 
adaption für handys nur als abschließenden weiteren schritt im 
hinterkopf behalten.

im prinzip sollte man ja heute ohnehin mehr oder weniger beliebigen 
webcontent ohne großen aufwand in PWAs 
(https://en.wikipedia.org/wiki/Progressive_web_application) packen 
können, aber ganz so perfekt funktioniert das in der praxis leider noch 
immer nicht mit allen webbrowsern und endgeräten.

erst falls wir tatsächlich auch bspw. div. sensoren von handies nutzen 
wollen od.ä., wäre es tatsächlich fast unumgänglich, dafür vorgesehene 
spezialisierte frameworks zu nutzen. in dem fall würde ich am ehesten zu 
"native script" (https://www.nativescript.org/) greifen, weil das am 
fließendsten einen übergang zu web typischen zugängen erlaubt.

der gestalterisch wichtigste punkt betrifft aber eine frage, der von 
deiner deiner historischen skizze doch signifikant abweicht:

es ist zwar absolut naheliegend, dass man in diesem zusammenhang einfach 
die zugänge aus bekannten audioprogrammen auf eine mögliche 
nutzbarmachung im netz überträgt, trotzdem ist das der punkt, wo ich die 
umkehrte herangehnsweise -- also eine übertragung typischer 
datenorganisationsformen der heutigen netzwerk und cloud service 
organisation in die andere richtung -- als ausgangsbasis der 
inhaltlichen gestalt vorschlagen würde. mit anderen worten: kein 
netzwerk von musikprogrammen, die mit OSC u.ä. verknüpft sind, oder 
pipelines von audio strömen, die die man sich gegenseitig zuschickt od. 
zwischendurch auch irgendwo einmal auf einem server zwischendurch parkt, 
sondern eben wirklich eine apparatur, die vielmehr als gesamtsystem 
einen geteilten systemzustand zugänglich macht bzw. zum thema hat. erst 
in den den endgeräten soll diese weitestgehend abstrakte repäsentation 
schließlich wieder in unterschiedlicher weise -- also quasi 
"perspektivisch" -- unabhängig interpretiert werden bzw. in form von 
mehreren nebeneinander laufen subsystemen im rahmen der ECS architektur 
in klang od. visuelle oberfläche übersetzt werden.

das ist eine herangehensweise, über die du vielleicht den kopf schütteln 
wirst, weil sie natürlich auf den ersten blick völlig unzweckmäßig und 
an den haaren herbeigezogen wirkt, trotzdem ist das wirklich einer der 
punkte, der mit konzeptuell besonders wichtig und bedeutsam erscheint.

in der praxis ist angedacht, dafür eine verteilte datenbank bzw. 
replizierungsmechanismen zu verwenden, die relativ einfach zu handhaben 
sind -- konkret rxdb (https://rxdb.info/). damit kann man dann auch via 
GraphQL sehr gezielt bzw bandbreitensparend relevante bereiche im 
datenbestand auslesen und sogar subskribieren, so dass man automatisch 
verständigt wird, sobald sich dort irgendwas ändert. man kann damit also 
in einer weise "reaktiv" umgehen, wie das heute in der 
web-programmierung als stand der technik gilt.

im übrigen hat dieses ungewöhnliche konzeption den vorzug, dass wir ja 
auch die funktionalität jener lokalen systeme, die die daten zur 
laufzeit in sound oder grafische repräsentationen übersetzten, nicht 
"hardcoded" in den client einbetten müssen, sondern dieses module auch 
über die datenbank austauschen und teilen können -- schließlich sind es 
ja nur ein paar zeilen javascript od. im extremfall webassembly module, 
die überall die gleichen voraussetzzungen für die ausführung vorfinden!
der client bietet also vielmehr nur ein grundgerüst an, in dem dann 
diese konkreten sound-, visualisierungs oder systemsteuerungsmodule 
heruntergeladen und nebeneinander ausgeführt werden können.

theoretisch könnte man die für die datenbank auch eine völlig 
dezentralisierte umsetzung heranziehen (bspw. https://gun.eco/), aber 
ich fürchte, dass wir in dem punkt besser zugeständnise an die 
stabilität und ausgereiftheit der mittel machen sollten, damit ddas 
ganze wirklich zuverlässig funktioniert.

eine konsequenz, die sich aus diesem skizzierten zugang ergibt, besteht 
übrigens darin, dass die zeitliche dimension der organisation ziemlich 
weit in den hintergrund gedrängt wird, und man statt dessen vielmehr mit 
einem gerade vorliegenden zeitlich punktuellen und doch komplexen 
"ist-zustand" im system operiert. dass dürfte einiges umdenken 
erfordern, wenn man über dafür geeignete akustische 
umsetzungsmöglichkeiten nachdenkt, berührt aber auch die frage, wie man 
in eine derartige apparatur dann überhaupt bewegung/dynamik/leben 
einhauchen kann? ich hab das ohnehin schon im meinem letzten schreiben 
angesprochen.

eine andere eigenheit besteht darin, dass jeder client im prinzip alle 
möglichkeiten besitzt, dass gesamtsystem auch aktiv zu verändern bzw. zu 
erweitern, da eben die wesentliche teile der akustischen und visuellen 
umsetzung nicht hart in die software eingeschrieben sind, sondern in 
modularen weise zur laufzeit aus dem netz nachgeladen oder eben auch in 
die andere richtung hochgeladen werden können. die laufen schließlich 
nebeneinader und in unterschiedlichen kombinationen am client. fabien 
hat den diesbezüglichen eingriffs und nachvollzugsmöglichkeiten in 
seiner GUI skizze ohnehein bereits mit dem "code"-symbol unten rechts 
angedeutet. mir persönlich wäre es in diesem zusammenhang nur sehr 
wichtig, das wir die form des aktiven eingriffs ganz generell so 
gestalten, dass sie weniger als aufruf oder möglichkeit einfacher 
interaktivität verstanden wird, sondern eben tatsächlich nur die 
mitgestaltung neuer module erlaubt, aber die apparatur in ihrem 
tatsächlichen ablauf weitestegehend selbstständig vor sich hin läuft 
ohne irgendwelche dirigenten zu benötigen.

in vielen aspekten orientierte ich mich in dieser beschreibung an 
organisationsschemata, wie man sie aus der computerspielentwicklung von 
den entity component systems (ECS) her kennt. in dem punkt nenn ich aber 
gleich gar keine konkrete software, die wir dafür heranziehen könnten, 
sondern versuche vielmehr aus den entsprechenden grundsätzlichen 
konzepten das heruaszuheben, was für uns hier nützlich sein könnte. es 
ist ohnehin immer ein bisserl mühsam beim studium der entsprechenden 
literatur und software mitzubedenken, dass wir eben kein spiel 
entwickeln wollen, sondern vielmehr eine mediale skulptur.

das ist jetzt alles natürlich ein bisserl viel auf einmal, aber es 
handelt sich ja auch nicht unbedingt um ein völlig ganz triviales 
vorhaben. zumindest sind damit wenigstens wieder ein paar wesentliche 
punkte angesprochen und festgehalten, die wir in den bisherigen treffen 
oft in relativ kleinem kreis diskutiert haben bzw. die ich im lauf der 
letzten monate wenigstens zu evaluieren und im hinblick auf ihre 
praktische nutzbarkeit hin zusammenzutragen versucht habe.

natürlich müssen wir uns trotzdem in ganz kleinen schritten und ersten 
praktischen versuchen an die ganze geschgichte annähern, aber zumindest 
als fernziel oder vagen traum möchte ich eben durchaus den blick auf das 
größere ganze auch nicht völlig aus den augen verlieren.

ich hoffe, du kannst irgendwas damit anfangen.

liebe grüße!
martin