+comunity+ machine learning - Input / Ideen für das nächste Treffen

[Martin Schitter]

Liebe Maggie!

Ganz lieben Dank für deine Ausführungen! Sie sind wirken -- wie so oft, 
wenn du dich einbringst -- wunderbar inspirierend und nützlich!

Dass ich in vielen Punkten eine gänzlich andere Position vertrete und 
oft geradezu gegenteilig argumentieren würde, ändert daran nichts. Im 
Gegenteil, dadurch wird's erst richtig spannend und tatsächlich sinnvoll 
sich damit in gemeinsamen Dialog auseinanderzusetzen.


## Computer als Instrument od. Gegenstand der Reflxion und Gestaltung

Schon im Verweis auf Rebecca Fiebrink und das Programm "Wekinator" 
treten diese unterschiedlichen Zugänge deutlich hervor. So weit ich es 
beim ersten groben Überfliegen richtig verstanden habe, werden hier 
ML-Techniken hauptsächlich im Sinne einer Interface-Erweiterung 
(Steuerung mittels Gesten etc.) genutzt. Das ist natürlich in der Tat 
eine interessante Geschichte, obwohl es mich doch wieder unweigerlich 
daran erinnert, wie sehr sich die damit verbundenen Zugänge 
unterscheiden, je nachdem aus welchen Kunstsparte man kommt.

Im Musik-Umfeld scheinen mir Ansätze, die der unmittelbare Interaktion 
und Improvisation im Zusammenspiel mit anderen Akteuren viel Raum und 
Aufmerksamkeit schenken, nichts ungewöhnliches zu sein. Wer dagegen 
Bilder oder Skulpturen fabriziert, oder an Texten bastelt, hat mit 
diesem Aspekt in der Regel nicht viel zu tun.

ich persönlich erlebe das Arbeiten an der Umsetzung von computer- und 
medienbezogenen Vorhaben meist eher in großer Nachbarschaft zu den 
Letztgenannten, weil es meist viel eher von langwieriger Programmier- 
bzw. technischer Umsetzungsarbeit im stillen Kämmerlein geprägt ist als 
von einer abschließenden  spielerischen Nutzung eines neu ersonnen od. 
erweiterten Instruments.

Aber auch diese Zugangsweise hat natürlich ihre Stärken und Vorzüge. 
Konzeptuelle Gesichtspunkte und die konkrete Gestaltung wachsen hier 
einfach anders heran. Was im Kontext der Live-Performance als viel zu 
unflexibel, komplex und unbeherrschbar im Weg stehen würde, kann hier 
heranreifen und entflochten werden. Ein Prozess, der auf Grund seiner 
Umsetzungsschwierigkeiten fast immer auch mit einem hohen Grad an 
Reflexion der Mittel bzw. der Thematisierung von Parallelen zu anderen 
alltäglichen Formen der Techniknutzung verbunden ist.

Aber so richtig befriedigend wirken diese Ansätze und die darin oft zu 
entdeckende narzisstischer [Technik-]Verliebtheit, die ständig in die 
bloße Wiedergabe von Spiegelbildern der Maschinen abzustürzen droht, 
natürlich auch nicht. So gesehen haben Zugangsweisen, die sich mit einer 
bewusst eingegrenzt instrumentellen Verwendungsweise begnügen, ganz 
bestimmt auch ihre Daseinsberechtigung.

Man kann halt in diesen Fragen nicht so einfach aus seiner Haut heraus, 
so dass es dann letztlich oft bei einem fast schon ein wenig 
eifersüchtig wirkenden Blick hinüber zu den anderen bleibt.


## zu den erwähnten Werkzeugen und Arbeitsmitteln ganz allgemein

Ja, du hast recht, Gene Kogen versucht in seinen Vermittlungsbemühungen 
tatsächlich sehr weit auf sein Zielpublikum zuzugehen bzw. Lösungen zu 
benutzen, die speziell für die Anforderungen im Medienkunst-Umfeld 
geschaffen wurden (Processing, OpenFrameworks, etc.).

Ich selbst bin kein großer Freund dieser Werkzeuge. Meiner Ansicht nach 
droht man sich damit relativ schnell in ein abgeschlossenes Ghetto zu 
manövrieren, das weit weniger gestalterische Freiheiten bietet, als wenn 
man gleich mit Werkzeugen für Erwachsene basteln darf.

Trotzdem begrüße ich es natürlich, wenn einfach jeder verwendet, was er 
bereits einigermaßen kennt und liebt!

Ich würde also höchstens Kollegen, die mich fragen, was sie lernen 
sollten, davon abraten, zu "Processing" zu greifen. Die Empfehlung, 
wenigstens "Python" zu lernen, würde mir da vermutlich schon weit eher 
über die Lippen kommen. Sollte das jeweilige Gegenüber aber ungewöhnlich 
motiviert oder besonders begabt erscheint, würde es vermutlich ohnehin 
schnell wieder in eine missionarisch anmutende Predigt über die noch 
wesentlich verlockenderen Vorzüge der Programmiersprache und 
Glaubensrichtung "rust" übergehen.
[Das lassen wir jetzt hier aber besser bleiben.]

In der Praxis spielt's aber wirklich fast keine Rolle, welche 
Programmiersprache, welches Betriebssystem od. welche anderen kreativen 
Hilfsmittel verschiedene Teilnehmer nutzen oder bevorzugen -- irgendwie 
bringt man fast alles dazu, notfalls halt übers Netz miteinander zu 
kommunizieren bzw. ganz praktisch zu kooperieren.

Am schwierigsten finde ich es in diesem Zusammenhang zu beantworten, 
welche Ansätze man tatsächlich heute nutzen soll, damit kompliziertere 
Sachen nicht nur in experimenteller und skizzenhafter Form am eigenen 
Rechner od. in irgendwelchen Perfomance- oder Ausstellungszusammenhängen 
genutzt werden können, sondern darüber hinaus auch direkt im Webbrowser 
zugänglich gemacht werden können? In der Hinsicht würde ich gegenwärtig 
am ehesten zu irgendwas raten, das sich mit vertretbarem Aufwand nach 
WebAssembly übersetzten lässt [also natürlich wieder: "rust!" :)] und 
damit auch die Bedienungs- und Ausgabemöglichkeiten in einem solchen 
Kontext möglichst optimal nutzen lässt. Leider wird's aber spätestens an 
diesem Punkt recht kompliziert, weshalb das hier nur eingeworfen sei, um 
den angesprochen "Ghetto"-Bedenken ein andere praxisrelevante 
Herausforderung diametral gegenüberzustellen.


## ML-Toolkits im besonderen

Die Beispiele, die du verlinkt hast, um Neuronale Netze in Processing 
quasi 'from scratch' zu implementieren, sind natürlich recht nett. So 
etwas kann, wenn man es nicht ausschließlich nur als völlig 
stumpfsinnige Abschreib- od. copy-and-paste-Übung versteht, durchaus 
Sinn machen. Es ist immer recht eindrucksvoll, wenn man an Hand relativ 
überschaubarer Code-Fragmente irgendwelche Techniken in ihrer 
prinzipiellen Funtionsweise nachzuvollziehen lernt bzw. einfach auch vor 
Augen geführt bekommt, dass das alles nicht unbedingt gleich völlig 
undurchsichtig kompliziert und unüberblickbar sein muss.

Trotzdem macht es in der Praxis oft deutlich mehr Sinn, für die 
jeweiligen Aufgaben passende spezielle Werkzeuge zu wählen. Dort kann 
man dann mit einer paar verhältnismäßig übersichtlichen Zeilen 
Programmcode weit mehr erreichen, als mit einer seitenlangen 
undurchsichtigen Neuerfindung des Rads. Was aber vor allen Dingen auch 
eine große Rolle spielt, ist die Tatsache, dass man mit derartigen 
Toolkits auch sehr einfach auf jenen riesigen Erfahrungsschatz bzw. 
gesammelte Verbesserungsbemühungen zurückgreifen kann, die über die 
Jahre erst dazu geführt haben, dass diese Techniken heute tatsächlich 
brauchbar funktionieren. Ganz einfachen Umsetzungen, wie sie diese 
Processing-Lösungen repräsentieren, gleichen hier eher einer Zeitreise 
zurück zu den Anfängen, als dass sie mit heute gängigen Mitteln 
verglichen werden könnten.

Was also tatsächlich nutzen?

Ich würde gegenwärtig am ehesten zu "PyTorch" (http://pytorch.org/) 
raten. Das ist zwar dem ungeliebtem f***-konzern entsprungen, aber 
ansonsten wirklich eines der tollsten Werkzeuge in diesem Umfeld. 
Allerdings ist das natürlich nur meine Einschätzung [die man ruhig mit 
der nötigen Skepsis betrachten und ggF. offen kritisieren sollte]. In 
letzter Zeit stützen sich immer mehr Veröffentlichungen und Forscher auf 
genau dieses Werkzeug. In Wahrheit gibt es aber eine große Menge 
ähnlicher Toolkits, die alle auch alle ihre jeweiligen ganz spezifischen 
Vorzüge haben. So war/ist z.B. auch "Keras" (https://keras.io/) sehr 
beliebt, aber auch "TensorFlow"  (https://www.tensorflow.org/) spielt 
eine recht bedeutende Rolle.

Auch, wenn es keinen Sinn macht, über die Vor- und Nachteile all dieser 
Lösungen hier ausufernd zu referieren, kann man schon ein paar Kriterien 
herausheben, die eine solche Empfehlung rechtfertigen:

Am wichtigsten finde ich den Umstand, dass die betreffenden 
Arbeitsmittel Vernünftig dokumentiert sind, und auch im weiteren Umfeld 
um sie herum, möglichst viel praktischer open source Beispielcode zu 
finden ist, um wenigstens die gängigsten Techniken in einfachster Weise 
praktisch zugänglich zu machen. In der Hinsicht ist dem PyTorch leider 
noch immer ein wenig anzuspüren, dass es verhältnismäßig jung ist. 
Mittlerweile gibt's zwar fast alles, wonach man sich sehnen könnte, aber 
trotzdem wirkt bspw. Keras in dieser Hinsicht fast noch verlockender. 
Das wird aber vom PyTorch u.a. dadurch wett gemacht, dass es viel besser 
zu debuggen ist, da es im Gegensatz zu Keras nicht so sehr nur als 
Abstraktions-Layer über anderen Lösungen liegt, sondern eben wirklich 
ein stimmiges Ganzes bildet, dass sich wunderbar in das verwendete 
Python-Sprachumfeld fügt. Das sind so in etwa die Gründe, die in letzter 
Zeit viele bewogen haben, auf diese Lösung umzusteigen.

Wie schon oben bei den allgemeinen Arbeitsmitteln, kann ich aber auch 
hier nur nocheinmal zu möglichst großer Pluralität der Mittel und des 
Nebeneinanders verschiedenster Vorlieben ermuntern. Mehr als eine ganz 
grobe Empfehlung, die als erste Orientierung dienen könnte, soll mein 
Vorschlag also nicht sein.

Abschließend sei vielleicht noch erwähnt, dass ja auch derartige 
spezialisierte Lösungen nicht unbedingt ausschließen, dass man darin 
manche Dinge ganz bewusst von Grund auf selbst konstruiert, statt fertig 
vorfindliche Mittel zu nutzen, um auf diese Weise ganz bewusst von den 
einfachen theoretischen Grundlagen zu komplexeren Umsetzungen 
vorzudringen -- ähnlich, wie es dein Processing-NN-Vorschlag nahe legt. 
Derartiges bekommt man bspw. in dieser recht einfach gehaltenen PyTorch 
lecture-Serie anschaulich vorgeführt:

https://www.youtube.com/playlist?list=PLlMkM4tgfjnJ3I-dbhO9JTw7gNty6o_2m

So viel im Augenblick zur Ergänzung deiner ermunternden Anregungen aus 
meiner Sicht.

alles liebe
martin