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@mccormick.cx http://mccormick.cx