ComfortableInClouds

Mess around with the filtergraph, and store different states in pattrstorage. When you try to recall a state, it gives a stack overflow error. yet, the [change] object should prevent a stack overflow from occuring. Why does this happen?

filtergraph-pattrstorage-why-a-stack-overflow-when-using-change-example-given

> Mess around with the filtergraph, and store different states in pattrstorage. When you try to recall a state, it gives a stack overflow error. yet, the [change] object should prevent a stack overflow from occuring. Why does this happen?

I would say that it happens because the numberbox connected to recall 

has a scripting name (and is therefore stored in presets, which is not a 

Kyle Kaplan wrote:
> Take a look at this patch:
>
> Mess around with the filtergraph, and store different states in pattrstorage. When you try to recall a state, it gives a stack overflow error. yet, the [change] object should prevent a stack overflow from occuring. Why does this happen?
>

I would say that it happens because the numberbox connected to recall 
has a scripting name (and is therefore stored in presets, which is not a 
good idea).

I forgot to mention that it's related to the use of the @autoname 1 

attribute of [autopattr] (who will give a name to all ui objects for you).

One should be carefull when using this attr.

I prefer to name myself the objects that will be part of the 

pattrstorage system (and I think that naming "tactical" objects is a 

I forgot to mention that it's related to the use of the @autoname 1 
attribute of [autopattr] (who will give a name to all ui objects for you).
One should be carefull when using this attr.
I prefer to name myself the objects that will be part of the 
pattrstorage system (and I think that naming "tactical" objects is a 
good habit...).

Filtergraph + Pattrstorage: Why A Stack Overflow When Using [change]? (Example given)