I've been meaning to bring up this issue for years, but never manage to remember: I can never seem to manage to hide the name of an array. Nothing changes at all if I right-click on the array and select "Hide object name and arguments"...the name just stays there:

what am I missing?

wow looks amazing! I will definitely have a play with this.

@yannseznec There is another method to hide the names of arrays. Rename the arrays with symbols containing only blanks. There are at least two different blank characters that can be used in Pd: ASCII decimals 32 and 160. So different names can be created by different length or different combinations of 32 and 160 blanks.

It would probably necessary to keep track of the names somehow, maybe by storing them in a list and get them by index when needed. And the patch could get somewhat un-intuitive. But it is a possible way.

If all related array objects stay unchanged, it would be enough to set them up with receives, so on load they could all receive the individual name of the according array.

The method is also described and used in this thread: https://forum.pdpatchrepo.info/topic/10854/xy-abstraction-to-get-mouse-click-and-drag-coordinates-vanilla/5

Data structure arrays have the benefit that they cannot be changed by mouse if this is wanted. So this could be nice for just displaying data.

@ingox 32 no longer works, with the addition of the list box 0bj in pd 52 all spaces (ascii 32) are escaped so symbols with spaces can be differentiated from lists, they made this behavior universal. 160 does work, as does '194 160' the unicode non printing character. I did not know about 160 on its own, that save me some typing. They also snuck in an edit method for arrays along with a few other new methods in 52.

"New method for garrays to set colors, line width, visibility, display style and disable mouse editing (documented in 2.control.examples/16.more.arrays.pd). Also added more flags to the "plot" object that plots arrays in data structures (by Christof Ressi)."

But I think @Balwyn is well on the way to making the old fashioned vanilla array a thing of the past.

@oid Thanks, didn't know that. But the xy patch in the other thread still works without changes in Pd 0.52 using 32 and 160 ASCII spaces in array names and no escaping is shown.

Well, i have to say in my example the arrays are being created by dynamic patching. Renaming arrays via message works, but it will not be displayed. This is probably a bug.

@ingox I think this might be system and or locale dependent, I get escapes with 32 160. Plain 160 is probably the safest way to go for portability since it is a non-breaking space in both UTF-8 and Unicode and should work on most system and still work if pd goes unicode. Apprently 194 160 is UTF-8 and not unicode as I had said, but it is the same character as 160 (a non-breaking space). I half suspect that 32 160 is being seen as a double space by pd on some systems and the 32 is dropped as pd tends to drop double spaces leaving you with just the 160s and no escaped 32s, but the other half of me suspects I am overlooking something.

@oid When you open xy, d you see escape characters?

@ingox I don't, I forgot that they fixed escaping in labels which were getting escapes for awhile. In my quick test used a send instead of garray to save on typing, I knew I was missing something. I am guessing back when you did this pd deleted multiple 160 in a row so you alternated between 32 and 160 to keep it from deleting them? Or perhaps pd did not actually print the 160 at all? Or perhaps the flaw of evolving logic during a long nights patching? So maybe 32 160 is best for backward compatibility? Which ever way, 32 160 should be as safe as plain old 160 and may provide increased backwards compatibility.

@oid Thanks for testing!

I used 32 and 160 to encode $0 into the array name so different abstractions can have arrays with individual names.