Did you guys really think I was only going to post ONE thing tonight? So did I. But it turns out, you and I were both wrong.

I present you some simple mixer abstractions. This set consists of a mono input mixer-strip, a stereo input mixer-strip, and a master mixer-strip. Each strip has panning, volume, mute, and solo (except master, because that would be stupid). The channel strips automatically throw their outputs to the master, to ease patching, but you can turn it off if you like. Anyway, I think the help patch explains most of it.

These use the state-saving abstractions I posted earlier.

http://puredata.hurleur.com/sujet-5664-state-saving-abstractions

http://www.pdpatchrepo.info/hurleur/mixstrip.mmb.zip

Look good! But I'm missing the pan.mmb abstraction.

I briefly looked inside, but I couldn't work out how the 'solo' button would mute other instances of the mixerstrip. What am I missing?

@atarikai said:

Look good! But I'm missing the pan.mmb abstraction.

Thanks. Should be fixed now.

I briefly looked inside, but I couldn't work out how the 'solo' button would mute other instances of the mixerstrip. What am I missing?

Basically, when you activate or deactivate solo on a channel strip, it sends a message to [mixstripmaster.mmb~] that solo has been toggled somewhere. [mixstripmaster.mmb~] requests the solo state of all the [mixstrip1.mmb~] and [mixstrip2.mmb~] objects and sums them up to get a "global" solo state for the mixer, which it sends back out to the channels. If they add up to 0, then that means nothing is on solo and all tracks should be on. If they add up to one or more, then something must be soloed, and so the track will check its solo state to determine if it should be on or off.

you are my.hero.mmb

Haha!