On Sun, Dec 17, 2006 at 11:35:58AM +0100, Steffen wrote:
On 17/12/2006, at 5.13, Chris McCormick wrote:
I use these a lot in my own patches at the moment in order to do in- patch state saving of all sliders without any externals. It works very
nicely with no fuss.That and the consensus expressed in other emails in this tread that
the definition of state is subjective might be good reasons for not
implementing state saving? Ie.: We want to save different things, and
we can, isn't that enough?
Well I agree with you for the most part. I think that the existing solutions are enough for me personally, but they're not enough for everyone. What about saving the 'state' of a big list of midi controller changes? And all of the use-cases that Frank presents, too. These make things more complicated.
We've already seen that amazing state saving things can be done with existing internals, so my preference would be for a few small additions to be made to the Pd core vocabulary that allow users to create their own state saving mechanisms using Pd itself. I guess the question then is what are those additions that give the greatest flexibility to people who want to create state saving mechanisms? I think this was addressed best by Frank earlier:
http://lists.puredata.info/pipermail/pd-list/2006-12/045251.html
Whoops, recursive mailing list loop. :)
Another thing related to this; i don't understand why it is so
important to bundle "things" into one file? The freedom that resides
in modularity i (at least) hold quite dear.
I think that it's about having the freedom of choice about which way you'd like to work. Some people want to create custom patches which use lots of their own library abstractions many times, and this feature isn't useful for them. Other people want to distribute their patches to others, and this feature becomes very useful. If the feature is there you can choose.
Chris.
chris@mccormick.cx http://mccormick.cx