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 15:18:26 +0100
At 03:17 PM 5/17/2003 +0200, you wrote:
>
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.
True.. provided suspend()/resume() (or Reset() in AU parlance) is called at
transport start. However, there's still the problem there of:-
- transport is not moving, we are at (say) 00:00:00 (ppq = 0)
- suspend/resume or Reset() is called
- at the next buffer, transport is still at 00:00:00 (ppq still = 0)
- the plug has no reliable way of knowing whether the transport started,
and hence playback should begin, or whether the stream was reset for some
other reason.
- at the next buffer after that, PPQ will have moved if we're playing
back... but that's TOO LATE for some plugs (like Paul's "Groove Agent", or
Autotune in some circumstances) - they already missed a buffer!
>
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()?
Most versions of VST-AU actually try not to load+instantiate (and open())
VST plugin until initialize() anyway. However it depends on what else the
host calls before initialize()... basically VST-AU delays loading the VST
plugin until as late as it thinks it can get away with.
>
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-)
Multitimbral VST plug-ins #$%^)*#% 2@#U%( t#$(%^ !#@$**( !W$)*(@#)) @#%*(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Honestly, though, I've never heard of this case... mail me off-list with
the details if you like.
>
What if a double-int-float-double-something cast screws this up? Should AU be
>
modified to support this in this case?
Absolutely not. The wrapper should implement a code workaround for the
particular plug - remapping the parameter space so that the stupid VST plug
behaves properly.
>
But I think it's a fact that many plugin developers out there think "if it
>
runs in Cubase, it must be right".
Yes, and I'll tell them to their faces what I think of that >:-)
>
Now that obviously even Cubase, SX and
>
Nuendo have differences in the VST implementation, what shall be the truth
>
for them?
Well, we all know the problem there... neglect by the owners of the spec in
seeing it implemented consistently or in making judgements as to correct
behaviour and then following those through. I've had more extra work than
most people from this kind of rubbish... Big Company X's plug-in's locked
up the system when variable sized buffers were fed to them; even though Mr.
Steinberg himself stated that plug-ins should be able to handle this, it
took Big Company X over a year to fix the problem. In the mean time I had
to add unnecessary workarounds to my host that polluted the standard and
overcomplicated my code.
Next time around I'll just bust out the debugger and hex editor and "fix"
their code myself.
>
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-)
Agreed, but that's much less of a problem in the situation where companies
are licensing a wrapper, because at least they can make sure that it
conforms to their interpretation of VST, and the wrapper can be customized
to meet different requirements in that regard.
>
>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...
Yeah, well, the Emagic stuff could be better.
>
I think it would be more comfortable to look into it and
>
adopt some of the AU goodies like Parameter Listeners etc.
True, that would be useful.
>
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-) ?
Not mine... I think it was Paul and Howard :)
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.