Expandable GOP?

Reply to Expandable GOP? on Sat, 22 Feb 2025 13:22:10 GMT

FFW — Sat, 22 Feb 2025 13:22:10 GMT

Hi,
does exist a template for an expandable GOP?

I do this but the controls are not hidden when the switch is set off (they remain visible out of the abstraction box):

Reply to Expandable GOP? on Sat, 22 Feb 2025 15:50:12 GMT

willblackhurst — Sat, 22 Feb 2025 15:50:12 GMT

I looked for the pd-tutorial page and tried these

canvas_dialog1.pd

Reply to Expandable GOP? on Sat, 22 Feb 2025 15:52:09 GMT

willblackhurst — Sat, 22 Feb 2025 15:52:09 GMT

ive got the range numbers wrong whatever

Reply to Expandable GOP? on Sat, 22 Feb 2025 20:27:47 GMT

oid — Sat, 22 Feb 2025 20:27:47 GMT

@FFW You need to hide the gop and then show it to force redraw, send 0 then 1 to the third argument. You also will want to send [dirty 0( to the canvas or pd will think the canvas has been edited and prompt you asking if you want to save changes.
gop.pd

Reply to Expandable GOP? on Sat, 22 Feb 2025 21:41:16 GMT

whale-av — Sat, 22 Feb 2025 21:41:16 GMT

@FFW You might have more luck using the coords message rather than donecanvasdialog.... as coords doesn't need the useful hacks that are mentioned above.
I have added a size message to an old gop demo patch and it seems to work reliably with a sub-patch.
I haven't checked for an abstraction
gop_switch_coords.pd
David.

Reply to Expandable GOP? on Sat, 01 Mar 2025 17:29:20 GMT

FFW — Sat, 01 Mar 2025 17:29:20 GMT

Thank you all! I'm giving a try and will do a feedback.

Reply to Expandable GOP? on Sun, 02 Mar 2025 16:50:28 GMT

FFW — Sun, 02 Mar 2025 16:50:28 GMT

It works well!
I'm using a canvas to set the enlarged size and the switch move to the right dynamically.

expandable.pd

Reply to Expandable GOP? on Sun, 04 May 2025 14:50:44 GMT

FFW — Sun, 04 May 2025 14:50:44 GMT

Is it possible to detect when the mouse is in/out of the gop to switch the size accordingly?

Reply to Expandable GOP? on Sun, 04 May 2025 16:18:18 GMT

whale-av — Sun, 04 May 2025 16:18:18 GMT

@FFW Yes...... well it was in Pd extended..... so maybe......
You would need to modify [mouse_region] from the HCS library.
It shows coordinates and constrains output to the mouse presence inside the GOP area.
You would need to remove the mouse click and drag constraint, using just the position so that you get bangs or coordinates only when the mouse is in the gop area.
It needs externals from PurePd and others probably.
You will be able to modify it to do what you want, and it should be more simple when done.
There will be other ways to achieve the same thing as long as you have the mouse coordinates from the window...... coordinates from the screen would not work.
David.

Reply to Expandable GOP? on Sun, 04 May 2025 19:12:02 GMT

oid — Sun, 04 May 2025 19:12:02 GMT

@FFW I do something like this:

Needs an [expr] with some if statements or a few [moses] and comparison/[expr if] to finish it up, but I think that shows the logic?

Reply to Expandable GOP? on Sun, 04 May 2025 21:07:36 GMT

FFW — Sun, 04 May 2025 21:07:36 GMT

@oid +1000 !

Reply to Expandable GOP? on Sun, 04 May 2025 21:23:09 GMT

FFW — Sun, 04 May 2025 21:23:09 GMT

I'd like to put this whole logic in an abstraction so I'll can reuse it but I don't find how to sendcanvas
to the parent patch

Reply to Expandable GOP? on Sun, 04 May 2025 22:46:52 GMT

oid — Sun, 04 May 2025 22:46:52 GMT

@FFW As far as I am aware there is no good way to determine how deeply nested in the patch an abstraction is. In the past when I have needed this I have used [canvasindex] since it produces no output if toplevel, something like this:

Possibly warrants a feature request on the pd github, results may happen quicker with an iemguts feature request but I am not sure if umlaeute has any interest in extending the features of iemguts but he is quick about dealing with bugs. Probably will not be a feature of vanilla anytime soon since the official way to deal with such things is [namecanvas] and named canvases which covers most use cases. With how things currently stand, numerical depth is more suited to the iemguts workflow than the pd workflow,

Edit: Not completly certain I understood you use case. Do you actually need to determine depth? Is the issue nested canvases? If depth is constant then [iemguts/sendcanvas] will solve your issue. I suspect my post was going the wrong direction and you don't need to worry about depth?

Reply to Expandable GOP? on Mon, 05 May 2025 10:42:59 GMT

FFW — Mon, 05 May 2025 10:42:59 GMT

@oid my bad, I wasn't clear enough.
I've done what I mind:

makeExpandable.pd

I've an issue with comments which remain visible when the gop is shrunk.

Reply to Expandable GOP? on Mon, 05 May 2025 21:41:11 GMT

oid — Mon, 05 May 2025 21:41:11 GMT

@FFW That one was my bad, I had not looked closely enough at your screenshot before responding. I am not seeing an obvious cause of your issue but a couple things jump out at me and could be troublesome. You are sending two coords messages for EVERY motion event on the parent canvas, put a [change -1] between the [expr] and the [sel 1] so it only does it once when the state actually needs to change. This will also make your expand and shrink methods work as expected, as of now if you send [expend( to the left inlet when the mouse is outside of the GOP it will immediately shrink back down the second the mouse moves, which I don't think is what you want?

Something like this would also be considerably more efficient than your [expr], as you have things now if you had 20 abstractions in the canvas which use this you do the [expr] 20 times for every motion event, that could really add up and cause problems, Did not test this, believe I have the logic right but if I don't it should demonstrate it. Obviously you would want to update x-max and y-max on every expand/shrink.

Adding in the [change] might fix things, pd might be getting confused by all those coords messages you are sending, not sure, no time to dig into it right now.

Reply to Expandable GOP? on Tue, 06 May 2025 15:57:24 GMT

FFW — Tue, 06 May 2025 15:57:24 GMT

@oid A realtime on expr indicates a 8ms compute time. I'll try with your version.

I've added a change and a pipe to delay the switch.

It doesn't fix the comments problem, they only disappear when I save their containing abstraction (or when I reload the main patch).

Now I'm looking for a dynamically added and resized background canvas to get rid of the transparency.

Reply to Expandable GOP? on Wed, 07 May 2025 00:19:27 GMT

oid — Wed, 07 May 2025 00:19:27 GMT

@FFW This seems to work, but I can not quite see why yours does not work and I went through it removing every possible cause I could think of until I had pretty much this same patch, and it didn't work. Patch it together from scratch and it works, so probably something stupid and easy to miss in your patch and we are both missing the obvious. I added a third and fourth argument so you have shrunk width and hight and expanded width and height for args now and left some of the details for you to fill in.
ffw.pd

This seems pretty useful, easy way to make menus and dynamic interfaces, good idea to stick this in an abstraction, never dawned on me to do such a thing.

Reply to Expandable GOP? on Wed, 07 May 2025 07:12:33 GMT

FFW — Wed, 07 May 2025 07:12:33 GMT

@oid this simple test doesn't work so it's certainly a bug with my system.

I have another issue with comments:

And [donecanvasdialog( is worse: all the guis remain visible as ghosts.

Reply to Expandable GOP? on Wed, 07 May 2025 07:38:51 GMT

oid — Wed, 07 May 2025 07:38:51 GMT

@FFW said:

And [donecanvasdialog( is worse: all the guis remain visible as ghosts.

With your version or with the one I posted?

Your issue with the seq helpfile is just an error in the helpfile, possibly who ever made it used a custom font which can cause such issues for everyone who uses the default fonts.

Reply to Expandable GOP? on Wed, 07 May 2025 10:06:41 GMT

FFW — Wed, 07 May 2025 10:06:41 GMT

@oid even with the minimal test

EDIT:
I can force the redraw with

[zoom 2, zoom 1(
|
[sendcanvas]

Reply to Expandable GOP? on Wed, 07 May 2025 10:51:20 GMT

oid — Wed, 07 May 2025 10:51:20 GMT

@FFW That is because you are not sending 0 to the third argument and then 1 or 2 as I do in mine. Sending 0 to that argument disables GOP then sending 1 or 2 reenables it which tells pd to redraw and the reason for all that extra stuff at the bottom of mine. Try something like this for your minimal test:

This should make it work, donecanvasdialog does the exact same thing as the canvas properties dialog does when you click "ok" or "apply," this is the exact message the tcl/tk frontend sends to the pd core so if your canvas properties dialog works than this should work.

Edit: Fixed some errors in the image, had 1 instead of $1.

Reply to Expandable GOP? on Wed, 07 May 2025 11:04:29 GMT

FFW — Wed, 07 May 2025 11:04:29 GMT

@oid not better

Reply to Expandable GOP? on Wed, 07 May 2025 11:34:07 GMT

oid — Wed, 07 May 2025 11:34:07 GMT

@FFW try this, open ffw-test.pd and see if it expands on mouse over and shrinks when the mouse leaves. Restart pd before opening it just in case you have one of those weird things going on caused by a confused instance of pd. This should work,
Archive.zip
Edit: if it doesn't work, what version of pd are you running?

Reply to Expandable GOP? on Wed, 07 May 2025 19:32:18 GMT

FFW — Wed, 07 May 2025 19:32:18 GMT

OK got it: setting the "gop mode" to zero is not enough, it has to be set with the large dimensions and then it can be shrink without ghosts.

And then it works with [coords( too.

EDIT: I've fixed it with a list: