state saving
discussion about netpd's future state saving. brain storming, pro/contra, todo list everybody is welcome.
what has happend so far:
- netpd-x see netpd/doc/netpd-x-help.pd
- pad first preset administrator
- padmin second preset administrator, breaks the netpd preset standard
- SplittedPresets
- mMm has a internal state saving system for saving different levels. songs, channels and single modules
----------------------------------------------------------
redesign of netpd's state saving mechanism
it's one of the main design principles of netpd to define and standardize as less as possible in order to keep a maximum of flexibility in userspace. it turned out, that the actual implementation of state saving in netpd doesn't really follow this rule. yet, [netpd-x]? provides a standardized interface to save and restore states of a netpd-patch. though it is very simple and can be used in many different ways, there are some drawbacks with the actual system. the naming scheme of the resulting preset-files is hardcoded and also it's predefined, that every netpd-patch will create its own preset-file. although it is possible to build a preset management system on top of this in userspace, there are certain limitations.
many discussion were held in netpd chat about this topic and the issue resulted even in an alternative preset saving system, which exists in parallel to the netpd preset system and which is not compatible with the netpd system. there was a conflict between two different needs:
unwillingness to work with the existing system because of its limitation
vs.
avoiding any parallelism in order to keep compatibility and to have a unified system
after some discussion it was decided, that this issue can only be solved by redesigning the state saving system in netpd by removing all remaining limitations and reduce it to the very basic functions.
sketch of the new system
- netpd-x doesn't save or read files anymore
- netpd-x does only deliver state data on request
- netpd-x provides an interface to request the patchname
- fileIO is done by the userspace preset administration application
- preset administration is done in userspace
- ...
it would be nice to also save local parameters. that could be useful for:
- mx.masterlevel
- midilearn, midickey, latch-x key
- instrument preference files i.e. font-size, recorder-settings
----------------------------------------------------------
discussion points:
- get and set whole songs (allpatches), single instrument(as usual), children/subgroup (i.e. jamx of an instrument). we would have to agree on a preset-syntax. if we want to store whole songs we have to somehow store the instrument names with the parameters. that could be like P-ADmin? did it or maybe there would be an optimized way. for subgroups we could create a new abs like: netpd-child that is a subgroup of netpd-x.
eerne: fileIO is done by the userspace preset administration application roman do you think we should not discuss that here at all?
if we want to store songs we should sketch how the could/should look like.
example of a classical preset
filename: instrumentname-presetname.pst i.e a-drumkit-test-a1.pst
content: parameter value(s) i.e. clap-release-s 100;
example of P-ADmin? preset
filename: songname i.e. myfirsthcsession
content: instrumentname parameter value(s) i.e a-drumkit clap-release-s 100;
example of a song
filename: ?
content:
instrument tags followed by instrument parameters (unlike P-ADmins? every parameter has prepended instrumentname)