Chadwick Wood

In the past I'd made some patches that use large amounts (a couple hundred) of UI objects to create sequencers. All of the UI objects all belong to a single pattrstorage instance via an autopattr.

I was running into problems where doing preset switching would get very slow. Now, I've read through other forum posts about this, and I understand that update hundreds of objects at the same time can get slow depending on all the stuff they're triggering, but I *also* wondered if this was partly a threading issue as well.

So I guess this is a question for Cycling '74 folks (I dunno that others could answer it), but is something like the pasted patch below more performant? The approach I'm trying now is, instead of having the UI object itself be part of the pattr system, I instead have a separate pattr box for every value I want to store, and a corresponding UI object that when changed updates the pattr box.

And, the pattr box is then connected to a "set $1" message that goes back into the UI object, with a deferlow in between them.

My thinking is that this allows the triggering of the preset switch to happen without the UI updates having to happen at the same time (thanks to the deferlow, they can happen whenever Max is done with the high-priority stuff for the scheduler in Overdrive).

Should this approach actually get better performance, or is it a waste of time? Basically, when a UI object (e.g. live.dial) is directly part of the pattr system, does it internally "know" to defer the UI updates to after the (I would assume) more important work of updating the value and triggering whatever should happen next?

comment

live.dial

deferlow

message

pattr

And, the pattr box is then connected to a "set $1" message that goes back into the UI object, with a deferlow  in between them.

In the past I'd made some patches that use large amounts (a couple hundred) of UI objects to create sequencers. All of the UI objects all be

pattr-performance-question-with-ui-objects

i dont see what deferlow or set would be doing here, but i can assure you that the performance problems are not caused by the stuff which happens in the graphics thread.

i run presets using a custom list-transformation of all parameters with hundreds of pictureslider objects on a 20 years old computer and everything is immediately updated, including the GUI itself.


i dont see what deferlow or set would be doing here, but i can assure you that the performance problems are not caused by the stuff which happens in the graphics thread.

i run presets using a custom list-transformation of all parameters with hundreds of pictureslider objects on a 20 years old computer and everything is immediately updated, including the GUI itself.


This is meant to be used in the context of having a pattrstorage and lots of preset changes happening. So when a preset is recalled, the pattr box's value will update, and that will trigger the "set $1" which then updates the UI object to match, without triggering the UI object to output its value, because that would trigger a feedback loop (UI object updates pattr, pattr updates UI object, etc).

The deferlow is there to make sure that the UI object update, which will happen when a preset is recalled, can be deferred to after whatever may happen from the actual updating of the value in the pattr box.

It's not "slow GUI updates" that is the slowness I've encountered... it's the scheduler temporarily seizing up during a preset switch, causing audio problems.

Anyway regardless of what the culprit is in my specific patches, my question still remains as to whether this approach I'm outlining does indeed allow GUI updates to be deferred, thus allowing other message-related patch update logic to get prioritized... or whether the UI objects handle that internally anyway!

This is meant to be used in the context of having a pattrstorage and lots of  preset changes happening. So when a preset is recalled, the pattr box's value will update, and that will trigger the "set $1" which then updates the UI object to match, without triggering the UI object to output its value, because that would trigger a feedback loop (UI object updates pattr, pattr updates UI object, etc).

For more context if it helps, what I'm often doing is having a metro going into a counter that drives a step sequencer, and that step sequencer in turn is recalling presets in a subpatch, which in turn is recalling other presets in multiple subpatches, etc. Basically a big tree of preset recalls at multiple levels of the patch. I found that on the steps that triggered preset changes, sometimes the timing would be noticeably off/slow.

Here is a patch with a few more comments that might give better context for what I'm talking about.

pattr performance question with UI objects