Frank Barknecht wrote:
Hallo, padawan12 hat gesagt: // padawan12 wrote:
Arrays are not the best thing to use for data persistence. Messages constructed using "set" and then textfiles are preferable. Alexandre Quessy just posted a method yesterday that implements a per patch memory. You might like to study the "bag'o'tricks" GOP abstractions to see another effective example of doing this.
Personally I think, saving state *inside* a patch is The Wrong Thing anyway, except for trivial things like [osc~ 440] or so. Anything else should go in a seperate file. I sometime compare this to using a text editor like Word or Emacs: It isn't useful to be able to only edit one single text document with software like this, so you save every text into a seperate file, but use the same program to edit them all.
Ciao
hi well, i have to disagree there. i don't see any objections to a mixed code/state file. if you only have one fixed synth (or whatever) patch with fixed effect-routes (as monolithic as word or emacs), then keeping the state in different files makes sense, but if you have a patch with a bunch of small modules/abstractions which can be chained in various ways, then the way they are chained (the order of the abstractions) is imo part of the state, too. most of my bagoftricks patches look radically different and i don't save copies of them with only some parameters changed. another bonus for me is ease of use, with clicking pd's save button, i save exactly what i'm working on at the moment, when i load it up later, it sounds the same. only one file to take care of. if you look around at the various music softwares around, you'll notice that their behaviour is very similar to this. an application of seperate file-statesaving within the realm of single file patches is the use of presets for single modules. i don't want to say one way of state saving is per se better than another, but it often depends on what kind of patches you use to determine which way is better suited.
charlie