due to the nature of my polysynth patch I can make [polysynth a] and [polysynth b] and have them both load a seperate preset. I haven't added specifying the preset filename to the creation or to the message structure yet but that is doable, you just have to hit the load preset button. currently things like tuning and lfo filenames are not saved with the preset because with pd vanilla i see no way to browse for a textfile in say lfo/pulsar/ to get pulsar1.txt and have the openpanel return that path it more than likeley will return /users/home/billy/dev/polysynth/lfo/pulsar/pulsar1.txt and if that value is saved then when Johnathon gets the preset Johnathon's synth doesn't load the pulsar1.txt
On Sun, Sep 30, 2012 at 9:42 PM, Ivica Ico Bukvic <i...@vt.edu> wrote: > > > > > From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of > Jonathan Wilkes > Sent: Sunday, September 30, 2012 8:46 PM > To: flad chester; pd-list@iem.at > Subject: Re: [PD] Preset system in pd? > > > > Pd-l2ork now has [preset_hub]/[preset_node] for which I'm currently writing > help files. But I don't think it lets you interpolate between values. > > -Jonathan > > > > > > > > To add to this, preset_node and hub are AFAIK the only preset system on pd > that allow for use in conjunction with multiple instances of the same > abstraction (e.g. you want to use two abstractions of same type and have > presets in them that are controlled in the parent patch above them). For an > example, see pd-l2ork K12 module (invoke pd-l2ork with –k12 flag). They also > offer communication between nodes and hub allowing each of the nodes to send > requests to the hub (e.g. any paired node can send a request to the hub to > store and/or recall presets which can lead to some very cool possibilities). > It is in many ways synonymous to pattrstorage in Max, so its contents are > saved as part of the patch, rather than having to save them in a separate > file. Finally, pairing nodes with a hub is simple and does not require any > $0 workarounds. Simply have a [preset_hub foo], and as soon as you add > [preset_node foo] it will automatically pair with the hub provided hub is > positioned hierarchically higher than the node (e.g. in the same canvas or > any of its parent canvases, it does not have to be before preset_node in the > glist if it is located in the same canvas). Other features include, ability > to compensate for infinite undo/redo (pd-l2ork) feature, cut/paste, to > front/back (pd-l2ork feature), and other actions that tend to alter glist > ordering. As a matter of fact, pd-l2ork always preserves glist structure > wherever possible (including infinite undo/redo actions), and since > preset_hub saves all presets as part of its creation arguments, undo/redo > also recreate all saved presets. Preset_hub/node also support every data > format except for pointers (for obvious reasons). > > > > That said, Jonathan is right, the preset_hub and node do not interpolate, > but with some [line] love, this can be easily added to the patch with > arguably better granularity control. > > > > Cheers! > > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list