supercollider VS pure-data

Link to the audio programming language / server they're using in the article: https://github.com/supercollider/supercollider

For the intrepid, especially those annoyed with the purported input-sluggishness of musescore et al, an interesting text-based alternative is LilyPond https://lilypond.org/

My dad wrote an opera using LilyPond in vim, though I believe these days he's actually doing more with supercollider, which skips sheetmusic and goes right to sounds: https://supercollider.github.io/

Weirdly enough,I got into programming through music. I got into making experimental electronic music and ended up learning SuperCollider. Figured I’d have to get a real job at some point and I liked learning Supercollider enough that I figured I should try to go back to school and learn some more useful programming languages

So you’re wondering what would making music with code look like? The tools I’m familiar with are TidalCycles, Sonic Pi, and SuperCollider. I’m having a hard time describing what it’s like to make music with tools like these so here’s a video of a performance. One person is live coding the music and the other is live coding the visuals. I think it’s super cool how the music is improvised and built over time by layering commands. Some keywords you could search to see more examples would be Algorave and Livecoding.

So far mostly Vim (not for coding, just writing so far), NetHack, Firefox, and mpd and ncmpcpp. Also mpv occasionally. I'm planning on installing SuperCollider at some point too and getting back into that, but that shouldn't be too heavy either.

I would say no there aren't any sample packs for this kind of stuff because this entire scene developed around using a samplers and sampling as well as some computer tools like Max/Msp, SuperCollider, Recycle, Cool Edit Pro and some other stuff I am quite likely forgetting at the moment. Also you might look at some of the IRCAM stuff too.

Sonic pi is basically a wrapper for the amazing language Supercollider (https://supercollider.github.io/). I highly recommend watching Eli Fieldsteel's excellent tutorials on it (https://www.youtube.com/watch?v=yRzsOOiJ_p4&list=PLPYzvS8A_rTaNDweXe6PX4CXSGq4iEWYC) to see some of what its capable of (I think he is almost a finished a new book on it as well).

Report bugs on the pd github https://github.com/pure-data/pure-data

You might be interested in clicking through the puredata source code.

https://github.com/pure-data/pure-data

> The other advantage is because these things were implemented in the 80s

Pd was developed in the mid 90s

> they are very computationally efficient

Not as efficient as it could be, though. For example, instead of proper SIMD instructions, the DSP perform routines only use manual loop unrolling, praying that the compiler will auto-vectorize it.

Finally, everything is single-threaded, leaving lots of performance on the table. FWIW, I have a PR for an asynchronous task API (https://github.com/pure-data/pure-data/pull/1357) and also a branch for multi-threaded DSP (https://github.com/Spacechild1/pure-data/tree/multi-threadin...).

> Any criticism or unwelcome suggestions are treated as an insult to Miller Puckette and the proponent is attacked, ignored, or advised to implement it themselves (ie to go away and not come back).

I don't think this holds for the general case, but there a certainly a few users caught up in Stockholm Syndrome :-) I can assure you that the developer team (which I am a part of) is very well aware of Pd's limitations and problems. Pd has seen quite significant UX improvements over the last few years, but the pace of development is very slow. Anyway, if you have specific criticism, suggestions or feature requests, feel free to open a ticket on GitHub: https://github.com/pure-data/pure-data.

As a side note, the minimalistic GUI itself won't change since it is an intentional design decision by Miller, but there is some effort to abstract the core/GUI communication to allow alternative GUI implementations. (Personally, I really dislike the current Tcl/Tk GUI - not because it's minimalistic, but because it's slow and buggy.)

> and idiosyncratic terminology (eg PD refers to module connectors as 'patch cords' just like on an analog modular synthesizer or mixer, but what synth people commonly call a pulse or a trigger is a 'bang' in PD).

Pd's 'bang' belongs to the control/event domain, you can't really compare it to trigger/pulse in modular synthesizers. (FWIW, there are several Pd externals that implement audio-rate triggers.)

> You can make it do anything, but unless you already have a very specific goals you will spend most of the time reinventing wheels in parameter space.

That's a fair point. It's important for people to understand that Pd vanilla is really a programming environment with only a minimal set of built-in objects that allow you to build higher-level abstractions. You definitely need a set of "abstractions" or libraries to be productive. Fortunately, there are many existing Pd libraries and they can be easily installed with Pd's package manager "Deken". The most extensive one is "ELSE" with nearly 500 objects, containing everything from band-limited ocillators, filters, sequencers, GUIs, etc. Personally, I have my own collection of abstractions that I made over the last years.

That being said, I would agree that you should always pick the right tool for the job. Just as you wouldn't write your website in C, you wouldn't pick Pd for typical EDM stuff (unless you have a very good reason). But for prototyping and experimental electronics it's a fantastic tool, I think.