[PD] bug in gop data-structs?

[Luke Iannini]

> On Wed, Jun 18, 2008 at 1:25 PM, Rich E <reakinator at gmail.com> wrote:
>> Hardoff, your problem is a different one, that I think I have experienced
>> as well.  The data struct objects don't hold their drawing order when the
>> main patch is redrawn.

Yo,
I have a horrible, tear-jerking workaround for this in senderfruit/
called "ds-raise" that will raise an item in a DS to the top.

It's written to only act on the first appearance of each template in a
struct (a limitation I need to remove library wide before splitting
out ds-abs officially; I've been using nothing but arrays and one of
each thereof so this hasn't been a personal priority yet).  But you
should be able to have a look inside and get the idea.

Worse, it needs to be called after the data-subpatch is opened with a
delay of ~200ms depending on complexity.  But, it does do the trick.
(in case it's not clear, you'd call ds-raise on each template you'd
like to order, in order, from bottom to top)

The z-order bug (which, actually, I'd prefer was converted to a real
parametric Z-ordering feature) and the mega-sketchy array-item mouse
dragging/interaction* in "grain-quantized" arrays (e.g. "plot -y
note(0:88)(712:0)(1) noteArray 155 0 0 0"), if fixed, would increase
my use of DS by at least a zillion percent.

*actually, this has become a valuable stochastic composition tool for me

Cheers
Luke