Hello, I want to send an array (1) from my main patch, to another array (2) that is within an abstraction, replacing the contents of array 2 in the process.

I want the size and the range of array 1 to also overwrite those properties of array 2, so that I can drop an array of any size and range into the master patch.

I have so far managed to overwrite the size of array 2 using [array size array-1], which allows you to get and change the size of an array, but I cannot find the equivalent for the range property. The [array] object has a couple of arguments, 'min' and 'max' that I thought might help, but they get the min and max values from the data in the array, not the actual min and max range from the array properties.

Does anyone know if there is a way to get min and max range properties from an array, and then set those properties to another?

@soundproofskin Set the array's properties through messages instead of the dialog, this will allow you to save the settings and recall them when you copy the array. Check the help for graphical array for the messages you can send, they are hidden in the subpatch to the right of the array.

@soundproofskin You should still be able to send the array a "bounds" message to set the range.
David.

Thanks for the replies @oid and @whale-av, I'm going to have a play with it again today and see if I can get that working.

In the help file, details for the "bounds" message are "bounds <list> - sets rectangle bounds (xmin, ymax, xmax, ymin)."

ymax and ymin are the ones that I'm looking for, but what do xmax and xmin do? I'm confused because the "size" property seems to set the amount of steps for the x axis. How are xmax/xmin and size related?

@soundproofskin The bounds are the physical bounds of the array (the box it is drawn in), if your rebound a graphical array to 0 -1 10 1 and it has the size of 100 the points of the array will extend 90 past the box which outlines it, the number of elements in the array remains the same. To change the number of elements of a graphical array you send the resize message, [resize 10( would get rid of those 90 points which extend beyond the array's box.

Thanks for the explanation @oid, I think I get it now. The y axis functions slightly differently because the values of the data are the y axis size property in that respect.

What was/is confusing me is that, though modifying the size property clips the data on the x axis when there is overflow as you describe, and I see the array stretch and shrink visually, modifying the xmin and xmax has no visual effect on my array. I'm using Plugdata, I don't know if that would have something to do with it.

@soundproofskin Yes, the bounds are just the size of the visual rectangle that the array is displayed in.
The array can have data that is displayed beyond that rectangle...... the rectangle imposes no constraints on the data.
It is similar to a GOP for an abstraction or a sub-patch, except that data outside the rectangle will still be displayed.
The -resize flag controls the size of the data in the array... so by changing that data can be lost, or the array can be packed with zeros if the data set is too short.

There used to be a lot more help for arrays in Pd extended. It is all still valid, even though newer array tools are available....... all_about_arrays.pd
I don't know whether plugdata behaves differently.... hopefully someone will let you know....
David.

Thanks for the Pd extended info. I have a rough patch working now, thank you both for the help.

@whale-av The current help is pretty good.

Plus more in the main help patch and easy access to the appropriate manual patches. Think the current docs offer more than the old extended help. A great deal has been done to improve the documentation in the past year.

Edit: "fisty element." Never noticed that typo.

I do find the help docs very useful while learning Pd, and a good reference when I forget what something does. It's refreshing not to have to Google everything like I would do if I was lerning something like Javascript, for example.

In this case though I couldn't find what I was looking for (a way to 'get' the ymax of an array) so I thought maybe I was overlooking something. With the help you have both given, the workaround is to set the properties of the local array and the array in the abstraction at the same time (the bang that does that also sends the data from the array in the main patch to the array in the abstraction at the same time).

This works well for new arrays, but is a bit clunky if I grab an array existing from somewhere that already has properties set - I have to check the existing properties, then reapply the properties via a message. It works, but being able to 'get' the ymax of an array so that it can be applied to another would mean not having to do that manual step each time.

@soundproofskin Do you copy existing arrays often enough for that to be an issue? Would the get method actually be easier, you would need to create a message and a receive with print/listbox so you can see the results, remember $0 does not work in messages, change it to $1, add a bang and a [$0 ], click your bang and get no result, see a typo, fix it, get your result, delete the new objects which you only needed once and do not want to pollute your patch with something you will never need again. Seems more work than just a quick right click.

If UI objects had a get method it would mean their properties would be data and our simple float atom would not be a storage container and interface for a float but a complex data structure which stores 3 symbols and 7 or 8 floats, this would quickly result in patches which are very difficult to read and debug. Dataflow can be difficult to get the hang of and it often feels like we are missing common features of programming languages but once you get the hang of it it starts making sense, if you want those properties as data create the data in the appropriate structure, a message or a list.