Forums > MaxMSP

Modifier-Click UI Objects

January 30, 2009 | 11:19 pm

In a number of audio programs the user interface objects like faders and knobs frequently respond to thinks like double-clicking or option-clicking–usually to return them to some default setting or position. Is something like that possible in Max 5? I’ve tried using a ubutton, but that covers the object and prevents you from using it in the normal way, or if it’s behind the object, it doesn’t register the click. I guess it could be done using the mouse coordinates from mousestate combined with the modifiers object, but that seems awfully convoluted. Is there some other (better) way to do this? Thanks.



Ch
January 31, 2009 | 8:25 am

One could do something like that :

– Pasted Max Patch, click to expand. –

does it fit your needs?


January 31, 2009 | 4:09 pm

JSUI is one of the solution that can do this,

Salvator


January 31, 2009 | 5:12 pm

Another way would be to use [modifiers], [mousestate] and (the almighty)
[hover].
I might post an example later ;)

Ciao


January 31, 2009 | 6:47 pm

Ch and Salvator, thanks for the replies and suggestions. Ch, your patch will set the fader, but it doesn’t pass the output since it’s using the "set" message. As for the JSUI, I’m using pictsliders, so I need something that "sits" on top of them. Here’s a solution I came up with using mousestate. One of the things I’m trying to avoid in this patch is a bunch of unnecessary polling, so I have it configured to only report the mouse position when you click the button. Depending on where the gain object ends up in your patcher window, you may need to change the numbers in the four >= and < = objects to reflect the new coordinates.

———-begin_max5_patcher———-
880.3oc0Yt0aSCCEG+41OEVQ7FcSw14JhgDWdAIjlDBdBlPoItsdzDGU6JJL
Ae1wWR1VYsItWRn8E6Fa23+me93iOI4tgCbFyVQ3NfW.9BXvf6FNXftIUCCp
tdfSdxpz4Ib8vbRY44jBgyHSeBxJgt8qKETVwEucNM86.NQvAhYDvjjLxBff
Afnn5+RYhHcFsX52VPREloFF3do6HPrp.FoqPxV.2T8WnY54fM91Kfw02mIr
BQQRNQ20qWPSlW2SwxbZwboFTcAezv4zeoGNDImh6GKaondvtpF+8vgphQGH
QdGU1LWBENfMA742Ctd7sRK9qEefLQLB7Q5zYxpOwJGAdCSHX402g4zBRJaY
g91f1N0vgAZfgf5JeMCwdagaQmZbSdGFSVzfWAtxQ.qpLV2ZdEl4W7yRhY7N
T0p.vYbRwTmMxfvtjAn8fA4DNOYJ4I9NsrcILRCiX8BOFcouZaSSjYy3HXGw
AZWvAbebIH+PJrmPCNYtz1A9VfDeckOpcmEsWxnsgF+tDMniGZJokD.rcv.i
8TUd31AylAB9LwWgrpbA3YTH34xRjtDqK8zk13CgB0DKDsurBsirx++DqxYY
zITxBdSPw2b5Rf1+IDacT3sVsQjA6xHy9GOj8xqjQZaZ+FFUcnrtxKxNdsQl
3dlrk6UWA7ZBInH+GiD39ij3yDhH8RBajHddGIhDc93i32HQLY4cDHR3oFQl
lPK9SCltI.6ClrjBdMZ4b5zBkwrcFDznk1YIiTkmFzhiSLqyGbdZdmZoossD
5kG01RdZQ5k9.cnxJHs6ozetjk1bVRlYgsMOErNRYfqkNJaBJntL2hiZ5XK4
DtHQPZGKwAlTUQcT9X8U5X5IW+FO9m2Bk1zUsuNG4rkKRqsrpv8fGL9LI+nE
IpWE0iFiJgb.79AMilkQz8WqubZVISxhJM.tYiKp1JIUxr.TaZBulv6bMgsk
S8mlBVaUYKRJrewTfEXJX2jDLJT8BZvPyCh6pCns9Ulm3zOt92GpU3ayhcP+
RVjMZxue0jqsaJ75MMEaqjv8ljhrURndSRd1HIX+5LYSPe2SNIE26JpsP9Qm
bJpeOCxJe6c7HHY9ypuQf44sflOrx5WEYNOxLvnnC+LHKrBudkq3NfqQw035
XxNaNpDuWd.lOORkr86GkdHggkW76g+E8.z+5B
———–end_max5_patcher———–



Ch
January 31, 2009 | 10:36 pm

I would not use mouse coord if i were you. to hard to maintain.
I would use the patch I post with a slight modif :

– Pasted Max Patch, click to expand. –

Just a suggestion.
Ch.



Ch
January 31, 2009 | 10:53 pm

oups sorry,
there’s a right to left weird bug in what I post, but you should fix it quite easily. (drag the number box to the right to see it working)

Or here is a different way (more complicated but that works well) :

– Pasted Max Patch, click to expand. –

Ch.


February 1, 2009 | 4:10 am

Great ideas gang! I’ve made it work using the patch I posted above, but ch is right, if anything in the window moves, I have to recalibrate all the numbers. These ideas are much more elegant. I’m especially intrigued by the [hover] object. I hadn’t thought about that one. I’ll give ‘em all a whirl. Thanks!


February 1, 2009 | 5:19 am


February 1, 2009 | 8:06 am

gusanomaxlist really intrigued me with the idea of using [hover]. Here’s an example with 4 [gain~] faders that when shift-clicked jump to 127.

– Pasted Max Patch, click to expand. –

February 1, 2009 | 8:32 am

If you just copy and past my patch into a window, you will have to trigger the [loadbang] before it will work.


February 1, 2009 | 9:21 am

Quote: bkshepard wrote on Sun, 01 February 2009 00:06
—————————————————-
> gusanomaxlist really intrigued me with the idea of using [hover]. Here’s an example with 4 [gain~] faders that when shift-clicked jump to 127.
>

If you want this to scale up to handle many objects more easily, you might want to try using thispatcher scripting. This approach could be adjusted to use some sort of object naming convention for the default value of the object. Say you are mixing many different GUI objects in one patch, you could use regexp and a coll to map the names to default values… I didn’t patch that up but here’s your patch updated to use thispatcher.

Personally, I like charlie/Stefan’s solution better, because you can wrap that up in a bpatcher and drop it into any patch and it will just work. This solution requires extra infrastructure that you have to take the time to setup in every patch.

– Pasted Max Patch, click to expand. –

February 1, 2009 | 1:24 pm

Nice one Adam ;)


February 1, 2009 | 6:04 pm

How many outlet ports do you folks get with the [hover] object? When I create one on my PPC G4 OS 10.4.11, [hover] has two outlets. However, when I create one on my Intel Powerbook OS 10.5.6, [hover] has four outlets. Is there a difference in the way this object works on PPC vs. Intel machines? I’ve noticed other differences between the way Max/MSP seems to operate between the two machines as well.


February 1, 2009 | 6:29 pm

Sorry, ignore my previous message about the number of ports. I had version 5.0.1 on my G4 and 5.0.5 on my PowerBook. Updating to 5.0.5 on the G4 resolved the problem.


February 1, 2009 | 6:39 pm

Adam, that’s really cool. I agree the Charlie/Stefan solution is easier to implement and really clean, but I do dig the scripting aspect as well. Thanks for that little demonstration!


February 2, 2009 | 2:00 am

Quote: bkshepard wrote on Fri, 30 January 2009 17:19
—————————————————-
> In a number of audio programs the user interface objects like faders and knobs frequently respond to thinks like double-clicking or option-clicking–usually to return them to some default setting or position. Is something like that possible in Max 5? I’ve tried using a ubutton, but that covers the object and prevents you from using it in the normal way, or if it’s behind the object, it doesn’t register the click. I guess it could be done using the mouse coordinates from mousestate combined with the modifiers object, but that seems awfully convoluted. Is there some other (better) way to do this? Thanks.
—————————————————-

Interesting thread with some good examples. Also I noticed that the fourth outlet of [modifiers] will respond to a right-click (since Mac treats control-click as a right-click, or vice versa). Don’t know about on Windows, will investigate.

It would also be nice to grab the scroll-wheel motion, but it seems to be restricted to moving the window scroll bars. Anyone know how to grab these values? Could be nice for zooming in and out of a waveform or scrubbing through a movie.


February 2, 2009 | 2:28 am

Quote: seejayjames wrote on Sun, 01 February 2009 18:00
—————————————————-
> It would also be nice to grab the scroll-wheel motion, but it seems to be restricted to moving the window scroll bars. Anyone know how to grab these values? Could be nice for zooming in and out of a waveform or scrubbing through a movie.
>

I can get scrollwheel input with [hi] -> [route 30]. My mouse sends a 1 each time I scroll up and -1 when I scroll down (or 2/-2 if I scroll really fast). So you probably need a running sum ([accum]) to keep track of an absolute scrollwheel position in your patch, but it’s definitely workable.

The number to watch in [route] might be different for you. Not sure though, I didn’t install any mouse drivers so this is probably part of the standard mouse protocol.


February 2, 2009 | 2:41 am

Quote: Adam Murray wrote on Sun, 01 February 2009 18:28
—————————————————-
> The number to watch in [route] might be different for you. Not sure though, I didn’t install any mouse drivers so this is probably part of the standard mouse protocol.
—————————————————-

Now I’m curious how portable this approach is. Does this patch work for other people? I tested this patch on OS X using a Logitech bluetooth wireless mouse.

– Pasted Max Patch, click to expand. –

February 2, 2009 | 3:09 am

Quote: Adam Murray wrote on Sun, 01 February 2009 20:41
—————————————————-
> Quote: Adam Murray wrote on Sun, 01 February 2009 18:28
> —————————————————-
> > The number to watch in [route] might be different for you. Not sure though, I didn’t install any mouse drivers so this is probably part of the standard mouse protocol.
> —————————————————-
>
> Now I’m curious how portable this approach is. Does this patch work for other people? I tested this patch on OS X using a Logitech bluetooth wireless mouse.
>

OSX, Logitech standard corded optical mouse gives me [10] as the scrollwheel number. I can’t get the +2 and -2, only +1 and -1.

Very cool especially as you can track with other apps active, including keystrokes (as [key] only works with Max active) if you focus upon the keyboard in [hi].

Any thoughts on how the mouse might be selected automatically by the [hi] object? Could do with [regexp] as long as there’s a "mouse" somewhere in the name, but wondering if there’s another way.


February 2, 2009 | 3:45 am

Quote: seejayjames wrote on Sun, 01 February 2009 19:09
—————————————————-
> Any thoughts on how the mouse might be selected automatically by the [hi] object? Could do with [regexp] as long as there’s a "mouse" somewhere in the name, but wondering if there’s another way.
>

You probably know you can type in the device name as an argument to [hi]. But to make something that just works on anyone’s computer? Regexp match on "Mouse" could probably work most of the time. However, since we just discovered that the scrollwheel control number is different between our mice, I’d be more concerned about that.

Probably a general purpose patch would need some sort of initial configuration step to have the user set the right device and control number. Then store those in some pattrs that autorestore when the patch loads.


February 2, 2009 | 6:43 am

I have the Apple Optical USB Mouse (Mighty Mouse), and it doesn’t seem to output a value through [hi] when the little scroll ball is moved. Pressing the ball, left- and right- clicking, as well as the two side buttons all produce values (5, 3, 4, 6 respectively) and moving the mouse is 7, but rolling the little scroll ball doesn’t seem to produce a value.


February 2, 2009 | 9:15 am

Here’s a modification of Adam’s [hover] patch that allows for different controllers to be sent different values.

– Pasted Max Patch, click to expand. –


f.e
February 2, 2009 | 9:40 am


February 2, 2009 | 10:42 am

bkshepard,

JSUI can replace both pict controller and mousestate etc…
Down the roead, I found it to me the most flexible way to do it. Attached is a simple patch.

Alt-click = reset to default
Shift-click = fine tune

Now if anyone know how to cath the scroll wheel in javascript, I’m strongly interested.

Salvator


February 2, 2009 | 10:55 am

re : this is a max 4.6 patc, which need the .pat extension …

Salvator


February 2, 2009 | 5:06 pm

Salvator, that’s excellent! I obviously need to work on my JavaScript chops!


February 5, 2009 | 7:46 am


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