die netpd-experience

ich verfasse diesen kleinen "artikel" mal auf deutsch, da die angesprochenen entwickler ja alle der deutschen sprache mächtig sind. das hier soll kein gezeter und gemecker über den gegenwärtigen zustand von netpd (mit netpd bezeichne ich den programmkern, sowie alle dazugehörigen synths, effekte, seqs, halt alles, was für den user die "netpd-experience" ausmacht) werden, sondern eher eine bestandsaufnahme von netpd halb aus user, halb aus developer-sicht. mir fiel nur auf, dass die netpd-experience aus mehreren wichtigen steuerungszentren besteht und ich stellte mir die frage, ob sich die experience durch optimierung dieser steuerungspatches nicht vereinfachen/verbessern lassen könnte. ich wiederhole, dass ich hier keine missstände oder handlungsbedarf anprangere, es soll einfach nur als anregung für zukünftige entwicklung verstanden werden.

schaltzentrale #1
ich sehe netpd als modulares programmsystem, vom interpreter pd abhängig; durch schaffen eines scripts oder einer batch-datei kann das starten von netpd bis in den chat auf einen mausklick reduziert werden. der chat selbst versteht sich als ausgangsplatform, es ist das erste geladene patch. ich finde dies insofern wichtig und richtig, da der user, welcher netpd startet, nicht von einer musik-, sondern einer kommunikationssoftware begrüßt wird. musik ja, aber im vordergrund steht die community. zur musik geht's dann über einen toggle.

schaltzentrale #2
kreationismus. mit dem creator startet sich die eigentliche "ausgangsplatform" zur netpd-experience. selbst keine inherenten musikalischen fähigkeiten bietend ist es quasi die metapher eines "betriebssystems" oder einer shell, welches andere programme starten und schließen kann. trotz seiner unentbehrlichkeit wirkt der creator (nach der anfangsphase einer session) jedoch relativ 'außenstehend' gegenüber dem eigentlichen prozess des musikmachens. er bietet (berechtigterweise) 2 globale funktionen (laden und schließen) und 2 lokale (sichtbarmachen gui+code). aus usersicht mitten im set ist die lokale funktion des sichtbarmachens wesentlich wichtiger für den kreativen prozess und sollte meiner meinung nach auch zusätzlich woanders verfügbar sein (ich glaube, daran wird schon gearbeiter, siehe schaltzentrale #4)

schaltzentrale #3
rhythm is it. damit der eigentliche sound überhaupt erst mal gehen lernt, ist ein zentraler taktgeber notwendig. dies wird zur zeit kompetent von master.pd erledigt, jedoch hatten eni und ich schon ein paar überlegungen angestellt, ob ein monolithischer, zentralistischer, diktatorischer, despotischer taktgeber wirklich noch so zeitgemäß ist. die idee: jeder der einen rythmus braucht, bringt ihn selber mit, jeder sequencer kann den takt steuern. aber: wenn mehrere taktgeber vorhanden sind, sind diese automatisch gleichgeschaltet. experimentell wurd schon von eni und mir dran gearbeitet, eine sehr kleine gop-abstraction zu kreieren, die den master vollwertig ersetzt und problemlos in die guis der verschiedenen sequencer und sogar dem mx einzubauen. monolithic transport panel vs ubiquitious one. anregungen dazu? notwendigkeit gegeben, oder nutzlose spielerei. vom experience standpunkt her sähe es folgendermaßen aus: ich lade einen synth im creator, vis'e den synth, vis'e den seq, klick auf ne note und klicke auf start: weit weniger klicks notwendig bis zum sound.

schaltzentrale #4
in the mix. während einer session ist der mx das wichtigste werkzeug, um sound zu steuern. leiser, lauter, links, rechts, an, aus. und? effekte natürlich. an diesem punkt wird die netpd-experience ein wenig schwammig: ich nutze also den creator um synths zu laden und sichtbar zu machen, aber ich nutze den mx um das gleiche für effekte zu erledigen? von den fx-libs mal abgesehen (eni schlug vor, effektlibs als abstractions direkt in den mx zu integrieren, also wieder weniger im cr zu laden) überschneiden sich die kompetenzen von creator und mx hier. aber anscheinend noch nicht ausreichend: vom mx aus kann man alles zu einem synth steuern, sein volume, sein panning, die fx-chain. man kann die effekte sichtbar machen, nur leider nicht die gui vom synth selbst (und erneut: ich glaube eni arbeitet schon daran). wenn mx nun alle wichtigen kontrollfunktionen inne haben wird, wird sein kompanion, der creator, zum simplen starter und schließer verkommen sein. aus user-experience sicht sollten meiner meinung nach beide patches zusammengelegt werden, das ist 1. aber meine persönliche meinung und 2. wenn überhaupt nur zukunftsmusik; ich weiß nicht, in wie weit es der entwicklerphilosophie von netpd entspricht (der unix-philosophie 1 tool per task entspricht es auf jeden fall nicht) außerdem könnte es somit netpd als reines audio-tool darstehen lassen (ist das schlimm?). hier besteht wie gesagt auch kein handlungsbedarf, ich wollte es nur als diskussionsvorschlag in die runde werfen.

schaltzentrale #5
sequenziell. die sequencersituation in netpd ist relativ zwiegespalten. für 2 unterschiedliche synthesizerarten gibt es 2 unterschiedliche (äußerst fähige!) sequencer. der eine spuckt bangs aus (roman hatte erwähnt, den qseq2 auf nbxes zu erweitern) der andere monophone noten und sliderwerte. soweit keine einwände. was jedoch die netpd-experience beeinflusst ist: der eine ist ein zentrales patch, der andere eine abs. ohne jetzt zu sagen das der eine oder andere "richtiger" funktioniert muss man zugeben: bei jamx kommt man durch weniger aufwand zum sound, aus user-sicht ist der sequencer auch besser an den synth gebunden. beim qseq ist die bindung seq-synth nicht so offensichtlich, dafür hat man den vorteil, dass man die percussion einer gesamten session zentral kontrollieren kann und die sounds von mehreren synths kompakt zusammengruppieren kann. das sind beides vorteile, die für sich stehen, und die auch bei einer umgestaltung der sequencer-landschaft nicht verloren gehen sollten. zeit für zukunftsmusik: alle sequencer als abstractions in patches, die sofort ohne andere patches loslegen können (siehe auch schaltzentrale #3); als zentrales interface wird ein arranger eingeführt, der durch ein simples protokoll mit allen seqs sprechen kann aber auch aus seinem hauptfenster aus die sequencer-guis öffnen kann. es stellt sich nur die frage, ob man dann nicht schon wieder ein patch erschaffen hat, welches sich dem user als unentbehrliche schaltzentrale darstellt. dies kann jedoch umgangen werden, in dem man einen solchen arranger klar dem mx (als hauptpatch) unterstellt.

// kommentar von roman

danke, syntax, für die vielen wertvollen gedanken.
entwicklungsgeschichtlich ist es eigentlich sehr leicht nachvollziehbar, warum sich netpd so entwickelt hat, wie es sich entwickelt hat. es stellt sich nun die berechtigte frage, ob man die so entstandenen grundstrukturen nicht grundsätzlich verändern möchte. gründe gibt es ja viele, wie man dem obigen text entnehmen kann. netpd ist mittlerweile so reif - darf man glaub ich schon sagen - , dass man sich solche ''high-level'' fragen stellen soll. bisher waren ja die meisten entwicklungen von netpd selbst ziemlich low level (weiter- und neuentwicklzungen von den netpd-abs).

ich möchte zusammenfassend die zwei strömungen kurz erläutern, um die es hier geht:

die 'unix'-variante (sorry, ich nenn sie jetzt trotzdem mal so...)
ich nenne mal das bisherige system so. denn zu beginn war netpd nicht viel mehr als die idee, über das netz controler-daten zu synchronisieren. klar stand im vordergrund das musik machen; dass man diesen simplen task aber auch für andere anwendungen und ideen verwenden könnte, blieb dabei immer offen. vorgeschrieben wird hierbei eigentlich recht wenig. mit der zeit gesellten sich jedoch patches hinzu, die so wichtig wurden, dass sie einen für bestimmte dinge einen standard setzten (zum beispiel master). in diesem sinne obliegt es bei diesem system den entwicklern von netpd-patches, schnittstellen zwischen den patches zu schaffen, da netpd selbst eigentlich das meiste sehr offen lässt und nur die grundbausteine liefert.
die bestandteile von netpd erfüllen hier relativ simple und einfach zu definierede aufgaben: der creator synched patches und visualisiert sie bei bedarf. folglich wurden auch netpd-patches oft auf eine ähnliche art entwickelt: qseq2 sendet triggers an instrumente, mx bietet routing für effekte, latch-x zeichnet automationen auf usw.
die nachteile davon sind, wie schon oben erwähnt, dass um nur einen ton zu hören, relativ viele schritte von userseite nötig sind, da alle beteiligten patches eben diskret als einzelne patches vorliegen. die übersichtlichkeit kann bisweilen (im vergleich zu logic/cubase) ebenfalls leiden. sympathisch an diesem system finde ich andererseits, dass es sehr seeehr offen ist (kann man auch als "komplett unstrukturiert" deuten, gebe ich zu) und sein spielwiesen-charakter. jeder kann netpd (miss-)brauchen, wofür er lust hat.

die 'integrierte'_variante
was diese variante vermutlich am deutlichsten unterscheidet von der obigen, ist ihr schwerpunkt auf der userperspektive. aus userperspektive gibt es zwei wichtige fragestellungen: wofür brauche ich das tool? um musik zu machen. wie nutze ich dieses tool, um das zu erreichen, was ich will? am besten möglichst einfach. diese zwei fragen werden bei obiger variante gar nicht gestellt, da der schwerpunkt eher auf einer (aufgaben-)technischen perspektive liegt. schenkt man diesen fragen jedoch beachtung, sollten redundante user-aktionen möglichst vermieden werden. wenn man also davon ausgeht, dass man mit nepd musik machen will, würde es sinn machen, funktionen, die man zum musik machen zwangsläufig benötigt, in creator zu integrieren (oder wie auch immer zusammenzuführen in einen patch).
diese variante bringt eindeutig viele vorteile, hauptsächlich weil sie die bedienung einfacher und schneller werden lässt.
dies bedeutete zudem: creator oder mx wären dann die allmächtige schaltzentrale, von dieser aus die globalen funktionen gesteuert würden, ein netpd-patch wäre dann per definitionem ein instrument, dass einen controler-input und einen audio-ausgänge besässe, sequencer wären dann eigentlich immer abstractions (oder nicht?).

yo, soviel zu den wichtigsten wesenszügen der beiden zu diskutierenden varianten.

bisher gab es eine strikte trennung zwischen netpd als umgebung und den von netpd-usern entwickelten patches: die umgebung stellt die minimalsten funktionen zur verfügung:
- chat: kanal zu server und damit zu allen anderen chat-clients
- server: verbindung zwischen allen chat-clients
- creator: synchronisation/visualisierung von patches
- netpd-abs: funktionen zur synchronisation von beliebigen werten/daten.
diese aufgaben sind alle so ''low level'', dass nicht von einer bestimmten verwendungsabsicht der systemteile gesprochen werden kann. in diesem sinne sind sie relativ vielseitig und für viele zwecke einsetzbar.
diese trennung erlaubt es, den entwicklern von netpd-patches völlig vogelfrei ihre patches zu realisieren, ohne sie nach bestimmten vorgaben an schnittstellen des hosts anpassen zu müssen. in diesem sinne ist jeder patch ein netpd-patch, sobald er mit creator geöffnet wurde. die gefahr darin ist, dass netpd als ganzes chaotisch wird, weil die patches-entwickler selber die ''high-level'' tasks lösen müssen.

ich bin im moment überhaupt noch nicht von der einen oder anderen variante fest überzeugt, aber ich tendiere eher dazu, das alte modulare (im sinne von "aus vielen teilen bestehend") system zu bevorzugen. ich persönlich sähe lieber den bot2 netpd-isiert, als netpd so zu bauen wie bot2. und das nicht, weil ich nicht einsehe, dass ein integriertes system für das handling und das eigentliche sound machen an sich viele vorteile bringen würde, sondern weil es mir grundsätzlich gefällt, dass aufgaben wie "takt geben", "signal an effekte weiterleiten" in der user-domain bleiben. es ist jedem freigestellt, einen eigenen mixer oder ein eigenes metronom mit besseren oder anderen funktionen zu bauen. zudem ist es für lösungen aus der user-domain nicht zwingend, dass sie globalen charakter haben, sondern meistens erfüllt man sich damit in erster linie einen eigenen wunsch. sobald aber "high-level"-funktionen in netpd integriert werden, habe n sie zwangsläufig globalen charakter, was ich problematisch finde. auch wenn patches wie master oder mx sich als quasi-standards durchgesetzt haben, sehe ich sie "nur" als dependencies von anderen patches. ich hätte mühe damit vorzuschreiben, dass sich alle netpd-instrumente dieser bedienen müssten. mir ist klar, dass ich mit dieser argumentationsweise die wünsche eines netpd-nutzers völlig aussen vor lasse. ich will zuerst nur mal die punkte herausheben, die mir persönlich an netpd wichtig sind.

weitere comments?

// kommentar von syntax

das netpd nun nach bot2 modelliert werden sollte hab indirekt vielleicht angedeutet, aber im kern wäre das ein sinnloses unterfangen. bot2 ist bisher eine sehr monolithische lösung, die bestimmt noch viele probleme gegenüber einer modularen aufwerfen wird. was netpd angeht plädiere ich nicht auf eine generelle umstellung des kernsystems, sondern eher darauf, ob man die gesamt-oberfläche (aus nutzersicht) nicht an ein paar stellen anders formulieren kann.
um nochmal kurz einen unterschied zur unix-philosophie aufzugreifen: unter *nix hat man zwar hunderte kleine einzelprogramme, die alle für ihren task spezialisiert sind, aber dennoch können diese in großen, integrierten applikationen zusammengefasst werden; k3b ist auch nichts anderes als ein (sehr schickes) frontend für 5-6 kleine tools oder so. die möglichkeit, die pd in dieser hinsicht bietet wäre die nutzung von abstractions und einer kleinen kommunikationsschnittstelle.
ein beispiel einer zusammenführung mx+creator: ein (zukünftiger zentral-)mx lädt _creator.pd als abstraction, dessen gui bleibt aber unsichtbar. die gui von mx verfügt über dieselben funktionen des creators, mx führt aber selber kein laden und schließen aus, sondern alle lade und schließbefehle werden an die creator-abs weitergegeben. somit kann creator als eigenständige applikation wie gewohnt weiter funktionieren, oder aber als integrierte abs mit frontend genutzt werden. ich weiß jedoch nicht genau, in wie weit man ein *nix-system mit einem pd-system vergleichen kann, und ob creation arguments auf bash und abs-ebene sowie unix-pipes und send(~)-recieve(~)-paare in pd quasi dasselbe sind.
das war in etwa auch der gedanke, der hinter der abstractisierung vom master.pd steckt. ich möchte das grundprinzip von netpd und somit die klare trennung von systemland und userland nicht ankratzen, ich wollte nur schauen, ob es möglich ist alles zumindest oberflächlich etwas integrierter zu gestalten, auch wenn es im kern noch schön modular ist.