XYrange is lost when switching [array] from non-GOP back to GOP

[fdch]

I attach a small test patch to show this.

Say you have a GOP array with Xrange 0..N+3 and Yrange 1..-1, and change it to non-GOP and then back to GOP, you get:

• Xrange is 0..1
• Yrange is inverted -1..1

NOTE: Sinesum message reverts it back to original coordinates when array is in GOP with wrong XY ranges.

array_gop.txt

[fdch]

I also wonder if non-GOP array should not become [array define array1] instead of [graph], which does not really allow for anything but hiding the array...

[umlaeute]

turning GOP on/off doesn't change the object itself. so an array really is [graph].

[Spacechild1]

first: a graphical array is a GOP subpatch ("graph") containg a data structure array. [array define] and [table] are canvases containing a graphical array.

now to your question: if you open the canvas properties you see the fields "X units per pixel" and "Y units per pixel". These are only enabled when GOP is off. The thing is that those really just set the array bounds:

X units per pixel: 100
Y units per pixel: -200

actually is:

X range: from 0 to 100
Y range from 0 to 200

Note that the bounds always start at (0, 0) and that the Y value is inverted (don't ask me why)... The array bounds have a slightly different meaning for a non-GOP subpatch (which data structure quantity/size corresponds to 1 pixel on the canvas?) vs. GOP subpatches (which data structure range is shown in the graphing area?).

so what happens is that by switching to non-GOP you effectively override the array bounds and there's no place in the internal canvas structure to cache the old values. there could be, but I don't think it's worth the complexity.

to your question why sinesum restores the array bounds: because it implicitly resizes the array and resizing automatically adjusts the X-values of the array bounds to fit the whole array.