Re: AU automation gestures/scroll wheel events
Re: AU automation gestures/scroll wheel events
- Subject: Re: AU automation gestures/scroll wheel events
- From: William Stewart <email@hidden>
- Date: Thu, 11 Jun 2009 14:47:08 -0700
we don't send begin/end gestures if the change is not a gesture that
would begin a potential series of parameter changes.
For example, when you directly edit the value of the parameter in a
text box, then we just set the new value - no gesture
Bill
On Jun 7, 2009, at 3:43 PM, Brian Willoughby wrote:
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
_______________________________________________
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