Audio / Synthesizer Programmiersprachen vs Faust vs Supercollider vs PureData vs C und so weiter…

[mooncast]

Das scheint aber erstmal ne generell Sprache/ C Ableger zu sein? Wo wär da ein Vorteil für Audio?

 

[Klinke]

Mmmm, die ersten Abschnitte der verlinkten Doku lauten:

The programming language for writing fast, portable audio software.

You’ve heard of C, C++, C#, objective-C… well, Cmajor is a C-family language designed specifically for writing DSP signal processing code.

Fällt mir schwer zu glauben, dass Cmajor keine Vorteile für Audio mit sich bringt.

 

[mooncast]

Gibt offenbar mehr als einen C Ableger der sich so nennt.

 

[Klinke]

Gibt offenbar mehr als einen C Ableger der sich so nennt.

Wow, stimmt. Das ist ja eine sehr dämliche Umbenennung (den wenn ich es richtig sehe ist Cmajor eigentlich bis vor kurzen unter den Namen "Soul" presentiert worden, ich schätze mal, dass die Umbenennung was mit der Akquirierung von Soundwise zu tun hat).

 

[everNoob]

Soul ist ne DSL(DomainSpecificLanguage) für DSP, für den ganzen Midi und GUI Kram müsste man dann trotzdem z.B. Juce hernehmen. Ist also wohl eher nicht das was hier gesucht wird.

 

[mooncast]

das ist ganz interesant, sind mir aber zu viele Baustellen.

Aus dem was ich gelesen habe geht auch nicht ganz eindeutig hervor wie am Ende der Code erzeugt werden soll.
Einerseits hat man Soul in nem Webbrowser, also geparsed in JavaScript, das dann als Heart compiliert wird was dann JIT interpretiert wird und daraus macht man dann wie was für welche Platform mit welchem Compiler?
Solche super-vielschichtigen Systeme machen mich etwas skeptisch vor allem wenn es Version 1.0 ist.
Man weiß dann nie genau ob man selbst einen Fehler macht oder ob der Fehler irgendwo bei der dritten Codeübersetzung auftaucht.
Mir ist klar dass alle Lösungen mehr oder weniger mehrschichtig arbeiten,
aber je nischenhafter und unabhängiger eine VM entwickelt wird und je mehr Interpreter und Compiler man schichtet desto wahrscheinlicher sind Bugs.
Selbst in Reaktor hatte ich es ein paar mal dass sich irgendwie irgendwo in der Übersetzung die Struktur verschluckt hat, mit jeweils recht kuriosen "unmöglichen" Folgen.
Da hilft dann nur noch die exakt identische Struktur ein zweites Mal neu aufzusetzen,
In Reaktor ist es relativ leicht und überschaubar solche Fehler die sehr selten vorkommen einzugrenzen.

 

[Tonerzeuger]

Ich plädiere ebenfalls für Pure Data, allerdings ohne Faust wirklich zu kennen. Damit entwickele ich schon lange alles Mögliche. Ja, bei komplexen Patches wird's leicht unübersichtlich, aber dafür kann man sehr schnell Dinge ausprobieren. Und performant ist es auch- ich kam testweise auf 10000 gleichzeitige Audio-Multiplikationen auf einem älteren i5 Prozessor (!).

 

[Tonerzeuger]

Ich füge hinzu: Auf einem Kern eines älteren i5-Prozessors, denn Multithreading geht da leider nur sehr eingeschränkt!

 

[mooncast]

Das ist ne Menge, aber der ARM auf dem Raspberry hat nur 800 Mhz
Ob es da SIMD gibt und ob PD das ausnutzt weiss ich nicht.

Aber gut als Hausnummer zu wissen, mein Synth sollte da schon laufen dann.

Für PureData spricht auch dass die Strukturen auch für Leute die nicht drin stecken halbwegs lesbar und nachvollziehbar sind, jedenfalls kleinere.

Es gibt ja von Miller Pucket das Book, DSP für Musiker, das finde ich ziemlich gut und das hat so Illustrationen mit PD Beispielatrukturen, die fand ich recht hilfreich auch ohne Programmkentnisse.

 

[einseinsnull]

ob eine sprache eine "richtige" sprache ist oder ob sie "vollständig" oder "unvollständig" ist ist vor allem metaquatsch.

das wesentlichste unterscheidungsmerkmal bei A/V umgebungen ist ob man das zeug 1. in echtzeit während dem programmieren, 2. nur per knopfdruck im wechsel mit dem programmieren oder 3. überhaupt erst nur nach einem kompilierungs- und bauvorgang laufen lassen kann.

programmierumgebungen bzw,. sprachen, auf die #3 zutrifft fallen für kreative leute, die ihr programm selbst nutzen wollen, komplett raus.

(ja, ich weiß, du kannst deine plug-ins und apps in XCode auch quasi-live updaten und dann sofort benutzen, es ist aber dennoch nicht das gleiche wie die klassischen audio umgebungen.)

 

[GegenKlang]

Deine Trennung zwischen #2 und #3 ist etwas vage. Was soll denn passieren auf "Knopfdruck", wenn nicht dass "Code da ganz tief innen drin" losläuft um ohne Echtzeitbindung aus logisch-schematisch-syntaktisch strukturierter Information irgendwas zu machen, das in der weiteren Abspiel-/Ausführungsphase nur noch wenig Rechenleistung benötigt, aber dafür eben nicht mehr so leicht inspiziert und reengineert werden kann?

Das trifft sowohl auf die Kompilierung von Quelltext in Maschinenbefehle zu, als auch auf die Generierung von Samples aus Quelltext. Oder die Erstellung von Büchern aus TeX-Sourcen.

programmierumgebungen bzw,. sprachen, auf die #3 zutrifft fallen für kreative leute, die ihr programm selbst nutzen wollen, komplett raus.

Mag sein. Abseits von A/V, in der Textbranche vor allem im Gebiet der Naturwissenschaften hält sich allerdings ein kleiner Kreis von Verlagen, die mit TeX-Dokumenten noch umzugehen wissen.

 

[einseinsnull]

Deine Trennung zwischen #2 und #3 ist etwas vage. Was soll denn passieren auf "Knopfdruck", wenn nicht dass "Code da ganz tief innen drin" losläuft um ohne Echtzeitbindung aus logisch-schematisch-syntaktisch strukturierter Information irgendwas zu machen, das in der weiteren Abspiel-/Ausführungsphase nur noch wenig Rechenleistung benötigt, aber dafür eben nicht mehr so leicht inspiziert und reengineert werden kann?

ich verstehe die frage nicht.

max/msp z.b. läuft in echtzeit während dem programmieren, supercollider (#2) muss man "starten", und während es dann "läuft" kann man nicht mehr gleichzeitig coden.

C++ (#3) muss man komplett "erst schreiben, dann kompilieren, dann laufen lassen" (wobei es heutzutage natürlich tools gibt, die die neueste version deines codes immer schon im hintergrund compilieren und z.b. dein AU plug-in in der neuesten version einer host lädt, wo es gefühlt permanent läuft.)

aber das sind halt 3 vollkommen unterschiedliche situationen.

textures habe ich live auf eine bühne noch nicht gesehen, und da läuft auch nix dauerhaft, sondern das wird nur mal kurz was erzeugt und dann eben mit 300 ms verzögerung dargestellt. so lange es auf dem schirm so aussieht wie später im buch ist alles gut (und deswegen ist textures auch quark 4 um längen überlegen hihi)

 

[0gfjndu]

Habt ihr gewusst, dass man in SQLite3 eine Mandelbrotmenge programmieren (oder, wenn euch der Terminus nicht gefällt, deklarieren) kann? SQL ist nicht turing-komplett, dennnoch lassen sich einige Klassen von Problemen, denen man mit generalistischen Sprachen beizukommen pflegt, eben auch so lösen. Im strengen Wissenschaftlichen Sinn ist das nicht programmiert, weil auch SQL eine Beschreibungssprache ist. Und um die Verwirrung komplett zu machen, gibt es die deklarative Programmierung als Paradigma.

Mit SQLite oder SQL kann gar nichts programmiert werden. SQLite und SQL sind eine Scriptsprache zur Kommunikation mit SQLite oder SQL Datenbanken. SQLite, eine Dateibasierte Datenbank, eine einfachere Version von SQL (Serverbasiert). Im Klartext: mit SQLite oder SQL können nur Datenbanken verwaltet oder die darin enthaltenen Datensätzen verarbeitet werden.

 

[GegenKlang]

meines halbwissens ist supercollider quasi #3, nur läuft der Kompilierprozess soweit möglich für jede neu eingegebene Codeeinheit nach ihrem Abschluss, der Rest (Ingest in die Playback-Loop) wird mit nem abschließenden Knopfdruck erledigt. In die gleiche Kerbe schlägt SonicPi.
Aber hast schon recht: Kompilierphasen vertragen sich nicht ganz mit spielartigen Disziplinen. Sie eignen sich eher in Szenarien, in denen es eine genaue Vorstellung oder eine Vorlage, Noten z.B., vom Endergebnis existiert

@acidfarmer: Was SQL/SQLite/Datenbanken sind, weiß ich. Die Mächtigkeit von SELECT, eigentliche eine Sprache in der Sprache, hab ich allerdings auch noch nicht erfasst und kann nur staunen über solche Zweckentfremdungen.

 

[0gfjndu]

@acidfarmer: Was SQL/SQLite/Datenbanken sind, weiß ich. Die Mächtigkeit von SELECT, eigentliche eine Sprache in der Sprache, hab ich allerdings auch noch nicht erfasst und kann nur staunen über solche Zweckentfremdungen.

SELECT ist nur ein Befehl um Daten aus der Datenbank abzufragen. In einer SELECT-Anweisung können mit den Daten z.B. schon Berechnungen stattfinden. "Zweckentfremdungen" sind mit SQL-Funktionen möglich, aber auch hier kann nur mit vorhandenen Datensätzen aus der Datenbank gearbeitet werden und ist immer noch weit weg von programmieren.

 

[serge]

Die Grundzüge von Live Coding mit Supercollider und was man damit machen kann.

 

[Klinke]

Meines Wissens benutzt Supercollider einen Interpreter, zumindest die Benutzung fühlt sich so an, da jede Veränderung sofort nach dem transmit der Code-Zeile/Blöcke hörbar wird und dabei immer die bestehende Session modifiziert wird. Schliesslich wird Supercollider ja auch viel zum Live Coding benutzt und ist das Backend von TidalCycles (mit welchem ich eine Zeit lang rumgespielt habe). Für mich ist Supercollider daher ganz klar #1. Das gleiche gilt auch für SonicPi und alle Tools die speziell für Live Coding entwickelt worden sind. Ich finde die deutlich "spielartiger" als Max/Msp oder PD.

 

[GegenKlang]

SELECT ist nur ein Befehl um Daten aus der Datenbank abzufragen. In einer SELECT-Anweisung können mit den Daten z.B. schon Berechnungen stattfinden. "Zweckentfremdungen" sind mit SQL-Funktionen möglich, aber auch hier kann nur mit vorhandenen Datensätzen aus der Datenbank gearbeitet werden und ist immer noch weit weg von programmieren.

Deklarative Programmierung ist Programmierung, aber weit weg von imperativer Programmierung. Und vielleicht interessiert dich https://www.sqlite.org/lang_with.html, Abschnitt 3.5. Als jemand, der schon ein Kassenverwaltungssystem (Datenbank und Logik) allein mit SQLite3 programmiert hatte, nur mit Tabellen, Views und Triggern, weiß ich, dass ich nichts weiß, dass musst du mir nun wirklich nicht unter die Nase reiben, gell.

 

[rolfdegen]

Hallöchen..

Spannendes Thema. Ich programmiere schon seit mehreren Jahren kleinen Hardware Synthis. Erste kleine Projekte z. B. einen Midi Monitor mit LC-Display und Tastatur habe ich noch in Assembler geschrieben. Dann folgte größere Hardware Projekte z. B. Synthesizer/Sampler in der Programmiersprache C. Zur Zeit interessiere ich mich für Pure Data und die Möglichkeit mit dem Raspberry Pi als Hardware Synthesizer/Sampler.

 

[einseinsnull]

meines halbwissens ist supercollider quasi #3, nur läuft der Kompilierprozess soweit möglich für jede neu eingegebene Codeeinheit nach ihrem Abschluss, der Rest (Ingest in die Playback-Loop) wird mit nem abschließenden Knopfdruck erledigt.

wenn du das so einordnen willst gilt das aber dann für jede umgebung und du kannst zwischen echtzeit und nichtechtzeit gar nicht mehr unterscheiden.

bei max wird - bei audiosignalen - auch die signalkette neu berechnet und unterbricht kurz wenn man etwas ändert. man muss aber nicht vorher stop drücken und danach wieder start, und das ist eben ein komplett anderer workflow. ich kann mich noch erinnern wie das genervt hat, wenn ich in supercollider immer vergessen habe das teil zu stoppen und dann nicht mehr editieren konnte.

und wenn du für max oder supercollider dann mit einer hochsprache eine eigene klasse schreibst, kannst du die überhaupt nicht mehr sofort ausprobieren, bevor du sie umständlich gebaut und nachgeladen hast. supercollider muss sogar neu gestartet werden wenn sich im suchpfad etwas ändert.

perfektes live coding gibt es leider noch nicht, vor allem das nachladen von dokumenten ist immer noch ein problem. aber kyma, max oder processing sind schon relativ dicht dran...

 

[einseinsnull]

Für mich ist Supercollider daher ganz klar #1.

ganz klar ist es für mich nicht, aber für SC oder processing gibt es in der tat eine ganze reihe anwendungen, oberflächen oder erweiterungen, mit denen das faktisch geht.

auch in max kannst dir natürlich entsprechende äh... subumgebungen... bauen, die den tatbestand erfüllen. die existierenden auf basis von javascript (mercury usw.) oder iain´s scheme zeug sind schon recht beeindruckend und halten, was sie versprechen. das problem mit dem signal chain recompiling bleibt allerdings auch dabei erhalten. midi oder video ist natürlich nicht davon betroffen.

vermutlich müsste man beim thema "live coding" noch zwischen "für eine performance" und "beim erstellen eines programms" unterscheiden. die meisten live coding geschichten funktionieren ja nur live und das ist dann irgendwie auch schon wieder etwas anders.

(vermutlich muss man auch zwischen SC2 und SC3 unterscheiden )

die runtime auf einer kyma hardware läuft immer. das gessamte betriebsystem rennt in signal rate. darin fügt man dann etwas ein. manchmal fühlt sich das nicht sehr direkt an, aber das ist nur eine frage der oberfläche und der ladegeschwindigkeit.

in max läuft main thread immer, der scheduler thread und das audio nur wenn ich ihn einschalte. wobei das alles natürlich auch programmatisch geht. baue ich eine clock, kann ich diese clock schon mal laufen lassen und danach erst entscheiden, welche zahlen die clock ausgibt. den algo für meine zufallsmelodie kann ich jetzt live ändern.
würde ich das gleiche mit audio objekten machen, würde es auch live gehen, allerdgins immer knacksen wenn sich etwas ändert. um ein programm zu erstellen ist das ausreichend, für einen live gig natürlich nicht.

in supercollider 2.x muss ich erst den algo schreiben und dann auf "run" drücken damit es losläuft. bevor ich nicht stop drücke, kann ich keine änderungen hören.

der eine empfindet das als ähnlich, für mich macht es einen fundamentalen unterschied.

 

[0gfjndu]

Als jemand, der schon ein Kassenverwaltungssystem (Datenbank und Logik) allein mit SQLite3 programmiert hatte, nur mit Tabellen, Views und Triggern, weiß ich, dass ich nichts weiß, dass musst du mir nun wirklich nicht unter die Nase reiben, gell.

Das ist mein täglich Brot, ich entwickle ERP-Systeme in C#

 

[nnnnnnnn15712]

Synthedit und Synthmaker gibt es auch noch
Die Instrumente lassen sich als VST exportieren

Venom VB-303 wurde auch damit erstellt, und viele andere interessante Synthesizer mit gutem Klang

 

[GegenKlang]

wenn du das so einordnen willst gilt das aber dann für jede umgebung und du kannst zwischen echtzeit und nichtechtzeit gar nicht mehr unterscheiden.

Stimmt ja auch. Echtzeit ist immer gefühlte Echtzeit. Echtzeitsysteme garantieren, dass jede Nutzerinteraktion innerhalb einer Zeit verarbeitet wird, die unterhalb der Wahrnehmungsschwelle liegt, oder vergessen wird, also wiederholt werden muss. Sind also zu wenig Ressourcen vorhanden, führt das zu Aussetzern bzw. zu mehr Mensch-Maschine-Interaktionsversuchen, nicht zu längeren Wartezeiten. Wenn eine DAW den Menschen auch mal warten lässt, ist das schon kein "wirkliches" Echtzeitsystem mehr. Laut der Online-Enzyklopädie meines Vertrauens gibt es da Stufen der Echtzeit.

Am Ende zählt für den Begriff der Audioprogrammiersprache, was hinten rauskommt. Wenn das ein Audiofile ist, ist es Audio-, wenn am Anfang das Wort war, ist es -programmiersprache. Alles andere sind konzeptuelle Gedanken.

 

[einseinsnull]

rationalismus kreativität

richtig zielführend

 

[Klinke]

in supercollider 2.x muss ich erst den algo schreiben und dann auf "run" drücken damit es losläuft. bevor ich nicht stop drücke, kann ich keine änderungen hören.

der eine empfindet das als ähnlich, für mich macht es einen fundamentalen unterschied.

Vielleicht war dies bei supercollider 2.x noch so, aber bei supercollider 3 wird einmal der Server gestartet (z.B. automatisch in dem Startup Script der Supercollider IDE) und an diesen kannst Du dann nach und nach den Code schicken, ähnlich wie bei einem jupyter notebook. Schau Dir doch einfach mal das gepostete Supercollider Live Coding Video an. Und da werden auch nicht irgendwelche Zusatzanwendung benutzt, das funktioniert genau so mit einer 08/15 Default Supercollider Installation. Selbst die Supercollider IDE müßte garnicht benutzt werden, ich habe bei Tidal Cycles meinen Code immer mit Emacs geschrieben und von dort zum Server geschickt.

vermutlich müsste man beim thema "live coding" noch zwischen "für eine performance" und "beim erstellen eines programms" unterscheiden. die meisten live coding geschichten funktionieren ja nur live und das ist dann irgendwie auch schon wieder etwas anders.

Supercollider funktioniert auch sehr gut nicht live. Und selbst Tidal Cycles (was ja nun ein Tool ist, welches speziell für Live Coding Sessions entwickelt wurde) hat Funktionen welche Dir erlauben Arrangments zu erstellen, die Du dann ohne Interaktion abspielen kannst (und was Dir fehlt, kannst Du ja immer noch in Haskell selbst schreiben). Aber vor allem war ja Dein genanntes Merkmal zur Unterscheidung erstmal, ob man in Echtzeit programmieren kann, und dies ist bei Supercollider nun mal (zumindest mittlerweile) definitiv der Fall.

 

[GegenKlang]

Wie es für eine natürliche Sprache ja auch keinen nennenswerten Unterschied macht, ob sie gesprochen wird oder geschrieben und später gelesen, sollten die Fähigkeiten einer Audioprogrammiersprache auch nicht daran beurteilt werden, ob sie echtzeittauglich ist. Wo immer aus Text Audiodaten werden, ist eine Audioprogrammiersprache beteiligt, basta. Echtzeit oder nicht, das ist eine Frage des Workflows, der Präferenzen des Musikers. Zumal der Anteil der von mir gehörten Musik, die aus Echtzeitsystemen stammt und auch affektbasiert, wie organisch gespielt wird, erstaunlich gering ist. Modularsynthetische Musik wirkt sogar recht häufig statisch wie ein Klotz aus Holz.

 

[einseinsnull]

da hast sdu wahrscheinlich recht, fast jeder hatte damals von anfang an "server" benutzt, auch lokal/am client - und ich kenne SC3 auch nicht wirklich.

und wie wir oben schon feststellten: ob das nun mit irgeneinem trick oder ohne auskommt ist egal, es kommt nur darauf an wie es sich anfühlt.

"zusatztools" lassen sich im regelfall mit tricks überall in diesen zustand versetzen um aus einer imperfekten "live coding" umgebung eine perfekte zu machen. die dann aber nicht den funktionsumfang des programms hat.

während es bei csound oder flowstone noch kompliziert ist braucht man z.b. in max einfach nur subcircuits, die man ein und ausschaltet und damit die live vorgenommenen änderungen in der signal chain so managen kann wie man sie gerade braucht.


https://vimeo.com/315143784?from=outro-embed


https://vimeo.com/309869256?embedded=true&source=vimeo_logo&owner=37322272

 

[schnuffke2]

Vorhin zufällig drüber gestolpert - etwas Neues von cycling74:


https://www.youtube.com/watch?v=xZNyQDCHs4o

Introducing RNBO | Cycling '74

RNBO is a new patching environment built to export software with the sound of Max. Create web experiences, hardware music devices, audio plugins, and new Max objects all from the same patch, or take your generated source code wherever you want.

cycling74.com

Man kann Patches erstellen, die dann problemlos für verschiedene Zielplattformen exportiert oder als C++Code ausgegeben werden können. Näher habe ich mich damit nicht befasst, aber denke, das gehört unbedingt hier rein.

 

[einseinsnull]

problemlos

*hust*