Brian H.

I'm just starting to look at [poly~], and trying to create a simple mixer that can created & delete channels dynamically (an abstraction with an argument for how many channels to load). Is [poly~] the way to do this? Or create objects with scripting msgs to [thispatcher]? They both seem promising, but on a cursory look I can quite see how to get the whole job done yet-- Not sure how to create the dynamic interface bits with [poly~] (i.e. the instances need to create their own [bpatchers]), and scripting all the details of dynamic positioning, etc. seems like it could get messy. Just curious to be pointed in recommended directions before going further...

Hi,
I'm just starting to look at [poly~], and trying to create a simple mixer that can created & delete channels dynamically (an abstraction with an argument for how many channels to load).  Is [poly~] the way to do this?  Or create objects with scripting msgs to [thispatcher]?  They both seem promising, but on a cursory look I can quite see how to get the whole job done yet-- Not sure how to create the dynamic interface bits with [poly~] (i.e. the instances need to create their own [bpatchers]), and scripting all the details of dynamic positioning, etc. seems like it could get messy.  Just curious to be pointed in recommended directions before going further...

mixer-with-poly

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

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?

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?

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.

Mixer with [poly~]?