Holiday notice: Cycling '74 will be closed 3 July, 2020. Manual authorization, support cases, and manual order processing will be delayed.
would disabling a few hundred simple objects reduce CPU strain signifacantly?
Jul 14 2018 | 5:48 pm
i've been building a maxforlive device since quite a while now as part of my thesis.
now that the device is almost complete, i copied it 7 more times (as there will be an option to use 8 instances of it simultaneously) and realised that the cpu utilisation reaches high levels when all 8 instances are active.
it's still usable, but not when small buffer sizes are selected.
there is something i could do to try and make the devices "lighter", but it would take some redesigning and i'm running out of time, so i would like to be sure it will have an impact before proceeding.
so, what i could do is this:
block input to 35 [+ ] objects and 35 [live.numbox] objects for each of the 8 devices, meaning there will be 35*8 = 280 less addition calculations and 280 less [live.numbox]'s receiving and outputing the result (when all 8 instances are active).
does anyone know if this would have any noticable reduction in cpu strain, or are the [+ ] and [live.numbox] objects negligable when it comes to cpu consumption?
and would removing these objects completely instead of just blocking their input, improve things further (loading times/ cpu consumption).
i am not certain at what rate the input values are being refreshed.
the data being received is coming from a wiimote and nunchuck through open sound control and being converted to integers before entering the [+ ] objects.
- Jul 14 2018 | 11:44 pmthere are two things which are expensive: - audio objects - hundreds of "simultanous" messages under scheduler conditions, no matter where they are going to. regarding your live numberboxes, you would first notice sluggish GUI with low redraw rate before you see CPU spikes in live or the OS.
- Jul 15 2018 | 9:32 amI've never used the mfl interface, so I don't know if this is relevant or an option, but if you encapsulate your processes in a poly and use @parallel 1 attribute, it will allow DSP processes to occur on multiple threads; you can also do downsampling with a poly~ if that's acceptable. You can also turn off instance-specific processes in a poly~ if they're not being used (ie if only a certain number of instances are being used at a particular time.)
- Jul 15 2018 | 12:49 pm@ roman: if i recall correctly, the Live GUI was getting sluggish after adding more and more active instances of the device. i will check again next time i test it. thanks for the tip.@ floating point: good to know this (especially if it also works in max for live), but each device is nested on a different Live Track anyway, so they are not all processed by the same core. generally there are no signal rate objects used (no MSP objects), just the wii accelerometer data for 4 different motions being fed into a bunch of simple objects for routing/scaling and a lot of UI objects as well. i'm not sure at what rate the wii data is being refreshed, however it is being received in maxforlive through OSC. does anyone know what is the "refresh rate" of OSC messages?
- Jul 15 2018 | 3:36 pmA wise person once said to me: Max craps out if things get extremely complicated.
- Jul 15 2018 | 9:18 pmOSC is UDP but that still means it can transport a lot of data. you should check the manual of your controller or measure the data in max (counter or accum will do that) to find that out.if it is too much for some reason, [speedlim] can be of help.
- Jul 18 2018 | 11:29 am@audiomatt: yes, i guess i will have to simply things a bit. also for cpu performance reasons and also 'cause an over-bloated user interface defeats it's purpose in the first place.@ roman: thanks for pointing at these objects, they will be quite useful to me. also i remember there was one way to check if certain objects or sub-patchers were straining the cpu. i don't remember if it was an option in max or a an external object someone had posted, but i seem to remember seeing a red frame or something like that around the problematic objects. does anyone know what i'm talking about? i thought i had it in my bookmarks somewhere but can't find it.
- Jul 18 2018 | 1:34 pmbeside such fancy options you can check what a poly~ patcher eats by turning it off and looking at the CPU meter in DSP prefs. :) for other kinds of subcircuits (first make sure you have a safety copy and then) delete/undo parts of your patch.
- Jul 18 2018 | 8:00 pmin max 7 my ...thing... works much better than in max4 now, but still not perfect. i guess i decide against auto-on for now.
- Jul 20 2018 | 5:02 pmi was told that UI elements consume more cpu than non-UI elements, possibly even if they are not visible. is this true?and what does "visible" actually mean? for example, if they are not in presentation mode? and what about being in presentation mode on a M4L device, but on a track that is not visible in the displayed area at the moment? i have been using mostly UI versions of gates and switches for the routing system, most of which are not in visible in the presentation mode. would replacing them with non-UI objects such as [gate] or [select] reduce CPU load, even if all these objects are not visible in the presentation? ps: roman i didn't understand your last post, was it intended for a different thread maybe?
- Jul 21 2018 | 12:26 pmIn older max versions one could count that GUI objects would not consume as much CPU if they were hidden, by whatever means. I have no idea if that is true today, but I guess so. Visible means - You see it, or at least it is meant to be seen on the screen, even if it is offscreen. gate is more light than ggate, and anyway any object that can do more than You really need, and can be replaced with a simpler version is a worse choice when it comes to efficency.
