Mattijs

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

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 

bugreport-pattr-loadsequence

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.

Am 31.10.2006 um 23:30 schrieb Mattijs Kneppers:

> 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 

> 1) Save the patch below and re-load it. Nothing appears in the max 

> Windows XP, Max 4.5.7, pattr incremental update 2 oct 2006 (actual 

> build date of the pattr object is 25 sept 2006)

> #P message 31 131 52 9109513 bindto test;

> #P newex 48 105 113 9109513 pattr test @autorestore 0;

> #P newex 31 152 94 9109513 pattr @autorestore 0;

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.

>
> 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
>


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

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.

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.

bugreport: pattr loadsequence