[PD] Strange behavior of savestate

[Christof Ressi]

> One would expect it to initiate with the default parameters

I certainly wouldn't expect that. copying a patch is really like saving it, the only difference is that the state is saved to a temporary buffer instead of a file.
Most Pd objects don't keep their internal state but some do, e.g. iemguis with init, [array define -k], [text define -k], and [savestate] is one of them.

let me explain this with numberbox2:
1) create a numberbox2, set it to "10" and duplicate it: the new number box will be "0"
2) do the same but with "init" enabled: the new number box will also be "10" 

> instead savestate recalls the parameters from the original abstraction 

that's correct and it's what I would expect.

> and it sends a bang out of its right outlet.

actually, the *original* abstraction sends the bang, because when you copy it, you implicitly also save it.

Christof

PS: I think I just found a bug in [savestate] https://github.com/pure-data/pure-data/issues/636

> Gesendet: Freitag, 17. Mai 2019 um 14:51 Uhr
> Von: "Philipp Schmalfuß" <philipp.schmalfuss at uni-weimar.de>
> An: "pd-list at lists.iem.at" <pd-list at lists.iem.at>
> Betreff: [PD] Strange behavior of savestate
>
> 
> Whenever an abstraction containing savestate is copypasted/duplicated,  
> it'll recall the state of the original.
> 
> to check this, just duplicate one of the abstractions in  
> savestate-help.pd. One would expect it to initiate with the default  
> parameters (0). instead savestate recalls the parameters from the  
> original abstraction and it sends a bang out of its right outlet. This  
> should only happen when the parent patch is saved, right?
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>