Help! my patch is Ggginourmous
Sep 21, 2010 at 8:56pm
Help! my patch is Ggginourmous
Now, I know I’m no Max ninja, and never been in all my life a master of optimization.
What my patch is about:
- a main patch with three big subpatches/tracks. When one track is ON other ones are OFF. I use mute~ and a lot of gates to make sure nothing is running on those excluded ones. I think mute~ will erase patchcord cpu load as soon it is placed.
What i know of optimization (random order):
1) dump graphic elements.
2) use poly~.
3) See CPU load with Shark.
4) Have the main patch recall the tracks JUST as you need them.
6) ask the forum if you find smarter people.
Sep 22, 2010 at 8:15am
1) Every bit helps. You might get away with replacing every bang button with [t b] using search-replace in a text editor. But make a backup first :P
2) Why can’t you use poly? It would help if at least the three big patches can be put into a poly to enable distribution across multiple processor cores.
4) Signals can cross-communicate between patches with send~ and receive~, and there can be multiple patches (even files) in one application. So I don’t understand why you can’t split your patch into multiple parts.
2/4) You can do dynamic loading of patches with poly, and dynamic creation of objects and connections with scripting and thispatcher. So there is always a way to have stuff load only when it is needed.
7) The solution of the rich and lazy: get a faster computer.
Sep 23, 2010 at 10:39am
Anyway: thanks a lot. Your answer was helping ;-)
Sep 24, 2010 at 6:59am
Just a question (I am optimising as well here): the t b object is the same as teh bang object but would occupy less CPU? So if I replace my bang objects with this tb object iit should have a good influence on the CPUload right?
Sep 24, 2010 at 7:27am
I think every bit helps, as said. So there’s no GUI element for the bang, and it doesn’t light up (even when hidden they are tracked, apparently). Same goes for storing numbers in number boxes versus the [i] object, etc.
I really wouldn’t do a search/replace for “bang” in your patch-as-text. This might work fine for other replaces, but “bang” can be found in many other places besides just the object name. Many inlet/outlet types are bang as well, and replacing them would be… well, not good probably :)
Just copy a [t b] and find all the bangs, select, paste-replace. You’ll probably find other things to optimize as well.
Might be a nice to have a message to [thispatcher]: “select
Sep 24, 2010 at 11:32am
My two cents:
When you say that your patch eats up 60% CPU, are you referring to the DSP load as it appears the dsp status window, or the overall CPU usage as reported by Activity Monitor? In the former case, your first concern should be optimizing the DSP chain (and I’d beware of send~/receive~s, they do cost while patch cords don’t), and not worrying too much about the rest of your patch. In the other case, you might want to check if there is any data paths you can defer – as long as you have overdrive on, this could help a lot.
But I can tell you that I have had patches eating 70-75% without any trouble; and usually you don’t have a great performance loss lowering your v/s from 4096 to, say, 1024 or 512… so, my first point is: to what end do you really need to lower your CPU usage?
Sharking is something worth doing – in some cases, it may clearly show you what are the resource hogs in your patch, and you might be so lucky to figure out a replacement.
Sure buttons are more costly than [t b]s. But if they’re hidden the overhead should be very small – in fact, the painting routine is only performed when there is something to paint. I don’t think replacing them can make a great difference, unless you have hundreds.
Sep 24, 2010 at 11:58pm
Instead of opening different apps try using [poly~] and voice management. This way you can stop any DSP processing from taking place in inactive subpatches but getting everything organised is much easier. If you have lots of effects that you use in different places you might want to look into [matrix~] so you can route everything into that effect. It will mean you have less instances running which will help reduce the strain. You can use [poly~] to load and replace subpatches without breaking the DSP chain, so it’s great for re-ordering effects on-the-fly.
Sep 26, 2010 at 5:33pm
thanks a lot for the informations. I was away for work so hadn’t had the opportunity to test everything, but I think I have much more things to tinker with ;-)
sooo, thanks all!
Sep 27, 2010 at 4:37pm
well, I have no ready-made recipe for optimizing the DSP chain…
about send~/receive~: you should think that a patch cord doesn’t have any inherent cost, while send~ and receive~ do – because they are objects, and objects always do some work. of course it’s not a huge cost, but if you have a lot of them and try to replace them with patch cords you may notice the difference. you can’t always do it, though: send~/receive~ allow feedback loops (with one vector of latency) and communication through the poly~ and pfft~ boundaries, which is not the case with patch cords.
Sep 27, 2010 at 10:14pm
“about send~/receive~: you should think that a patch cord doesn’t have any inherent cost, while send~ and receive~ do – because they are objects, and objects always do some work.”
because they interrupt the signal == it is like having 2 connections.
time to remind the community that [send] will also transport a signal – without extra cost.
You must be logged in to reply to this topic.