poly~ inside poly~ and mute
Dec 9, 2008 at 9:08am
poly~ inside poly~ and mute
I have a question to those who know the inner workings of max better
I had some strange noises from poly~s within poly~s and just wonder if
Dec 9, 2008 at 9:47am
Quote: stefantiedje wrote on Tue, 09 December 2008 02:08
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….
Dec 9, 2008 at 2:33pm
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.
(see the joined zip file)
i stopped thinking about using poly~s inside poly~s…
what are you trying to do exactly?
Dec 9, 2008 at 3:15pm
> If a poly~ is muted it will write zeros to its outlets as far
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?
Dec 9, 2008 at 3:24pm
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.
Dec 9, 2008 at 3:31pm
> 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!
Dec 9, 2008 at 3:40pm
Quote: jayrope wrote on Tue, 09 December 2008 08:31
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.
Dec 9, 2008 at 4:08pm
Dec 9, 2008 at 4:49pm
> The difference between muting a poly~ and muting a subpatcher
Okay, i understood this now.
thank you very much. how could i read up about those max intestines myself?
Dec 9, 2008 at 6:54pm
Quote: jayrope wrote on Tue, 09 December 2008 09:49
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….
You must be logged in to reply to this topic.