pure-data VS glicol

> 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...).

FWIW, Pd and Max/MSP always had sample-level control in the sense that subpatches can be reblocked. For example, if you put a [block~ 1] object in a Pd subpatch, the process function will be called for every sample, so you can have single-sample feedback paths. Pd also has the [fexpr~] object which allows users to write FIR and IIR filters in a simple expression-syntax. Finally, Max/MSP offers the very powerful [gen~] object. You can check it out for inspiration (if you haven't already).

Pd (and Max/MSP) also allow to upsample/resample subpatches, which is important for minimizing aliasing (caused by certain kinds of processing, such as distortion).

Pd also uses the reblocking mechanism to implement FFT processing. The output of [rfft~] is just an ordinary signal that can be manipulated by the usual signal objects. You can also write the output to a table, manipulate it in the control domain with [bang~], and then read it back in the next DSP tick. IMO, this is a very powerful and elegant approach. SuperCollider, on the other hand, only supports a single global blocksize and samplerate which prevents temporary upsampling + anti-aliasing, severly limits single-sample feedback and leads to a rather awkward FFT implementation (you need dedicated PV_* objects for the most basic operations, such as addition and multiplication).

Another thing to think about is multi-threaded DSP. With Supernova, Tim Blechmann miraculously managed to retrofit multi-threading onto scsynth. Max/MSP offers some support for multi-threading (IIRC, top level patches and poly~ instances run in parallel). Recently, I have been working on adding multi-threading to Pd (it's working, but still very much experimental): https://github.com/Spacechild1/pure-data/tree/multi-threadin.... If you design an audio engine in 2022, multi-threading should be considered from the start; you don't have to implement it yet, but at least leave the door open to do it at a later stage.

---

I'm not sure how far you want to go with Glicol. I guess for the typical Algorave live coder all these things are probably not important. But if you want Glicol to be a flexible modern audio engine/library, you will have to think about FFT, upsampling, single-sample feedback, multi-processing etc. at some point. My advice is to not leave these things as an afterthought; you should at least think about it from the start while designing your engine - if you want to avoid some of the mistakes that other existing audio engines made. This is just a word of "warning" from someone having spent countless of hours in Pd and SuperCollider source code :-)

Great write up!

What I like about Pd is that you can freely reblock and resample any subpatch. Want some section with single-sample-feedback? Just put a [block~ 1]. You can also increase the blocksize. Usually, this is done for upsampling and FFT processing. Finally, reblocking can be nested, meaning that you can reblock to 1024 samples and inside have another subpatch running at 1 sample blocksize.

SuperCollider, on the other hand, has a fixed global blocksize and samplerate, which I think is one of its biggest limitations. (Needless to say, there are many things it does better than Pd!)

---

In the last few days I have been experimenting with adding multi-threading support to Pd (https://github.com/Spacechild1/pure-data/tree/multi-threadin...). With the usual blocksize of 64 sample, you can definitely observe the scheduling overhead in the CPU meter. If you have a few (heavy-weight) subpatches running in parallel, the overhead is neglible. But for [clone] with a high number of (light-weight) copies, the overhead becomes rather noticable. In my quick tests, reblocking to 256 samples already reduces the overhead significantly, at the cost of increased latency, of course.

---

Also, in my plugin host for Pd/Supercollider (https://git.iem.at/pd/vstplugin/) I have a multi-threading and bridging/sandboxing option. If the plugin itself is rather lightweight and the blocksize is small, the scheduling overhead becomes quite noticable. In Pd you can just put [vstplugin~] in a subpatch + [block~]. For the SuperCollider version I have added a "reblock" argument to process the plugin at a higher blocksize, at the cost of increased latency.

I've worked on Ambient Engine and now on the Bevy engine. I totally agree with these points, very valuable. I only make some comments from my professional (audio) perspective:

We need the highlight author's affirmation of cli. Rust's tui (ratatui) is great. I used it to make Glicol-cli [1]. If you are a Linux user, you are welcome to test the music production of the code.

Speaking of game audio, I actually think rust is perfect for audio. I have also continued to develop Glicol recently, and my recent goal (starting tomorrow) is the bevy_glicol plug-in. I want to solve bevy's audio problem on the browser.

All in all, even though I've had my share of pain with ecs, I still think rust is very valuable for game and app development, maybe not multiplayer AAA, maybe practical apps.

[1] https://github.com/glicol/glicol-cli

[2] https://github.com/chaosprint/glicol

Nice! Great project website styling and demo.

I had a WebGPU scope demo using vanila JS here, but it's not connected to AudioContext at all.

https://stackblitz.com/edit/vitejs-vite-cuc9vs

Still, I had to use the old WebGL solution for https://glicol.org since the WebGPU support seems to be pretty slow at the moment.

Suno is great and I already shared its potential back in v2. I have always believed that the essence of digital music is "organized numbers". I think what needs to be thought about is how to use AI in this process. If you look at the results (numbers) generated, then we are indeed very close. But there is another future I believe: I hope AI can compose music with me, like copilot. This is why I keep working on

https://glicol.org/

and the destination is:

https://github.com/chaosprint/RaveForce

Also want to hear your feedback.

Interesting!

Similar note-based expression can be found on TidalCycles/Strudel. although it's not valid MIDI format anymore, you can use notation like c4, f3, and make them as "pattern". Samples are also supported in the same manner:

https://strudel.cc/

And in my project Glicol, I use only numbers in the seq node. So 60 means middle C. Underscore means rest.

https://glicol.org/

I also applied with Glicol (https://glicol.org/) and got rejected, which is totally understandable. I am basically working this project on my own with almost zero extra funding.

I am currently working on a new website. The old stack is Vite, Svelte and Windi CSS (discontinued unfortunately). So this time maybe Astro + Solid + Tailwind.

And I am also trying to rewrite the whole Rust backend if possible, so there is quite some work to be done.

Let me know on GH or Discord if you are interested.

It's a good chance to try Rust, WASM, DSP, etc.

This is a really informative and inspiring article.

It hasn’t been 6 months (not 6 years) since I quit my full-time job as a Rust developer to start my own business.

As time goes by, I can feel the pressure of mortgage and car loans, and I can also feel the care and pressure of my family.

My original plan was to make an interface for Glicol (https://glicol.org), and to develop relevant hardware with firmware written in rust for school education.

I sent some cold emails to VCs, but most of them got no reply.

I also sent an email to the Norwegian Museum of Science and Technology, offering to perform for children for free, but they didn’t reply for two months. I shamelessly sent it again, and someone finally replied with a rejection.

Only one VC talked to me and thought that I should convince and validate a partner first, and he suggested that I go to an incubator.

Very good advice.

Later I learned that even Norwegian education startups skipped Norway and focused directly on the US market.

People from the incubator also told me that it is impossible for Norwegian schools to accept new things independently.

This is very enlightening to me because most of Glicol's visitors are indeed from the US. And it took me so long to discover this fact.

But if I don’t start, I’ll never get past those six months.

I picked up LOGO when I was 6 and leant Pascal and C later.

I didn't program for a few years because I wasn't interested in competitions. So I think interest is the most important, otherwise it will be easy to get lost and give up.

Later, I became very interested in programming, mainly because I came into contact with music technology.

I think since your child is interested in game development, it is a good choice to start step by step. For example, starting with threejs. I also recommend learning Rust and Bevy so you learn the underlying layers and ECS.

Last but not least, although it's not related to games dev but I sincerely invite you and your son to try Glicol (https://glicol.org), the project that I am developing.

I quite my job as well to work on

https://glicol.org

I have a lot of feelings, but I don't have a blog so far. But one of my feelings is that universities should alloc some of their funding to many of these open source projects and open source community should be better managed rather than donation. My plan is to start my own company and work on hardware .