Optimization of gate~ : are the signal disabled?
Hi,
I have to optimize a very complex patch and so I ask an help to understand better the behavior of gate~.
When a message (different from 0) is sent to the gate~ this means
that one of the gate~’s outlets will send out the input signal.
If I am not wrong, to all the other outlets a zero signal will be
sent.
Does this mean that all the operations made on the not enabled
outlets are calculated even if the input signal does not arrive?
If so, what do you suggest me in order to avoid unnecessary
calculation after the gate~ object?
Thanks in advance
As far as i can oversee it [gate~] closes all outlets, which are currently inactive. That means that there is not zero signal but NO signal leaving those outlets. Look into the [begin~] object, nevertheless.
jrp
Ok,
I will study poly.
Thank you very much!
> [gate~] does output something on all outlets.
Interesting, Jean-Francois.
What exactly is it, that [gate~] puts out on inactive outlets? in fact a zero signal? This would mean, that having 8 outlets would use 8 times the amount of data *eventually even in 32-bit??) of that single outlet used?
Would it eventually help to cable only the active outlet using a script?
Thanx for the hint with poly~ in any case.
jrp
>> [gate~] does output something on all outlets.
>
> Interesting, Jean-Francois.
> What exactly is it, that [gate~] puts out on inactive outlets? in fact a zero
> signal? This would mean, that having 8 outlets would use 8 times the amount of
> data *eventually even in 32-bit??) of that single outlet used?
Actually, in an audio network in MSP, there is no such thing as an
"inactive" outlet (I ignore things like begin~ / exceptions). If things are
connected, they are part of the network, and MSP evaluates the network as a
whole, every time it needs (defined by signal vector size).
> Would it eventually help to cable only the active outlet using a script?
No, because when you disconnect / connect audio cables, there is a click
because MSP has to learn a completely new network to evaluate. Try it. You
should hear clicks.
> Thanx for the hint with poly~ in any case.
Yes, what is inside a poly~ can be turned off, really turned "inactive".
Good luck, and beware: [poly~] make take quite some
time/effort/tutorial/examples/trials until you are comfortable with it.
Jean-Francois.
This is true of _all_ MSP signals. when the DSP is on, all MSP objects
are in constant communication, and every little yellow patchcord is
sending 44100 zeroes per second if "nothing" is coming through it.
Please look at " How MSP Works - Max patches and the MSP Signal
Network" in the MSP tutorials for further clarification.
M
On Nov 21, 2008, at 15:49, jayrope wrote:
>
>> [gate~] does output something on all outlets.
>
> Interesting, Jean-Francois.
> What exactly is it, that [gate~] puts out on inactive outlets? in
> fact a zero signal? This would mean, that having 8 outlets would use
> 8 times the amount of data *eventually even in 32-bit??) of that
> single outlet used?
> Would it eventually help to cable only the active outlet using a
> script?
>
> Thanx for the hint with poly~ in any case.
>
> jrp
> --
> ---
> fiction-induced heat
> in too many places to name.
> mood description: audiotic.
That is very interesting! Thank you very much.
This actually means, that one can save LOADS of CPU by using scripting.
Thanx again, jrp
when you script MSP objects in and out, you will force the DSP chain
to recreate itself, meaning it turns itself on & off again throughout
your patch, so not really so great. poly~ is really your friend here.
M
On Nov 21, 2008, at 16:35, jayrope wrote:
>
> That is very interesting! Thank you very much.
> This actually means, that one can save LOADS of CPU by using
> scripting.
>
> Thanx again, jrp
> --
> ---
> fiction-induced heat
> in too many places to name.
> mood description: audiotic.
on the subject of begin~.... I like it! I find it very convenient and don't want it to leave. I understand that mute~ might be more flexible but I don't see the need for begin~'s planned obsolescence
Dear all,
I post this patch in oreder to have feedback from you.
I use poly~ to control the amount of CPU for the outlets of gate~.
As you see in the patch I use a select object control the appropriate thispoly~ object. In particular I send the "mute 0" message to the subpatch relative to the outlet enabled by gate~ and the "mute 1" message to all the other subpatch relative to the outlets disabled.
My question is: instead of using the mute messages can I control
thispoly~ with the same signal that is outlet of gate~?
Indeed when the outlet of gate~ is disabled a zero signal is sent; I ask if such a zero signal put as input of thispoly~ has
the effect of disabling the subpatch (and so saving CPU!!!).
I made some test with these 2 approaches, and I controlled the CPU usage. I have not notice any difference.
HELP!!!!
Thanks in advance
Hi!
I have no word to thank you!
Now all it works. Please have a look to the new version of the
patch and please tell if this is the best way to do reach my goal.
I eliminated all the thispoly~ objects.
...so, I have to conclude that when I use the gate~ object I also have to use a select object to enable/disable poly~ in order to save CPU. Is this right? Is there another solution?
Thanks in advance.
Hello,
thank you for the suggestions.
I am not speaking about the gate~ inside the
filters. My question is relative to the gate~ that
select one filter rather than one.
I'd only want to know if it is right to use gate~ and
select together in order to save CPU.
What do you think?
Thanks in advance
Think design first. Then CPU performance.
What about making the same patch without the outside poly~? Just the 2
functional poly~, but at MAIN level?
J-F.
>
> Hello,
> thank you for the suggestions.
>
> I am not speaking about the gate~ inside the
> filters. My question is relative to the gate~ that
> select one filter rather than one.
>
> I'd only want to know if it is right to use gate~ and
> select together in order to save CPU.
>
> What do you think?
>
> Thanks in advance
Hi,
thanks for replying.
I intend what do you want to say and you are right.
I agree with your suggestion of thinking first of all
to the design of the patch.
However that patch I posted was only an example.
Now imagine a subpatch where there are 20 outlets for gate~ each
one process the sound with a different type of fft filter (put
inside a poly~).
The question is if the right way to use gate~ and to save CPU
is using it with the addition of a select object that enable the
DSP in the poly~ in which the gate~ pass the signal.
I was wondering if there is another solution.
Best regards