Re: Moving our AU plugin to Leopard/Xcode3
Re: Moving our AU plugin to Leopard/Xcode3
- Subject: Re: Moving our AU plugin to Leopard/Xcode3
- From: William Stewart <email@hidden>
- Date: Tue, 13 May 2008 11:45:44 -0700
I'm not sure that I understand the "fixing the initialization code"
comment - could you point me to exactly what this is.
Oh, and just to be clear - we certainly do not make changes to
deliberately break or cause difficulties. However, some amount of
change is necessary and will continue to be ongoing. The main concern
we have is not source compatibility, but rather binary compatibility:
- if you have the source and are recompiling, then some changes maybe
needed. We try to minimise these, and we also try to break builds
where these changes would be bad if they weren't made. Then you know
you have to make them! You have the source, and we endeavour to
explain the need for these changes in the read me that accompanies the
example code
- binary compatibility is that existing binary code that hasn't been
changed should continue to work. We don't always achieve this I'll
admit, but it is a goal that we take seriously.
Bill
On May 13, 2008, at 9:45 AM, Chris Johnson wrote:
On May 13, 2008, at 11:38 AM, Olivier Tristan wrote:
tahome izwah wrote:
I agree in general.
But AUCarbonViewBase::HandleEvent() is clearly Carbon specific, and
you don't need it in a Cocoa AU.
If you tend to support all major AU host, I don't think you can
safely do Cocoa AU GUI so far. so I guess I'll wait for this.
For myself, I will be keeping a close eye on any reports of the
base AU class requiring changes, as I'm not very good at keeping
abreast of such chaos. My work is strictly generic interface in part
to protect me from just such incompatibilities, and I'll be very
disappointed if Apple manages to screw even me up, as apart from the
actual DSP code my stuff is very crude and simple. That's happened
before, however, with Apple's failure to include a working example
of initialization code in the AU templates. I strongly encourage
Apple to provide their basic 'gain change plugin' example template
in working condition and unbroken... for those of us who aren't very
smart and can only trust that the provided example is in fact correct.
Apart from that, Audio Units rock- since fixing the initialization
code as directed by Sophia Poirier, I've had zero technical
complaints or incompatibility reports from users for my generic/host
interface plugins. Thanks CoreAudio guys- please always try to not
pointlessly screw up the basic stuff :)
Chris Johnson
airwindows
_______________________________________________
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
_______________________________________________
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