personal_username

I'm building a very big patch with lots of nested presets to be recalled, talking about thousands of them. So everytime I change some top-level preset (that controls the others) I have very perceivable slow-downs in my patch, most of the times with perceivable clicks. So far, the only things that comes in my mind is to change every pattrstorages' attribute to "changemode 1" so that only changes will be considered.But still not enough.

I'm building a very big patch with lots of nested presets to be recalled, talking about thousands of them. So everytime I change some top-level preset (that controls the others) I have very perceivable slow-downs in my patch, most of the times with perceivable clicks. So far, the only things that comes in my mind is to change every pattrstorages' attribute to "changemode 1"  so that only changes will be considered.But still not enough.

Hi all, 
I'm building a very big patch with lots of nested presets to be recalled, talking about thousands of them. So everytime I change so

pattrstorage-«in-the-thousands»

Without wanting to discourage you; as much as I love!! the pattr system for it's abilities I frequently run into performance issues when using it excessively. Especially the performance in nested systems (and evem slower when using interpolation with nested pattr systems...)is not very good. I hope very much someone proofs me wrong!!! Beside "changemode 1" the only tip I can think of is reworking your patch, moving all UI to the top level to avoid nested pattrstorages and send the changed values to your subpatches with send/receive. Though this way you may lose control over the order in which parameters are updated in your subpatches....

It would be fantastic to see soem significant performance improvements here!!!

Inclined to agree with Jan's comment, however, from (limited) experience with this issue, one thing that *may* help - if you happen to have a number of pattr-controlled Live UI objects nestled in your patch - is to try enabling the 'Defer Automation Output' and/or increasing the 'Update Limit (ms)' from the default of 1.0. to a (possibly much) greater value via the object Inspector.

Inclined to agree with Jan's comment, however, from (limited) experience with this issue, one thing that *may* help - if you happen to have a number of pattr-controlled Live UI objects nestled in your patch - is to try enabling  the 'Defer Automation Output' and/or increasing the 'Update Limit (ms)' from the default of 1.0. to a (possibly much) greater value via  the object Inspector. 

Thanks guys, I'll try to see how I can improve the performance and update you with hopefully successful (to some degree) improvements. @ spectro: where can I find the "Defer Automation Output"? Couldn't find it in the preferences. Thanks!

Oh, I got an idea, bit before I implement it (spending ours) it might be worth to ping it here :-)

What if I control the timing of every pattrstorage so that this thousands variables will not change at the same time? I will put a variable delay before the pattrstorage index number hits the pattrstorage object. so first subpstcher will have delay 10, a second one delay 20 and so on...

And btw: I still cannot find "defer automation output" setting

Ha, I was about to suggest that final idea previously. I guess I just didn't hit "reply". I think my original reply suggested you divide the stored settings into smaller groups and then toggled them separately according to your needs.

Unfortunately (I guess) the 'defer automation output' is only pertinent to Live UI objects (located in the object inspector). With that said you may want to investigate using [defer] and possibly [deferlow] as an adjunct to, or replacement for using, staggered delays.

In light of that, it may be worth taking a look at this: https://cycling74.com/articles/event-priority-in-max-scheduler-vs-queue

Unfortunately (I guess) the 'defer automation output' is only pertinent to Live UI objects (located in the object inspector).  With that said you may want to investigate using [defer] and possibly [deferlow] as an adjunct to, or replacement for using, staggered delays. 

In light of that, it may be worth taking a look at this: https://cycling74.com/articles/event-priority-in-max-scheduler-vs-queue 

pattrstorage (in the thousands)