• 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: Stealing transport control in Cocoa AUs & Logic (& elsewhere)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Stealing transport control in Cocoa AUs & Logic (& elsewhere)


  • Subject: Re: Stealing transport control in Cocoa AUs & Logic (& elsewhere)
  • From: Paul Davis <email@hidden>
  • Date: Fri, 15 Apr 2011 14:45:08 -0400

On Fri, Apr 15, 2011 at 2:24 PM, Jonah Petri <email@hidden> wrote:
> Hello list,
>
> My plugin pops out a utility window which accepts first responder and responds to some keyboard events.  Unfortunately the events which I don't handle (e.g. the spacebar key) go to the window's noResponder: method, which just beeps.  This means that when the user has my window frontmost, he can't use the normal keyboard events to control transport.
>
> Is there some convention for handling this case?  I could synthesize events to be sent to the window containing my main AU view... that's the best idea I've come up with at the moment, but I don't want to make some host developer miserable in the future by doing something hacky like that...

Ardour/Mixbus has a toggle button that changes key handling in a
plugin window. Our default allows the host to be the first responder;
if the button has been turned on, we forward all key events to the
plugin window without attempting to handle them in the host.

however, you are using an *extra* utility window. the guidelines apple
have issued for "making plugins play nice with Logic" include a
recommendation *not* to do that. doing so will also have negative
impacts on ardour/mixbus, and its hard to imagine how it wouldn't make
life tricky for any host.

I quote:

   "For even better user interface integration, custom Audio Unit
Views should refrain from using overlay windows and from opening
sheets or auxiliary windows other than for file browsing. All user
interface elements should be presented inside the root Audio Unit View
by laying out its content dynamically and resizing as necessary. The
host window listens to size change notifications and will adapt
automatically."

See http://developer.apple.com/library/mac/#technotes/tn2207/_index.html
 _______________________________________________
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

References: 
 >Stealing transport control in Cocoa AUs & Logic (& elsewhere) (From: Jonah Petri <email@hidden>)

  • Prev by Date: Stealing transport control in Cocoa AUs & Logic (& elsewhere)
  • Next by Date: ExtAudioFileRead lengthInFrames issue
  • Previous by thread: Stealing transport control in Cocoa AUs & Logic (& elsewhere)
  • Next by thread: ExtAudioFileRead lengthInFrames issue
  • Index(es):
    • Date
    • Thread