bkshepard

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.

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.


modifier-click-ui-objects

JSUI is one of the solution that can do this,

Another way would be to use [modifiers], [mousestate] and (the almighty) 

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

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

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 

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 :

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 :

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) :

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)

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!

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!


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.

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 just copy and past my patch into a window, you will have to trigger the [loadbang] before it will work.

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.

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.
>

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.

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.


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.

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.


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!

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!


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.

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.
----------------------------------------------------

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.


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.

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.
>

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.


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.

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.
----------------------------------------------------

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.

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.
>

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.


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.

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.
>

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.


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.

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.


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

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.

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

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

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

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

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


Modifier-Click UI Objects