Re: AUView opening before initialzation BIG HASSLE!
Re: AUView opening before initialzation BIG HASSLE!
- Subject: Re: AUView opening before initialzation BIG HASSLE!
- From: Urs Heckmann <email@hidden>
- Date: Mon, 8 Sep 2003 14:18:32 +0200
Angus,
you're in kinda big dilemma. You're a host manufacturer and a plugin
developer 8-))
I'm just a plugin developer and an advocate of AU's beauty. I want
hosts and plugins to behave correctly in order to avoid the stuff you
see all day. If my interpretation of the specs is incorrect, I'll fix
my stuff. But if my interpretation is correct, I want to see it work
that way, everywhere.
Most of the times, when confusion like that comes up, due to an
uncertainty, some people at CoreAudio team start mumbling, and they
come up with a verdict. This is important, to keep the standard clean.
The case that I experienced might happen only 1 out of 10000 times, by
sheer coincidence and circumstances. So most plugin developers may not
even experience this certain problem, until 2 months after a plugin
release a crash occurs, maybe live on stage during a Britney Spears
concert.
If there's certainty, this case can hopefully be prevented, both on
plugin side and/or host side.
Well, maybe I'm just confused that a lot of hosts already treat some
stuff "their own way". I think I'll use AUHosting as reference and add
it to my plugin distribution. Hence I'll offer stand alone versions of
my plugs that might or might not work with any other host :-b
Cheers,
;) Urs
Am Montag, 08.09.03, um 12:41 Uhr (Europe/Berlin) schrieb Angus F.
Hewlett:
Can you not just call Initialize() (or better, an internal initialize
method) from your plug when you run in to a problem? That's what I do
in
VST-AU:- if it is possible for it to complete a call without
Initialize()ing, it does so, but if it has to intialize those things,
it
does that instead. Equally, in the view class, I don't instantiate
anything
big until I need to create and display the view.
The downside of this approach is that it makes host load times a bit
unpredictable... depending on what the host asks for when scanning
plugins,
it may take a couple of ms per AU or a few hundred ms (many VST
plugins are
slow to load). I could improve performance some more by caching more
information than I currently do (the output configuration is cached;
the
audio I/O properties are cached; the parameter table is not).
Regards,
Angus.
At 03:27 PM 9/7/2003 +0200, Urs Heckmann wrote:
Hi,
I have a Music Devcie that publishes its parameters and stuff after
Initialization. This is legal, as far as I know. Before init, I return
an UnInitialized error on these requests.
A certain host sometimes opens the view before initializing the music
device. And that leads to a crash, because important stuff isn't set
up. (Even if I circumvent these crashes, the gui would just not
happen.
Void.)
How can I tell the host not to open the gui before initialization? -
Wouldn't publishing parameters and stuff AFTER init first implicitly
forbid opening the view?
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.
=======================================================
Angus F. Hewlett, Technical Director
FXpansion Audio UK Ltd - http://www.fxpansion.com
=======================================================
_______________________________________________
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.
_______________________________________________
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.