supercollider VS faust

The visual patching part of Max makes sense when you know the history of the program. It was built for musicians working at the forefront of interfacing MIDI with the power of the more compact mainframe computers of the day (PDP-11 IIRC). The 'programming' was done through a GUI running on the first Macintosh. At first there was no audio processing in Max itself, it was purely for generating and manipulating MIDI data.

You can see the continuation of this 'bare-bones' style of Max with Miller Puckette's continuation of his original work in Pure Data[1] (aka Pd). The nice thing about Pd is that it's open source, so all the scheduling and signal flow logic can be examined and understood. As I understand it, the basics of Pd are comparable to how Max still works under the hood, though no doubt there has been some deviation over the years.

As it is now, Max offers a very smooth interface to the basic paradigm that was established 40 years ago, with many modern advances, but the fundamental idea hasn't changed all that much since it first came out.

If you really hate having to work through a GUI there's always SuperCollider[1] and its many derivatives (Sonic Pi, TidalCycles, etc.). It's nice to have options!

[1] https://msp.ucsd.edu/software.html

[2] https://supercollider.github.io/

SuperCollider has a longer DSP feature list and a more powerful language. The dealbreaker was deployment: scsynth is a separate process. Shipping a game app that has to spawn and supervise another OS process, on iOS, with sandboxing and lifecycle quirks on top, was more friction than I wanted. libpd, by contrast, runs embedded in the game process.

At this point, we can produce the array of pitches that are midi notes. To create sound from these notes I've used a specialized programming language called SuperCollider. I won't dive much into details here, but you may have a look at the code if you're interested. Beware, there are quite a lot of branches there and all of them contain some interesting code.

This is essentially sound design from first principles. There's a good book here: https://www.amazon.com/Designing-Sound-Press-Andy-Farnell/dp... Note that the software used (Pure Data) can be replaced by another high-level language (SuperCollider: https://supercollider.github.io/) pretty easily. I know of no "tool" to do what you want because there are few things that are universal to different kinds of natural and unnatural sound. (Note: study acoustics and psycho-acoustics to better understand why the former is true.)

Since then, I've been working more and more with TidalCycles. TidalCycles is an open-source live coding framework for creating patterns written in Haskell. TidalCycles uses SuperCollider on the backend, another language I've been using for live coding. Recently, I started using Tidal Looper for live vocal processing. This blog post will walk you through what you need to get started with vocal looping with Tidal Looper.

Faust was the closest call. It's a DSP language that compiles to C++ (or wasm, or LLVM), elegant, fast, and has reasonable live-coding paths via the faust2* scripts. The catch is its library catalog. Pure Data has decades of community-built abstractions for the kind of instrument-flavored building blocks this piece leans on. Faust has fewer of these prebuilt. The choice came down to "find or build what I need in Faust" vs "wire up things that already exist in Pd." Pd won.

The Faust compiler uses de Bruijn indices internally to reuse computations. Anyone else know any other examples?

https://github.com/grame-cncm/faust

That's also a big reason why I prefer appimages.

ossia score's AppImage is 100 megabytes: https://github.com/ossia/score/releases/tag/v3.2.0

Inside, there's:

- Qt 6 (core, widgets, gui, network, qml, qtquick, serial port, websockets and a few others) and all its dependencies excluding xcb (so freetype, harfbuzz, etc. which I build with fairly more recent versions than many distros provide)

- ffmpeg 6

- libllvm & libclang

- the faust compiler (https://faust.grame.fr)

- many random protocol & hardware bindings / implementations and their dependencies (sdl)

- portaudio

- ysfx

with Flatpak I'd be looking at telling my users to install a couple GB (which is not acceptable, I was already getting comments that "60 MB are too much" when it was 60 MB a few years ago).

Glicol looks very cool! Also check out Faust if you haven't (https://faust.grame.fr), another FP sound programming language.

The linked (https://github.com/grame-cncm/faust) looks reasonable to me.

Chata probably needs to work out roughly what the semantics of the language should be. Its good to know what the library support is intended to be as that informs language design (assuming the library is to be implemented in chata anyway). Quite a lot of this page is about syntax.

There are some design decisions that have deep impact on programming languages. Reflection, mutation, memory management, control flow, concurrency. There are some implementation choices that end up constraining the language spec - python seems full of these.

Echoing p4bl0, implementing the language will change the spec. Writing a spec up front might be an interesting exercise anyway. I'd encourage doing both at the same time - sometimes describe what a feature should be and then implement it, sometimes implement something as best you can and then describe what you've got.

Implementation language will affect how long it takes to get something working, how good the thing will be and what you'll think about along the way. The usual guidance is to write in something familiar to you, ideally with pattern matching as compilers do a lot of DAG transforms.

- I'd say that writing a language in C took me ages and forced me to really carefully think through the data representation.

- Writing one in lua took very little time but the implementation was shaky, probably because it let me handwave a lot of the details.

- Writing a language in itself, from a baseline of not really having anything working, makes for very confusing debugging and (eventually) a totally clear understanding of the language semantics.

Good luck with the project.

Faust integration would be awesome: https://faust.grame.fr Then again we have MaxMSP, so in the end it feels kind of redundant