pattrstorage slot recall suspends other Max processes?
I’m working on a patch that’s too much to paste here but I notice that when I send an int into [pattrstorage] that recalls a slot with 610 client objects (mostly [number], some [umenu] and [live.menu]) Max seems to suspend all other operations until the slot is loaded. This includes MIDI output in other patchers that are not clients of the [pattrstorage], [metro] bangs, etc.
The int message to [pattrstorage] is being sent through [deferlow], but the behavior occurs whether or not [deferlow] is used.
The patch is big but does not use much GUI or other cpu intensive stuff. Mostly just numbers and MIDI messages, and not many of those.
This is not a real problem as my patch doesn’t need to stay live while the slot is loading, but I’m curious whether this is a default Max functionality or something else. Anyone know?
I have a similar issue when interpolating between two presets with pattrstorage. I am assuming the scheduler is getting filled up. I tried using pattr objects instead of scripting names with autopattr, and that seems to help some. But I am curious to see what other responses you get.
Well I am certainly using autopattr, but I’m not interpolating, and I have every object exposed to pattr set to "interp none"
I don’t know the reasoning behind [pattr] objects bound to a UI object being more efficient than [autopattr]. I have heard this elsewhere in the forums; can anyone explain?
I am not using [autopattr] for autonaming, simply using [autopattr] to save on clutter of many [pattr] objects and ease of organization. Everything is carefully prioritized within [pattrstorage]. Nothing has a scripting name that is not a needed part of the pattr system. Not sure why the scheduler would overload when recalling 610ish items.
Again, it’s not really critical for this project, but I am curious why the preset recall would suspend MIDI (which is basically echo-ing through Max) output for ~ 2 sec.
As a test to get a similar hang time I needed to generate 4800 random numbers between 0 and 999,999 and store them in a [coll].
Maybe it’s the prioritization??