bugreport: pattr loadsequence

Oct 31, 2006 at 10:30pm

bugreport: pattr loadsequence

Hi, I experience a problem when

1) loading two pattrs,
2) loadbanging a value into the first pattr,
3) binding the second pattr to the first pattr

The second pattr won’t output the value of the first pattr. When I repeat the sequence after loading, it works fine. Perhaps this has something to do with the autorestore functionality? When looking at the patch in text I see #X prestore 1 0 value;, even though I set @autorestore to 0.

Steps to reproduce:
1) Save the patch below and re-load it. Nothing appears in the max window.
2) press the bang. max window says
test: value
test: value

Expected results:
on load the max window should say
test: value

Windows XP, Max 4.5.7, pattr incremental update 2 oct 2006 (actual build date of the pattr object is 25 sept 2006)

#P newex 55 43 45 9109513 loadbang;
#P button 31 43 15 0;
#P newex 31 175 45 9109513 print test;
#P message 31 131 52 9109513 bindto test;
#P message 48 84 31 9109513 value;
#P newex 31 62 27 9109513 t b b;
#P newex 48 105 113 9109513 pattr test @autorestore 0;
#X prestore 1 0 value;
#P objectname test;
#P newex 31 152 94 9109513 pattr @autorestore 0;
#X prestore 1 0 value;
#P objectname u336000004;
#P connect 3 0 1 0;
#P connect 2 1 3 0;
#P connect 0 0 5 0;
#P connect 4 0 0 0;
#P connect 2 0 4 0;
#P connect 6 0 2 0;
#P connect 7 0 6 0;

Greets,
Mattijs

#28461
Nov 6, 2006 at 1:09pm

Hi Mattijs -

pattr objects play some tricks with the “loadbang” system to ensure
that pattr values get properly registered before pattrstorage asks
for them. This is not likely to change immediately, and what you’re
experiencing is an unfortunate side effect of this. Possibly the
problem can be solved in a future version. For now, I would use the
autorestore mechanism, rather than loadbang, to deal with this.
autorestore is supposed to render loadbang usage unnecessary.

jb

Am 31.10.2006 um 23:30 schrieb Mattijs Kneppers:

>
> Hi, I experience a problem when
>
> 1) loading two pattrs,
> 2) loadbanging a value into the first pattr,
> 3) binding the second pattr to the first pattr
>
> The second pattr won’t output the value of the first pattr. When I
> repeat the sequence after loading, it works fine. Perhaps this has
> something to do with the autorestore functionality? When looking at
> the patch in text I see #X prestore 1 0 value;, even though I set
> @autorestore to 0.
>
> Steps to reproduce:
> 1) Save the patch below and re-load it. Nothing appears in the max
> window.
> 2) press the bang. max window says
> test: value
> test: value
>
> Expected results:
> on load the max window should say
> test: value
>
> Windows XP, Max 4.5.7, pattr incremental update 2 oct 2006 (actual
> build date of the pattr object is 25 sept 2006)
>
> #P newex 55 43 45 9109513 loadbang;
> #P button 31 43 15 0;
> #P newex 31 175 45 9109513 print test;
> #P message 31 131 52 9109513 bindto test;
> #P message 48 84 31 9109513 value;
> #P newex 31 62 27 9109513 t b b;
> #P newex 48 105 113 9109513 pattr test @autorestore 0;
> #X prestore 1 0 value;
> #P objectname test;
> #P newex 31 152 94 9109513 pattr @autorestore 0;
> #X prestore 1 0 value;
> #P objectname u336000004;
> #P connect 3 0 1 0;
> #P connect 2 1 3 0;
> #P connect 0 0 5 0;
> #P connect 4 0 0 0;
> #P connect 2 0 4 0;
> #P connect 6 0 2 0;
> #P connect 7 0 6 0;
>
> Greets,
> Mattijs
> –
> SmadSteck – http://www.smadsteck.nl
> Interactive audiovisual sampling soft- and hardware
>

#87403
Nov 11, 2006 at 9:01pm

Hi Jeremy, thanks for the explanation.

I am afraid autorestore will not help me. I explicitly want the pattr to be bound before patcherargs in other abstractions execute on load.

Here is why I need this functionality:
I bind a pattr to retrieve the value stored in the source pattr. Other abstractions depend on this value being retrieved before they init. loadbang/loadmess always execute before patcherargs. I could use this to implement the required load order, except for the fact that pattr doesn’t output its value when bound by a loadbang.

Cheers,
Mattijs

#87404

You must be logged in to reply to this topic.