I'm a big fan of Glicol, my main issue with it is the lack of documentation. There's some great getting started guides, but beyond that not too much (for example, an example for glicol-cli is provided using the built in BD drum, but I can't find any reference for all drums available).
As I say, it's otherwise perfect for me, it's sound design capabilities are really fantastic
There are indeed some similarities. I was influenced by SuperCollider (SC). One of my master's graduation projects was a system based on SC: https://github.com/chaosprint/Packing. Both SC and Glicol are written in low-level languages—SC in C++ and Glicol in Rust. Inspired by SC's reusable scsynth, I created glicol_synth as an independent audio library.
However, their syntax differs greatly. Glicol's syntax is designed for live coding, prioritizing simplicity and readability and it's actually partially inspired by modular synth(for example: https://glicol.org/demo#minitechno and https://glicol.org/tour#fm), while SC's syntax inherits from Smalltalk, adhering to standard OOP. SC's ecosystem is mature, offering GUI development, various sound processing methods, and robust multi-channel support. In contrast, Glicol's sound processing is still very minimal and experimental. Once the basic architecture, like multi-channel and audio graph handling, is established, adding sound processing modules will be linear.
Additionally, Glicol's support for both browser and CLI is a highlight.
This is likely to be personal incompatibility with Roland’s style, but I’ve always found Roland user interface designs to be inscrutable banks of deep menus, arbitrary buttons, tiny screens, and “wizard” style branching between wholly disparate aesthetic presets that change everything at once. I have never been able to intuit and memorize Roland gear well enough to customize according to my own mental models. The idea that anything Roland would be held aloft as “well thought out” by somebody is baffling to me.
Roland’s popularity and success speaks for itself so there’s no need to prove anything. Their UIs are just completely at odds with my personal creative flow.
Back in the late 90s I mixed an entire album on a VS-880 (with good results, it sold a couple thousand copies and got decent college radio airplay) so I’ve definitely given them a chance and gotten the full experience — but that damn thing fought me relentlessly. None of the motions I learned stuck with me.
I feel the same way about a lot of hardware electronic gear (I was utterly defeated by an Akai sampler around the same time). The exceptions are the interfaces that hew to a consistent theoretical model and emphasize tweaking of individual parameters rather than selection of presets. I was highly productive within the Logic Audio environment; I had good impressions of the Nord Modular and its GUI software.
Any Roland-style modeling of modular synthesis is likely to leave me behind. Glad it works for you and many others, though!
The new Roland technical strategy does not speak to me either.
The book is from Roland’s 100M modular system and written in the late 1970’s or early 80’s. That version of the System 100 was menuless, entirely analog, and patched with some basic normals and wires. I came across the book because my Eurorack is mostly Behringer System 100 modules because they are cheap as am I.
===
I picked up a VS880 for about $100 last year and use it as my primary multitrack recorder because I prefer not to use general purpose computers for creative work anymore and it’s a hobby. I have a ZuluSCSI plugged into the back and record to an SD card on that.
This year, I made a commitment to learn how to use it…not much point in selling it…and do more recording. What I like about it is not the menus. It’s that being the first in the series, the design brief seems to have been a better tape machine and alternative to ADAT. Later models were competing with DAWs.
Because the VS880 is fanless, I can leave it on all day while I do other things (e.g. take a nap). Of course it works for me because my musical ambitions are very unambitious.
> I’ve always found Roland user interface designs to be inscrutable banks of deep menus, arbitrary buttons, tiny screens, and “wizard” style branching between wholly disparate aesthetic presets
This also describes the Akai MPC world.
I suspect it describes any system that has accumulated sufficient lineage to always be in tension between new features, existing technology, standard practice and legacy user expectations.
Synthesizer manufacturers are expert at repackaging modules, hardware and software - their business model can't handle the costs of blank slate development for each new product... Baffling UX often results.
this is why I like Arturia gear. It's simple but you can play live music on it without having to dive into a menu on anything. Even if I'm not using their instruments I dont think I'll ever be able to get away from the keystep.
Even classical music has a similar 'problem'... performances of the 'same' work can be very different. (And I'm sure that would be true even if the same instruments and same musicians are used.) Most of the differences come from different conductors/ensembles. (Orchestas also have 'traditional performances' that they'd rather cling to, and may resist conductors (often younger ones) who attempt any 'wild-haired' differences.)
Music's very fluid. Recordings of performances are probably as close to 'same' as we can get. Non-musicians may prefer to listen to these 'same' performances over and over for the 'fidelity' of their experiences. But it might stop them (as they age) from discovering better ones.
If MIDI is used to create the dynamics, 'patches' and all other modulations, oscillations, tempos, et.al of a synth or ten, then something close to 'same' might be approachable. But that means, oh, say, ten times as much work.
Depends on the listener whether that's a good thing. In my experience, a superior cover of a single recording (same or different singer, different producer) can turn a OK single into a damn! single.
When designing a notation, you're choosing what parts of a work you consider to be essential (notated) and non-essential (non-notated). That is itself an artistic choice. Everything you choose to not represent in the notation is something that you are letting future performers or cover artists choose for themselves.
The notation serves as sort of a negotiated dividing line between what the original artist wants to claim for themselves and consider a required part of "the work" versus what future artists are allowed to participate in.
Given that modular music is rarely played by anyone except the original author, I suspect that standardized notation isn't very important. All that really matters is each author having their own private shorthand so they can recreate what they care to recreate.
This seems like a somewhat solved problem. Other domains - like CGI - use node networks that show active parameter values. There isn't a lot of space between a node network and a modular synth patch.
The big difference is that you can save and load patches in a node editor, but you have to rebuild everything by hand on a modular. Even then you're never going to reproduce panel settings exactly.
Some people find this appealing, but for me it's the main reason I stopped using my big modular and changed to Cherry/Softtube/VCV Rack.
It's also true that if you're synth-literate you should be able to recreate many patches by ear. There isn't usually that much going on, so it looks a lot more complex on paper than it really is. Things get more complex if you're using modules that play samples or do something exceptionally unique, but even then you can usually get in the ballpark - if not exactly, then close enough for something that works aesthetically.
The musical part is a different problem. You can scribble graphic scores, but they're far too crude to represent anything beyond the vaguest hint of what's going on.
Notated organ music has had the "modular synthesizer" problem for centuries. The solution that organists chose was to just write stuff down in front of the score. It would probably be a lot more clear than any of the suggestions in the article to use a node network and a short text description of the settings of each node.
People also need to let go of the idea that written music is about conveying how to create an exact reproduction of the original sound. That's what a recording is for. A musical score conveys the scheme under which to produce sound, and notates the important characteristics of the sound to produce. Everything else is intentionally left up to the performer.
If you don't believe that is valuable, you don't need to use it as a tool. However, it allows future musicians to both understand what you were thinking and put their own spin on your work.
I attempted to write a program once to solve for how annoying it can be to notate modular patches.
It's essentially a small DSL that can produce graphviz charts of patches. There have been other attempts to do this kind of thing, but they rely on the writer to describe their modules, which makes it quite tedious. I wanted to have a 'library' format that would allow people to specific module interfaces once, and then they could be imported.
I got a basic prototype working in Perl if anyone is interested, but never got around to really polishing it up and writing a bunch of 'libraries' for different modules.
Interesting problem to think about. The beauty of modular for me has always been that you can take voltage from literally anywhere and use it for CV. Modern modules also have an insane variety in controls and control surfaces, even for standard things like VCOs you have a ton of variety and featuresets. Saving the patch state is one thing but actually notating is crazy. Like I can't imagine someone being able to read this notation and play it accurately like someone sight reading a piano piece. You'd surely require familiarity with the setup ahead of time. As for recording it for posterity, being verbose and describing what you're doing in full works, I guess.
Didn't pd basically borrow spice's circuit layout language for the way it textually stores patches? I know it exists and it's so brittle that nobody ever, ever, edits it, but maybe there's a way to make it a little more resilient and editable?
A textual notation for rich and generic graphs can only become more "resilient and editable" by giving nice names to entities and by keeping documents small and hierarchical.
I’m both fascinated by notation attempts for modular, and find them refreshingly useless.
I’ve been playing with modular synths for over 25 years. One of my favorite parts is the ephemeral nature of patching. A bump of a knob or the nature of unsynced elements can quickly make actual recall of a larger patch impossible. Due to heat or other variability I’ve had patches change on me over 45 minutes of no one touching them. In a world of digital recall and perfection; this really speaks to me. Immediacy can be relished. It is now or never
I saw Morton Subotnik at my college and he spoke of phase shift due to heating of poorly design VCOs in a serendipitous way rather than something to be feared.
just pretend PCM is notation and that’s that. problem solved
the new problem introduced, however, is that now a “musician” (interpreter) is just a wav player
and a musician creator (singer songwriter, or composer, or producer of some sort) must choose zero or one way too many times in order to “write” one track.
Readit News
For example, in this article, he discusses algorithms as "Algorithms as Scores" (https://cris.brighton.ac.uk/ws/portalfiles/portal/268697/Mag...).
These concepts have profoundly influenced my creation of Glicol (https://glicol.org/).
As I say, it's otherwise perfect for me, it's sound design capabilities are really fantastic
However, their syntax differs greatly. Glicol's syntax is designed for live coding, prioritizing simplicity and readability and it's actually partially inspired by modular synth(for example: https://glicol.org/demo#minitechno and https://glicol.org/tour#fm), while SC's syntax inherits from Smalltalk, adhering to standard OOP. SC's ecosystem is mature, offering GUI development, various sound processing methods, and robust multi-channel support. In contrast, Glicol's sound processing is still very minimal and experimental. Once the basic architecture, like multi-channel and audio graph handling, is established, adding sound processing modules will be linear.
Additionally, Glicol's support for both browser and CLI is a highlight.
https://reaktorplayer.wordpress.com/wp-content/uploads/2018/...
Roland’s popularity and success speaks for itself so there’s no need to prove anything. Their UIs are just completely at odds with my personal creative flow.
Back in the late 90s I mixed an entire album on a VS-880 (with good results, it sold a couple thousand copies and got decent college radio airplay) so I’ve definitely given them a chance and gotten the full experience — but that damn thing fought me relentlessly. None of the motions I learned stuck with me.
I feel the same way about a lot of hardware electronic gear (I was utterly defeated by an Akai sampler around the same time). The exceptions are the interfaces that hew to a consistent theoretical model and emphasize tweaking of individual parameters rather than selection of presets. I was highly productive within the Logic Audio environment; I had good impressions of the Nord Modular and its GUI software.
Any Roland-style modeling of modular synthesis is likely to leave me behind. Glad it works for you and many others, though!
The book is from Roland’s 100M modular system and written in the late 1970’s or early 80’s. That version of the System 100 was menuless, entirely analog, and patched with some basic normals and wires. I came across the book because my Eurorack is mostly Behringer System 100 modules because they are cheap as am I.
===
I picked up a VS880 for about $100 last year and use it as my primary multitrack recorder because I prefer not to use general purpose computers for creative work anymore and it’s a hobby. I have a ZuluSCSI plugged into the back and record to an SD card on that.
This year, I made a commitment to learn how to use it…not much point in selling it…and do more recording. What I like about it is not the menus. It’s that being the first in the series, the design brief seems to have been a better tape machine and alternative to ADAT. Later models were competing with DAWs.
Because the VS880 is fanless, I can leave it on all day while I do other things (e.g. take a nap). Of course it works for me because my musical ambitions are very unambitious.
After the D50 - and especially after the DX7, which started the one-slider-panel 80s trend - synth interfaces started to sprout two-line LCD panels.
Most Roland UIs today are pretty horrific.
This also describes the Akai MPC world.
I suspect it describes any system that has accumulated sufficient lineage to always be in tension between new features, existing technology, standard practice and legacy user expectations.
Synthesizer manufacturers are expert at repackaging modules, hardware and software - their business model can't handle the costs of blank slate development for each new product... Baffling UX often results.
Music's very fluid. Recordings of performances are probably as close to 'same' as we can get. Non-musicians may prefer to listen to these 'same' performances over and over for the 'fidelity' of their experiences. But it might stop them (as they age) from discovering better ones.
If MIDI is used to create the dynamics, 'patches' and all other modulations, oscillations, tempos, et.al of a synth or ten, then something close to 'same' might be approachable. But that means, oh, say, ten times as much work.
Depends on the listener whether that's a good thing. In my experience, a superior cover of a single recording (same or different singer, different producer) can turn a OK single into a damn! single.
Edit: (Case in point: 'Major Tom (Coming Home)' 1983 version: https://www.youtube.com/watch?v=wO0A0XcWy88 )
When designing a notation, you're choosing what parts of a work you consider to be essential (notated) and non-essential (non-notated). That is itself an artistic choice. Everything you choose to not represent in the notation is something that you are letting future performers or cover artists choose for themselves.
The notation serves as sort of a negotiated dividing line between what the original artist wants to claim for themselves and consider a required part of "the work" versus what future artists are allowed to participate in.
Given that modular music is rarely played by anyone except the original author, I suspect that standardized notation isn't very important. All that really matters is each author having their own private shorthand so they can recreate what they care to recreate.
The big difference is that you can save and load patches in a node editor, but you have to rebuild everything by hand on a modular. Even then you're never going to reproduce panel settings exactly.
Some people find this appealing, but for me it's the main reason I stopped using my big modular and changed to Cherry/Softtube/VCV Rack.
It's also true that if you're synth-literate you should be able to recreate many patches by ear. There isn't usually that much going on, so it looks a lot more complex on paper than it really is. Things get more complex if you're using modules that play samples or do something exceptionally unique, but even then you can usually get in the ballpark - if not exactly, then close enough for something that works aesthetically.
The musical part is a different problem. You can scribble graphic scores, but they're far too crude to represent anything beyond the vaguest hint of what's going on.
People also need to let go of the idea that written music is about conveying how to create an exact reproduction of the original sound. That's what a recording is for. A musical score conveys the scheme under which to produce sound, and notates the important characteristics of the sound to produce. Everything else is intentionally left up to the performer.
If you don't believe that is valuable, you don't need to use it as a tool. However, it allows future musicians to both understand what you were thinking and put their own spin on your work.
It's essentially a small DSL that can produce graphviz charts of patches. There have been other attempts to do this kind of thing, but they rely on the writer to describe their modules, which makes it quite tedious. I wanted to have a 'library' format that would allow people to specific module interfaces once, and then they could be imported.
I got a basic prototype working in Perl if anyone is interested, but never got around to really polishing it up and writing a bunch of 'libraries' for different modules.
https://git.spwbk.site/swatson/modmark
Interested if anyone knows of / has written something better.
I’ve been playing with modular synths for over 25 years. One of my favorite parts is the ephemeral nature of patching. A bump of a knob or the nature of unsynced elements can quickly make actual recall of a larger patch impossible. Due to heat or other variability I’ve had patches change on me over 45 minutes of no one touching them. In a world of digital recall and perfection; this really speaks to me. Immediacy can be relished. It is now or never
Deleted Comment
just pretend PCM is notation and that’s that. problem solved
the new problem introduced, however, is that now a “musician” (interpreter) is just a wav player
and a musician creator (singer songwriter, or composer, or producer of some sort) must choose zero or one way too many times in order to “write” one track.