Re: [linux-audio-dev] VST 2.0 observations

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] VST 2.0 observations
From: David Olofson (david_AT_olofson.net)
Date: Sun Dec 15 2002 - 06:57:09 EET


On Sunday 15 December 2002 04.57, Tim Hockin wrote:
> > Conclusion:
> > a. The information is there, but you have to *pull*
> > it from the host. Doesn't seem like you're ever
> > notified about tempo changes or transport events.
> >
> > b. Since you're asking the host, and there are no
> > other arguments, there is no way that one plugin
> > can keep track of more than one timeline. It
> > seems that it is assumed that there is only one
> > timeline in a net.
>
> So all the mechanisms we're discussing are more flexible?

Seems like it...

> Obviously we don't have EVERYTHING hammered yet..

Well, I think it's time someone look into the implementational issues
of timeline calculations. How much does it *really* cost? How about
SMPTE and other fields?

Also note that VST didn't have events at all from the start. That
*might* have affected their design decisions.

[...]
> > 4. There is a feature that allows plugins to tell the host
> > which "category" they would fit in. (There is some
>
> Ick - external.

Agreed.

However, should we have categorization as part of the host SDK (along
with preset management etc), or just let applications deal with it?

I vote for having it in the SDK... (Or you won't find your plugins
unless you arrange them all once for each application. *heh*)

> > 9. There is a bypass feature, so that hosts can have
> > plugins implement sensible bypass for mono -> surround
> > and other non-obvious in/out relations. (As if in/out
> > relations ever were to be assumed "obvious"!)
>
> not clear what you mean..

Actually, this is not very clear at all. What does "bypass" really
mean?

Well, VST was originaly a very "primitive" API for FX only, and the
plugins were used for inserts. No nets or anything; just basic chains.

So, one would assume that "bypass" is as simple as copying the inputs
to the outputs. Pretty much like ripping the plugin out, although the
host is able to have the same effect on the processing, while still
leaving the plugin in the "net". The advantage would be that the
plugin could still run VUs and stuff.

These days, the most important advantage is probably that you can use
"bypass" to have plugins with non-obvious in->out relations do the
"same thing" logically. As in a mono->5.1 plugin piping the mono
input to the center output or something, when "bypass" is activated.

No idea what synths and other "non-FX" plugins would do... (If they
support it at all. They probably don't in general.)

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sun Dec 15 2002 - 07:03:41 EET