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:
- create a numberbox2, set it to "10" and duplicate it: the new number box will be "0"
- 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@uni-weimar.de An: "pd-list@lists.iem.at" pd-list@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list