Help! my patch is Ggginourmous
hi all!
i’m working on a very big patch which consumes at 4096 vector size at last 60% CPU.
Now, I know I’m no Max ninja, and never been in all my life a master of optimization.
My point is now I *need* to become one.
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.
I got lots of sliders, bangs, and some tables. But I think (remember, not a ninja) one msp patchcords needs a lot more cpu then 1000 bangs. So i think I better try to optimize cords. I’m using a lot of reverbs and feedbacks, btw.
2) use poly~.
ok, I can’t use poly
3) See CPU load with Shark.
I yet have to try it.
4) Have the main patch recall the tracks JUST as you need them.
I can’t. I need to have Max applications: i would need to have one main app + three apps. But signals can’t cross communicate between apps.
6) ask the forum if you find smarter people.
ok, let’s try it
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.
7.1) What audio driver are you using? On windows, switching to a low latency driver type like Asio from MME or DirectSound can have a significant effect on the processor load for audio calculations.
Thanks EMV,
precious informations.
1) I’ll try with replacing bangs etc., althought I never though of doing that directly on the patch text file. way quickier ;-)
2) I know poly to be a solution for polyphonic instruments, like synths etc., I don’t know really how poly~ could be used in my case… for istance, I have MIDI notes that trigger external samplers and come back. plus i use [fluidsynth] for playing several soundfonts (perhaps I could use it here?).
One thing I noticed is multiple istances of the same fx object, like multiple reverbs and resonators… I think I’m gonna have a matrix. I think It’s much more CPU saving…
4, 3 is missing) Yes, signals can cross-communicate between patches, but not different applications… what i did is to have one main app that when asked opens the track app with [adc~] inside. In the meanwhile the tracks closes the main app. So i have one thing at a time, and i must say it helps saving CPU.
2/4) For this point I need to study more… *_* never tried to dinamically do that, so I’ll do some research…
7, i like random lists) Yes, I’m working on that ;-)
7.1) Good point: I’m using a M-Audio 410, I think it’s very entry level. But this take us back to point 7.
Anyway: thanks a lot. Your answer was helping ;-)
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?
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
Hi.
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.
HTH,
aa
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.
lh
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 ;-)
@ andrea: it’s on the activity monitor. But i don’t get what you mean when you sey to optimize the DSP chain… also, do you mean send~ is more heavier than an audio MSP cord?
@ Luke: mmm.. this use of poly~ is very interesting. sure i need to discover more about it. and yes, I’ll use matrix~ :-)
sooo, thanks all!
well, I have no ready-made recipe for optimizing the DSP chain…
you might find out that you have very expensive object you can get rid of – e.g. spectroscope~s
or that you can use simpler ways to achieve the same result – in some cases you can use onepole~ instead of biquad~, or do FFT things in cartesian coordinates instead than polar coordinates
or that you can downsample parts of your patch (poly~ allows you to do it)
or …
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.
aa
"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.