> 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ß" <[email protected]> > An: "[email protected]" <[email protected]> > 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? > > > > > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
