Frank,
Each abstraction I create works with ID numbers. So if I want to plop down a mixer strip I'll assign it a number and those numbers are used to identify which filenames to use to store/retrieve values.
If this is all done with Pool (in one settings file or several) the same idea could be applied.
My requirements for state saving are... that the settings files be saved in the path of the parent patch. I don't know if midi channel and CC need to be taken into account with state saving, because that can be taken care of in the argument level of the abstraction...
That's all I can think of at the moment...
David . . David McCallum . Music wants to be free . http://mentalfloss.ca/sintheta .
Frank Barknecht wrote:
Hallo, Regardless of how saving is done technically: What are your and other's requirements in state saving in the light of abstractions?
I think, that a persistable abstraction needs to provide hooks to change its own state, but it also needs to make its state local, so as not to change the state of another instance of the same abstraction.
I guess this all is a typical case for the Memento design pattern. Interestingly while looking for an URL to explain the Memento pattern to those without the Gang of Four book, I found this page:
http://www.agcs.com/supportv2/techpapers/patterns/papers/tutnotes/sld025.htm
where Memento is explained at saving the state of an audio mixer!!
ciao