On May 9, 2018, at 3:28 AM, pd-list-request@lists.iem.at wrote:

From: Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu>

There's a tricky bit though - what when the user copy/pastes an array define object meaning to later change the name - in this case is it appropriate to print the warning? I'm not sure.

If, as you suggest below, there was a static/shared option, I'd think the warning would be printed if you copy/paste an [array define] *without* said option set. Asking for a shared object would make it explicit the "multiply defined" aspect is required.

On the larger topic, I like the idea of having a "-shared" or "-s" flag to [array define]. I can think some of th details through but not all of them yet...

Yeah, that's basically what I was thinking, but also for regular arrays as well.

When there are [struct array -s -k] objects, perhaps some in abstractions and some in 'main' patches, where do the contentes get saved? Should it be the case that all "-k" instances save their contents, whether in abstractions orin 'main' patches, and then should it be considered a conflict when loading a patch causes one to be 'restored' twice?

In that case, I'd say it's a "lazy load" singleton situation where the first shared instance of that name is loaded and subsequent instances are pointers back to the shared instance until they are all deleted, then we start over. I guess it would be like reference counting.

... and incidentally, whatever is done I guess it should be that way for "value", "array", "text", and (eventually) "scalar".

Yeah, I was thinking something similar: a mechanism for sharing the underlying data behind the instances when needed as an option without disturbing current behavior. It not an aspect that's needed much for regular patches, but I've already run into a few abstractions that would benefit from sharing this kind of data, ie. static lookup tables, etc.

Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/