[PD] Multiple (same) instances, and [sssad]

[geiger]

On Wed, 9 Aug 2006, Chris McCormick wrote:
> For me that is not the case. For example, I might use my GOP datastructure
> envelope abstraction for several different things in one patch. I may use
> it to control the filter cutoff of something in one part of the patch,
> and somewhere else use it to control the volume of something. Now let's
> say I move the entire volume-controlling aparatus to a different part
> of the canvas, and then click the "load" bang in the [sssad/panel] state
> saving abstraction by Frank. Intuition says that the envelope should load
> the same data it has had all along, but with the method you proposed it
> would load some other data corresponding to this different location in
> the patch, maybe even the data of the cutoff-controlling envelope, which
> would be all wrong, or no data at all, which would just be irritating
> since your lovely hand crafted envelope would be gone forever.

Well, it might be confusing, don't know. Maybe its just that I think
that I do not move things around that frequently, and if I do, I just
have to save the settings together with the new patch. Anyhow, lets
drop that idea then.

> I don't mean to save the IDs into the abs.pd file. I mean to save them
> in the parent patch with the line which signals the creation of a new
> abs.pd(.) So something like this:
>
> After the instantiation line:
> #X obj 24 583 abs my abs arguments;
> #I 54322345;
>    ^^^
>    This is the unique ID generated by Pd.
>
> Or even breaking backwards compatability:
> #X obj 24 583 54322345 abs my abs arguments;
>               ^^^
> 	      This is the unique ID generated by Pd.

Ok, I see. I misunderstood. I must have been sitting on my brain.

> > The only way you can distinguish these 5 abstractions in a patch is
> > by their position and the way they are connected to other objects.
> > Or, by naming them, which is what we currently do.
>
> I think there is a fourth way as I have indicated above; to associate
> some Pd generated ID with each abstraction instantiation in the parent
> patch. Nobody has to use this ID, but it's there if you want something
> more permanent than $0. It would make it easier for unnamed things to
> be saved by memento or sssad or state.
>
> Then there is another can of worms; generating IDs unique across several
> patches put together at different times. Hmmm. Maybe the ID could be the
> unix timestamp + milliseconds at the time when the abstraction was first
> instantitated?
>
> All of this is academic anyway, unless someone is willing to write the
> code and submit a patch, or Miller is listening and caring.
>

Ok, I get your idea. Although, you are right, its really in the guts of Pd
and you have to add something that makes it possible to store your ID. I
think a clean solution for that can only be implemented by Miller.

Günter


> Best,
>
> Chris.
>
> -------------------
> chris at mccormick.cx
> http://mccormick.cx
>