Cycling 74 » Topic: SWOD restoring a patch using pattrstorage

SWOD restoring a patch using pattrstorage

Paul Greyson — Tue, 22 Jan 2008 00:34:14 +0000

In a large patch with many controls, I get a SWOD of variable length (up to 30 seconds) when restoring control values using pattrstorage.

Shark shows that a large amount of time is being spent in sched_purgeqelems.

The patch is driven by a qmetro.

This is a somewhat old version of Max (v4.5)

Any help would be appreciated.

- Paul

Re: SWOD restoring a patch using pattrstorage

(karrrlo) — Tue, 22 Jan 2008 01:30:54 +0000

for starters : check the priority message for pattrstorage ;
you can decide the order in which messages are sent to your pattred elements.

turn interpolations OFF for any GUI that doesnt need any

maybe you can split your UI in several bpatchers having all there own pattrstorage and recalling them one after the other , instead of using one single pattrstorage that stores/recalls everything……

Quote: Paul Greyson wrote on Tue, 22 January 2008 01:34
—————————————————-
> In a large patch with many controls, I get a SWOD of variable length (up to 30 seconds) when restoring control values using pattrstorage.
>
> Shark shows that a large amount of time is being spent in sched_purgeqelems.
>
> The patch is driven by a qmetro.
>
> This is a somewhat old version of Max (v4.5)
>
> Any help would be appreciated.
>
> – Paul
—————————————————-

Re: SWOD restoring a patch using pattrstorage

Paul Greyson — Tue, 22 Jan 2008 03:32:04 +0000

I could probably rework the use of pattrstorage. But 30 seconds to restore the patch seems like a bug.

Oh forgot to mention: the problem seems to get worse over time. i.e., when I first start the patch, restore will take maybe 1/2 second. After several hours, I’m at 30 seconds.

Re: SWOD restoring a patch using pattrstorage

Rocky G — Tue, 22 Jan 2008 08:57:11 +0000

Make sure changemode is enabled.

Consider upgrading to 4.6.3 as there have been several bug fixes in the pattrstorage system since 4.5.

I agree with karrrlo, having one pattrstorage for a complex patch is inadvisable. It doesn’t have to be heinous, you can create multiple pattrstorages and control certain operations such as read and write like so:

#P button 170 46 15 0;
#P newex 206 248 97 196617 s toPattrstorage01;
#P newex 206 227 90 196617 sprintf %s01.xml;
#P newex 105 198 51 196617 tosymbol;
#P newex 105 169 75 196617 sprintf %s %s;
#P newex 165 370 90 196617 sprintf %s04.xml;
#P newex 186 320 90 196617 sprintf %s03.xml;
#P newex 165 392 97 196617 s toPattrstorage04;
#P newex 186 341 97 196617 s toPattrstorage03;
#P newex 204 298 97 196617 s toPattrstorage02;
#P newex 203 278 90 196617 sprintf %s02.xml;
#P message 170 120 44 196617 filepath;
#P newex 170 88 62 196617 prepend set;
#P newex 170 66 76 196617 opendialog fold;
#P message 66 125 35 196617 write;
#P message 35 125 30 196617 read;
#P connect 1 0 11 0;
#P connect 0 0 11 0;
#P connect 11 0 12 0;
#P connect 15 0 2 0;
#P connect 2 0 3 0;
#P connect 4 0 11 1;
#P connect 3 0 4 0;
#P connect 13 0 14 0;
#P connect 5 0 6 0;
#P connect 9 0 7 0;
#P connect 10 0 8 0;
#P connect 12 0 13 0;
#P connect 12 0 5 0;
#P connect 12 0 9 0;
#P connect 12 0 10 0;

Just don’t do a recall on all of them at once! You’ll get slowdowns, lost data etc. as you have already discovered.