SC vs Pure Data, race to the finish line

[jamshark70]

@tremblap

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.

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

@Spacechild1

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.

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

@Spacechild1

It would be interesting to make the same comparison between SuperCollider and Max/MSP.

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.

@Sam_Pluta

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.

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