• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: AU automation gestures/scroll wheel events
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Prev by Date: Re: Using alBufferDataStatic()
  • Next by Date: Merge Wav files
  • Previous by thread: Re: AU automation gestures/scroll wheel events
  • Next by thread: processing question
  • Index(es):
    • Date
    • Thread