Partly for fun (partly to vent!), I made the same synth in SC and in Pure Data. Converts to SC from Max/Pd might not be surprised at how that went 
… but it did also make me think about the usability of the tools. Approachability doesn’t guarantee usability.
hjh
haha This is a great project, James. Good work!
Great video! I really appreciate that you show both sides.
Actually, Miller Puckette would very much agree with your final assessment. He often talks about how computer music environments, despite presenting themselves as “neutral”, can have a strong influence on the musical outcome because they suggest certain strategies while discouraging others.
“Max and Pd hate the studios and love the stages” (25:24)
One thing to keep in mind is that Pd only comes with a minimal set of built-in objects. If you build things for the first time, it can be very verbose, but once you know the right libraries or made proper abstractions, things get much faster. In practice, many of the things you implemented manually could be replaced by a single abstraction, like the random number generator or the envelope generator. That being said, a polyphonic synthesizer would still be easier to build in SuperCollider, but the difference wouldn’t be as striking.
It would be interesting to make the same comparison between SuperCollider and Max/MSP.
Fascinating. I’m trying to think what would be quicker and easier to build in Pd. Perhaps a patch that responded to a variety of different incoming midi messages from a controller, displayed a gui, and then passed those messages on to an external midi synth?
There is, if you are of the academic inclination, an interesting paper right on the subject: McPherson, A., and K. Tahıroğlu. 2020. “Idiomatic Patterns and Aesthetic Influence in Computer Music Languages.” In Organised Sound 25(1):53–63.
If you see Miller’s patches, I feel like the design philosophy is revealed. He doesn’t really make giant instrument patches or focus on synthesis or sound effects. He tends to make smaller patches of objects where each C object takes care of various kinds of dsp math. And this is the place where pd really shines, at least as I’ve seen. The real-time fft stuff is way more versatile and better at prototyping processes that will eventually become their own C objects.
That’s a great paper, thanks for the hint – lots of sources to follow up on!
Thanks for this – I’m very interested! And cheers to Cambridge UP for making this article open-access 
– https://www.cambridge.org/core/journals/organised-sound/article/idiomatic-patterns-and-aesthetic-influence-in-computer-music-languages/0991907053485F9919E6CE89019AFB05
Sure. CEAMMC library has a lot of great random number generators – but, they have published packages for Windows and Mac only, and it isn’t clear how to compile the externals without also using the CEAMMC Pd distro.
I’d really like a floating point RNG in pd-vanilla. It isn’t exactly the same to generate large random integers and divide, because the result is quantized. (OTOH quantized random numbers did, at one point, lead me to discover a fascinating audio illusion that I might not have stumbled upon if I had been using a floating point RNG in Pd… Auditory illusion with exponentially-spaced frequencies )
Probably the non-abstraction where I’d really open myself up to criticism is the audio recorder. Curiously, though, http://blazicek.net/list_of_pure_data_objects.html shows no external library providing a one-click recording object… which is a bit surprising. Nobody ever wanted to “just hit record”?
FWIW I have created abstractions for Pd. My best ones make sound files as easy to use in Pd as in SC (Properly usable soundfile playback without silly gotchas | PURE DATA forum~).
I’m not sure it would be that much better. You’d save a little time with adsr~ but AFAIK most of the pain points in Pd will be pretty much the same. (The [poly] / [clone] pair in Pd might reduce to [poly~] in Max, but IMO [clone] is much, much less irritating than the kludgey way Max does voice management.) The selling points for Max are the pretty interface objects, and jitter IMO.
That’s a really good point. At some fundamental level, I don’t think in those terms, and probably never will. I would love to see some of these patches…
I’m certainly biased. When I first encountered SC (v2!) in late 2002, I felt an immediate rapport, which I’ve never felt with graphical patching. (At the same time, some limited use of Max/MSP in grad school did prime my brain to understand DSP graphs in SC.) I’ve gotten better at Pd but I don’t love it. It seems to put up roadblocks in exactly the places where I want to do things (and, as you’re pointing out, the places where it flows don’t overlap as well with my interests).
I respect Pd and I’m glad that it exists.
It’s much more visually compelling to watch the boxes and wires being created, where the code window, visually, is relatively undifferentiated. That might be part of why I’m hammering at the inefficiency of the patching interface – the sexiness of the interface distracts attention away from how much time it’s wasting.
Also a very good point about FFT. SC’s PV_ suite has some gaps.
hjh
which is a bit surprising. Nobody ever wanted to “just hit record”?
Of course 
I think [else/rec.file~] comes closest. Personally, I have a similar abstraction, but it generates file names from [zexy/date], so it’s really “just hit record”.
FYI, there is [markex/randomF] which I regularly use. But yes, I think it’s a bit ridiculous that Pd vanilla doesn’t have a floating point random number generator…
I was just starting to work on one today… minimal core + disorganized and uncatalogued extensions = redundant effort
hjh
Interesting points with a respectful discussion tone!
One special point that got my attention in JMC’s SAPF lecture: code is flexible because it is abstract (can hold almost any behavior and data) and “dataflow” languages are more static because you are interacting with the thing itself thus not being allowed to change the inner concept/behavior of this visual block, only its data/content.
Thinking about the most special pro points of each system, IMO the idiosyncratic advantage of using dataflow languages is that you are always going to build a GUI that can be used by people with no computer skills (even though it takes more working hours). This is specially good in contexts of live eletronics and stage, as mentioned above.
On the other coin side, code’s best advantage is its flexibility. You can write basically anything, remake mario bros on SC or build a linux kernel using sclang (OK too far 
). Loops, conditionals and iterative operations are often a nightmare on dataflow languages. Moreover, for writing deeply complex things, code seems to be less painful way. However, when programming a GUI with code solely, you can write a factory of GUIs but it will often require some amount of manual tweaking, dirty hands to make it more organic or fine tuned to the user needs.
Just to remember old times, there was a discussion on the list with interesting personal views about this topic (sometimes rant, let’s stop chordXword war and make computer music peace 
):
[sc-users] Coding vs patching: would you eat soup with a fork?
I sometimes have the impression that PD design is more DSP oriented than SC. Do you people feel the same?
I mean, the way it allows you to do single sample feedback, fft, stop/change the processing “on the fly“ (block~ and switch), the way you control table and plot things + the lack of music abstractions (flexible envelope generator, structures to manipulate scales/note/sets , patterns, etc) seems to me that Miller Puckette design goal was to have a fast C audio processor with some super transparent GUI.
This seems to happen even in the details of PD’s design choices: e.g. miliseconds standard necessarily make the users more aware of DSP domain.
Yeah, I noticed this awhile back. Because every “variable” is physically attached to the place that needs its value, the only way to refer multiple times to the same variable is to have multiple objects and sync their values. For single numbers, Pd has [value] which greatly simplifies it, but for lists etc, it gets laborious to save the same value in multiple places.
Similarly, if a subpatch or abstraction is like a function… then the function can feed its value to only one place. You can’t have two places calling the same function. Function reuse requires separate copies of the function… meaning, if your abstraction is more like an OOP object with internal state, you can’t have multiple references to it. Working around this can get nasty. I had tried to bring this up on the Pd forum… the best answer I got was along the lines of “you’re not seeing the Pd way” but it still wasn’t clear to me what is Pd-idiomatic for multiple clients of a single state (where we have e.g. a = Point(0, 1) and can do a.y anywhere in that scope). This could be a/ either I’m too dense to understand it, or b/ Pd users tend to avoid that situation and thus might not understand why you would need it.
For all my griping, I learned a lot from getting dataflows better under my fingers… but they still make me tired and I don’t see myself trying to make a large project completely in Pd.
hjh
That video is pretty eye-opening… Puckett’s disparagement of composition as “office work” and relegating it firmly to the past in favor of performance seemed exactly backward to me… Coding is not just a way of building tools that allow a performer to make art, coding can be the way one makes art, directly.
I expect I’m one of a minority here who use SC to make static pieces - for my use case Max/Pd are pretty impossible!
Last post for today … In context of the whole lecture, I don’t think Puckette is as derogatory toward composition as that. Later in the same lecture, he makes it clear that he’s aware that he has a bias toward electronics for live performance and that he doesn’t expect this to be universally shared.
I’m not even sure that the term “office work” (which came from Zicarelli, not original with Puckette) is meant as an insult, but more as an observation that western art music culture depends heavily on non-performance intellectual activity to prepare for the performance and that it might not be ideal in all cases to privilege that model.
He has very interesting things to say about mapping physically practical inputs onto the total space of 44000 or 88000 or 96000 numbers per second that makes up digital audio. You can, in Max/Pd, create a long list of events by hand (in Pd, you could write them out in a [text] object) and play them back deterministically = fixed-form composition. But it isn’t fun to write long lists of parameters, so you probably won’t. So then you’re looking for higher level abstractions to produce the event parameters, and this is where the bias comes in, IMO: Pd doesn’t have anything built in like SC patterns. It’s possible to implement compositional algorithms in Pd but I find boxes and wires to be more cumbersome at this.
~~
Of the “idiomatic” and musical style: I also made a shorter version of my video, only the demo, with a minimalist-style backing music track made in SC (in about half an hour, using some of my stock synths and my live coding sequencer). A DJ friend heard it and immediately asked me if I’m familiar with Mira Calix’s work – who has also used SuperCollider 
so… something in the water there…
hjh
hey james,
i made this visualization of Fredrik’s sc tweet for an upcoming book about sc (… in japanese).
using graphviz it essentially Pd-fies (or max-fies, for that matter) what that code is doing, in terms of cabling-stuff-together, right?
this is Fredrik’s sc tweet;
play{Splay.ar(SinOsc.ar(9,SinOsc.ar(midicps((Sweep.ar(0,(33..3))%128&(Sweep.ar(0,(3..9))%(LFSaw.ar(3)*9+99)))+33),0,pi)))/3}
turned into a ‘spagetti’ max/msp-esque mess.
The idea of having a patch within a patch that does something specific and with dedicated inputs and outputs was the nice thing about Pd for me. I came from Pd originally and had significantly modified my version with a bunch of my own objects. That was a definite plus.
My issue was that even vanilla seemed to just be running really heavy all of the time where SuperCollider you’re very much in control of what is being evaluated, how fast, and when.
And it’s also very easy to lose track of where you as you build larger patches. I was really into Pd in undergrad, but I almost cannot return to it because I’ve forgotten what the objects were, how and when things do what they do, and at the end of the day it’s just not as robust or flexible after a certain point.
I am getting much more use out of SuperCollider because it strips away the prettiness and visual organization of things like Max or Pd.
I use Pd now mostly for processing numbers. I find it’s much easier to watch the process through the number boxes and bangs because you can find bugs more easily. It is not fun to try to use MIDI with Pd though, I found it took a lot of work to set up and was not very responsive but that was around 2015-2016 I was using it most.
I find that friends and colleagues with a background in modular tend to gravitate toward Max and Pd.
FWIW I haven’t really gone back from SuperCollider to Pd. I bought an EWI and was going to use it with Pd, but SuperCollider was just so much easier, deeper, and more flexible.
I would certainly agree with you on all those points, although I don’t think I ever really got into the midi options.
The other thing, although not important in regard to your comment, is that I never really understood why they trashed the Extended version of PD and kept Vanilla only. I thought Extended was really useful for beginners, and others too who needed to get up and running fast. I few years ago I wanted to show some students a musical process (using PD for the visual aspect), and realised that half of my older patches didn’t work because you need re-load various objects (some quite basic too) into PD. I found this not only time consuming, but also couldn’t really see what the advantage was either.
Pd-extended was essentially maintained by a single person. Eventually, the maintainer burned out and nobody stepped in. The spiritual successor to Pd-extended is Purr Data: https://www.purrdata.net/
IMO, having a small core + libraries maintained by different people is much more sustainable in the long run. Sure, a huge monolith with batteries included is nice for beginners, but it quickly becomes unmaintainable. This actually happened with sc3-plugins - they are now frozen and there is a still on-going discussion on how to deal with new UGen plugins in the future.
