Tj Shredder

I have a question to those who know the inner workings of max better

If I have a poly~ inside a poly~ and I mute the parent poly~, does this

automatically mute the child poly~ as well?

I ask, as poly~s have their own dsp chain, and I am not sure if that

implies that the inner poly~ will be muted automatically or not. It

might only mute the outlet of the inner poly~....

I had some strange noises from poly~s within poly~s and just wonder if

it could be a reason that the inner ones are not muted...

I have a question to those who know the inner workings of max better
than I do:
If I have a poly~ inside a poly~ and I mute the parent poly~, does this
automatically mute the child poly~ as well?
I ask, as poly~s have their own dsp chain, and I am not sure if that
implies that the inner poly~ will be muted automatically or not. It
might only mute the outlet of the inner poly~....

I had some strange noises from poly~s within poly~s and just wonder if
it could be a reason that the inner ones are not muted...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com

poly-inside-poly-and-mute

Quote: stefantiedje wrote on Tue, 09 December 2008 02:08

----------------------------------------------------

> I have a question to those who know the inner workings of max better

> If I have a poly~ inside a poly~ and I mute the parent poly~, does this

> automatically mute the child poly~ as well?

Yes they do have their own dsp chain, but they also exist within a parent dsp chain dsp chain (either the main one, or the one of a poly~ / pfft~ they are in). So, if the mute the parent (stopping the poly~s internal dsp chain from being called) then the child will never be called to process and so yes, it will be muted and will not not be using cpu cycles.

> I had some strange noises from poly~s within poly~s

What kind of noises, and how/why? If a poly~ is muted it will write zeros to its outlets as far as I know, so you shouldn't hear anything. Unless, that is you are using send~/recieve~ inside a poly~ to the outside world, in which case muting processing might result in a vector of samples being looped and hence an annoying buzzing sound....

Quote: stefantiedje wrote on Tue, 09 December 2008 02:08
----------------------------------------------------
> I have a question to those who know the inner workings of max better
> than I do:
> If I have a poly~ inside a poly~ and I mute the parent poly~, does this
> automatically mute the child poly~ as well?

> I had some strange noises from poly~s within poly~s 

first of all, i tried to reply by mail, but i'm not sure the mail has been sent, i had an error with the joined file. Sorry if my message is doubled.

another thing to know is that using in~/out~ in the child poly~ will not act as you want.

i.e. the child's [out~ 1] object will in fact output its signal to the parent's first outlet. that's due to the way the dsp chain is compiled.

i stopped thinking about using poly~s inside poly~s...

> If a poly~ is muted it will write zeros to its outlets as far 

> as I know, so you shouldn't hear anything. Unless, that is 

> you are using send~/recieve~ inside a poly~ to the outside

> world, in which case muting processing might result in a 

> vector of samples being looped and hence an annoying 

Oh my, really? That would explain buzz troubles i had two days ago during a performance. Is there any way to predict the buzzes or to generally use audio send~ objects from inside a poly~ without getting buzzes? 

And how comes, that the cpu load sinks due to a muted poly~ while it still writes zeros to it's outlets? that seems odd to me. i would assume, that only a non-existing signal has no cpu load?

> If a poly~ is muted it will write zeros to its outlets as far 
> as I know, so you shouldn't hear anything. Unless, that is 
> you are using send~/recieve~ inside a poly~ to the outside
> world, in which case muting processing might result in a 
> vector of samples being looped and hence an annoying 
> buzzing sound....

Oh my, really? That would explain buzz troubles i had two days ago during a performance. Is there any way to predict the buzzes or to generally use audio send~ objects from inside a poly~ without getting buzzes? 
And how comes, that the cpu load sinks due to a muted poly~ while it still writes zeros to it's outlets? that seems odd to me. i would assume, that only a non-existing signal has no cpu load?

Quote: jayrope wrote on Tue, 09 December 2008 08:15

> Oh my, really? That would explain buzz troubles i had two days ago during a performance. Is there any way to predict the buzzes or to generally use audio send~ objects from inside a poly~ without getting buzzes?

This would only happen if you mute the poly~, or perhaps other objects within it, and I'm not even certain it would happen then - it's just a possibility - the only explanation that springs to mind. If you have a patch with a reproducible problem I could look at it, otherwise it's possible that something else was to blame.

> And how comes, that the cpu load sinks due to a muted poly~ while it still writes zeros to it's outlets? that seems odd to me. i would assume, that only a non-existing signal has no cpu load?

The cpu load from writing zeros to a couple of outputs is minimal, you probably won't even see it in DSP status unless you have a LOT of outputs, and even then you might not. In comparison, the amount of work going on inside an average poly could be quite a lot. Also, if you have 100 instances of a patch running that processing is happened 100 times per signal vector, but zeros are written only once-per output per signal vector.

Quote: jayrope wrote on Tue, 09 December 2008 08:15
----------------------------------------------------

> Oh my, really? That would explain buzz troubles i had two days ago during a performance. Is there any way to predict the buzzes or to generally use audio send~ objects from inside a poly~ without getting buzzes? 

> zeros are written only once-per output per signal vector.

that is, when using pass~ before the respective send~ inside a poly, or also without it?

thank you for the in-depth explanation, alex!

Quote: jayrope wrote on Tue, 09 December 2008 08:31

> > zeros are written only once-per output per signal vector.

> that is, when using pass~ before the respective send~ inside a poly, or also without it?

I think you may be a bit confused here. poly~ writes zeros to its outputs when muted, not to any send~ objects within it. pass~ is not required.

The situation with send~s and receives inside a poly is often complex and can generate confusion/problems, I would probably avoid it if at all possible.

The difference between muting a poly~ and muting a subpatcher is that when you mute a poly~ none of the internal objects are called at all during dsp processing, but when you mute a subpatcher the objects inside are still called (in order), they just skip any processing (expect in a few cases where objects are not doing significant processing). This often results in values left at the outputs which are non-zero. pass~ actually only does work when muting IS on, and writes zeros to the output. Checking the mute flag is not enforced by the C API, so 3rd party externals may ignore the mute flag and still process in the subpatcher case. For this and some other reasons (simplicity of not having to use pass, no overhead from calling the dsp chain) many prefer muting using poly~ to ensure minimal cpu usage, and silence at the outputs even when there is no need for multiple instances of a patch, or other poly features.

Quote: jayrope wrote on Tue, 09 December 2008 08:31
----------------------------------------------------
> > zeros are written only once-per output per signal vector.
>
> that is, when using pass~ before the respective send~ inside a poly, or also without it?

I think you may be a bit confused here. poly~ writes zeros to its outputs when muted, not to any send~ objects within it. pass~ is not required. 

> The difference between muting a poly~ and muting a subpatcher 

> is that when you mute a poly~ none of the internal objects 

> are called at all during dsp processing...

Just n the side of this discussion i was looking for a way to mute certain instances of a poly~, not the complete poly~ including all instances. nevertheless it is good to hear i don't need to take care of zeroing out send~ objects with a pass~ right before any of these.

I just have a poly here, which contains a selector distributing signal upon thispoly~ to one of it's outlets accordingly, and i was under the impression, that this causes a massive cpu load on top just for the fact of including the selector~ into the poly~...

thank you very much. how could i read up about those max intestines myself?

> The difference between muting a poly~ and muting a subpatcher 
> is that when you mute a poly~ none of the internal objects 
> are called at all during dsp processing...

Okay, i understood this now.
Just n the side of this discussion i was looking for a way to mute certain instances of a poly~, not the complete poly~ including all instances. nevertheless it is good to hear i don't need to take care of zeroing out send~ objects with a pass~ right before any of these.
I just have a poly here, which contains a selector distributing signal upon thispoly~ to one of it's outlets accordingly, and i was under the impression, that this causes a massive cpu load on top just for the fact of including the selector~ into the poly~...

Quote: jayrope wrote on Tue, 09 December 2008 09:49

> Just n the side of this discussion i was looking for a way to mute certain instances of a poly~, not the complete poly~ including all instances

Oh ok - well there's muting a poly (the object - from the outside) and then there's muting an instance of a poly using thispoly~. Both I believe will result in the dsp chain not being run - in one case for all instances, in the other only for the instance in question.

The zeroing thing only happens when you mute a poly from the outside.

> I just have a poly here, which contains a selector distributing signal upon thispoly~ to one of it's outlets accordingly, and i was under the impression, that this causes a massive cpu load on top just for the fact of including the selector~ into the poly~...

Selector~ is pretty cheap, not quite sure what you mean though - could you post a patch? The best way to check cpu load though is to try different things and see how it affects the numbers in DSP Status - after time you get a feel for things.

> thank you very much. how could i read up about those max intestines myself?

Well I learnt fron programming my own externals, which you may not wish to do, but you might try reading some of the SDK docs - possibly the older one may be of more interest, as it is a bit more discursive than the new SDK, which focuses more on being a concise reference....

Quote: jayrope wrote on Tue, 09 December 2008 09:49
----------------------------------------------------
> Just n the side of this discussion i was looking for a way to mute certain instances of a poly~, not the complete poly~ including all instances

poly~ inside poly~ and mute