hi, i've got this:

the purpose of which is to use multiple ways of switching between "top of the canvas" and "bottom of the canvas". I think here's a complete list

• a midicontroller (two midi messages) (Loupedeck Live device) (the button-presses on the device sends Midi messages)
• the pageup/pagedown buttons on the keyboard, if available
• shift-° to switch between the top and the bottom of the screen
• Karabiner (macOS) configured mouse buttons to send the very same message
• two red buttons (aligned so that whether in top canvas area or bottom canvas area, the button stays in the same place

..but i'd really prefer to not have this large amount of objects on the main script canvas, taking up space, since space is at a real premium for me. so i'm wondering how i could have this inside an abstraction and still get the same results on the main canvas. any ideas?

if it helps, here's my current main script view:

"Page up" :

"Page down"

so i'm really trying to reduce the amount of extra objects i have on my screen.

if you have any other suggestions on how to reduce the amount of "non-clickable objects" on screen, i'm open for anything.

I think you could do the scrolling in tcl/tk only.
load some *-plugin.tcl file that binds the correct keys to bind the class PatchWindow.
but, I'm not sure how to move the objects w/ it.. I guess if you know their receive name you could also move them by index and sending the canvas messages per normal (using iemguts if necessary?)

@esaruoho As you have all the parts you want to see in an abstraction (or they could be in a sub-patch) you can move the "graph on parent".... GOP..... window around...... instead of moving the objects.
Like this.... gop_switch_coords.pd
The coords method works very well..... the donecanvasdialog method is less reliable.
If you want the control "unattached" from the abstraction or sub-patch you can send messages to the window....
David.

@whale-av said:

@esaruoho As you have all the parts you want to see in an abstraction (or they could be in a sub-patch) you can move the "graph on parent".... GOP..... window around...... instead of moving the objects.
Like this.... gop_switch_coords.pd
The coords method works very well..... the donecanvasdialog method is less reliable.
If you want the control "unattached" from the abstraction or sub-patch you can send messages to the window....
David.

ok, this was really interesting! dynamically moving which GOP segment is shown.. this gives me plenty of ideas,

but unfortunately it doesn't *seem to solve the "main script pageup/pagedown" coordination that i need to happen within the main script window

@esaruoho You will have to put the main script window in a sub-patch or abstraction and do the same thing.
It should be easy to co-ordinate the messages to the windows.
You can also have a GOP window showing through another GOP window...... multiple levels.
David.

@whale-av said:

You can also have a GOP window showing through another GOP window...... multiple levels.

btw, i just realized that this whole goppery that you introduced to me enables me to kinda have panels for the loopers, i.e. i've been fighting for years trying to keep the 16 loopers as small as they could be, thinking, i'd like to add this, i'd like to add that, but now with this "press a button to switch panels for each of them" (i'm guessing it'd be possible to have 16 identical abstractions and have a button outside the abstractions that i click on and they all change panels) kinda opens up really new and beneficial possibilities.

i'd still prefer to not wrap the whole patch inside a GOP cos i'm still worried that having too many GOPs will just mess the screen update (as I'm already having issues with GOP and UI changes with sliders getting frozen if too much UI color updating is going on, etc),

@esaruoho I think the simplest and least likely way to cause problems might be to just make them two non GOP subpatches then you can send [vis 0( and [vis 1( to the needed subpatches to close one and open the other. Avoids the GOP stuff since they are both just normal subpatches which you can open to get your desired view. Adapting the GOP size/position can get very buggy in my experience, it is great when it works but is unreliable when there are lots of GUI objects being updated for pd to keep track of.
spswap.pd

Edit: Suppose sending all those vis 0 messages when you press escape became redundant when I switched to sending 0 to all the toggles to make sure they became unset, oh well. Also, no real reason to use [key] for the letters and escape since [keyname] handles them just fine, force of habit, I generally want to stuff the output into arrays.

@whale-av said:

@esaruoho As you have all the parts you want to see in an abstraction (or they could be in a sub-patch) you can move the "graph on parent".... GOP..... window around...... instead of moving the objects.
Like this.... gop_switch_coords.pd
The coords method works very well..... the donecanvasdialog method is less reliable.
If you want the control "unattached" from the abstraction or sub-patch you can send messages to the window....

hi, i tried to modify this script you provided so that it'd edit the plom.pd abstraction, but got told:
plom.pd: no such object

i'm not a hundred on how to proceed. was i supposed to put this into the abstractions?

@esaruoho The second part of the message....... plom.pd editmode 0 ...... should be (pretty sure as I cannot see your patch names)..... pd-plom.pd editmode 0
The [coords.....( message doesn't need the editmode resetting though, and works much better than [donecanvas dialog.....( which can produce buggy screen drawing the first time the message is sent.

For a sub-patch ..... [; pd-subpatch message(
For a patch window..... [; pd-patch.pd message(
David.

@whale-av said:

@esaruoho The second part of the message....... plom.pd editmode 0 ...... should be (pretty sure as I cannot see your patch names)..... pd-plom.pd editmode 0
The [coords.....( message doesn't need the editmode resetting though, and works much better than [donecanvas dialog.....( which can produce buggy screen drawing the first time the message is sent.

For a sub-patch ..... [; pd-subpatch message(
For a patch window..... [; pd-patch.pd message(
David.

ok, i copypasted the coords message into an abstraction but i'm still not sure where to send the message to - tried [s plom] and [s plom.pd] and [s pd-plom] all to no avail.

the abstraction i'm using is "plom.pd" in filename, but it has extra arguments ( [plom 1 29 57 100] ) to provide it with a number (1st of 16 loopers) and which midiCC/channel it listens for toggling recording on/off (29), and apparently 57 + 100 are leftovers of when i used to have a rotary knob controller to control pitches.

i must apologize, am having a kind of a hard time comprehending the script you sent, even though it is simple and works. if i can get it to work once, i can run with it forever.

ok, the minute i stopped using the [plom 1 29 57 100] abstraction and just copypasted to [pd $0-plom 1 29 57 100] - the coords started working. but i worry about what this might break, as i've been using abstractions instead of subpatches for all of the 16 loopers for years.

@esaruoho [send pd-plom.pd] ........ as it is a patch (abstractions are just patches that can be re-used and made different with arguments).
David.

btw, for the sake of posterity, here's how i'm working to comprehend the ranges sizes and margins, as they don't seem to be self-evident.

@whale-av said:

@esaruoho [send pd-plom.pd] ........ as it is a patch (abstractions are just patches that can be re-used and made different with arguments).
David.

ty! one thing that this coords seems to toggle off is "Hide object names and arguments" - is that the 5 there?

ok, found that
0 = GOP OFF + hide names OFF
1 = GOP ON + hide names OFF
2 = GOP ON + hide names ON

i tried to find a way to output the canvas GOP settings to PD console via print but couldn't figure it out. is there no documentation about dynamic GOP changing within PD documentation?

@esaruoho https://puredata.info/docs/developer/PdFileFormat covers all that stuff.

unfortunately, when i send the canvas/GOP move command to 16 abstractions, they drop audio. this does not seem to happen if i just send it to one gop.

is this pretty much the wrong way to go around doing GUI changes?
am running with Apple M1 (13-inch 2020) 16 GB

@esaruoho There isn't really a right way to do this stuff and these are internal messages which just happen to be available and usable to us . Using the vis message method I mentioned in your other thread* generally works better. You can probably get your GOP setup working by splitting up the moves, you are trying to get too much done between blocks, https://lists.puredata.info/pipermail/pd-list/2012-12/099455.html

*Edit: Apparently that was this thread, was still waiting on the coffee when I posted.

@esaruoho Another thing you can do to avoid audio dropouts and improve UI is separate the audio and UI portions of your patch, run each in different instance of pd using [netsend]/[netreceive] to communicate between them, isolates the UI from the DSP. [pd~] could probably also be used this way but I have little experience with it, I am stuck in my ways.

@oid As you say, separate instances of Pd.
The audio clock for [pd~] is slaved from the Pd instance, so a fail will be shared (pretty sure).
David.