[PD-dev] presets... why not?

[Frank Barknecht]

Hallo,
guenter geiger hat gesagt: // guenter geiger wrote:

> I think that the real difference in concept, between what are you
> describing and the state external is that
> 
> 1) the state can be stored in memory
> 2) the state(s) are written into a single file
> 
> I see several advantages in this approach:
> - possible to save several state sets
> - its faster to load new states (they are in memory already)
> - the directories don't get polluted by single state files

Yes, and even these 3 (especiall #1 and #3) are major advantages, IMO.

> The idea of having one file per state was to make it easier to
> handle single states outside of pd, renaming, copying etc.
> At the end I didnt use this feature too often, because it was easier
> to do everything from within pd.

Yes, yes, yes, yes! I totally agree. In my older sseq patches, I used
a similar approach to state: Have a lot of states in lots of files,
that get sequenced like: 
 
 [r whichBarToPlay?]
 |
 [float]
 |
 [load $1-sate.seq(
 |
 [sseq ...]

This has proved to be terribly to handle, for reasons you sure could
think of yourself: "Where are these darn sequence-files again?" "What
were the names I gave them 6 weeks ago?" and so on

My proposed version actually makes it easier to move state files
around and share them, because they are a single file and do not
depend on the location in the FS at all.

I think it would be nice to somehow include something like subfolder
or state/preset merging features as well. 

Example: My drum synth angriff comes with three presets: the same
patch algorithm is changed to create snare, hihat, bass drum and clap
sounds just by using another preset (realised as tables here). One
might want to change just the preset of the angriff abstraction,
without affecting the other states. How would such things fit into the
mechanics?

ciao
-- 
 Frank Barknecht                               _ ______footils.org__