Re: Transport start/stop for Effect Units needed
Re: Transport start/stop for Effect Units needed
- Subject: Re: Transport start/stop for Effect Units needed
- From: "Angus F. Hewlett" <email@hidden>
- Date: Sat, 17 May 2003 11:52:14 +0100
At 09:52 AM 5/16/2003 +0200, you wrote:
>
I think it wouldn't be appropriate to change the APIs to get a
>
workaround running for those who do not want to use the APIs.
That's absolutely true. But perhaps you can point out HOW Howard's code
might accomplish its job IF it were written as an AU?
If the functionality is not there, it makes no difference whether there is
a wrapper or not. Equally, if the functionality IS there, it should be
possible for the wrapper to translate it.
>
But I see now that some companies are
>
going to license his technology to get rid of the need to convert their
>
stuff from VST to AU. If you follow user postings on sites like
>
osxaudio.com, you'll see that a lot of musicians will consider that as
>
an imposture. Any company that ships "AudioUnits" which in fact are
>
VSTs sent through the wrapper will gather annoying feedback.
Urs, you should know better than that. The developer wrapper technology is
not the same thing as the end-user wrapper, and AudioUnits which have been
compiled with it are indistinguishable from "the real thing" (whatever that
is) from the end-user's perspective.
Also, you should know that most companies that support multiple plugins
will either license wrapper technology from a third party (FXpansion is not
the only company developing such technology) or develop their own wrapper.
It's the only remotely sensible way to go. A wrapper on the technical level
is equivalent to an abstraction, which is usually seen as a GOOD thing in
programming terms. No company can afford to rewrite all their plugs for the
different platforms, and there is no need to do so. Maybe if VST -really-
sucked as a platform (I mean more than the stupid lack of documentation),
or AU offered some really important things that users wanted which VST
could not provide, it would be a different matter. However, as things stand
today that is not the case.
>
I don't see much of a difference between "wrapped VST" and "true
>
AudioUnit". - Except for, like consensus of buggyness in VST world,
>
every other plugin that's coded strictly for Cubase SX will cause some
>
sort of problems with the wrapper and possibly bring another
>
modification request for AU on the table.
The problem there is not with the wrapper, the problem is targeting Cubase
SX too closely in ones' VST code. Those of us that code on the Wintel and
OS 9 platforms as well have to support a ton of different VST hosts, and
targeting only Cubase SX would be positively foolish in most cases.
>
However, any additional effort made to support this "subversion" of
>
AudioUnits standard wouldn't make the situation better (I mean lack of
>
AUs). - It's not hard to write AUs, and the day VSTGUI goes open source
>
(under BSD license, I've heard), any techy problems will be gone,
>
especially those with Emagic's porting stuff (well, if they manage to
>
improve that a bit as well).
This whole idea of VSTGUI needing to be open-source in order to develop AUs
with it is nonsense. Sure, it's better to have the source available, but
it's not necessary at all. Also, people are using these kind of
capabilities in VST; it clearly has a useful application. I agree that the
AU spec should be kept intact and developed cleanly. HOWEVER, in cases like
this it is necessary to either (a) show that the capability DOES already
somehow exist in AU, or (b) note that it does not exist, and table for it
to be added to the spec in a planned way at a later date.
>
Sorry I had to say this (after long telephone calls with another guy
>
who just prove me right last weekend).
What do you mean..?
Regards,
Angus.
=======================================================
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.