I have a patch that uses more than 100 phasor~ objects.
They all have line~ and *~ objects turning their amplitudes up and down, off and on.
The patch uses 46% of my pretty nice mac pro CPU.
Is there a way to make a osc~ or phasor~ object stop oscillating when not in use?
Perhaps there is a strategy one could use to turn off whole abstractions.
I am trying to make my program more efficient. Any ideas?

a.d.

hi
[switch~] is what you need to use, but you would have to wrap each phasor/line in a subpatch, or make it into an abstraction and put a switch in each subpatch (an abstraction would already contain one).

Then check that the output is 0, by doing this :
(main subpatch output)
|
[env~ ]
|
[> 0.01]
|
[switch~]

so basically, if the output is more than 0.01 then a 1 is sent to [switch~] which turns processing on. If it is less than 0.01 then it outputs a 0, turning it off.

hope this helps

in this case though, because the amplitude is controlled by [line~] objects, switch~ can be directly controlled with messages. env~ is going to use a lot of unneccessary memory otherwise.

WOW! that worked.
48% down to about 14%, that's pretty significant.

Incidentally, because of the design of my patch, I had a choice between putting one switch~ object in every instance of an abstraction containing 5 phasors and 5 line objects, (1 switch per 5 phasors)

or

adding five switch~ objects in five pd phasorsandwitch subpatches. (1 switch per phasor)

I tried both ways and came out with no significant difference.

...so, that must mean that the switch~ object itself uses some CPU when being turned on and off on the fly. Use it only for stuff that is turned on or off as a setting rather than during actual performance.

Cool!!! is there any place I can find other random tips on optimizing complex PD patches? I'm sure there are other things I can do. Eventually I hope to deploy this on a very small linux machine.

a.d.

The best way i found for optimizing my patches is trying them a couple of times and then being aware of those features i built in - because i tought they would be cool - be never seem to use and throw those out. But then other features seem to creep in...

As far as gui is concerned i've noticed you can go a long way as long as you don't have large tables visually represented. Moving sliders also cause lots of cpu strain. When i started out and wanted e.g. to have an lfo on a parameter, i used to send it to the slider that was already controlling that parameter. Although it's nice to have visual feedback of what's going on, it just consumes too many cycles...

And last but not least, skimming throug a lot of posts here can often point you in directions you didn't think of before...

If you want you can always upload a patch so that others can take a look at it...