Roman Haefeli wrote:
yo, sorry to drop in. let me just add a little note about the state saving of netpd: it turned out, that it was a mistake to cover both tasks, collecting/setting states and reading/writing data from/to files, in the same system. some people got frustrated, because this system didn't allow them to save their presets in the way/format they wanted. we decided to redo all the state saving stuff and just skip file IO handling part, so that people can choose themselves, what they are going to do with this data. for flexibility's sake, i think the route that SSSAD is following totally makes sense, at least in my opinion.
hi
i am sorry for the inconvenience with the netpd's state saving manager. i wrote 2 systems that should have made life easier when dealing with presets in netpd.
the first was an abstraction that creates names for the netpd-x to load and save presets. a feature is that it can save all instruments, then it makes 1 preset for each instrument.
later i wanted to optimize the system in order to store all data in 1 single preset. also i didn't like that each abstraction carried it's own gui, that made the abstraction very big (40kb)
while i implemented all my desired features into p-admin it happend that the new presets were not compatible with the old one's. instead of <key><value> it was now <instrument><key><value>
it is still possible to use both ways by replacing an abstraction and adjusting the version tag. but that's really not userfriendly. after some talk we decided to downgrade back to the first approach.
the plan at the moment is that one day we use the OSC format. so we could work in a very flexible way with the data. i wonder if people have good experience with OSC or are there any problem one should be aware of? compatibility, bugs, etc?
so actually i just wanted to say i'm sorry if somebody got frustrated because of the preset-manager in netpd :)
here some thinking:
http://www.netpd.org/FutureOfStateSaving
http://www.netpd.org/NextSteps
eni