Re: AU automation gestures/scroll wheel events
Re: AU automation gestures/scroll wheel events
- Subject: Re: AU automation gestures/scroll wheel events
- From: Howard Moon <email@hidden>
- Date: Mon, 15 Jun 2009 14:16:55 -0700
Ok, but that doesn't answer the question about how to handle scroll
wheel changes that DO cause parameter value changes. Should begin/
end gestures be sent? If so, is there a preferred way to go about it?
-Howard
On Jun 11, 2009, at 2:47 PM, William Stewart wrote:
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:
40apple.com
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:
40antarestech.com
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