AudioMatt

I’d like to write an object that loads and unloads subpatches which run audio. Is there any information on doing this?

I’d like to write an object that loads and unloads subpatches which run audio.  Is there any information on doing this?

examples-of-poly~-style-startingstopping-dsp-in-subpatches

I have this example on how you can use poly~ to dynamically chain multiple dsp effects: 

https://github.com/tmhglnd/poly-recursion

I have this example on how you can use poly~ to dynamically chain multiple dsp effects: https://github.com/tmhglnd/poly-recursion

Ah! Im looking for a way to do what poly~ does in C

but this is super cool. I sort of didn’t know you could do this.

Ah!  Im looking for a way to do what poly~ does in C 

but this is super cool.  I sort of didn’t know you could do this.  

turning poly´s on and off is a nobrainer and i would go so far saying that it is its main feature.

but what really sucks is that you sometimes have to build a poly patcher from an already existing patcher, that you sometimes have to change the order or number of ins and outs, then maybe later you decide that you are not going to use the poly version and all the effort seems to be in vain.

an external which recreates the features of [patcher] but accepts a "disable" message would be a good addition to max. ^^ 

though i think it would already work like that if it was so easily possible.


turning poly´s on and off is a nobrainer and i would go so far saying that it is its main feature.

but what really sucks is that you sometimes have to build a poly patcher from an already existing patcher, that you sometimes have to change the order or number of ins and outs, then maybe later you decide that you are not going to use the poly version and all the effort seems to be in vain.

an external which recreates the features of [patcher] but accepts a "disable" message would be a good addition to max. ^^ 

though i think it would already work like that if it was so easily possible.

Roman that's exactly what I want to do from C is mute and unmute dsp in a patcher loaded internally.

You can also use (enable $1) > [pcontrol] > [abstraction] or connect [mute~] object. Include the [pass~] object within the abstraction to make sure when enable that you don't get unexpected noise from the outlet.

Concerning writing a existing patcher into a poly~ patcher, I would just write a wrapper for that patcher, connection [in]'s and [out~]'s to the abstraction within.

You can also use (enable $1) > [pcontrol] > [abstraction] or connect [mute~] object. Include the [pass~] object within the abstraction to make sure when enable that you don't get unexpected noise from the outlet.


enable $1 flips audio on and off?!?!?!?!?!?!??!?

It's not in the help file or the reference.

putting pass~ objects into a bunch of your abstractions or patches is a solution not better than creating a poly~ version... however sometimes it might still be more appropiate. 

and "enable" to [pcontrol] only disables midi properly.

strange enough: in older versions of max the 

 were showing how to do it with "mute" to [pcontrol] - the 

and while works with the tapin/tapout example in a [p ] in this mute~ helpfile, it does 

if you only think about very big patches or patching with bpatchers: both pcontrol and mute~ must be connected directly. do you really want to have one extra object in the canvas for turning subcircuits on and off? ... for my part i prefer the patches to receive 0 and 1 in the righmost inlet like my poly´s do. ;)

and dont forget that you often need to do more than turning DSP off - for example you might want to send out 0 at all signal outlets before you cut the connections off...

conclusion: mute~ and pcontrol both offer solutions for special cases, but it is not what you originally had in mind and wont make your idea unjustified.


putting pass~ objects into a bunch of  your abstractions or patches is a solution not better than creating a poly~ version... however sometimes it might still be more appropiate. 

and "enable" to [pcontrol] only disables midi properly.

strange enough: in older versions of max the mute~ helpfile were showing how to do it with "mute" to [pcontrol] - the pcontrol helpfile does not.

and while works with the tapin/tapout example in a [p ] in this mute~ helpfile, it does not work with my abstractions.

if you only think about very big patches or patching with bpatchers: both pcontrol and mute~ must be connected directly. do you really want to have one extra object in the canvas for turning subcircuits on and off? ... for my part i prefer the patches to receive 0 and 1 in the righmost inlet like my poly´s do. ;)

and dont forget that you often need to do more than turning DSP off - for example you might want to send out 0 at all signal outlets before you cut the connections off...

conclusion: mute~ and pcontrol both offer solutions for special cases, but it is not what you originally had in mind and wont make your idea unjustified.

what does this mean? I just tried it and my audio flipped on/off with no gap. Is this unsupported behavior? 

my plan right now is to load my subpatchers inside a generic patch with a pcontrol attached to turn them on/off

and "enable" to [pcontrol] only disables midi properly. 

what does this mean?  I just tried it and my audio flipped on/off with no gap.  Is this unsupported behavior? 

my plan right now is to load my subpatchers inside a generic patch with a pcontrol attached to turn them on/off

yes in [p] it works, but not in [mypatch]

and it seems that it only disables the MSP objects. if you make a [patcher] containing "inlet-connection-outlet" you can not mute that thing (unlike in a poly)

other than the mute~ helpfile suggest with its tapping buffer example, using pcontrol still requires a pass~ object per outlet. that is, for lower levels, when you do "enable 0 1", too(!)

not sure where this makes a difference, but i see dark clouds rising.


yes in [p] it works, but not in [mypatch]

and it seems that it only disables the MSP objects. if you make a [patcher] containing "inlet-connection-outlet" you can not mute that thing (unlike in a poly)

other than the mute~ helpfile suggest with its tapping buffer example, using pcontrol still requires a pass~ object per outlet. that is, for lower levels, when you do "enable 0 1", too(!)

not sure where this makes a difference, but i see dark clouds rising.


I experimented alot on this, In the end I put all the audio code in gen~ and the main code block is in a conditional which just doesn't do anything if the sound output level is zero. I found it much more efficient than turning things on and off at the object level. It does mean putting everything in codebox so its not for everybody. If there were string processing in gen I wouldn't use objects much at all.

I experimented alot on this, In the end I put all the audio code in gen~ and the main code block is in a conditional which just doesn't do anything if the sound output level is zero. I found it much more efficient than turning things on and off at the object level.  It does mean putting everything in codebox so its not for everybody. If there were string processing in gen I wouldn't use objects much at all. 

Examples of poly~ style starting/stopping dsp in subpatches?