pattrstorage slot recall suspends other Max processes?

    May 26 2013 | 10:51 pm
    Hello. Max 6.1.2 OSx 10.6.8 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 []) 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?

    • May 27 2013 | 2:09 am
      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.
    • May 27 2013 | 3:14 am
      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??