Forums > MaxMSP

mouse targeting issues when creating new patch cords

July 5, 2012 | 7:39 pm

I’m starting to get really frustrated (with what I suspect may be a bug?) when connecting patch cords. I’l hover over an object’s in or outlet, the red/blue circle appears, and when I clock-drag I start moving the object or drawing a selection box instead of drawing a new patch cord. It is very frustrating and has made me slow down considerably. After some testing I have discovered that the red/blue circle does not indicate the target size, which is likely part of the problem. I feel like the indicator should match the target size, as its conveying to me that I can click in this circle to make a connection. Is there a way to increase the patch target sizes? Is this a bug? Am I just moving too fast?

July 6, 2012 | 8:03 am

Zooming in would probably be the best fix, particularly if scroll type zooming were supported as in many graphics apps. If you are on the MAc this can be aproximated by scroll.

July 6, 2012 | 2:07 pm

Although the circle is bigger than the inlet/outlet, the active "hot" area for clicking/dragging patch cords is the rectangle of the inlet/outlet itself, not the circle around it. To zoom in and out while editing, you can use command = and command -.

July 6, 2012 | 4:23 pm

Scroll zooming is inexplicably missing in Max, at least on the Mac. Ctrl+Scrolling is actually OSX’s vision assistance which does a pixel zoom across all displays towards your cursor. Not desirable. Zooming with the keyboard isn’t exactly the greatest solution either, especially if the proposed solution is to zoom in and out every time one makes a parch connection.

I like the view at its native size, and have yet to feel any desire to zoom in. One could assume this is because i’m still editing rather simple patches, but i’ve made many complex patches in other node based environments and rarely used zoomed there either. That said, id never even try to use keyboard based zooming with the exception of a "zoom to default" hotkey to get back to normal. The ubiquitous "Cmd+Scroll" on Mac or "Ctrl+Scroll" on Windows seems the sensible zoom for a primarily mouse-based-navigation interface. It has become a standard for any XY canvas interface since the scroll wheel mouse was popularized.

Even knowing that the circle is not indicating the target area (as it very much seems to,) I’m still dragging objects instead of patching them a good 1/5 of the time. In an attempt to get to the bottom of the issue, I recorded my use of the app for a while to examine the misses up close, and did some basic target testing using a pixel loupe. In my use capture, I discovered that most of the time I was only a pixel or two off from the visual target, usually above it, weather or not I was starting from above or below the point. Fitts law may lead one to have trouble believing this, but many studies have shown this over shoot to be common in mouse environments.

Whats more, according to my tests in a defaulted environment, the targets to not line up with their visual indicators. The top most pixel of the patch point indicator very consistently does not start a patch cord, instead selecting the object in the case of an Out, or starting a drag selection for an In. Below the patch point indicator you can find as many as Two pixels of extended target which will start a patch cord when you are in fact over the canvas. While my recording indicates it hasn’t been an issue for me, i’l also note that the target seems to be three pixels narrower than the indicator on both sides.

All of this was at the default zoom, both with an without snap to grid on, in as many variations as I could think up at the time. OSX 10.7.4, Max 6.0.5 (1741622) Might anyone else care to try it out on a different system to verify?

These findings explain my frustrations using the application. While it appears to be a software issue, its worth noting that even if it were rectified I was still overshooting the patch point indicator in many cases. I believe expanding the target size a pixel or two beyond the indicator, in addition to fixing the target alignment, would greatly increase the reliability of making patch connections.

Even with these interface frustrations, i’m still really enjoying Max and all it has to offer. The only reason i’m providing this obsessive detail UX feedback is because i’m looking forward to using it quite frequently for many of my projects.

July 6, 2012 | 7:36 pm

FYI: Reported what I found with the bug report form and got a confirmation that they were able to reproduce, but not all the time. Issue logged, hopefully to be further investigated. Great response time. Max rocks.

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