Using Delays and Metros and Lines
Mr. Clayton has implored us to use fewer metronomes, delays, lines and other objects that bog the scheduler if we seek better Max performance. My current patch is littered with such objects. It's a real beachball spinner, and I'm running a clean MacMini dual core server. I'm trying to streamline, but frankly, there are a several events that need to repeat at different (multiple-minute) intervals, and several automated fades that require line objects, and I'm at a loss without using a handful of qmetros and delays.
If I use fewer metronomes, I need more delays and vice versa.
Does anyone have any more rule of thumbs when it comes to using these objects (besides "use fewer")?
Oh--and am I correct in understanding that just because a qmetro is sending out a bang every 2 minutes, the object itself (nevermind what it drives) is just as stressful on the scheduler as a 10ms qmetro?
Cuz eitherway, it's keeping track in the background?
As always, y'alls' insights are appreciated.
I'm honestly not sure if it's easier on the CPU, but you could try using [train~] in place of metro.
"Oh--and am I correct in understanding that just because a qmetro is sending out a bang every 2 minutes, the object itself (nevermind what it drives) is just as stressful on the scheduler as a 10ms qmetro?"
That's not the case. I'm really no expert here, but as I understand it, if a patch is triggered by a metro (or qmetro), all objects etc connected to that metro explicitly or otherwise will need to be evaluated by the scheduler which runs at a more or less fixed granularity. (~1ms) This sequence needs to occurs for *each* metro bang. All things being equal, If those bangs are closer together ie 10mS the scheduler will have more to do per unit time (ie in one second) than for a metro or qmetro at 120,000 mS.
As far as dealing with events ocurring at different intervals and rates, You may gain some performance improvements by attempting to derive all your events from a single, master metro (or transport) and using counters and conditional tests (ie == etc to trigger other less frequently occuring events. If events occur over periods of minutes, it may also be possible to use the date function...
HTH
Thanks Spectro. I get what you're saying, but I was wondering about metronomes all alone ("regardless of what they drive"). I suppose I could find out with a really good CPU monitor and a clean system...maybe.
Your proposal for counters and double= "gates" is an interesting idea to try.
and MuShoo--ah! I've never used train~...clever alternative.
I saw a little performance increase last night when I removed message boxes I was using to trace bugs. I know there are other ways to trace bugs, but I like message boxes. But it still draaaaaags. Especially when four line objects are ticking away at once. Maybe I should substitute three of those line objects with expressions enacted on one line's output to get the four different sets of outputs I need. Oh gee! more math!
there is no special trick or rule when to avoid high priority stuff
and when not, you have to decide yourself.
but what i for example do is that i use [defer] wherever something
coming from a [metro] or [line] is going into a GUI object.
in a system where everything is displayer somewhere, this will
at least save about 50% of the data.
you should also carefully try out if a [line 10.] is really required, in
some situations a [line 80.] might do as well.
[delay] is stressing the CPU, but there is no other option if you want
an exact delay. but if you are going to set up delay times which are
"quantized" anyway, you should use the "original" bangs coming from
the main metro instead of having 10 parallel delay objects.
last but not least you might try to set the scheduler to 2 ms instead of 1,
for video at least this should be just fine.
-110
[defer] is a great object! Thanks for that and other suggestions Roman Thilenius.
It does come down to parallel processes, doesn't it. And delays are processes. I think I might be suffering a human-centric bias that delays and very slow beats shouldn't count as work expenditure...!