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?