Alexandre

One can put some objects inside a subpatch and use mute~ or pcontrol, in order to free the cpu. But as an alternative, I was wondering about the "enable 0" hidden feature of all signal objects : A "enable 0" message sent to a signal-domain object stop its process to free cpu, while "enable 1" put it back on. (see patch)

But looking at the maxmsp doc, this feature doesn't appears anywhere, plus it doesn't appears in the message list that you get by control-clicking on an object input... (the only "enable 0" found is about pcontrol) Does this mean that this feature is not really stable, or that we are not supposed to use it ? Or is it fine to use it anytime on shared patches ?

P.S : in this patch, it look like there is some residual process working when all is disabled, anybody knows why ?

wondering-about-the-enable-0-hidden-feature-of-all-signal-objects

Alexandre wrote on Sat, 25 July 2009 19:55

But as an alternative, I was wondering about the "enable 0" hidden feature of all signal objects : A "enable 0" message sent to a signal-domain object stop its process to free cpu, while "enable 1" put it back on.

As I recall, the enable message was used internally by one of the early MSP mute/unmute techniques, possibly by the selector~/begin~ combination.

It's probably not documented because you're not supposed to use it in normal patches (and the selector~/begin~ thing is sort of deprecated nowadays, too). There's a real potential to end up with unwanted noise in the lines if an MSP object is arbitrarily disabled.

And, yes, there is always some residual MSP processing, even if all objects are disabled. The MSP signal chain is still processed, and every object in the chain is called; the savings are that the object returns immediately without actually doing any work. See the SDK examples to see how this works.

But the CPU usage is very, very close to zero when everything's disabled.

Alexandre wrote on Sat, 25 July 2009 19:55But as an alternative, I was wondering about the "enable 0" hidden feature of all signal objects : A "enable 0" message sent to a signal-domain object stop its process to free cpu, while "enable 1" put it back on.

And, yes, there is always some residual MSP processing, even if all objects are disabled. The MSP signal chain is still processed, and every object in the chain is called; the savings are that the object returns immediately without actually doing any work. See the SDK examples to see how this works. 

But the CPU usage is very, very close to zero when everything's disabled.


So i guess it means that the only reasonable way to momentarily suppress few audio objects, is then to put them in a subpatch using mute~...

But then, in my case, this will be a lot of subpatches containing only few objects (knowing inlets/outlets will also cost cpu), and my patch will not be as clear to look at...

So i guess it means that the only reasonable way to momentarily suppress few audio objects, is then to put them in a subpatch using mute~... 

But then, in my case, this will be a lot of subpatches containing only few objects (knowing inlets/outlets will also cost cpu), and my patch will not be as clear to look at...


I'd recommend using a one voice [poly~] but this might not be useful to you. Why do you want to remove lots of subpatches containing only few objects from the processing chain. Maybe if you shared your reasoning someone would be able to help more.

> Why do you want to remove lots of subpatches containing only few objects from the processing chain.

That's because these a lot of little processes in it, connected as a tree, i need to choose between some of them. Plus i'm building all this from inside a 60 voices poly~...

> I'd recommend using a one voice [poly~]

what would be really the disadvantage of using subpatch/mute beside this one voice poly~ solution ?

If you have a situation where you want to choose one subpatch from many to insert at a particular place in your signal chain you can dynamically load one in using [poly~] without disrupting the DSP instead of including all the subpatches you might want and then bypassing/routing+muting all the ones you don't want. Again, this might not work for you as I don't know what you're doing but if it is helpful to you then great.

And woooooo 60 voices, is this some mega performance patch and when can we hear something from it?

The thing is that all my little processes are differents so i cannot put them all inside a poly~

(which would be then inside my first poly~ : By the way, it is ok to use a poly inside poly ?)

-> And also, it is ok to mute/unmute a lot of stuff every 3 signal vectors ? (granulated sounds) Or is these a cpu cost added by the mute/unmute action at this special instant ?

nop, but if it's as nice as my resonances shared here last week, i'll post it here too. 

The thing is that all my little processes are differents so i cannot put them all inside a poly~ 

-> And also, it is ok to mute/unmute a lot of stuff every 3 signal vectors ?   (granulated sounds) Or is these a cpu cost added by the   mute/unmute action at this special instant ?

>is this some mega performance patch
nop, but if it's as nice as my resonances shared here last week, i'll post it here too. 


Yeah as far as I know recursive [poly~]s are fine. I'm not sure how many levels deep you can go down before it gets a bit crazy, I assume it all depends on the amount of work each one is doing and the number of voices.

I liked your resonance patch, it made some nice sounds so I shall look forward to seeing this one make an appearance on the list.

Ok, one poly inside the poly will be fine but i'm not sure i'm gonna use it for now.

Well, if somebody knows, i still have this question that is growing in me : it is ok to mute/unmute a lot of stuff every 2 signal vectors ? (shorts granulated sounds) Or is these an additionnal cpu cost added by the mute/unmute action at this special instant ?

Thanks!
Ok, one poly inside the poly will be fine but i'm not sure i'm gonna use it for now.

Well, if somebody knows, i still have this question that is growing in me :  it is ok to mute/unmute a lot of stuff every 2 signal vectors ? (shorts granulated sounds) Or is these an additionnal cpu cost added by the mute/unmute action at this special instant ?

Wondering about the "enable 0" hidden feature of all signal objects