Forums > MaxMSP

zooming and scrollong

October 15, 2011 | 2:29 pm

i’m not much of a giver on these forums, more of a bigtime selfish info leecher. i have endless respect for all the givers who have literally made my life possible. but ONE thing i wish i woulda given long before Max 6 was made:

max is a 2D spatial environment, much like any cad or vector drawing program. my patches can get big space wise. i’ve used most types of creative apps throughout life, and there’s ONE way of navigating this space that few apps have implemented, but that blows all others away…

if you’re on mac you can easily see the best, smoothest example of this method by going to mouse/trackpad and enabling "zoom with scroll wheel while holding…" hold the key and zoom the screen. it zooms to wherever your mouse is.

the other important thing in a proper implement is that the cursor stays on the same spot in the patch whether zooming in or out. your cursor remains right where it is on the screen and patch, everything zooms around that point. this means allowing lots black space around the work area in zoomed out views. most of the times i’ve seen it tried, the cursor might not stay in the same place, don’t even bother, it’s the key to making the feature intuitive and not a waste of effort.

so you get that going and all your navigation is done with a single modifier key and the scroll wheel. if you’re working at the top and need to work at the bottom, just zoom/scroll all the way out real quick, look at the whole patch, mouse to where you want to work and zoom in. scrolling with the mouse wheel and shift side scrolling is sometimes useful, but turn the scrollbars off, you’ll never touch them. any view movement is intuitively done by zooming out a little, zooming back in to your next spot. when the cursor remains in the same spot (long as you aint moving it), this becomes easy, kinda hard to explain.

also in this way, encapsulation works best as a means to reuse patchwork, and not make navigation easier. the most efficient way to work would become laying your whole circuit out in one patch. zoom out, boom, you got everything you’ve done laid out and connected in one view (of course text becomes unreadable, but that’s not the point), and flying in to edit is like a lightning strike with the mouse. kinda like mac expose, but everything is in the same spot and relation every time. selecting and moving large chunks of a patch is cake. if you want to get REALLY productive and be able to ditch all those thoughts of "where was that?", then all encapsulations could be built and edited on the main patch, like editable bpatcers. you just need a single infinite space in which to arrange them. still keep all the window abilities for interface design.

i love software that has options for workflow and usability… but this is one area where i think this one method should dominate. it’s hard to describe until you actually use the proper implementation on large 2d material. but it completely removes all the thoughts we waste on screen real estate and navigation. wish i could remember the name of the old cad software that did it perfectly… but it really does change the world of mouse interaction.



grg
October 15, 2011 | 3:23 pm

I second that!
In addition: the most important timesaver from 2D CAD applications for me is wheel-click = "hand tool" (move the canvas arround). I know Max has this extra window for Navigate Zoom Window now, but wheel = zoom & wheel click = move would be a huge usability bump & speedup.


October 15, 2011 | 3:28 pm

oh yeah i forgot about the hand tool… i like it as the space bar.


October 15, 2011 | 3:38 pm

well, let me put it this way. in the world of 2D workspace, i think this feature cuts down development time dramatically no matter WHAT kind of user you are. i can’t imagine a single feature that can do so much in this respect.


October 17, 2011 | 4:46 am

For "hand-style" moving with space bar, try this javascript and patch. the only thing I didn’t get was how to tell how big the patch is through js? not the window, the patch itself. any thoughts on that? would be simple to incorporate into the patch. it uses [mousestate] and js auto-window-scrolling to let you move around when holding the spacebar, works quite nicely :)

save as patch_window.js:

function window_scrollto(x,y) {
this.patcher.wind.scrollto(x,y);
}

patch:

– Pasted Max Patch, click to expand. –

October 17, 2011 | 4:51 am

…and for mousewheel zooming, try this one, though it’s basic and doesn’t zoom into where the cursor is (just uses "zoomfactor $1" to [thispatcher]). It requires the [ol.mousewheel] external:

– Pasted Max Patch, click to expand. –

October 17, 2011 | 3:06 pm

so, I didn’t have time to figure these parts out, but hopefully someone can extend the hand-scrolling one to do the following:

1) determine the overall patch size on load (maybe through JS), so the hand-scroll reaches everywhere
2) "zero" the current location on space-bar-press so that it hand-scrolls from there (as of now it jumps to the top left corner)

…if these were figured out, it would be totally viable to plop the controls into any patch you have. voila!

One other thought: wondering why one can’t do window-scrolling via a message to [thispatcher]? Not a big deal to do with JS, but anytime external files can be avoided, it’s a plus.


November 30, 2011 | 12:47 am

Hi, try use the several modes of mousestate: it can return the patch-relative values as well, so you can help the system to skip the top left corner effect.

i just implemented several navigation methods to the manope max presentation environment, like zoom with "z"+mouse up or down (for me it’s better whan with the wheel which i use for scrolling), navigate to "keyframes" etc, please check it:

http://makrame.periszkopradio.hu/en/alkalmazas/manope/

best
Balázs


Viewing 8 posts - 1 through 8 (of 8 total)