In addition to being easier to write larger works, supercollider also seems a lot easier to understand your work a few months later. However, the learning curve for supercollider for me was actually pretty steep. If I'm honest, it took me several attempts spread over multiple years to finally feel somewhat comfortable in it, despite (or perhaps because of...) having plenty of programming experience in "somewhat similar" languages like python and c++. Nowadays, I guess the situation has improved by having many high-quality tutorials online and with the helpful forum, but when I started I distinctly remember having to overcome a lot of discomfort.
It would be good if a future SC could reduce some of the discomfort. It's hard for me to contribute to that, though, because I didn't experience that at all... for me the language syntax and operation was mainly "Oh, OK, that's how SC does this." I'm really not sure why my experience was different... e.g. I see many users struggle with groups, buses, node order etc, but I saw pretty quickly how to organize them into a DAW-style mixing framework (after which, I could ignore the billions and billions of possible wrong ways to use buses etc). There are still design mistakes in some of my early classes though. At the same time, between starting to learn SC and giving a really solid performance (that wasn't constantly on the verge of crashing and burning) was a couple of years. At the same time, if I went out today to buy a saxophone, I wouldn't book a gig for only a couple months later either...
@@jamesharkins4272 Syntax was never a huge problem (apart from the order of execution of mathematical operations...), but I lacked a clear mental model of what is server side and what is language side, especially because both things can be written in the same .scd file in almost the same syntax. But you quickly hit "why does "if" not work in a synthdef" etc... I think once that mist disappeared, the rest was no big deal.
Interesting video, thanks. When I first saw the supercollider code, it seemed terribly complicated and I spent most of my time (at the beginning) just copying lines from other synthdefs and scratching my head. Now it seems like riding a bike, so straight forward, easy and all so obvious. Somehow it seemed the most complicated to learn, but the fastest to master and certainly, now, is the most satisfying to code. My uploaded videos are also a testament to the capability and power of supercollider. I think even if supercollider had been slower in this race, I would still prefer it, because it all makes so much sense at a glance.
After a year or so of using SuperCollider and loving it, I still don't feel comfortable with the SC's client language. I just don't really like it. Luckily SC comes with all sorts of client bindings for regular programming languages one can use it with: Python, Lisp, Clojure, Lua... anything really. An ability to bind it with a real programming language is a huge benefit of SC. It also solves this OSC back and forth issue that was mentioned in the video. I just process the incoming OSC/MIDI on the client side with a library for the language of choise.
I use pd, somewhat happy about it, but the real time-saver is in the extensions (else, zexy & more), so that ADSR / file-player etc. are already written for you.
Sure, pre-built envelope and recorder would shave off some of the difference. Still, there's a difference in philosophy between the tools: Pd "you can build things that you will need often" vs SC "here's a bunch of things that are easy out-of-the-box" (like one-click recording of the main out). The one that might be easy to overlook, though, is the randomized detuning. In SC, I write: var n = 5; var sig = Saw.ar(freq * Array.fill(n, { detun ** Rand(-1, 1) })).sum; ... which I can type in less than 20 seconds (and if I want to change the number of detunings, I just change n and reevaluate the block). In Pd: Rand(-1, 1) is floating point, so I have to simulate it by [random] with a large integer, then divide and subtract to get the bipolar normalized range. Minimum, say, 1 [random 1e+06] and 1 [expr pow(1.008, $f1 / 500000 - 1)], vs 11 characters. (The CEAMMC library has floating-point RNGs, but I can't find a compiled external for Linux, so, not helpful to me.) For the array, I can either copy/paste the detune+oscillator stack and manually wire up the copies (tutorials that do this make me cringe), *or* put one detuned oscillator into an abstraction and [clone] it (which I did in the video). I like the flexibility of [clone] but neither of these is as quick as typing SC's automatic multichannel expansion (the array of detune factors causes both '*' and 'Saw' to expand). To recall one of the points from the video, the more physically difficult an idea is to realize, the less likely that you will attempt it. For another example, in my libraries, I have functions that do a tree search over a set of diatonic intervals to find the arrangement of those intervals, starting from a given top note, that will be the most consonant over a given bass note. In SC, this is fairly straightforward because it's easy to manipulate arrays without overwriting prior copies. In Pd, it would require either data structures (which nobody understands) or some difficult patching around [text], and backtracking recursion is a lot harder in an environment that doesn't keep function-scope frames for you... so it hasn't been worth it to me to try. So this ends up being, for me, a creative limitation of Pd -- something musically important to me that is out of reach in the tool.
this very much mirrors my own experiences, having built some pretty complex systems in both SC and Pd. on the subject of things adding up, it would be interesting to tally up how much time on the Pd side goes into pixel-hunting to get those wires to connect 😄
Thank you for this wonderful comparison! I'm a little puzzled by the "Waiting" written again and again and the waiting time you talked about with SuperCollider. Is that compilation of the code or...? Yes, I'm a newbie.
Pure Data working practise (culture?) tends toward using lots of low level tools, and repetition, at least in the examples I've seen. Whilst you certainly compare PD vs SC (and SC was a clear winner), I'm not sure this was a Graphical vs Textual issue. It was noticeable to me that the elements you were using in SC were MUCH higher level (e.g. an envelope with exponential curves as an option). PD sub-patches at an equivalent level could readily be made and used. (But they seem not to be)
That's a fair comment up to a point -- the further observation, though, is that SC provides these higher-level resources out of the box. You can build an envelope generator in Pd with exponentially-mapped segments -- but in Pd, if you want this, you HAVE to build it (or find an external/abstraction); in SC, it's just there. While I understand the reasoning behind Pd's minimal-core philosophy, it does make it harder to just get where you're going, quickly.
@@jamesharkins4272 Yes. But the low-level vs high-level differences are swamping any realistic chance of actually doing a fair "graphical vs textual" comparison (which would be interesting).
@@paulwomack5866 I do hear what you're saying, but it might be impossible to do a really fair comparison -- because the problem spaces that are optimally handled in code are quite different from the problem spaces optimally handled in patching. I would argue that the problem spaces suited to patching are (significantly?) smaller than those suited to code: offhand, reactive programming based on device input ([ctlin] --> math objects --> synth parameter is more intuitive than SC's callbacks), and DSP graphs *excluding* multichannel expansion (I have to admit that exposure to MSP and Pd made it much easier for me to understand what is happening in SC SynthDefs). If I did a demo of "connect a MIDI controller to filter frequency," it would be instantly understandable in Pd and more awkward in SC. Classical algorithms are unbearably clumsy to realize in patchers (I have implemented a classical heap in Pd vanilla -- only once I saw someone did a quicksort in Pd but that broke my brain). Even moderately complex math expressions can be head-scratchers in patching, whereas in C/Java/Python/SC, you just write them. Not surprisingly, computer science has largely ignored patching -- because patching is terrible at the things computer science is interested in... which is why, if you're looking for interesting algorithmic composition in Max, probably there are code-based externals driving them, because nobody is going to try to do a tree-searching constraint solver, for instance, in pure Max objects. You'd shoot yourself first. So one question is, what percent of the project is DSP (good for patching) and what percent is compositional logic (bad for patching)? Now, I did catch wind of a multichannel feature being prepared for the next Pd release. That would make parts of this video obsolete.
pd also has a nice and not quite known 'fast-forward' message you can use to batch record (render) sounds, see else/batch.rec~, is there something like it in SC?
I've been curious about max and pd for a long time, but I already know sc and it just seems like so much work to learn a new graphical system. Maybe that's not a typical experience... ;D
One factor was that I needed graphics for a course, and it seemed better to have everything in one paradigm (rather than "here's SuperCollider... now here's Processing." I wouldn't recommend learning Max "just because" if you're already working in SC
MY only issue with SC is this appears to be the most complicated way to make music we have ever conceived. Like it is just so overly complicated. In comparison I can jump on a DAW and just start making music that probably sounds better with a VST. One way it may surprise me is if it can capsulate this idea of mine that most natural sounds embody more than the one behavior you find in terms of ASDR.
It depends on what you're trying to do. I was just telling a colleague, I like "non-repeating repetition" -- seems like minimalism but not actually literally repeating. SuperCollider's pattern library is a *great* way to do this. If you're interested in fixed media and you get your hands into every note, that's great, use a DAW. I don't like pushing blocks around on a screen; I would rather use code. BTW I can "jump on [my live coding system]" and have a basic beat going in about 5 minutes.
I’m totally okay with pure data, because I’ve already got the commands down, and i plan things that I need beforehand. I’ve tried supercollider, and it took so long for me to do anything.
Admittedly here I chose a best-case for SC and worst-case for Pd. It's all YMMV -- actually I teach with Pd because students whose first language isn't English seem to struggle less when some of the logic is expressed graphically rather than using English keywords. But I've got logic in my SC live setup that would take a really unpleasant amount of time to rebuild in Pd, which was approachable in SC.
That's Ubuntu Studio 20.04, which ships with XFCE 4.something. Recently installed Ubuntu Studio 22.04 on a new laptop, which uses KDE Plasma 5.24 instead... which is beautiful but also occasionally unstable. I am not sure it was a good decision for them to switch desktops, but it seems the Ubuntu Studio team is unreachable (they don't even answer mailing list messages... remember mailing list?) so there is no way to give feedback...
Hi, I'm programming in Pd for some time now and tried learning Supercollider for two times with not much progress. A bit of a rant below. I think Pd's simplicity is at the same time its best and worst thing, it makes sense with its philosophy, Pd vanilla is supposed to be a low level language for music, to give you only the essentials to build what you want without bias towards a specific style of music, it's kept small by design. It becomes a little more fluid and personalized overtime when you start growing your own library of objects and patches, some of the things you build is this video you only need to build one time. But gosh, it's annoying to make logic with [bang] [f] [+ 1] [mod] [sel] [moses] etc... it feels like a start from almost nothing, too much work. I think Pd's philosophy of being this low level language for music is the main reason it takes more work, not because it's graphical. It is my go to when I have a musical idea very specific I want to realize, but I'm also a bit tired of it at the same time, it feels like solving mental puzzles all the time to make it do something.
You've put your finger on it -- to write a counting loop in Pd is at least 5 boxes and 4 connections (with multiple hand moves between mouse and keyboard, this REALLY slows you down) where in SC it's "number.do { |i| ... }` and *no* hand moves away from the keyboard. Sometimes I suspect that Max/Pd users might shy away from some kinds of complexity because it's just too slow to build graphically. (But, Max/Pd may also be very successful for users who don't need high complexity.)
FWIW I teach using Pd for this reason. But... it's a bit of an exaggeration but I sometimes see Pd vs SC as a tricycle vs a 21-speed touring bike. You can get on a tricycle and ride it pretty much right away, but top speed is limited. The bike can go fast! But you will fall down while learning to ride it.
In addition to being easier to write larger works, supercollider also seems a lot easier to understand your work a few months later. However, the learning curve for supercollider for me was actually pretty steep. If I'm honest, it took me several attempts spread over multiple years to finally feel somewhat comfortable in it, despite (or perhaps because of...) having plenty of programming experience in "somewhat similar" languages like python and c++. Nowadays, I guess the situation has improved by having many high-quality tutorials online and with the helpful forum, but when I started I distinctly remember having to overcome a lot of discomfort.
It would be good if a future SC could reduce some of the discomfort. It's hard for me to contribute to that, though, because I didn't experience that at all... for me the language syntax and operation was mainly "Oh, OK, that's how SC does this." I'm really not sure why my experience was different... e.g. I see many users struggle with groups, buses, node order etc, but I saw pretty quickly how to organize them into a DAW-style mixing framework (after which, I could ignore the billions and billions of possible wrong ways to use buses etc). There are still design mistakes in some of my early classes though.
At the same time, between starting to learn SC and giving a really solid performance (that wasn't constantly on the verge of crashing and burning) was a couple of years. At the same time, if I went out today to buy a saxophone, I wouldn't book a gig for only a couple months later either...
@@jamesharkins4272 Syntax was never a huge problem (apart from the order of execution of mathematical operations...), but I lacked a clear mental model of what is server side and what is language side, especially because both things can be written in the same .scd file in almost the same syntax. But you quickly hit "why does "if" not work in a synthdef" etc... I think once that mist disappeared, the rest was no big deal.
Such a great comparison. Thanks for taking the time!
From a user friendliness perspective i think that Sonic Pi is a good way to get someone acclimated with musical live coding
Interesting video, thanks.
When I first saw the supercollider code, it seemed terribly complicated and I spent most of my time (at the beginning) just copying lines from other synthdefs and scratching my head. Now it seems like riding a bike, so straight forward, easy and all so obvious. Somehow it seemed the most complicated to learn, but the fastest to master and certainly, now, is the most satisfying to code. My uploaded videos are also a testament to the capability and power of supercollider.
I think even if supercollider had been slower in this race, I would still prefer it, because it all makes so much sense at a glance.
After a year or so of using SuperCollider and loving it, I still don't feel comfortable with the SC's client language. I just don't really like it. Luckily SC comes with all sorts of client bindings for regular programming languages one can use it with: Python, Lisp, Clojure, Lua... anything really. An ability to bind it with a real programming language is a huge benefit of SC. It also solves this OSC back and forth issue that was mentioned in the video. I just process the incoming OSC/MIDI on the client side with a library for the language of choise.
I use pd, somewhat happy about it, but the real time-saver is in the extensions (else, zexy & more), so that ADSR / file-player etc. are already written for you.
Sure, pre-built envelope and recorder would shave off some of the difference. Still, there's a difference in philosophy between the tools: Pd "you can build things that you will need often" vs SC "here's a bunch of things that are easy out-of-the-box" (like one-click recording of the main out).
The one that might be easy to overlook, though, is the randomized detuning. In SC, I write:
var n = 5;
var sig = Saw.ar(freq * Array.fill(n, { detun ** Rand(-1, 1) })).sum;
... which I can type in less than 20 seconds (and if I want to change the number of detunings, I just change n and reevaluate the block).
In Pd: Rand(-1, 1) is floating point, so I have to simulate it by [random] with a large integer, then divide and subtract to get the bipolar normalized range. Minimum, say, 1 [random 1e+06] and 1 [expr pow(1.008, $f1 / 500000 - 1)], vs 11 characters. (The CEAMMC library has floating-point RNGs, but I can't find a compiled external for Linux, so, not helpful to me.)
For the array, I can either copy/paste the detune+oscillator stack and manually wire up the copies (tutorials that do this make me cringe), *or* put one detuned oscillator into an abstraction and [clone] it (which I did in the video). I like the flexibility of [clone] but neither of these is as quick as typing SC's automatic multichannel expansion (the array of detune factors causes both '*' and 'Saw' to expand).
To recall one of the points from the video, the more physically difficult an idea is to realize, the less likely that you will attempt it. For another example, in my libraries, I have functions that do a tree search over a set of diatonic intervals to find the arrangement of those intervals, starting from a given top note, that will be the most consonant over a given bass note. In SC, this is fairly straightforward because it's easy to manipulate arrays without overwriting prior copies. In Pd, it would require either data structures (which nobody understands) or some difficult patching around [text], and backtracking recursion is a lot harder in an environment that doesn't keep function-scope frames for you... so it hasn't been worth it to me to try. So this ends up being, for me, a creative limitation of Pd -- something musically important to me that is out of reach in the tool.
I stole a bunch of things from SC into else :) and can still do that more ;)
btw, there are already mutichannel aware objects in else for oscillators, adsr~ and more, plus more to come
this very much mirrors my own experiences, having built some pretty complex systems in both SC and Pd. on the subject of things adding up, it would be interesting to tally up how much time on the Pd side goes into pixel-hunting to get those wires to connect 😄
Thank you for this wonderful comparison! I'm a little puzzled by the "Waiting" written again and again and the waiting time you talked about with SuperCollider. Is that compilation of the code or...? Yes, I'm a newbie.
Pure Data working practise (culture?) tends toward using lots of low level tools, and repetition, at least in the examples I've seen.
Whilst you certainly compare PD vs SC (and SC was a clear winner), I'm not sure this was a Graphical vs Textual issue.
It was noticeable to me that the elements you were using in SC were MUCH higher level (e.g. an envelope with exponential curves as an option).
PD sub-patches at an equivalent level could readily be made and used. (But they seem not to be)
That's a fair comment up to a point -- the further observation, though, is that SC provides these higher-level resources out of the box. You can build an envelope generator in Pd with exponentially-mapped segments -- but in Pd, if you want this, you HAVE to build it (or find an external/abstraction); in SC, it's just there. While I understand the reasoning behind Pd's minimal-core philosophy, it does make it harder to just get where you're going, quickly.
@@jamesharkins4272 Yes. But the low-level vs high-level differences are swamping any realistic chance of actually doing a fair "graphical vs textual" comparison (which would be interesting).
@@paulwomack5866 I do hear what you're saying, but it might be impossible to do a really fair comparison -- because the problem spaces that are optimally handled in code are quite different from the problem spaces optimally handled in patching. I would argue that the problem spaces suited to patching are (significantly?) smaller than those suited to code: offhand, reactive programming based on device input ([ctlin] --> math objects --> synth parameter is more intuitive than SC's callbacks), and DSP graphs *excluding* multichannel expansion (I have to admit that exposure to MSP and Pd made it much easier for me to understand what is happening in SC SynthDefs).
If I did a demo of "connect a MIDI controller to filter frequency," it would be instantly understandable in Pd and more awkward in SC.
Classical algorithms are unbearably clumsy to realize in patchers (I have implemented a classical heap in Pd vanilla -- only once I saw someone did a quicksort in Pd but that broke my brain). Even moderately complex math expressions can be head-scratchers in patching, whereas in C/Java/Python/SC, you just write them. Not surprisingly, computer science has largely ignored patching -- because patching is terrible at the things computer science is interested in... which is why, if you're looking for interesting algorithmic composition in Max, probably there are code-based externals driving them, because nobody is going to try to do a tree-searching constraint solver, for instance, in pure Max objects. You'd shoot yourself first.
So one question is, what percent of the project is DSP (good for patching) and what percent is compositional logic (bad for patching)?
Now, I did catch wind of a multichannel feature being prepared for the next Pd release. That would make parts of this video obsolete.
multichannel connection in Pd now offers a nice and easier way to manage polyphony as well
Last time I checked, mc in Pd didn't extend to oscillators or filters...? Maybe that's changed.
pd also has a nice and not quite known 'fast-forward' message you can use to batch record (render) sounds, see else/batch.rec~, is there something like it in SC?
I've been curious about max and pd for a long time, but I already know sc and it just seems like so much work to learn a new graphical system. Maybe that's not a typical experience... ;D
One factor was that I needed graphics for a course, and it seemed better to have everything in one paradigm (rather than "here's SuperCollider... now here's Processing." I wouldn't recommend learning Max "just because" if you're already working in SC
MY only issue with SC is this appears to be the most complicated way to make music we have ever conceived. Like it is just so overly complicated. In comparison I can jump on a DAW and just start making music that probably sounds better with a VST. One way it may surprise me is if it can capsulate this idea of mine that most natural sounds embody more than the one behavior you find in terms of ASDR.
It depends on what you're trying to do. I was just telling a colleague, I like "non-repeating repetition" -- seems like minimalism but not actually literally repeating. SuperCollider's pattern library is a *great* way to do this. If you're interested in fixed media and you get your hands into every note, that's great, use a DAW. I don't like pushing blocks around on a screen; I would rather use code. BTW I can "jump on [my live coding system]" and have a basic beat going in about 5 minutes.
I’m totally okay with pure data, because I’ve already got the commands down, and i plan things that I need beforehand. I’ve tried supercollider, and it took so long for me to do anything.
Admittedly here I chose a best-case for SC and worst-case for Pd. It's all YMMV -- actually I teach with Pd because students whose first language isn't English seem to struggle less when some of the logic is expressed graphically rather than using English keywords. But I've got logic in my SC live setup that would take a really unpleasant amount of time to rebuild in Pd, which was approachable in SC.
which linux distro are you using? your desktop looks pretty decent. like the blueish sort of color grading. by the way, nice patches
That's Ubuntu Studio 20.04, which ships with XFCE 4.something. Recently installed Ubuntu Studio 22.04 on a new laptop, which uses KDE Plasma 5.24 instead... which is beautiful but also occasionally unstable. I am not sure it was a good decision for them to switch desktops, but it seems the Ubuntu Studio team is unreachable (they don't even answer mailing list messages... remember mailing list?) so there is no way to give feedback...
Hi, I'm programming in Pd for some time now and tried learning Supercollider for two times with not much progress. A bit of a rant below.
I think Pd's simplicity is at the same time its best and worst thing, it makes sense with its philosophy, Pd vanilla is supposed to be a low level language for music, to give you only the essentials to build what you want without bias towards a specific style of music, it's kept small by design. It becomes a little more fluid and personalized overtime when you start growing your own library of objects and patches, some of the things you build is this video you only need to build one time. But gosh, it's annoying to make logic with [bang] [f] [+ 1] [mod] [sel] [moses] etc... it feels like a start from almost nothing, too much work. I think Pd's philosophy of being this low level language for music is the main reason it takes more work, not because it's graphical. It is my go to when I have a musical idea very specific I want to realize, but I'm also a bit tired of it at the same time, it feels like solving mental puzzles all the time to make it do something.
You've put your finger on it -- to write a counting loop in Pd is at least 5 boxes and 4 connections (with multiple hand moves between mouse and keyboard, this REALLY slows you down) where in SC it's "number.do { |i| ... }` and *no* hand moves away from the keyboard. Sometimes I suspect that Max/Pd users might shy away from some kinds of complexity because it's just too slow to build graphically. (But, Max/Pd may also be very successful for users who don't need high complexity.)
The cognitive load and barrier to entry are lower for Pd.
FWIW I teach using Pd for this reason. But... it's a bit of an exaggeration but I sometimes see Pd vs SC as a tricycle vs a 21-speed touring bike. You can get on a tricycle and ride it pretty much right away, but top speed is limited. The bike can go fast! But you will fall down while learning to ride it.