in the attached patch, you can switch between 2 different visual areas of a graph-on-parent subpatch with a toggle. the problem is, that if you sitch to one view and try to tweak a fader, the output value changes but not the visual display of the fader - unless you move the subpatch within the main-patch... then it suddenly works.
i know, i asked that question some days ago in another relation, but this would be a real cool feature to save panel-space if there was't the approched issue....
is'nt there a way to get this to work??? please.........

http://www.pdpatchrepo.info/hurleur/subpatch_view.pd

ok, this may be a good atarting point - not very elegant, but seems to work:
i found out, if you make a structural change within the subpatch, it seems work. so now i send the message to change the view, and then i send imideately a message to find any object (in this case a [+~]), to cut it and undo the cut-action again.
this works pretty well, try it out - set dsp on and tweak the faders! of course, just a starting point but a good one, i hope....

http://www.pdpatchrepo.info/hurleur/subpatch_view_test_2.pd

and here is a project patch i'm working on at the moment. it demonstrates, how useful it could be, to be able to change views within subpatches - if it would work a little more smoothly...
open the folder and run Rumble_Box.pd.
note, that this patch is not fully working and is only to demonstrate the mentioned effect. i guess, this is a too big gui for a view-change to be computed faster - but for more tiny guis this may be a nice feature though!

edit: oh, i forgot to mention, that the sequencer works with midi-out, so you have to assign a midi-out that runs into a midi in. i solved this by using midi yoke and midi ox - midi yoke 1 for in and out and connected via midi ox.
but for the visual aspect you will need no sound anyways... *grin*

http://www.pdpatchrepo.info/hurleur/Rumble_Box.zip

nice one toxonic! thanks for raising my wisdom +1!

For fun I tried to implement a line, so that the canvas would slide to the next location. no luck. it seems line knows I'm being cheeky and refuses to ramp, instead delays and then bangs. the little fucker.

@arif said:

nice one toxonic! thanks for raising my wisdom +1!

For fun I tried to implement a line, so that the canvas would slide to the next location. no luck. it seems line knows I'm being cheeky and refuses to ramp, instead delays and then bangs. the little fucker.

• 1 indeed.

You're really trying to push it arif

oh, this would be a nice feature, but i guess this will not work, since only elements, that are fully inside of the visible area, will be displayed.
thank you for your comments! if someone finds a possibilty to enhance this, please post it here!

>>it seems line knows I'm being cheeky and refuses to ramp, instead delays and then bangs<<

maybe try [line 0 100] or something like that. the creation arguments specify the start point (0) and the time between each update on the output (default 20ms, in this case 100ms)

line will be acting fine, but your gui can't keep up with such rapid updates.

Hey toxonic,

I thought you might be interested in this patch Chris McCormick posted on the list. It does a sort of expandable GOP window.

http://www.pdpatchrepo.info/hurleur/hide-patch.pd

uhh, that's pretty cool. thank you maelstorm!
i wonder, where all you people get that deep knowledge about messages?
like this here:
[; $2 donecanvasdialog 1 -1 1 0 -1 $1 60 $1 60 0 0(
donecanvasdialog? somewhere a collection of all possible pd-messages and what they do out there? that'd be cool!!!

good point there toxonic, if maelstorm hadn't told me about it, i never would have found that donecanvasdialog .... i agree a list of all possible messages etc would exist, just like the one for objects ...