[PD] re: state saving

[David NG McCallum]

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