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
- the state can be stored in memory
- 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