Re: AUs with Cocoa UIs (in Logic)
Re: AUs with Cocoa UIs (in Logic)
- Subject: Re: AUs with Cocoa UIs (in Logic)
- From: Stefan Gretscher <email@hidden>
- Date: Wed, 25 Oct 2006 12:15:55 +0200
Hi,
first off, let me promote once more the official AU developer support
address for specific Logic-related issues:
email@hidden
This is where you can get in touch with the Logic development+QA
teams directly if you encounter any problem with running your AU in
Logic. It's an Apple-internal mailing list - while every AU developer
can post to it, only Apple employees can read the list.
As your questions are of general interest though, I'll answer on
coreaudio-api:
Am 25.10.2006 um 06:52 schrieb J Carlson:
I have tried AUs with Cocoa UIs different ways over time in Logic.
I get some inconsistencies which could be my fault - I haven't
explored every aspect of Cocoa UIs since I was prevented by such
behavior in my earlier attempts. AU Lab and Garage Band give
results which are different, where applicable. My results are
consistent with other developer's AUs with Cocoa UIs - including
Apple's example code so I have a feeling it is Logic's implementation.
The main issue we're facing here is that Logic is at its core a
Carbon application, while GarageBand and AU Lab are Cocoa-based. This
means that Logic needs to bridge Cocoa UIs to Carbon world, whereas
in the other two apps the Cocoa UIs work natively. The result is that
Cocoa UIs naturally work "better" in GarageBand and AU Lab than in
Logic, because in Logic there's an additional glue layer involved
which makes things much more complicated and thus more vulnerable to
bugs.
The root of most issues with Logics Cocoa-UI-bridge is that Carbon
and Cocoa maintain separate window orders - this means that while the
ordering between individual Cocoa windows is well-defined by the
Cocoa APIs, and ordering between individual Carbon windows is
similarly handled by the Carbon world, there's alas no dedicated API
to define the ordering between a Carbon window and a Cocoa window.
Logic tries to work around this problem, but the workarounds aren't
perfect, causing occasional window ordering problems and also
confusion about which window is supposed to have the key focus.
Things are made worse by the fact that Logic uses floating windows
for the plug-in UIs, which are by default not intended to get the key
focus at all.
A few points of difference:
1.
Selecting or opening a view makes it key. For example, moving a
plugin editor's position 1 px or simply clicking on the plugin
editor's background requires the user to select the Arrange ( for
example ) before Logic will acknowledge any Key Commands.
This had to be implemented on purpose to reduce the likeliness of the
next issue you mention to strike:
2.
Image overlay. This came up a few weeks ago ( on this list ), with
a demonstration photo. I don't remember seeing a solution. In this
case, the Cocoa view ( only ) will sit above other floating windows.
This happens when the window order is messed up. There's no
workaround known at this point (otherwise I'd already fixed it in
Logic).
Clicking on the window's header should restore the correct window
order again.
3.
Views "flop around" inside the plugin editor. If you are moving a
plugin editor, the cocoa view is a moment behind. Logic's standard
plugin elements ( Link, Bypass, presets... ) casts a shadow over
the view - though the view overlay has been improved.
The glue code has a slight latency because of the different timing of
Carbon and Cocoa. Again no workaround known.
My questions ( if it is Logic ):
1.
I am guessing this is not news ( or is it? ) since I have had such
odd behavior as long as I remember. I can file a proper bug report
if it is news.
No need to do this, these issues have been reported already. Alas as
explained above there's no easy cure to the issues. A potential
solution would be to move Logic from Carbon to Cocoa, but that
obviously is a huge amount of work.
I have developed AUs for a while, Cocoa, Carbon, and Generic.
Though mainstream support seems low, I would like to try Cocoa UIs
in my next project.
Improving the support for Cocoa based AU UIs is important to us, and
the more AUs with Cocoa UIs are around the higher this priority will be.
It may help us on this mission if you provided us with copies of your
AU(s) so we can test Logic with it in our QA team. If you're
interested in this, please contact me off-list.
2.
If it is known and a Logic issue, any announcements on when it may
be fixed I may not have seen?
Apple in general doesn't announce release until the software is ready
to ship. All I can tell you right now is that we're investigating
possible solutions.
My questions ( if it is my code ):
3.
Are there ways around this behavior?
I am not aware of it, but maybe some other developer of Cocoa UIs has
found some solutions?
Also, depending on how complex your code is, you might also consider
implementing both a Carbon and a Cocoa UI. This would guarantee the
best user experience (there's more hosts beside Logic that are Carbon
based and will suffer from the same problems), but of course this
requires a lot of work so you'll have to judge whether it's worth the
efforts.
At present, Carbon would be the only choice - if I can't overcome
this behavior.
Do you think the current implementation of Logic's Cocoa UI hosting
is so bad that it stops you from releasing AUs with Cocoa UI? Until
now I considered the issues to be glitches rather than show stoppers,
but if you say otherwise then we'll need to raise the priority of
these fixes and re-evaluate our schedules.
I assume AU Lab and GB are hosting properly since they host very
similarly.
see above.
4.
Are there any examples ( you could point me to ) that work properly
in Logic and AU Lab. Any other suggestions?
I was using the FilterDemo from the CoreAudio examples a lot when
implementing the Cocoa UI bridge in Logic. (I don't know though how
up-to-date the current release of FilterDemo the CA SDK is...)
Maybe some other developers using Cocoa for their AU UIs can share
their findings?
Best,
Stefan
------------------------------------
Stefan Gretscher
plug-in development & 3rd party plug-in support
Logic Pro team, Apple Computer
email: email@hidden
phone: (+49)-4101-495-586 (Central European Time)
AU developer support: email@hidden
TDM developer support: 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