[PD-dev] saving preset pools in the parent path, rather than the abstraction path?

[Frank Barknecht]

Hallo,
B. Bogart hat gesagt: // B. Bogart wrote:

> Well quite a response here!

Because it's an important topic. 
 
> The bottom line is:
> 
> - For the end user it is annoying to save a state-file in an
> absolute location manually. State-saving should be transparent so
> the user does not have to worry about how it works or where it
> stores files.

But storing state files in absolute places is omnipresent in the
computer world!  Even in music software. If you edit a text in Word or
write a track in Cubase, you always are free to save your work
whereever you want, not only next to some application binary. I iam
sure, that every software user is familiar with this concept. This
also is imporant for reusing one toplevel patch with different state
files. Analog to reusing Word to write more than one text document,
which generally is considered to be useful. ;)

> - abstractions are used in the context of parents. I think it makes
> little sense that each abstraction has its own set of states that
> are not attached to the parent somehow. 

There are uses for this, too. For example data delivered with and used
inside an abstraction should be inside the abstraction (for example
different windows for grains etc.

> When you load the same abstraction in another patch you don't want
> it to still have states from its last parent. You might, but
> considering it is a different context, you probably don't.

In RRADical abstractions itself don't save or restore state *at all*,
only the [caretaker] does this and the [caretaker] belongs in the
toplevel patch. This is the Memento design pattern. 

> - The high-level meaning of a patch is in the top-most parent. This
> is where the ~ user spends performance time. The states of all the
> abstractions are intimately connected to this parent patch, and the
> collection of states for all abstractions are only useful for this
> particular patch (or performance mind-set). For this reason the pool
> has to be associated with the top-most parent.

I agree, that's why it is this way in RRADical. The toplevel patch has
the caretaker object which is only responsible for storing and
restoring state files and only the caretaker is. (Actually it doesn't
have to be in the toplevel patch, it can be in its own separate
patch.) This separation between the state itself and the guy, who is
saving the state, maybe is the single most important concept in
Memento as a design pattern.

> What I was trying to do when writing the request was make memento do
> this:
> 
> * When you load a (parent) patch memento automatically loads the
> pool file saved next to the parent patch, which is assumed to be the
> one last used for this patch.

First: Why? Word doesn't automatically load the last edited document.

Second: This would be no real problem if the toplevel patch knows its
location: Its working directory is the current working directory.
Even if the toplevel patch is not in the current working directory, a
user can load a state file with [openpanel] like the user does it all
the time in Word.

> * The user continues to play with the patch, moving sliders and such. They can
> either re-load the initial states from the pool, or save the changes they have
> made over the previous pool.

This actually is, how it's done in Memento/RRADical.

> When the patch is loaded it loads the last state-file used.
> The user does not ever choose a file to store the values. 

Why shouldn't he choose a file? It avoids needing a Word binary for
every .doc file. I really don't see, why having to open a state file
to work on is less useable than automatic loading of state files which
is, what I'd rather consider to be less usability. I mean, the state
file is just a single document describing a track or similar things.

> Now if you have a bunch of patches in one folder (as we usually do) then one
> patch would stomp over the "presents.dat" (or whatever it is named) created in
> another. So the ideal place to store the presents would be something like:
> 
> [relative top-parent path]/[parent-name]-presets.dat
> eg ./blah.pd saves ./blah-presents.pd

I think, this is too restrictive.

> You email the blah.pd and the blah-present.dat file to a friend, then open the
> patch and like magic the presets are already loaded.

This can be achieved with a not too clever [loadbang] sendung some
messages to [careGUI], if we use something like Guenthers [pwd]
external. However [pwd] must sit in the top-most patch then.

> I don't know if I am on my own here in developing something like pixelTANGO but
> for me user-transparency is more important than developer elegance.

Actually I think, we are really not that far away in what we want to
achieve. To both of us, the user of our patches is the main target
audience, and our target user is not an experienced Pd user. I require
two more clicks to restore state. (BTW: I intend to make this only one
click actually, so LOAD will directly load a file and restore
settings.) However we do not agree on how automatic state saving and
restoring should happen, as should be clear from this discussion. 

> Frank: Now your seeing why I can't accept user-naming of abstractions for
> pixelTANGO.

Well, yes, this looks consistent with your approach to setting state
file locations, however... ;)

Ciao
-- 
 Frank Barknecht                               _ ______footils.org__