glicol VS supercollider

Note: Nick Collins and Alex McLean created Algorave. The time I spent learning from the Algorave community was crucial to my later work on Glicol (https://glicol.org/).

Btw, I have a feeling that if you want to learn about computer music, you can send the PDF to LLM and ask what the chapter is about and how to represent it using csound or supercollider.

My experience is that with computer music, you have to keep experimenting and listening in order to truly understand and innovate.

This is a cool project, but it seems like it hasn't been updated in a long time?

It seems like https://github.com/chaosprint/glicol has a similar problem.

I'm rewriting glicol (https://glicol.org/) with no std, and embassy-rs + 2350 is my go-to choice. Highly recommand this stack if you're planning to start working with embedded systems in 2026.

Relevant to this discussion - my project Glicol (https://glicol.org) addresses this space. Currently working on a no_std rewrite, demo coming next year :)

Some simple thoughts:

I feel that one challenge of programming languages is how to remember these rules, formats, and keywords. Even if you're using familiar formats like YAML or JSON, how do you match keywords?

When developing Glicol (http://glicol.org/), I found that if it's based on an audio graph, all node inputs and outputs are all signals, which at least reduces the matching problems. The remaining challenge is ensuring that reference documentation is available at the minimal cost.

Great finish. I was busy designing and soldering the prototype synthesizer during the summer, but I had to put it on hold because my baby was born in September.

I had the same problem back then: injection molding is quite expensive to start. But you could consider a more creative approach: using a PCB directly as the panel, such as a TE's Pocket Operator. Alternatively, you could use 3D printing; there are many inexpensive services in China. CNC doesn't have the mold-making issue, but it's more expensive and doesn't seem suitable for children.

Another interesting point: after my child was born, I didn't have much time for my sound work. But recently, I was surprised to find that I spend most of my time playing white noise on Glicol (http://glicol.org/).

```

"

when you have more and more interactions on the gui web audio api will become a problem, check out audioworklet.

I am developing https://glicol.org/ and it has a js port on https://glicol.js.org/ a typical usecase is drum machine with very high time accuracy

love the wav download option

I tried to create a tone in Glicol (https://glicol.org/) with some random idea there and it works quite well:

```

renoise is super cool.

if you're interested in live coding, you might also want to check out Glicol (https://glicol.org).

Its parser and audio engine are also implemented purely in Rust, and it supports declarative, dynamic updates. A no_std version for embedded systems is also in development.

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.