RLPF.ar

(Or, "Because I don't have enough hate mail")

I've wanted to write this one for a while -- been saving up. It's a loooong rant...

One of my tasks this year was to teach Max/MSP to a graduate student. This has turned out to reinforce my feeling that SuperCollider is a far superior audio programming platform in almost every respect. But, it will never catch on in China because here, a product's value is measured by its price tag. Max is expen$$$ive, $700 for a non-academic license. SuperCollider is free. By the prevailing logic over here, if it's any good, you can charge an arm and a leg for it -- therefore, SuperCollider must suck because we give it away.

In fairness, I do see the point that Max/MSP on a curriculum vitae means more, in the present computer music culture, than SuperCollider. This might not bother me, were it not for Max's gaping technical lacunae. Why has the live-computer-music scene has almost monolithically embraced a platform with stunning weaknesses? I'm baffled. I suspect the reason is similar to the feedback loop that keeps Java dominant in corporate software development. Companies hire Java programmers, and schools churn out Java programmers because that's where the jobs are. With Max, it's not exactly the same -- more like, professors teach Max because that's what they learned.

Before I release the hounds, Max has one major edge over SuperCollider: image processing with jitter. Since Max, MSP and jitter all work basically the same way, someone who wants to make live electronic music and video can learn just one paradigm, where a SuperCollider user needs to learn Processing (a second language) and interface the two with Open Sound Control. Steeper learning curve.

But the cost of a unified environment... uggghhhhhh... graphical patching. Programming in text can take more imagination to keep the (usually invisible) data connections in mind. Patching is great for learning and teaching -- you can see right away on screen where the information is flowing. That Max's strength, and its downfall -- because, when the tasks become more complex, the data connections explode, sometimes it seems exponentially. Text-based programming languages have been continually improving their strategies, over more than half a century, to manage the explosion in complexity. Graphical patchers have less history, and their strategies (subpatches, abstractions, send/receive pairs) are less articulate than text-based strategies. They also don't deal with the fundamental problem: with the exception of send/receive pairs, all of the connections must be visible in some window somewhere, whether the connections number in the dozens or thousands.

Some simple stuff. Say I want to add a little new signal processing logic. In SuperCollider, I'm writing in a text editor so, to make more room, I -- get this -- press the return key. In Max, I have to select and move objects using the mouse, and probably tweak some of the "virtual patchcord" paths -- before I can even get started on the new ideas. Bo-ring. But the real problem is the effect on one's creativity. In SuperCollider, I don't think twice about adding units here or there to breathe a little more life into a dull sound, or throwing a new element into a composition algorithm for more variety or expressiveness -- because the cost in the interface of inserting new logic is trivially low. When working in Max, I constantly find myself thinking, "Gee, I'd really like it to sound like this, but then I would have to move these things around, re-patch 30 different things... maybe it's too much trouble." The tool should get out of the way -- creativity should not be "too much trouble" -- but Max's paradigm is always in your face, reminding you how awkward it is.

Then there are the freaky implementations. "Let's add a noise gate to this microphone input." Okay... [omx.comp~] looks interesting... then you find out:

• [omx.comp~] doesn't set the threshold in decibels (like every other noise gate in the world). Instead, you have to use some crackhead arbitrary 0-100 measurement.
• The noise gate is really a "downward expander with a ratio of 1:2." Only 1:2? I wouldn't consider it a real noise gate until the ratio gets up to at least 1:4.
• Then the kicker -- standard dynamics processors apply the ratio to the level in decibels. If the threshold is -20 dB and the incoming signal is -30 dB, a 1:2 downward expander would output -40 dB. SuperCollider's Compander unit works this way. [omx.comp~] uses some other method that I can't guess, producing a much smaller gain reduction. This makes the object useless for the normal use of a noise gate: to silence the input when the signal is only low-level line noise.

That's not the only place the behavior strikes me as counterintuitive -- just an especially obvious one. It rankles, though, because of the steep price tag. I can forgive oddities in free software, but if I am to pay several hundred dollars for a product that claims to be the best, I expect the i's to be dotted and the t's to be crossed.

I haven't even gotten started on [poly~] yet. One would think that playing several notes at the same time would be a fundamental and easy-to-use feature. Let's compare:

// SuperCollider
// play one note
(instrument: \default, degree: 0, dur: 2).play;

// play a triad
(instrument: \default, degree: [0, 2, 4], dur: 2).play;

// strum the notes
(instrument: \default, degree: [0, 2, 4], dur: 2, strum: 0.08).play;

In Max, we have [poly~]:

1. Make an abstraction with the signal processing for one note (like writing a SynthDef in SuperCollider).
2. Inside the abstraction, when the note starts, send a pair of messages: (1, mute 0) to a [thispoly~] object.
3. When it ends, send the reverse pair (0, mute 1) to the same [thispoly~]. It must be the same [thispoly~], even if this is inconvenient for the graphical layout.
4. Worry about the "target" of data flowing into the poly~.
5. Use special (note...) or (midinote...) lists to trigger notes.
6. Debug, maybe even cry, when it doesn't work right away.

It makes me wonder how interesting work is done in Max at all. Then I remember -- every interesting Max project I've ever heard of embeds text-based code (usually Java) into Max objects! I suppose it's just too difficult otherwise.

My work on Affectations comprises some 16,000 lines of SuperCollider code, including some fairly sophisticated compositional algorithms to hold interest over 47 minutes of performance time. Had I tried to do the same in Max, I would have had to a/ take two years instead of one or b/ compromise the music's interest level just to allow development time for fighting the inherent flaws of the graphical-patching paradigm. That's the crime of the computer music community's fixation on Max/MSP: when the choice of tool leads the composer to cut good ideas for convenience's sake, nobody wins. (I concede that some people are doing interesting work in Max/MSP. But I wonder, how much more interesting could it be in a less cumbersome environment?)

Standard disclaimers, your mileage may vary, etc... but I stand by my opinions. (Comments by non-registered users are disabled, but my email flame suit is on here.)