[linux-audio-dev] VST 2.0 observations

[David Olofson]

1. getTimeInfo() does *not* take a time argument of any kind;
   only a 32 bit filter, to say which fields you actually need.
   That is, you can only get the full info for the start of
   the buffer. There is a tempoAt() call, that gives you the
   tempo at the specified sample frame in the buffer.

2. The VstTimeInfo struct is interesting. I like the unit
   for musical time: pulses with 1 PPQN. :-) Tempo is in
   BPM. (Why not QN/s? ;-) There is a field that says where
   the last bar starts. There's also time signature, SMPTE,
   MIDI clock (samples to next clock) and a bunch of flags.
   Flags include transport changed, playing and "cycle
   active". (The latter come with loop start and end positions,
   obviously.) And automation reading + writing... It is also
   interesting to note that the "sample position" field in
   here is timeline bound - it may jump! There's a nanoseconds
   field as well, holding the "system time" corresponding to
   the first sample in the buffer.

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.

3. There are calls that allow plugins to get the audio input
   and output latency.

Conclusion:
	c. I'm assuming that this is mostly useful for
	   VU-meters and other stuff that needs to be
	   delayed appropriately for correct display.
	   Obviously not an issue when the audio latency
	   is significantly shorter than the duration of
	   one video frame on the monitor! ;-) Seriously
	   though, this is needed for "high latency"
	   applications to display meters and stuff
	   correctly. They're not very helpful if they're
	   half a second early!

4. There is a feature that allows plugins to tell the host
   which "category" they would fit in. (There is some
   enumeration for that somewhere.) Might be rather handy
   when you have a large number of plugins installed...

5. A getCurrentProcessLevel() host call lets the plugin ask
   what kind of context it's being called from. Can return
   values corresponding to "not supported", "user/GUI",
   "audio/irq", "sqeuncer/irq" and "user/offline". Other
   values are possible and "probably" (as they say) mean
   something that pre-empts the user thread.

6. There is support for using the whole process() call
   asynchronously. This is for external DSPs and stuff. The
   plugin is expected to return "instantly" from process(),
   and then the host wanders off to do something else. The
   host will use another plugin call to poll, to see if the
   data from the external DSP (or whatever) is available.

Conclusion:
	d. I think we can ignore this feature. We don't
	   do external DSP, and we don't feel like having
	   hosts poll/busy-wait for data, do we...?

7. There's a bunch of calls specifically meant for off-line
   processing. This is basically about accessing the host's
   "open" files, setting markers and stuff, being notified
   when files are opened, closed, changed, when markers are
   changed etc. A plugin API in itself.

8. You can ask the host about the speaker arrangement,
   for surround stuff...

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"!)

10.Finally, the states. There are 2 calls related to this;
   suspend() and resume(). Nothing much is said about these,
   and they're not used for much in the examples. Just for
   clearing delay buffers and the like. Memory is generally
   allocated in the constructors and freed in the destructors,
   but I'm not sure when and where you're supposed to
   reallocate buffers if you need to... (This is when you
   start realizing why compatibility problems with VST are
   so common. Where are the reference docs!? *heh*)


//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 -'
.- M A I A -------------------------------------------------.
|    The Multimedia Application Integration Architecture    |
`----------------------------> http://www.linuxdj.com/maia -'
   --- http://olofson.net --- http://www.reologica.se ---