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: Urs Heckmann <email@hidden>
- Date: Sat, 17 May 2003 15:17:45 +0200
Am Samstag, 17.05.03, um 12:52 Uhr (Europe/Berlin) schrieb Angus F.
Hewlett:
>
>
> 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.
Well, IIRC, Howard would get along quite well with the ppq field of
VstTimeInfo if not Cubase SX had a bug, where this field is only
updated every second call on dual processor macs.
Crossreferencing with VST mailing list, it's that bug in SX that let
Howard change Autotune's behaviour from ppq to transport fields. Until
then, Autotune worked correctly with ppq only. So, if the bug wasn't in
SX, Autotune would still work with your wrapper.
Howard could just license your technology, use it on an old-way
compiled (ppq...) Autotune and that would be it. Probably.
>
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.
So do I 8-)
Well, we think quite the same. - Hey, your wrapper will help a lot of
companies with their stuff, and that's good.
But: If a high percentage of AUs come as wrapped VSTs (in opposition to
internal abstraction layers), so maybe wrapped VST will be the common
AU on the market (which I think is likely), I'm afraid that the
workaroundings that are common to VSTism will somehow affect AU world.
Howard's posting is the first (yet harmless IMHO) example for this I
found.
Dunno, but what if someone comes up with a request that serves the odd
sides of VST? - Like the neglected open() call which has a very well
implemented equivalent in AU's initialize()?
I mean, you already do a tough job on oddities like Waveshell, but -
paranoid as I am - I could imagine a bunch of really underwhelming
requests comming up...
Or something like that automation stuff (a funny rumor I heard
recently) of a well known company where the multitimbral info is coded
in the least 2 bit of the parameter values 8-) - What if a
double-int-float-double-something cast screws this up? Should AU be
modified to support this in this case?
>
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.
Absolutely agreed.
But I think it's a fact that many plugin developers out there think "if
it runs in Cubase, it must be right". - Now that obviously even Cubase,
SX and Nuendo have differences in the VST implementation, what shall be
the truth for them?
As long as Bill's argument doesn't apply to VST, so as long as portions
of the standard seems somehow undefined, I consider this the biggest
advantage AU has over VST. Well, if Bill's argument applies to AU 8-)
>
This whole idea of VSTGUI needing to be open-source in order to
>
develop AUs
>
with it is nonsense.
Hmmm, right, one could get along with the Mach-O version. - But if I
take into account what problems even you had making it run properly
with the Emagic stuff... I think it would be more comfortable to look
into it and adopt some of the AU goodies like Parameter Listeners etc.
(Well, my obscure telephone call was with someone who already had
VSTGUI's source and he asked me how to get some stuff running...)
>
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.
Yes, but in this case, I have the impression that the order of reason
is wrong. It'd be more sensible to ask for a feature with a concrete
problem of the format, not with a reference to a bug in another
application and another standard. Well, and if that request was valid,
hehe, wasn't it your question first 8-) ?
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.