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

[Chris McCormick]

On Wed, Aug 09, 2006 at 02:14:36PM +0200, geiger wrote:
> 
> On Wed, 9 Aug 2006, Chris McCormick wrote:
> 
> Most of the time, if you have several abstractions of the same type in
> a patch, they do the same thing, so nothing is lost. If your patch only
> has one abstraction of each type, there is no problem anyhow.

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.

> > The
> > only real solution I can see is a $0 type of argument that is generated
> > when a new abstraction is instantiated and saved with the abstraction
> > so that next time it gets loaded it has the same ID. Being slightly
> > frightened of Pd's sources I have no idea how much work this would be
> > though, or even if Miller would be interested in a patch to introduce
> > this new identifier.
> 
> Hmm, I see, seems that we are talking about different problems here.
> There is only one file where the abstraction is stored (lets say abs.pd).
> Now you have a patch with 5 "abs", every single one with a different ID
> but just one file (the abs.pd) to save them too.
> 
> ok, you could say that you save them all to the single file (ugly but
> possible), but then how do you know which id corresponds to which
> abstraction in the patch.

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.

> 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.

Best,

Chris.

-------------------
chris at mccormick.cx
http://mccormick.cx