[PD] Strange behavior of savestate
christof.ressi at gmx.at
Fri May 17 17:11:13 CEST 2019
> 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.
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
More information about the Pd-list