Problems muting with mute~ begin~ poly~ etc.

zlp

Hi. I'm working on a patch that needs to rewire the MSP network fairly often. (kind of a dna/analog synth evolutionary thing) I used scripting at first, but of course that won't work because of the MSP hiccups during object creation/destruction. So, based on the reference and previous forum talk, I've been telling a poly~ to select one of several possible objects and mute the rest.

Here's the problem: I can't completely remove the unused objects from the DSP chain like scripting does, so my CPU usage is off the charts! I have tried these methods:

1) Use begin~ and selector~
--seems to work except for certain key objects

2) make a subpatcher and use mute~
--outputs zeroes but still uses DSP

3) make a subpatcher and use pcontrol (enable 0)
--same as #2

4) encapsulate it in a poly~ and mute that
--same as #2

5) send "enable 0" directly to the objects in question
--same as #2

I attached a quick demonstration of methods 1 and 2. I know there is debate over the efficacy of using number~ to report if a network is flowing (internal "change" algorithm"?) but when put inside my larger patch (poly~ with many instances), my old scripted version costs maybe 20% and these versions cost 100%+ (kills msp) so I suspect that nothing is really being removed from the DSP chain.

Thanks for any help or insight.

Max Patch

Copy patch and select New From Clipboard in Max.

Roman Thilenius

> 4) encapsulate it in a poly~ and mute that
> --same as #2

but it should not. (use any CPU)

there must be something you are doing wrong.

a turned off poly patcher should use 0.0 CPU even
if 30 audio cables are going into it and its full
of DSP code.

around here using poly~ is the only known way of
safely turning shit on and off.

-110

(karrrlo)

Howdy Zach,
if muting all your synths except one as you described still uses too much DSP ,could it might mean that the issue is in the architecture of the non muted synth itself ?
what happens when all synths are muted ? anything else going on ?

ciao camarade,
k

Quote: zlp wrote on Tue, 05 December 2006 16:43
----------------------------------------------------
> Hi. I'm working on a patch that needs to rewire the MSP network fairly often. (kind of a dna/analog synth evolutionary thing) I used scripting at first, but of course that won't work because of the MSP hiccups during object creation/destruction. So, based on the reference and previous forum talk, I've been telling a poly~ to select one of several possible objects and mute the rest.
>
> Here's the problem: I can't completely remove the unused objects from the DSP chain like scripting does, so my CPU usage is off the charts! I have tried these methods:
>
> 1) Use begin~ and selector~
> --seems to work except for certain key objects
>
> 2) make a subpatcher and use mute~
> --outputs zeroes but still uses DSP
>
> 3) make a subpatcher and use pcontrol (enable 0)
> --same as #2
>
> 4) encapsulate it in a poly~ and mute that
> --same as #2
>
> 5) send "enable 0" directly to the objects in question
> --same as #2
>
> I attached a quick demonstration of methods 1 and 2. I know there is debate over the efficacy of using number~ to report if a network is flowing (internal "change" algorithm"?) but when put inside my larger patch (poly~ with many instances), my old scripted version costs maybe 20% and these versions cost 100%+ (kills msp) so I suspect that nothing is really being removed from the DSP chain.
>
> Thanks for any help or insight.
>

zlp

Good question karl. Perhaps you can shed a little west-coast light on the problem?

I whipped up a tester to directly compare the two systems. It's attached as a zip because there are 11 little patches to get loaded by various poly~s.

It takes 23% CPU to run 10 multiply operators inside the magic muted poly~ structure, but 1% to run them as hardwired multiply objects. (More notes in the patch)

Can anybody find what I'm missing? (beyond the basics: sanity, rationality, etc.)
-zlp

PS - Note the weird behavior of the original (text) patch from my first post. Seems related.

(karrrlo)

hey zach here is the mother patch.
when muting all the instances of your [poly~ operators] except one , dsp takes 3% of cpu so i guess that running ten or more instances quickly goes beyond 20% of cpu.

running a simple *~ between 2 oscillators not included in a poly~ takes 1-2%, 10 copies of this same AM in the same patch takes only 5% . so the issue is somewhere in the poly~.
check each synth individually maybe one of them might be more cpu hungry....
my 1/4 $

Max Patch

Copy patch and select New From Clipboard in Max.

Quote: zlp wrote on Tue, 05 December 2006 20:14
----------------------------------------------------
> Good question karl. Perhaps you can shed a little west-coast light on the problem?
>
> I whipped up a tester to directly compare the two systems. It's attached as a zip because there are 11 little patches to get loaded by various poly~s.
>
> It takes 23% CPU to run 10 multiply operators inside the magic muted poly~ structure, but 1% to run them as hardwired multiply objects. (More notes in the patch)
>
> Can anybody find what I'm missing? (beyond the basics: sanity, rationality, etc.)
> -zlp
>
> PS - Note the weird behavior of the original (text) patch from my first post. Seems related.
----------------------------------------------------

(karrrlo)

....maybe [/~]......

zlp

Uh, that's exactly what I'm saying. Something in the poly~ is using DSP when it's not supposed to. There's no real "synth" in there at all. It's a nested poly~ that looks like this:

The outer poly~ emulates a single operator (like *~). The inner poly~s are simply operator objects with ins and outs, so they can be muted and unmuted depending on whether each one is the "chosen" operator for the outer poly~. That's all there is.

In the zip attached to the last post there should be 2 example patches so you can compare the muted poly~ technique against the hardwired technique. Any thoughts?
-zlp

(karrrlo)

>Something in the poly~ is using DSP when it's not supposed to.

maybe having another poly~ ?
try with your second example patch ( 2 - non-poly test patch.mxb) to insert another poly~ in it ( another operator with ten instances i.e. ). see the difference with a [*~] and then a [/~].
in both cases having a poly~ inside the main poly~ sucks cpu, but the one with the [/~] sucks 10% more on my machine ...
its in the doc somewhere , max/msp does not like divisions and we are advised to use multiplications instead...

Quote: zlp wrote on Tue, 05 December 2006 22:08
----------------------------------------------------
> Uh, that's exactly what I'm saying. Something in the poly~ is using DSP when it's not supposed to. There's no real "synth" in there at all. It's a nested poly~ that looks like this:
>
> The outer poly~ emulates a single operator (like *~). The inner poly~s are simply operator objects with ins and outs, so they can be muted and unmuted depending on whether each one is the "chosen" operator for the outer poly~. That's all there is.
>
> In the zip attached to the last post there should be 2 example patches so you can compare the muted poly~ technique against the hardwired technique. Any thoughts?
> -zlp
----------------------------------------------------

Peter Castine

On 6-Dec-2006, at 1:43, zpoff wrote:

> 1) Use begin~ and selector~
> --seems to work except for certain key objects
>
> 2) make a subpatcher and use mute~
> --outputs zeroes but still uses DSP
>
> 3) make a subpatcher and use pcontrol (enable 0)
> --same as #2
>
> 4) encapsulate it in a poly~ and mute that
> --same as #2
>
> 5) send "enable 0" directly to the objects in question
> --same as #2

Encapsulate in poly~ and send 'mute 0 $1' messages to the poly~
object to turn on and off as needed.

Works here.

And it's documented in poly~.help (bottom left).

-------------- http://www.bek.no/~pcastine/Litter/ -------------
Peter Castine +--> Litter Power & Litter Bundle for Jitter
Universal Binaries on the way
iCE: Sequencing, Recording &
Interface Building for |home | chez nous|
Max/MSP Extremely cool |bei uns | i nostri|
http://www.dspaudio.com/ http://www.castine.de

Mattijs

Quote: zlp wrote on Wed, 06 December 2006 01:43
----------------------------------------------------
> 1) Use begin~ and selector~
> --seems to work except for certain key objects
>
> 2) make a subpatcher and use mute~
> --outputs zeroes but still uses DSP
>
> 3) make a subpatcher and use pcontrol (enable 0)
> --same as #2
>
> 4) encapsulate it in a poly~ and mute that
> --same as #2
>
> 5) send "enable 0" directly to the objects in question
> --same as #2

There is one option you didn't mention (the only one I found reliable so far): build the muteable parts to vst plugins, load them in the vst~ object and mute them with the bypass message.

Mattijs

(karrrlo)

>
> Encapsulate in poly~ and send 'mute 0 $1' messages to the poly~
> object to turn on and off as needed.
>
> Works here.
>
> And it's documented in poly~.help (bottom left).
>
he tried that in his example patches ( see the second set of patches he sent ) + muting all his instances of in his poly~ works as expected. the issue is that even with only one instance of the poly~ running the CPU is above 20% where the content of the poly~s are just basic single signal operations .......

Peter Castine

On 6-Dec-2006, at 18:08, karl-otto von oertzen wrote:

> he tried that in his example patches ( see the second set of
> patches he sent

Actually, what he did was a little different. What I was after is
attached below. However, both Zachary's and my versions should be, in
essence, equally effective.

> the issue is that even with only one instance of the poly~ running
> the CPU is above 20% where the content of the poly~s are just basic
> single signal operations .......

One thing you can do is kill the gate~ objects, which are superfluous
and cost some CPU. That reduced CPU by around 4% on my Intel, should
buy maybe 8% on a G4.

There is still significant overhead in my version. I'm not sure why.
I've used this technique in other, very complex, projects to
successfully reduce CPU demands. It is worth noting the the wrapper
poly~ 'operators' (plural) is more complex than the poly~
'operator' (singular), so in a sense Z's patches 1 and 2 are not an A/
B comparison.

Finally, muting a poly~ will never reduce its CPU demands to absolute
zero. The best you can be done is to reduce to some small fraction of
a percent. But you put 70 of 'em together (as in the example) and it
adds up. Who was it who said "A few billion cycles here, a few
billion cycles there, sooner or later it we're talkin' about real CPU"?

-- P.

(The following is a replacement for the operators file from Zachary's
previous .zip)

Max Patch

Copy patch and select New From Clipboard in Max.

(karrrlo)

>
> One thing you can do is kill the gate~ objects, which are superfluous
> and cost some CPU. That reduced CPU by around 4% on my Intel, should
> buy maybe 8% on a G4.

... i would not have never imagined that a [gate~] would be so "gourmand"...good to know. taking the [gate~s] off reduces the cpu up to 8-10% as you predicted it would on my G4 ... never the less there are still some sudden cpu peaks now the patch oscillates from 16 to 28 % ...

thanks for this clarification Peter.

zlp

Interesting ideas folks. I won't be back to MAX for a few more hours but I'll surely investigate the VST solution that Mattijs suggests. It has come up in previous posts as the only surefire way to bypass DSP objects.

Thanks for nixing the gates, Peter. They're leftover from earlier attempts to get stuff to stop flowing. That should certainly help. It's true that the guts in those poly~s will be more complex than the directly-connected objects, but the only message-math taking place is the rarely-triggered logic to figure out who should get muted. The rest is MSP encapsulated in muted poly~s. Of course, the number~ boxes for testing are outputting messages too, so that will get scrapped. I can't figure a way to avoid nesting the poly~s in this application so I believe I'm stuck with that. (except for VSTs of course)

And on Karl's advice, I'll go with * instead of / where possible.

I'm still extremely curious about why the cycle~ object in the first posted patch refuses to mute when all the others do. For now it's filed under "that little bit of magic that gives max character"!
-zlp

Peter Castine

On 6-Dec-2006, at 21:26, karl-otto von oertzen wrote:

> ... i would not have never imagined that a [gate~] would be so
> "gourmand"...good to know.

You do have 20 of them (2 for each instantiation of the poly~). Also,
I think the 'silent' patch cords may be filled with zeros. All very
simple processing but it adds up.

> taking the [gate~s] off reduces the cpu up to 8-10% as you
> predicted it would on my G4 ... never the less there are still
> some sudden cpu peaks now the patch oscillates from 16 to 28 % ...

You may find the Running CPU Usage 'Extra' from Litter Power helpful
in tracking CPU, particularly when there are stray peaks. It's in the
Starter Pack.

-- P.

zlp

The Plot Thickens!

Now I've got VST doing the work. I used "disable" instead of "bypass" because I didn't want input to echo across to output when muted.

But only one poly~ voice will work. Subsequent voices don't seem to honor the disable requests, so all potential ops are "oping" when I'd rather have just one. In my particular application I don't need more than one voice of any poly~ (the 10-voice versions we have been using so far are for demonstration only). Regardless, is there something I'm missing here. I didn't find anything obvious in the devguide that would explain this but I've missed the obvious before!

When I get time to do a 10-operator test with single-voice poly~s I'll post it for comparison. Till then you'll find the current state of things attached. Cheerio!
-zlp

Stefan Tiedje

zpoff wrote:
> I'm still extremely curious about why the cycle~ object in the first
> posted patch refuses to mute when all the others do. For now it's
> filed under "that little bit of magic that gives max character"! -zlp

When I cut the number of voices in your first patch (the one with the
gate~s) from 10 to 1, I get 2% CPU, thats about the same functionality
as the non poly~ test patch. You never muted ALL the other operators in
the remaining 9 voices the All stay on if you don't mute them. Remeber
that there is a target message to poly~ which is essential for this kind
of stuff. The default target probably is 1, not 0...

If I send a [target 0] message to your [poly~ operators 10] and then hit
one of the operator messages, I get even less than 1% CPU.

I had roughly the same CPU readings as you (Powerbook 1.5 GHz)

If you want to control voices with muting, you need to [loadmess mute
1]->thispoly~ for each poly, if you embed poly~'s into poly~'s you need
to do that for each level...

hope that clarifies the confusion...

Stefan

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

zlp

Now we're getting somewhere! In response to Stefan's post I "flattened" the 10voice poly~ into 10 seperate 1-voice poly~s. (below) It works (6% CPU instead of 23%) I'm unclear about the muting, though, since I was never trying to mute/unmute individual voices of the 10voice "operators" poly~. I was only ever muting the single-voice sub-poly~s inside. Those little guys were being muted by "mute 0 1" as referenced in the poly~ help...

"Turn signal processing on and off using the mute message: mute 1-for-mute, 0-for-non-mute;
mute 0 1 mutes all, mute 0 0 unmutes all"

So I'm still not getting why multiple voices of a poly~ don't mute, even though the muting structure is internal to each. So now I'll redo all the tests with multiple 1-voice poly~s to see if I can get the CPU down even closer to the hardwired version. Thanks all.
-zlp

(this patch requires the "poly muting tests and extensions" zip from earlier in the thread.)

Max Patch

Copy patch and select New From Clipboard in Max.

Stefan Tiedje

zpoff wrote:
> "Turn signal processing on and off using the mute message: mute
> 1-for-mute, 0-for-non-mute; mute 0 1 mutes all,
> mute 0 0 unmutes all"

The mute 0 x message and the muting of single voices is like seperate
commands. If you send mute 0 1, and then mute 1 0, you will not hear
anything, the "mute all" is overriding the single voice mute command.
Play a bit with the help file, as the 3 voices have different pitches
you can easily hear what's going on.
Most important all the voices will be on by default !!!

> So I'm still not getting why multiple voices of a poly~ don't mute,
> even though the muting structure is internal to each.

they do, just don't mix the global mute command with the single ones...
And mute all voices in the poly on load with a mute message to
thispatcher, then switch them on one by one from outside...

Stefan

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