I'd considered using poly~ to do something like what you are looking at too. As you suggest, it does mean that you will probably need to handle the UI (assuming there will be a UI of some sort) and audio engine parts seperately (Bpatcher for the former and Poly~ for the latter). In real terms that route would require a greater level of planning in terms of the interaction between ui and engine etc. With that said, there may be no significant gain in doing it that way (except for self-esteem and some cpu cycles). In light of that, Bpatchers (alone) are probably a little easier to go with. Scripting can get messy, but would obviously need to be part of the picture (via thispatcher or more likely js or...) If you want to be able to arbitrarily add (and/or remove) channels/instances One thing you coud take a look at is the now old but potentially handy Matsui suite (from AudioMatt?) which had a working example of scripting to create and remove mixer channels. I'm not sure if that is available online here or Maxobjects but it may be worth sniffing it out. I'm not aware of other relevant (or more recent) scripting tools or examples in Toolbox etc but no doubt there is something out there. Perhaps a search or possibly another forum member may yield some joy in this regard....

Thanks for the great reply, which was really helpful! A couple of additional clarifications, now that I'm digging [poly~] more...

1. Since every patcher used with [poly~] needs specific ins/outs for it, do people just stick these onto anything they make that might be used with [poly~]? Or otherwise have to add them to every existing abstraction they want to use in a [poly~] after-the-fact?

2. In cases where streams of control data from different sources need to go to different instances continuously, I'm wondering if [poly~] is really the best approach-- I'm running into a problem of having to constantly switch instances with the 'target' msg. With things at a slower speed, this seems OK. But with 50+ constantly changing numbers (let's say every 10-50 ms) going to 50+ instances, it seems like it might be less practical & reliable, having to keep all the target msgs and data (which may need to go to different [poly~] inputs) straight? In practice, do people find this kind if thing is a problem?

Many thanks, Brian

Regarding your issue #2, I tend to set a poly~ to "target 0" and format the messages so that the patch loaded in poly~ can sort out the messages it needs. In the stuff I've done so far with poly~, I want most of the messages to go to all instances, and where an instance cares it can use its instance number to sort things out. In your mixer case, I might prefer all messages with a channel or group number, and let the loaded patch figure out whether the message was for it.