[PD-dev] presets, a proposal

[B. Bogart]

I think unique IDs for the objects makes sense. I've had to do this for my
OSC abstractions (am using the first creation argument currently). I see a
symbol_id for each abstraction (or gui object?) as giving these benifits:

possibility of namespaces for the abstractions, useful for OSC etc..
Adds the possibility (in the future) of making dynamic object connections
much easier.

It would be great that the symbol be accessible iside pd via a new $
variable.

Sounds good...

Ben
----- Original Message -----
From: "guenter geiger" <geiger at xdv.org>
To: "Krzysztof Czaja" <czaja at chopin.edu.pl>
Cc: "Frank Barknecht" <fbar at footils.org>; "pd-dev" <pd-dev at iem.kug.ac.at>
Sent: Tuesday, December 02, 2003 1:22 PM
Subject: Re: [PD-dev] presets, a proposal


> On Tue, 2 Dec 2003, Krzysztof Czaja wrote:
> > hi Frank,
> >
> > these changes are for enabling external devs to code [preset],
> > [state], etc.
> >
> > [preset]'s user would just create a [preset] object, and click
> > (shift-click for storing) on its slots, or control the thing with
> > messages.
>
> Hi
>
> It is a good thing to have an official API for saving state. In the case
> of state the API doesn't really help (Well, it does if I wanted to save
> the sliders and GUIs from PD, but this is not the main problem yet).
>
> The important question is how to make the system robust against
> later edits of the patch and how to make it possible to include
> more than one abstraction that has state saving in a patch.
>
> This can not be solved with the object position and class name.
> Position has the problem that you can not move the object afterwards,
> the class name is too general (there will be only few, number, slider,
> toggle).
>
> My experience when working with state is, that most of the time you
> do not want all the GUI's to be saved. This let me to the idea that
> in order to make one of the GUI objects save its state, it should have
> an unique identifier (more than position and class name), one that can
> be set in the settings dialog.
>
> If every object has a settable "save-symbol", we solve both problems.
> Only objects with save-symbols are saved, and we can identify them
> upon loading easily.
>
> The next problem is with multiple abstractions of the same type in one
> patch. In this case, the state(preset . whatever) itself has a parameter
> that can be changed per abstraction (either as an argument or via a set
> message). This way we can distinguish several abstractions.
>
> This would mean the addition of a save_symbol for every saveable object
> within pd, together with the API K. suggested.
>
> Does this make sense ?
>
> Guenter
>
> >
> > k
> >
> > Frank Barknecht wrote:
> > ...
> > > Not that I really understand your patch fully, but does statefn also
> > > handle setting the state again afterwards? Or is this still only
> > > possible through the standard ways to set an internal state, i.e.
> > > through inlets or messages?
> >
> >
> > _______________________________________________
> > PD-dev mailing list
> > PD-dev at iem.at
> > http://iem.at/cgi-bin/mailman/listinfo/pd-dev
> >
>
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/pd-dev