[PD-dev] presets, a proposal

[guenter geiger]

On Wed, 3 Dec 2003, Krzysztof Czaja wrote:
> hi Guenter,
>
> the main advantage of the proposal is simplicity.  Another
> advantage is, that it is equivalent to the preset api in max, yet
> simpler, and different enough to avoid copyright claims.  Besides,
> it works out-of-the-box (I have already done a preset's prototype,
> in order to test it).

Of course it works. No doubt.

>
> The main point is that both validation, and object selection, is
> done in a client code.  So, it is up to a client code to use
> symbolic ids, once these are available.

But how are you adding a symbolic id to an object outside of pd ?
There is no way you can tell if the object is still the same with just
its classname and coordinates.

> For my part, I do not feel they are needed so badly.  What most
> users expect, is to be able to drop a [preset] object on a patch,
> and click on it.  For more demanding users, there are various ways
> of including or excluding objects.  The [preset] in max includes
> all guis in a patch by default (except [table]), and uses
> connections drawn from its outlets for specifying exceptions.

Does not sound very intuitive to me.

> This is a flat scheme, though -- subpatches and abstractions need
> their own [preset]s (synchronization is pretty easy).
>
> Checking symbolic ids should be just another way, used by another
> client.  Yet another could be based on the 'flags' argument and
> return value of the statefn call, as designed in the proposal
> ``for future use''.
>
> Also with validation, just checking object's serial number against
> its class name should do for recalling from memory.  An additional
> xy check, and a simple warning if failed, seems ok for loading
> from a file.

WIth symbolic ids you get the advantage that it won't fail to
load load states if you just moved the object in the patch.

> There is no danger of corrupting things, because an
> object is guaranteed to handle restoring request -- the requst
> being a simple pd_forwardmess() call, which passes atoms stored by
> the object's class' statefn function.  If this happens to be
> another object of the same class, then a user would probably
> figure out that the edits have been made, without much confusion
> (ask maxers).
>
> Without knowing Miller's opinion, we are probably wasting our
> time, though...

I did not say that your approach is bad. As we have been talking about
this subject already, I know that Miller doesn't like the max approach,
and I have to agree with him.

No matter if you put the logic of doing this into the state saving
client, or if you put it into pd itself. Its still clumsy, checking
class names (which will be the same most of the time), checking
positions (which don't and shouldn't have anything to do with the
object identity).

Serial number change too if you delete objects.

At the end you will probably have perfect error checking, but absolutely
no tolerance (at the same time you could put timestamps onto
the state files and the patch, and if the state is older than
the patch you refuse to load).

These problems could be solved if you have a unique identifier for
the objects, probably automatically generated, but saved in the patch.

Anyhow, I understand that you need your interface for max-style
preset, so I invite you to commit it to the CVS.

(If you do not agree with the CVS, please tell us so, there was
an unanswered mail by hc. about this topic. We can not read your
mind, and your opinion is important)

Guenter

> Krzysztof
>
> guenter geiger wrote:
> ...
> > It is a good thing to have an official API for saving state. In the case
> > of state the API doesn't really help
>
> why is it so, btw?
>