Re: AUGraphInitialize in audio thread
Re: AUGraphInitialize in audio thread
- Subject: Re: AUGraphInitialize in audio thread
- From: Marc Poirier <email@hidden>
- Date: Sun, 20 Apr 2003 07:02:17 +0200 (CEST)
On Thu, 10 Apr 2003, Angus F. Hewlett wrote:
>
At 02:30 PM 4/9/2003 -0700, Brian Willoughby wrote:
>
>
>Considering your needs - to alert the user about insufficient licensing -
>
>perhaps CoreAudio should allow for an exception to be raised, or add a
>
unique
>
>return code to indicate licensing restrictions. It would be up to the
>
host app
>
>to display the text of the exception, or to interpret the return code.
>
>
>
>It's a very common and powerful design principle to create code units which
>
>have no UI. This technique allows them to be used in many more ways than
>
>initially predicted. Breaking the paradigm by popping up alert panels is
>
>probably something that will restrict the flexibility of AudioUnits.
>
>
I must say, I have some reservations about this. Specifically, what other
>
classes of functionality besides UI might break or be unsafe in these other
>
uses? Or is it -only- UI that's affected?
>
>
Also, is this restricted to Initialize(), or does it apply to constructors
>
as well?
I think that no one is saying that it's strictly forbidden (the "breaking"
problem really is a bug in AUGraphInitialize, it shouldn't really happen),
but I think that folks are just saying that it's much better to not do
what I was doing, from a good design point of view and just that it is
more what is expected from plugin behavior. Maybe I'm misunderstanding,
but that's what I am gathering, that this isn't totally forbidden stuff,
just discouraged.
But so far as discouraging things go, I think that it definitely should
really be discouraged to do any UI stuff / alerts / etc. from the
component constructor because so often hosts scan plugins and minimally
construct them when the app launches, and it sucks to get an alert from a
plugin while the host app launches. That's just my opinion, though.
>
Finally, with regard to error messages, how about a Property for "last
>
error message". So, whenever the plug returns an error, it can set the
>
contents of a text buffer (or even a more detailed structure) internally,
>
which the host can receive via a GetProperty() call.
That sounds like a good idea. Yeah, if we're getting discouraged from
presenting messages from the audio component, then we need another
option... :)
Marc
_______________________________________________
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.