Subject: [linux-audio-dev] interesting LADSPA-relevant post on vst-plugins
From: Paul Davis (pbd_AT_Op.Net)
Date: Wed Apr 17 2002 - 16:22:07 EEST
I think we should consider this for LADSPA. As far as I can see,
the issues are identical. Joe is smart guy too, if that helps :)
--p
------- Forwarded Message
Date: Wed, 17 Apr 2002 05:37:04 -0700
From: Joe Bryan <joe_AT_uaudio.com>
To: <vst-plugins_AT_lists.steinberg.net> (VST PlugIns)
Subject: [vst-plugins] Re: SetBypass
This is interesting. Before the setBypass() function has even been
implemented, there are now two conflicting implementations for it!
First, Charlie proposed using setBypass() to interrupt a stream, and now TC
is suggesting using it to replace suspend/resume. Sorry, I do not believe
either interpretation is appropriate, and I will describe why.
The suspend/resume calls are both resource and state management functions
(i.e. they consume and release resources), and are therefore "heavyweight"
functions, while setBypass() is a lightweight flow control function only.
If setBypass() replaces suspend/resume, resource management suddenly
becomes flow control. There are a lot of plugs that depend on suspend() to
deallocate resources, and if this is replaced with setBypass(), the
resources cannot be released until the plug is completely removed. In
addition, there is no flow control implied by suspend/resume: the stream
stops completely.
I suggest using a new set of functions named stop() and start() as an
*optional* state change notification for use by plugs that care about the
integrity and status of the signal flow.
Currently, many VST hosts do not notify the plug if they interrupt the
audio stream being sent to it. This happens when plugs are disabled, or
when other plugs are inserted, thus causing a discontinuity or
repositioning of the stream, respectively. Currently, the stream's flow is
changed without proper notification to the plug, and this causes glitching
and other problems because of the discontinuity.
For example, in Cubase and Nuendo, if you insert a reverb on a track, run
signal through it, bypass/mute the track (or set the fader to zero), stop
the transport, then enable/unmute the track, the reverb will suddenly
output the tail from before the bypass/mute. This is manifested differently
in different hosts, but the result is the same: a signal discontinuity.
There is currently no good stream state change notification mechanism in
VST that's separate from suspend/resume and bypass.
I propose this solution:
Add stop() and start() methods to any plug that cares about the
notification. Hosts can optionally call stop() before interrupting a
stream, and plugs can optionally support it. If stop() returns 1, then the
host must call start() before continuing any processing. (Alternately,
suspend() may be called directly following stop() to shut it down.) The
plug would support these by simply resetting the stream's internal state
(clearing and buffers, etc.).
Here is an example state transition diagram for a plug:
constructor (state goes from new to init)
setup (state goes from init to ready)
resume (state goes from ready to started)
processing... (state goes from started to running)
[stop (state goes from started/running to paused)
start] (state goes from paused to started)
processing... (state goes from started to running)
setBypass(true) (state is unchanged, signal flow changes)
setBypass(false) (state is unchanged, signal flow changes)
processing... (state is unchanged)
suspend (state goes from paused/started/running to ready)
[resume (state goes from ready to started)
[processing...] (state goes from started to running)
suspend] (state goes from paused/started/running to ready)
destructor
(Note: the alternate state transition paths into suspend from stop and
resume are not shown, but these are also valid paths, as indicated by the
paused/started allowed current state for suspend.)
The use of setBypass() is now free to be used as its name implies it should
be used: to notify a plug that the stream *will continue playing* and the
plug should *bypass* it's signal processing and output the source.
For what it's worth, many plugs already have internal parameters for soft
bypass (all Powered Plug-Ins have one or more bypass params that provide
both glitch-free bypass and a DSP load reduction), and I believe this is a
better approach because it supports automation and remote control surfaces
better. For this reason, I see no reason to support setBypass unless it
simply maps directly onto a bypass parameter. A more consistent interface
would be to add a getBypassParamId() call to return the parameter ID for
the bypass parameter, and use the standard get/setParameter() interface to
control it.
- -Joe
Joe Bryan
Universal Audio
At 08:33 PM 4/16/02, VST PlugIns wrote:
>From: "Sven Duwenhorst" <svend_AT_tcworks.de>
>Subject: [vst-plugins] Re: SetBypass
>Date: Tue, 16 Apr 2002 10:18:16 +0200
>Message-ID: <INEBLGPNGICLKLKGGFDBMEKECLAA.svend_AT_tcworks.de>
>Content-Type: text/plain;
> charset="us-ascii"
>Content-Transfer-Encoding: 7bit
>
>The plugin should return 1 from its dispatcher call, if it supports
>setBypass. By default the dispatcher returns 0, if you don't overwrite
>setBypass (see AudioEffectX.cpp + .h). If your plugin supports setBypass, we
>do not call suspend/resume in Spark.
>
>Best,
>Sven
>TCWorks
#############################################################
This message is sent to you because you are subscribed to
the mailing list <vst-plugins_AT_lists.steinberg.net>.
To unsubscribe, E-mail to: <vst-plugins-off_AT_lists.steinberg.net>
To switch to the DIGEST mode, E-mail to <vst-plugins-digest_AT_lists.steinberg.net
>
To switch to the INDEX mode, E-mail to <vst-plugins-index_AT_lists.steinberg.net>
Send administrative queries to postmaster_AT_steinberg.de
------- End of Forwarded Message
This archive was generated by hypermail 2b28 : Wed Apr 17 2002 - 16:07:14 EEST