Emagic Logic Info was: AU : carbon view how to ?
Emagic Logic Info was: AU : carbon view how to ?
- Subject: Emagic Logic Info was: AU : carbon view how to ?
- From: Urs Heckmann <email@hidden>
- Date: Mon, 14 Oct 2002 23:47:32 +0200
Bill Stewart:
Or leave it the way it should be - this will help people get Logic to
make
sure it does this correctly:)
Bill
Hi Bill,
let's never forget they had to serve more platforms (including a very
odd one :-) until lately. That's why they used a crossplatform
framework approach with some limited features.
If I understand them right (we have mailings almost daily, and yes, I
get replies from email@hidden), they work hard on
throwing away that old stuff, using regular Carbon instead. - They say
some features in their latest build work better, automation lets
controls update/redraw. (A new LogicAU SDK may follow soon, VST porting
lib maybe as well)
Here is a rough (hopefully correct) translated transcript of my recent
questions regarding my problems with RumblenceAU:
UH: Do you replace mCarbonPane with something proprietary?
E: No.
UH: Is the Toolbar a real Toolbar or a View/Control?
E: Afaik, it is something rather selfmade. That's from times when we
ran 3 platforms. We currently work on fitting it better to carbon.
<snipped a dumb question>
UH: Does Bill's [that's you, Bill :-) ] suggested tempo/measure thing
work in 5.4?
E: Yes.
UH: Is my AUView allowed to install an EventLoopTimerRef (as sort of
[VST] idle() replacement) and let controls update from there?
E: Yes. Unfortunately one can't send idle-events from host to plugin.
UH: Am I right that controls receive only MouseTracking events but no
Click/Hit/Hittest?
E: [statement of apologies + a little sigh, not translateable] This
refers somehow to your first question. There will hopefully be a
solution soon.
UH: Is there something more you [Emagic] do with controls or ports
[referring to an oddity with my first test plugin releases] one should
better know about :-)?
E: [referring to a bug in Rumblence I addressed tonite, implying NO as
answer] You should certainly save the old port before any drawing, then
[before drawing] call SetPortToWindowPort and restore the old port
afterwards.
<snip>
So I was wrong : the pane was not blocking events, it was Logic
in fact... I understand now.
So I probably should use Mousetracking temporarily (I don't like
that...), and then move to normal carbon event handling once
Emagic really support carbon event model.
Many thanks for the code,
@ Raphael: You're welcome!
Last but not least I will post a new version of Rumblence with the
drawing bug (a port confusion, my fault, not Logic's) solved tonite.
Lesson learned:
Always finish CG drawing (initialized with QDBeginCGContext (
windowPort, &context ); ) with
CGContextSynchronize( context ); // updates the drawing while tracking
the mouse
QDEndCGContext ( windowPort, &context );
Use the windowPort (something that should be clear but could easily be
overseen by newbies like me :-) and restore the current port...
Hope these "news" are helpful...
Cheers,
;) Urs
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.