Ask HN: Is there a great DAG framework for Python to write a synth-patch GUI?
For synth patches, we love our Direct-Acyclic Graph apps like Max/MSP, PureData, Axoloti, SpinCAD Designer, etc. But most of these are native apps or Java. How can I write "one DAG editor to rule them all" that can target multiple DSP targets, microcontrollers, raw C code, other APIs with a simple-ish plug-in archtecture. Most of them time, these apps are written by passionate synthesists and hence the limited portability, but how would a hardcore CS approach this?
8 comments
This is an important objective of the rapidly-progressing plugdata project! The patcher is based on pure data so you can live patch yourself into deep space with any GP computer (a RasPi works fine), but has a sleek, calm, efficient, and themeable UI. In the last couple of weeks has grown a compiler that is working in its preliminary form both compiling in to C and flashing a Daisy synth dev board. The eventual hope is to gain compatibility across microcontrollers for not just audio synthesis, but for any creative purpose.
The project is here: https://github.com/plugdata-team/plugdata
The builds are coming thick and fast. 0.6.2 is so far behind the daily builds right now that 0.6.3 is going to be an enormous leap in functionality. Tim and the development team are doing a spectacular job of staying focused and cranking out bugfixes and features sometimes multiple times a day.
The project is here: https://github.com/plugdata-team/plugdata
The builds are coming thick and fast. 0.6.2 is so far behind the daily builds right now that 0.6.3 is going to be an enormous leap in functionality. Tim and the development team are doing a spectacular job of staying focused and cranking out bugfixes and features sometimes multiple times a day.
From where I stand (I'm a designer and artist, but I'm helping where I can) the project needs more people who understand microcontroller structure. The Daisy can't yet talk to its GPIO, so it can't yet do i2c or anything similar. But by the time the project is fully rolling, it shouldn't be tied to a single chip architecture, never mind a single development board.
The project needs people who care and know about programming DSP hardware! And Tim is an amazing core developer. It's a pleasure working together.
The project needs people who care and know about programming DSP hardware! And Tim is an amazing core developer. It's a pleasure working together.
Does Faust do what you want? It's a language specifically for digital signal processing, and has a wide variety of compile targets.
https://faust.grame.fr/
> Faust (Functional Audio Stream) is a functional programming language for sound synthesis and audio processing with a strong focus on the design of synthesizers, musical instruments, audio effects, etc. created at the GRAME-CNCM Research Department. Faust targets high-performance signal processing applications and audio plug-ins for a variety of platforms and standards.
> The core component of Faust is its compiler. It allows to "translate" any Faust digital signal processing (DSP) specification to a wide range of non-domain specific languages such as C++, C, LLVM bit code, WebAssembly, Rust, etc. In this regard, Faust can be seen as an alternative to C++ but is much simpler and intuitive to learn.
https://faust.grame.fr/
> Faust (Functional Audio Stream) is a functional programming language for sound synthesis and audio processing with a strong focus on the design of synthesizers, musical instruments, audio effects, etc. created at the GRAME-CNCM Research Department. Faust targets high-performance signal processing applications and audio plug-ins for a variety of platforms and standards.
> The core component of Faust is its compiler. It allows to "translate" any Faust digital signal processing (DSP) specification to a wide range of non-domain specific languages such as C++, C, LLVM bit code, WebAssembly, Rust, etc. In this regard, Faust can be seen as an alternative to C++ but is much simpler and intuitive to learn.
Wow, thank you for the great reference. This would be a great target for The Editor. E.g. the editor could allow a musician/designer/inventor to compose the sound patch in the Faust modules, then call Faust to render the code across a variety of platforms!
Yeah maybe that would work. I learned Faust online at Kadenze and have participated on the Faust Slack channel and made a few additions to some build files for making VST3 plugins in Juce. Boy that was a year or two back! I also compiled some Faust to the ESP32 and hacked in OSC support. I was mostly writing in native Faust and debugging in the web IDE although there is at least one block based graphical tool.
I'm really not sure how you would map Faust to something like the FV-1 though - its instruction set is designed to do a handful of structures really efficiently.
I'm really not sure how you would map Faust to something like the FV-1 though - its instruction set is designed to do a handful of structures really efficiently.
I asked over at the Faust Slack channel and the guy from Grame said (after looking briefly at the FV-1 instruction set) that it would require a custom backend assuming it's even possible. Which doesn't sound like a ringing endorsement. I think the missing link here is for the other ASICs like fxCore, CoolAudio V1000, etc. Faust is portable to ARM and other general purpose CPUs. They are also working on a project to implement Faust on FPGAs which gets super low latency. My question as always is "how much processing can you get on that"? It remains to be seen.
I'm not a hardcore CS, I'm just the guy that wrote SpinCAD Designer on top of ElmGen. You could start with an existing graphical editor. I'm all in favor of not reinventing stuff if possible. I think Teensy Audio Tool forked node-red. I spent an hour maybe looking at it and it would take more time than that to figure out what they did. Notably, node-red blocks have 1 input and 1 output. Teensy audio blocks have multiple inputs and outputs possible. Although not necessary, I like the "audio in one dimension and control in the other" aspect of SpinCAD Designer.
Then you gotta have code templates for each target and then also some per-target means of stitching it all together. I only know SpinCAD Designer but that involves doing a topological sort of the model and then walking down it, allocating FV-1 registers and RAM as you go. My recollection of the Teensy audio tool is that it generates function calls for C or C++, which obviously wouldn't work for chips like fxCore or FV-1.
Then you gotta have code templates for each target and then also some per-target means of stitching it all together. I only know SpinCAD Designer but that involves doing a topological sort of the model and then walking down it, allocating FV-1 registers and RAM as you go. My recollection of the Teensy audio tool is that it generates function calls for C or C++, which obviously wouldn't work for chips like fxCore or FV-1.
Look at DawDreamer, an audio-processing Python framework supporting core DAW features and beyond:https://github.com/DBraun/DawDreamer