Reducing CPU load
We developed a synthesizer with MSP for the use with our hardware. Basic concept is like "modding everything with everything". So every parameter of a voice can be modulated by any of the available mod sources. These are Velocity, Key-Position and … All signal based lfos and envelope-generators.
The Oscillators are the ones out of msps library and also seem to use a certain amout of cpu resources, i think because of the really good anti aliasing…
This complex voice structure however leads to a cpu load of 50% when playing 8 voices in a Max For Live Runtime on a Core i7 2.3 GHz retina mac machine …
Quite a lot, but i havent seen any other max synthesizers yet.
What to do to reduce cpu load? I tried replacing the signal envelope gens with control-rate generators, that helped but the ended in poor sound quality … Modulation quality.
So at this time i think i have to deal with that.
Anyone else got some tricks or tips for me to reduce cpu load?
hard to tell without the patch. but when i read the description i think this is what would need about
50% CPU on my ten years old computer, so there is probably some room left for optimisation. ;)
Any chance you’ve got a lot of GUI objects in there to monitor signals and parameters? Loads of these updating in (near) realtime can eat a lot of performance.
I recently found that GUI elements were eating up about 80% CPU in my patch (Max was saying about 30% but looking at activity monitor told a much different story, up in the 120% range). I slowly started pulling GUI elements away (meter~, waveform~ etc.. and now it’s down to 50% in activity monitor). I actually kept meter~ but moved them to a super slow polling rate.
I didn’t realize the massive hit it would have, but it’s worth keeping in mind (and checking activity monitor too as Max only tells you MSP object CPU usage, and not GUI/max/total usage).
I seperated the gui from the rest right at the beginning. The gui isnt a problem at all. In idle state it takes only a few cpu cycles. But the realtime modulation of every parameter with every mod source is quite expemsive.
I will post the patcher later,
1) what versions of maxforlive and live are you running? you need at least 5.1.8 and 8.2.2 respectively, preferably higher.
2) from your description it sounds like you might be using lots of live.remote~s? if so, you need to downsample the modulation signals.
3) in general, downsample all modulation signals.
4) and all voices are inside a properly managed poly~ instance, yes?
1) Both, latest versions …
2) i am not. At all… We wrote externals in c to communicate with our hardware, a keyboard which uses an ethernet connection – with our own protocol – 16 bit velocity and touch sensitive keys –
The externals run in a seperate low priority thread, tested and implemented proper. And not cpu intense in any way
3) hmm … I think controlling is done with a polling rate of 20ms …
4) yes of course, i also inplemented dsp chain management and begin~ network management of some sub-signal-chains (switching osc waveforms).
I just checked my voice once again, did some refactoring and tested one situation: i removed all the controlling and just left the signal path in a default configuration.
Well there it is … Now i know that most of the cpu cycles are lost in the signal path … And i think that optimization just can be done with more writing externals … Which will be done … But in later releases …
Currently i am on my way back to my office and will finally upload the voice patcher to let you get more into it!
Ah! And the begin~ signal management doesn’t seem to work within a poly~ instanciated patcher … Leaving just the begin~ objects out, cpu load goes a little bit down…
May be I’m wrong…but with your new MBP and may be you just dump a tons of soundlibrary,from your ex laptop…may be spotlight do something and may be iPhoto trying to faces your photos ….. but hey 50%load on production is acceptable right ….
Do GUI elements that are not visible, in subpatchers for example, also consume unnecessary amounts of CPU?
In many of the unseen subpatchers of a project I’m working on I have float and message boxes so things look clearer when I open it up to look at what’s going on, and I’m wondering if I should delete these.
chris muir’s benchmark test is always a good approach to find these things out. i use it constantly. running the following, you’ll see that there’s no difference between seemingly "hidden" and visible GUI elements. avoid them when you can.
-- Pasted Max Patch, click to expand. --Copy all of the following text. Then, in Max, select New From Clipboard.----------begin_max5_patcher---------- 2687.3oc6cs0iqZqE94L+JP44oagM2Ouc1pUsaod4gdQGo1pHRByLzRfHfLc Z2p+2O1XSFLfASfPRlYMOjnwba4Oau7ZY72W97cKVtN4kfrkZ+GseUawhOe2 hEEEQKXA++Wrbm+Kah7yJNskaR1sKHNe48rikG7RdQ4+1xu4Se4W9Ue+usT6 6+4u6i+v+q7L16mu4ov3GWkFrIm8jLsveP+dMSCS5WHSD8KL4SsemeQwG1EF GEjW7LQ7BC2V7jRV+GeA1n71+PRbdr+tfhC8KAoa8i8W95cI4Pd4sQmWZV9e GwN8p2irv+onPD0z3VdZPFop5mGlDW05scXVuM8Kc9GZ+N8h926ti9w8iDL+ kO8ie5ie6WwQRsNfRjt.ThbFNTpe4fROlw6nOZjjXeqCR6BnLbo2eC6hGoUw CCiGBN85MOk.R4AoqBh8Wyp+5sBSXovD6jx+68ALqib.skq8ieb4Ys1issne 4vFvYLfZOBoRujyMzbRcxNV2wmswq+XteZtVdPVd+CUQNdzurcG7HUD9xMR8 nwe9b5kGRpPxgOrSgKNrYwC2X3N5P1WN3qz3Yl8nfuGhRH1XW8y7LXOqh9Yr daCartyXGqSaS2jDkjxrHA26jNQh1RKdEV+nvUaafLbLJtv6E+2i2mlMPOkm FJbWbcnWrKl9I1T7xeHIcmeA9YOZ2P0etNV2K7Y0mqrQakMgiez15C44Iwcz cw0nhWIrd4mp2aws8gNH08vKBqRvjR6b7PRbveQL7F9e1qsNHdyS67S+yUTe Qo8BZXTwzoH7ILFya3NiLFHhR5vFR8yV3yf169zl+rrtVa5ypfSPJGt43M4Q DFE7bPZF4VUAAVrze+9JEunxkPaj9C1nFm6OVTXLqH8iEkF7bX40acrT+TRS TNwlOjxflWbKc2SuMIaCRiODVXJrBIcWtq7FdzKMhOIWwWF7focbds5RcMEk r4OC1V0nVlrOHNLtJ9Ib3sAO3eHJeU63t3weveSfzKVR+jEKeLMbaRL0LDPa ZwkOPhWEVuUqpUmhyH1eeKWLoaJAYjbvLR07P1Z+TZiA26Ot7f4IIQhG530E E7PN+v6Ciiqgi4I6kevzvGepiqccB4f655dWbjrUGhYGcEwgP9pL+mEw6b+n HtGBwa+K9wgjIIBJhSgVc0OdP1LfOksIMIJRn9xNxysbjsj9waB9qvs4OU7f p1cfb5g6K6Fs7Xq71vGogXJTVt+iYhkzv8.onCq4iSWkGraeDoVHdBBKCP0A kU8kJTdMepLOPGGw0tWS9rZXV5GVkedr2nLGmxRESd.aR.BZokgeRK+SwaCd YY4wJlFg6a3DgAgoVpM8BqAvO8wLRzzj+5CrJbBwm0CaVObWkAKT0mSWNQjF NVGfYqQIsTvFq6zaBQagPgkFNLa0EPtEIb4c5.oyP.xNhNdXQH2SyRsHkcbM MPlz6hmGI5jhHdcLn+07l1dK5PBat8PmUL74NhDQ8vnmmgtG9mPkFxxVHSjd QbCrtcc2SC2dOMW7oOl0X3iYKCVrZPiy0P3NP8bs0ZqUBwsJ.bjgwIO110ZV 8RJf3yETKjInzUYQGUcM4ajNn5HpsbDCchH1jNdWI3.YYMQvgyUNbzUjKZa1 enZFw8gV1ESxxVqYj2o3.zU5vw+aZnezjhkhIG2bTH5CVdVHWm508WS5UDWk l7qrDfqc4skHrjjgkmPb+IEKKwXgjiqkfrEKncjKKOYOmiKpYU3q8jjUHQY4 IK2rMn6rlkm4b89OxxcVs7m6IG5dyit2bo6Ie59yot27pUH2ZUxudH4X2Qd1 8lqc24a2cN2cm2cm4dKK+61yAWt6m9yEu87wq6inta8FGuu7yk4Cm+hjcLjm idmS50U5mcmudGfV871IQnFj9rejVXr1tLsvLszf8Io4Aa0H3ZvxpW4w4FEm ebr.Zi4KEmybsFRAvtLUA16BzosnKFDXiq+L610WmSe1SyQ2Khe2yjd4adHA zrgNEk5sQH8hAFV1itQx3B1H0LVmq4Vouf3cVcWVlEtrLvevRkFHr7FHSnAZ R8xY5NoN4r.mbStSNSG5nloyGmMLDprQp.uTedFSmgD3kt7l.mYdPP03ynmg VFIqiLMRD7j5ole7VdLZjv03Qus7JB8Y9nlLv28xC99Tnli9pf3h4zFEF2WB HEnH875t4HK4P5lRqmGjpVSjkj3UdX7wkD3WOFqTKm6Sga2FD2VSv1vLZter LSOotWmZsxX.0JyalZk4.pUnalZk0.pU12L0J6A1CDcSTqbFPsBeyzV4NfZk 0YpV85qOPX8dWRWstsqXqZ4J+77zv0GxYSFz1hceRqXVuKt6iQIq8i3KT1w. GUY80dcw3tqYEeBdQI0inP9qkjuoMTXetnK40f3cNdoQR1KLecxTtQXTZ+.w goQuef7zmpMDzGIPT1riC72a1D.DnoBH9I5Bu2BN75NGrQDhuBMs4UrB.0va XiHGj3IjtuHDm1pc2fs6BryVygZxElBVAatwbRWVSFoBLaqnMuKb69DRtE7t ArslMxvtXE3P5EKo.8+DelySEUk9ST+FWKMNVCYLvUjMqTGJmqGa1VUb185w WiyPr4qDb1UQa141yj8PWO1rmpcMrlHalm0PYFC8ksvmOk8zd2TcnyLCZa2u WKi.VkYh3LTWrb2ky3Xa96kZnLN1YnbR7sDWbr7p7VWsYj9zzU+5iJNBuLCf HN.QbtrDwQPJ.j4ZhI+AHc810BgSiHN8Q4gIgaIS+FeUk0ygAQblme7yAudN S6VhV9R4LaItqZvz3anfOtPwWzmBd3xzLGtBdXObFGabMqfGmCDiG+0oq4IF 5usPrQodIbMa5zUuDr44T9MlOcHwFORcHAackAD8pnHVliTQQv1fhhbtUTjy g1fXZLRwAA6LUhCxkQmOLMFqPefcuBE5CPyN.M6.Vp.PyN.M6.zrCPyN.M6. zrCPyN.M6.zrCPyN.M6.zrCPyN.M6.zrCPyN.M6.zrCPyN.M6.zrCPyN.M6. zrCPyN.M6.zrCPyNdGpYGWC7UGzVf2y5.waSM63so9p71TKbtFzsHPyN.M6. zrCPyNt7Z1w7y732oL79FjH82h5UvsntPbKp+F2h5bxsndx7tRretsDhoYWt qdmpYGihuitH6Qx2Q7aC9N5woQ6oy2QzsFeG8zcF4uf5F.eGuE46nCa2wMhe LzMus46HG.FyOr4V.eGOm7cDgYQdYXZCDdDH7HP3Qfvi.gGABOBDdDH7HP3Q fvi.gGABOBDdDH7HP3Qfvi.gGABOBDdDH7HP3Qfvi.gGABOBDdDH7HP3Qfvi .gGABOBDdDH7HP3Qfvi.gGABOBDdDH7HP3Qfvi.gGABOBDdDH7HP3Qfvi.gG ABOBDd7swOR4g8+yJJ+GobrWQmao+Hkiax2GqQS3I1N4rR0s3YKF5Fq1WueG GCZlNtPGNUV0tl8yZ1GqQigplCREyAOeliqBlCxa9rGupNzjYONyq8f5ydPy l8XnqP607AOXWEfmZ17Y2d5q6C1d9rGGUFs6NecmsTo8BMu1SuC2MlO6wTE2 gm5rEr4xpseZolRs8Oas8May8Kq78Ia88GK4I+u28+8z3TbK -----------end_max5_patcher-----------
ha! this is crazy! – as for my observation: only after opening the (2nd) patcher with the numbox inside, it starts increasing in CPU load. i’ll post that to a new thread as i can’t explain this (:
Hi! I realized a multiconvolver patch and I am having the same problem with the waste of CPU in realtime. It increases in a crazy way, sometimes having some very unusual peaks, as 90-95%. In average it takes 20-30% but it takes some peaks of 96 and 100% for a pair of second. Something must be wrong. I am using 12 convolvers, and yes, I realize that its a big number of realtime processing. I used the mute and pass objects to close the subpatches reducing the processes, but it keeps eating the memory up in a such terrible way, so it doesnt work. Can anyone help me to optimize the memory?
Forums > MaxMSP