Re: AU automation gestures/scroll wheel events
Re: AU automation gestures/scroll wheel events
- Subject: Re: AU automation gestures/scroll wheel events
- From: Brian Willoughby <email@hidden>
- Date: Sun, 7 Jun 2009 15:43:51 -0700
On Jun 5, 2009, at 20:31, Jim Wintermyre wrote:
ii) Using the mouse scroll wheel for GUI elements poses the
problem of when to send begin and end gestures. I'm thinking the
best way would be to simply measure elapsed time between events
and send an end gesture if elapsed time is greater than a timeout
value. Anyone got any better ideas?
Yeah, that's a tough one. We have the same problem. We let the
user move the mouse over a knob and then move it by adjusting the
scroll wheel. But sending the begin/end gestures on each scroll
wheel movement notification (several per typical "scroll") breaks
in touch automation mode. The timer thought might be the best
workaround, just cancel it immediately if some other param change
starts before the timeout is reached. Yes, this will break if the
user actually intended to leave the last value "pressed" for a
while, but you simply can't do that with a non-pressable scroll
wheel. Typically users only want the scroll wheel for quick
adjustments of knobs anyway, as a shortcut to having to click and
drag. For something where they want to leave it at a certain value
for a while, they just have to click and drag.
That mostly seems reasonable, but I'm left with the question: Why
fake a gesture at all? When developing any software which responds
to gestures, I would not want to see certain changes grouped into a
gesture unless it was absolutely certain that they were indeed a
gesture that comes from human interaction.
Does Apple have anything to say about this? Is there any
recommendation for whether gesture begin and end messages should be
sent? It seems like there are three ways to handle this: A) Send no
gesture messages at all when the HID cannot sense gestures - only the
value change messages would be sent. B) Send begin and end gesture
messages around each individual value change, thus making it clear
that no two value changes can reliably be assumed to be part of the
same gesture. C) Use a timer to estimate gestures, without any
certainty, and place begin and end around groups. It's the latter of
the three that I find to be the least correct option, but that is
just my opinion at the moment. I'd like to hear more discussion of
this, particularly from Apple.
I've read the AudioUnit documentation, and skimmed the "ink gesture"
documentation, and I see nothing which condones "inventing" gesture
begin/end marks when they're not conclusive. The message is intended
to expand the API beyond mere mouse down and mouse up, but I do not
believe that it is intended that everyone insert these messages based
upon guesswork.
Brian Willoughby
Sound Consulting
_______________________________________________
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