hi, i've got 16 arrays displaying via GOP on my mainview.
i'd like to be able to open up the "subpatch view" directly from the mainview.

now, if i right-click on an array/abstraction and pick open, and then right-click on the array and choose open, i get shown "subpatch" where i can draw stuff in, i.e. destructively modify the array.

how do i get from "not-inside-abstraction" to the subpatch view?

@esaruoho

Where subpatch is the name of the subpatch you want to see.
vis 0 will hide it again.

Some info on messages to windows....... 0.all_msg.pd although there are others that are not documented in that patch.
David.

@esaruoho The only way I know to open graphical arrays is through sending mouse messages to the canvas, [vis 1( does not work with them. The mouse message is x, y, and two numbers which I do not recall what are off the top of my head but 0, 0 works, then done-popup is the number of the menu entry and mouse x, y ( an x and y somewhere within the bounds of the array), menu entries are 0 - properties, 1 - open, and 2 - help.
openarray.pd

Edit: To add, when you want to find what messages to send and the all_msg.pd that @whale-av posted fails—it is rather dated but quite useful—then [iemguts/receivecanvas] and [r pd] connected to a [print] will generally give you want you need, just perform the desired action and see what is printed by them to the log.

Another method is to use [array get] and [array set] and copy the array to a larger editor array and back to the calling array with a metro to update as you edit.
Here i've used an hslider to blackout the arrayname but also receive a click to open the editor and send its id.
setget.pd

@whale-av said:

@esaruoho

Where subpatch is the name of the subpatch you want to see.
vis 0 will hide it again.

Some info on messages to windows....... 0.all_msg.pd although there are others that are not documented in that patch.
David.

unfortunately, when i did [; pd-plom.pd vis 1( - all 16 of them became visible, which also unfortunately just opens up the plom script, not the plom array (subpatch). do i need to call the subpatch's subpatch? like kinda like pd-plom.pd-plom1 for plom1 array to be shown?

@esaruoho Since you already numbered the abstractions you can use [namecanvas subpatch-$1] to give them individual names. Then you can use a number to [;subpatch-%1 vis 1( to show them. I don't know if there is a way to just open an array via message. If not you can instead put a subpatch into each abstraction that only contains the array and open these with [namecanvas].

@Balwyn said:

Another method is to use [array get] and [array set] and copy the array to a larger editor array and back to the calling array with a metro to update as you edit.
Here i've used an hslider to blackout the arrayname but also receive a click to open the editor and send its id.
setget.pd

Hi Balwyn, I've been attempting to modify your suggestion, which, btw, is pretty hot - esp the clickable slider opening the window, but i've been hitting a snag there, since if i try to incorporate this into my 16 looper abstractions, the minute i start editing, all the other loopers also get the same edited array content. so it's very destructive. i've tried to do this:

i.e. have each of the looper abstractions have it's own method for shooting up a $0-edit screen, but they still seem to want to talk to all of the loopers. they're all plom$1 but the abstraction parameters specify what they are actually called, i.e. 1-16.

@Balwyn said:

Another method is to use [array get] and [array set] and copy the array to a larger editor array and back to the calling array with a metro to update as you edit.

EDIT: it seems that the screenshot I took already worked! it no longer overwrites anything. I ended up cleaning it up a bit, and am now trying to figure out how [vis 0( could also be used to control the windowsize + position of the array edit, since having it stably in a specific place would be pretty amazing.

@esaruoho The (on-screen) position and size of a sub-patch window is saved when you save the main patch.
David.

@Balwyn said:

Here i've used an hslider to blackout the arrayname but also receive a click to open the editor and send its id.

ok i think the issue i've been having is that the ID is not sent, as it defaults to 1 for me. so i'm gonna need to use $1 to define the ID, and hope that that results in not overwriting anything.

(i'm getting intermittent overwriting of other array slots when starting editing. and unfortunately, the window size + window position are not retained between sessions due to $0- being incorporated into the name of the window. so i still need to figure out a way to set the size + position when opening the subpatch window.

OK, got it working. The issue was the ID stuff that was kinda throwing a spanner in the works (since the original ID thing was about defining whether it read from array-1 or array-2.. and that selection logic isn't required since plom$1 already contains the ID for it (1...16)

@whale-av said:

@esaruoho The (on-screen) position and size of a sub-patch window is saved when you save the main patch.
David.

unfortunately this doesn't seem to be so when dealing with $0-subpatches. unlesssss.. unless if i'm supposed to open up a plom.pd, open the window, resize and position, then save the plom.pd and load the larger script.
let's see.

yep, that's it! by saving the position of the subpatch within plom.pd into a specific place, all 16 windows now open in the right place and with the right size. thanks for walking me through this, David!

@esaruoho sorry for the late reply I'm in Australia, but it looks like you have it sorted anyway
cheers
Balwyn

@esaruoho said:

am now trying to figure out how [vis 0( could also be used to control the windowsize + position of the array edit, since having it stably in a specific place would be pretty amazing.

@esaruoho Well, this is possible with the now undocumented message [relocate( which is not at all intuitive and may disappear sometime in the future, however it still works at the moment.
It is in the Pd-extended documentation but has disappeared in later releases of Pd

No warranties for the next bit
so make back ups or use a copy of your patch

Copy the four objects and paste them in your patch if you want to test, click the bang and the $0-edit subpatch should open at size of 720x530 at the position of 50 left 50 top (adjust the message list to suit.
[menuclose( is required instead of [vis 0( for it to work
move-subpatch.pd

ok this is so very, very strange. @Balwyn - i had a functioning system, then loaded a wavefile into an array and tried to use that with the "click on fader and array opens and you can edit it" and it just all broke.

so, now, for some reason, no matter what is in the original, say, [plom$1] array, gets overwritten by whatever happens to be in the [$0-plom-edit] array. i've tried to send an array get + set to it, but for all intents and purposes, nothing is happening anymore.

so each abstraction has a $1 defining what the number is (plom1...plom16) , and the s $1-id is also used for the metronome starts and stops, since that was in your script
plom.pd

not sure what's going on anymore i think i went too far and went astray when loading a non-puredata-sampled wavefile in and thinking it'd work, it just resulted in the plom array changing from 65536 to smaller than that, but upon saving the array at 65536, the whole "copy to $0-plom-edit" stopped working. for no apparent real reason.

Did you close the edit window with the "done" bang?
If not the metro will still keep updating the last array that opened it.

@Balwyn said:

Did you close the edit window with the "done" bang?
If not the metro will still keep updating the last array that opened it.

i did close the edit window, and mapped esc key to also send the Done bang. i'm now trying to trace back, and it seems like something goes wrong with the [array get plom$1] going to [array set plom$1-edit] in the abstraction itself, i.e. it is definitely sent, but somehow the [vis 1, edit mode 0( which also has a [array get plom$1-edit] going to [array set plom$1] results in whatever was gotten from the abstraction, being overwritten by what was being sent from plom$1-edit. i tried introducing delays into the mix, so that there's enough time to do the dump from plom$1 to plom$1-edit, but at least [delay 50] did not thus far help.

are all the arrays the same size?

ended up just panicking and jury-rigging this:

this seems to send enough of metroreset stuff to stop the metronome from running, whether clicking done, or by pressing the esc key. hopefully this has now plugged whichever hole i accidentally messed up into making.

the bang between [r $1-id] and [array get plom$1] looks like it is blocking the id, and the delay is toggling the metro twice

@Balwyn said:

are all the arrays the same size?

yep, the 16 arrays are all 65536 and the "big array view" arrays are 65536 too.
i think what went wrong was when i loaded something other than 65536 into the 16 arrays and loaded one into the big array view.