Re: Open times are too long
Re: Open times are too long
- Subject: Re: Open times are too long
- From: Howard Moon <email@hidden>
- Date: Thu, 27 Mar 2003 14:59:46 -0800
I'm a little confused as to how the VST2AU wrapper could be modified to
"generate properly behaved AudioUnits". The VST plug-in being
converted to an AudioUnit may itself have to be changed in order to
accomplish this, correct?
For example, our VST plug-ins all construct the editor class from the
constructor of the effects class. (Which, btw, is one of the problems
that has so far prevented us from successfully using the wrapper to
display our custom gui.) This means that when the AudioUnit effect is
constructed, even if simply for the purpose of getting its property
information, our editor (view) is also constructed. In order to
decouple that, we will have to modify our VST code, which, given that
we still support VST hosts, is not something we want to do until we are
sure that the whole AudioUnits paradigm is stable and generally
accepted.
On a related topic, I have previously asked (eMagic) about the problems
we had, and at least one item has still not been responded to: why is
the effect class constructed twice when running Logic Audio, but only
destructed once? Something I read in this thread implies that that is
still the case. Am I correct?
Howard
On Thursday, March 27, 2003, at 02:18 PM, Jeff Moore wrote:
ComponentOpen is not just an AudioUnit selector. It is used by every
component based API out there. So, there is no way to pass a flag that
indicates that the open is for informational purposes only. Plus, the
Component Manager will open and close components all the time in the
normal course of doing it's job. The only feasible solution to the
problem Bill outlines is to make ComponentOpen be as lightweight as
possible.
Glenn, you make two valid points. The VST2AU code should be updated to
generate properly behaved AudioUnits (I'm sure Bill will apply the
appropriate pressure). And in the future, placing commonly queried
static information in the AU's component resources sounds like a
really good idea.
But this will only go so far.
First, we're talking about something for the future, which doesn't
help hosts today. Then, there are probably plenty of things that would
be of interest to a host that cannot be put into a resource. So I
don't thing that one can get away from the fact that ComponentOpen has
to be as lightweight as possible to make working with AU's convenient.
On Thursday, March 27, 2003, at 12:39 PM, Glenn Olander wrote:
I think you put your finger on it by identifying the coupling of
the view and the AU as the largest culprit. This is currently
enforced by the VST2AU wrapper. Considering that the majority
of plugs will probably be using that, it might be fruitful to
address the problem in the wrapper. Perhaps add a flag which indicates
when an instantiation is just for the purpose of querying properties,
in which case the GUI (and other classes) instantiation may be
skipped.
Of course, if these "lightweight" instantiations are just for the
purpose of querying properties, then perhaps those properties should
be
kept in a resource so they may be queried without instantiating
the plugin at all.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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.