Re: AU automation gestures/scroll wheel events
Re: AU automation gestures/scroll wheel events
- Subject: Re: AU automation gestures/scroll wheel events
- From: Jim Wintermyre <email@hidden>
- Date: Fri, 19 Jun 2009 18:04:15 -0700
Hmm, lots of comments on this one recently. I've been out for a bit
and missed all the fun. A few more comments:
- The reason we added scroll wheel support was because *users
strongly requested it*. They also want it to work with automation.
To me, that's a pretty damn good reason to do it, and if it has to
work with automation, you have to send gesture events, even if there
is not a "real" gesture start and end in the sense of clicking a
physical button. And I must say, in actual use it is very intuitive
and quick - just move the mouse over knob 1, scroll wheel to new
value (holding down a modifier like shift if you want finer control),
move to knob 2, scroll wheel to new value, etc.
- What is at issue here is getting it to work with automation, and
more specifically touch automation mode (with other modes it will
"mostly" work if you send gesture begin/end on each individual scroll
wheel event). Generally, when users change a parameter, they want it
to be automatable. They don't care how the parameter changed,
whether it was from a mouse click/drag, a control surface, a scroll
wheel, or a text box. From that standpoint, I respectfully disagree
with Bill's implementation, and suggest that if you're changing a
parameter from a text box it *should* send gesture begin/end events,
so that the param change can be automated. (Having said that... I'm
not sure our plugins actually do this for our knobs that also have
text entry boxes, gotta go check that!) Maybe the notion of
"gesture" is getting overloaded here since it also means "automate"
in this case. I'm putting on my flame-retardant suit now...
- I think I like the mouse-region-enter-exit strategy for when to
send the gesture events for the scroll wheel event, but with a couple
tweaks. First, only send the gesture start event on the first scroll
wheel event, not when the mouse enters the region of the control.
That's more likely what the user expects, especially in touch
automation mode. If they really wanted to click on the knob at the
current value and keep it there for a while, well, they can click on
it and keep it there for a while (instead of using the scroll wheel).
Typically when they're using the scroll wheel they want to just make
quick adjustments to different params. So using mouse-leaving-region
as a signal for when to send the gesture end on a scroll wheel event
seems pretty reasonable. I think I'd made it a user preference
though, with the other option being a user-settable timeout.
Jim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden