View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0007266ardourfeaturespublic2017-03-04 17:512020-04-19 20:18
Reportermike-overtonedsp Assigned Tox42  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
PlatformArdour5OSLinuxOS VersionUbuntu 14.04 LTS
Product Version5.8 
Summary0007266: Support for 'effSetBypass and related effCanDo' in VST plug-ins
DescriptionLatest release (beta V2.4.2) of the OverTone PTC-2A plugin now (in theory) supports 'effSetBypass' and provides visual feedback to the user (UI greys out). Would be nice if Ardour supported this 'canDo' - see additional information
Steps To ReproducePress the 'Bypass' button in Ardour, plugins which support 'effSetBypass' (advertised to the host by returning non zero from effCanDo when called with string "bypass") can respond either with their own internal bypass,and / or with some visual feedback to the user that they are disabled.
Additional InformationHost calls dispatcher in the plug-in with 'effCanDo' opcode and parameter string 'bypass'. Plugin returns a non-zero value, indicating support for 'effSetBypass'. When the user presses the hosts 'Bypass' button for the plug-in the plug-in's dispatcher function should be called with opcode "effSetBypass' and parameter 1 or 0 indicating bypassed (1) or not (0), or the host can call the plug-in's setBypass function directly (with parameter 1 or 0). This would enable plug-ins which support this feature to either bypass themselves (allowing them to switch on / off or in / out gracefully e.g. clearing filter histories etc) and provide visible feedback to the user. Example, the latest release (V2.4.2 Beta) of the OverTone PTC-2A for linux should respond by greying out its UI (this is the behaviour on other OS in cubase when the host's bypass is selected)
TagsNo tags attached.

Activities

x42

2017-03-06 00:44

administrator   ~0019492

A first prototype of this is implemented in Ardour 5.8-74-ge6f4f179b

It'd be great if you could double-check if everything works as expected.
If you don't compile Ardour from source, tomorrow's https://nightly.ardour.org/ build should do.

Thanks for brining this to our attention! click-free bypass is a very nice feature.

mike-overtonedsp

2017-03-07 11:21

reporter   ~0019500

Last edited: 2017-03-07 11:23

 Thanks for adding that, just tried with 5.8.85-g5956e86 and it seems to be working as expected. Probably stating the obvious, but, it is of particular importance that this feature is only triggered for plug-ins which have reported that they can support it (via the canDo) so we avoid any potential backwards compatibility issues (for example, blindly triggering effSetBypass and expecting a plug-in to behave, might cause session breakage if a plug-in fails to respond or implements some default / previously untested behaviour). Ardour appears to be negotiating this correctly.

x42

2017-03-07 12:00

administrator   ~0019501

Thanks, for checking. I'll close this ticket then.

As side-note, I did find a plugin which does report CanDo "bypass", but the actual call to effSetBypass returns 0 and nothing happens (u-he Presswerk Linux VST [1]). So I've also included a check if un-bypass works returns != 0 after instantiation. I don't know if that's established procedure.

Current logic is in
https://github.com/Ardour/ardour/blob/master/libs/ardour/vst_plugin.cc#L97-L115


[1] reported to the u-he forum at https://www.kvraudio.com/forum/viewtopic.php?f=31&t=424953&p=6722882#p6722882

mike-overtonedsp

2017-03-07 14:03

reporter   ~0019502

Last edited: 2017-03-07 14:09

 The VST2.4 SDK says that the plug-in's setBypass should return true if it supports a 'soft bypass' e.g. the host should then continue to call the plug-in's audio process, because it might need to 'stay alive' and the plug-in will handle the bypass iself e.g. copying its inputs to outputs (perhaps with whatever internal latency compensation it might need to apply etc).
If the plug-in returns 'false' then the plug-in doesn't support a 'soft bypass', the host doesn't have to call the plug-in's audio process during bypass, and the host can bypass the plug-in's audio process.
The same applies for calling using the dispatcher and effSetBypass opcode - typically the plug-in's dispatcher will just do something like:

case effSetBypass:
  return setBypass(value);
  
where 'value' is true to bypass the plug-in or false to un-bypass it.

This appears to be what the u-he plug-in is doing, from your description, and it is what our plug-in's will do if they support this feature.

Therefore the suggested logic might be as follows (rather than checking the effBypass result on instantiation, which might race a plug-in depending upon how various functions are implemented) :

1. Check effCanDo 'bypass' to see if the plug-in supports a 'soft bypass' - this can be done at instantiation.

2. When the user presses the host's bypass button, if the plug-in claimed to support effSetBypass, trigger effSetBypass in the plug-in.

3. If effSetBypass returns 'true' - the host should continue to call the plug-in's audio process, and the plug-in will handle the bypass.

4. If effSetBypass returns 'false' - the host should assume the plug-in didn't in fact support the request, and should implement the bypass itself.

x42

2017-03-07 14:47

administrator   ~0019503

It's not easy with Ardour's current Plugin abstraction to handle ceases where a plugin announces that it CanDo "bypass" but later fails to do that.

Really what's the point of this anyway? Allowing plugin-devs to only implement bypass for some easy cases and skip the hard (e.g. latent) ones, then blame the host if bypass clicks? "CanDo" should be named "MaybeCanDo" :)

A graceful fallback will require a lot of refactoring (or some nasty hacks) and I'm not yet prepared to handle it for a couple of odd-one-out plugins.

I do expect from professional DSP to be able to properly bypass itself under any condition (or not at all and document it if there's a good reason for it)

The current implantation indeed makes the assumption that un-bypassing a newly instantiated plugin is a no-op. If this can lead to a race-condition there's arguably a lot more wrong with the plugin: Bypass must be in sync with processing or you cannot guarantee click-free bypass to begin with, can you?
Then again you might be right that there are some plugins in the wild for which this can be problematic. I guess we'll find out.

mike-overtonedsp

2017-03-07 15:29

reporter   ~0019504

I think the point of it is to allow the plug-in to say 'yes I can do soft bypass' and then to also be able to inform the host 'I tried to do the bypass, but something went wrong' (who knows what might have caused that, but it's just a method to inform the host whether the soft bypass actually happened, so the host can intelligently handle the situation and, most importantly, the user still gets something like expected behaviour)

(It's not a plug-in / host blame game, it's about consistent user experience, there are plenty of plug-ins that break host applications, and there are plenty of odd things different host applications do which break plug-in functionality, we just have to work with it. It's just the same if you plug together supposedly compatible hardware boxes together, even analogue ones, sometimes odd things happen - and, in a studio environment, people tend to blame the biggest thing in the room, usually the console. In software that might be the DAW)

If you follow the logic I've set out, it should work without breaking - the most important thing is not to break backwards compatibility. I thought it would be a simple fix, but if it's too difficult to implement without major changes within ardour, then don't waste time on it, we can live without it. I just thought it would be nice if it worked like it seems to in other DAWs.

Its just an (unfortunate) fact that you should never *assume* how a plug-in might be doing something internally based on what you (or I) might *think* is sensible, because we don't know how it's actually implemented, therefore it has to be 'safe' from a user perspective, first and foremost. If you trigger bypass on instantiation, it shouldn't do anything but I can't guarantee that's true for every plug-in you might encounter anymore than you can.

x42

2017-11-09 18:40

administrator   ~0020082

Last edited: 2017-11-09 21:26

 @Mike: It was just brought to my attention that the PTM5a does not handle effBypass correctly. It only grays out the GUI, but processes the signal regardless.

Other OvertoneDSP plugins e.g. AF210 do handle this correctly (proper click free bypass).

According to the VST spec (copy at https://github.com/josephernest/smplr/blob/master/vst/audioeffectx.cpp#L1005-L1021)
"process will be called, the plug-in should compensate its latency, and copy inputs to outputs"

Could you please verify the validity of this bug report (it came in on #ardour IRC) to rule out an ardour issue. Thanks

x42

2017-11-09 18:59

administrator   ~0020083

Last edited: 2017-11-09 21:09

 PS. Doing a quick test myself using the demo VST, it looks like effBypass does work with the PTM-5a and has the same effect the left-side switch "EQ On/Off".
-- not the right-side "power on/off" switch in the plugin GUI.

So when the host asks the Plugin to bypass, the plugin still does some processing, and not just "copy inputs to outputs" as the VST standards recommends.

Unless this is intentional, it would seem to be a bug in the PTM-5a plugin. effBypass should probably make the plugin behave as if it was powered-off (right-side power switch, not left-side EQ on/off)

mike-overtonedsp

2017-11-09 22:36

reporter   ~0020084

@x42 - it seems as if the plug-in calls the 'wrong' bypass function in its DSP, though this particular emulation has some features (as does equivalent hardware) which make the concept of 'bypass' more subtle. The hardware behaviour is to provide the user with only the EQ In / Out switch, which simply switches the passive filters in and out of circuit but leaves the active (tube) gain stage in the signal path. This is currently what gets triggered by 'effSetBypass' from the host.
Obviously in the real hardware, the power switch powers off the unit - to emulate this in the plug-in would mute the signal and be essentially pointless, so the power switch provides a clean bypass once the DSP has 'powered off' - the complication being that the tube amp model has to 'warm up' when it is powered on and off.
To 'fix' I would need to implement a separate 'Ardour bypass' path in the DSP to allow this to work as the user wishes, which, unfortunately will potentially break session compatibility in (almost all) other host applications / sessions.
At the present time the user should be able to obtain usable / acceptable functionality with the plug-in's controls which means this is not going to be a high priority.

x42

2017-11-10 02:44

administrator   ~0020087

Last edited: 2017-11-10 02:52

 OK, so this is intentional, fair enough. I suggest to just document it "This plugin truly emulates the actual hardware including its bypass characteristics (low freq rolloff)." or something along those lines. Problem solved.

I don't understand the 2nd part. Could you please elaborate?
How is Ardour different from other VST hosts with respect to effBypass?

Why would a separate "Ardour bypass" be needed, while it's not needed in other VSTs hosts? Or asked differently: What would need to be changed in Ardour to make a dedicated plugin-side "Ardour bypass" unnecessary?

system

2020-04-19 20:18

developer   ~0023730

Issue has been closed automatically, by Trigger Close Plugin.
Feel free to re-open with additional information if you think the issue is not resolved.

Issue History

Date Modified Username Field Change
2017-03-04 17:51 mike-overtonedsp New Issue
2017-03-06 00:44 x42 Note Added: 0019492
2017-03-06 00:44 x42 Assigned To => x42
2017-03-06 00:44 x42 Status new => feedback
2017-03-07 11:21 mike-overtonedsp Note Added: 0019500
2017-03-07 11:21 mike-overtonedsp Status feedback => assigned
2017-03-07 11:22 mike-overtonedsp Note Edited: 0019500
2017-03-07 11:23 mike-overtonedsp Note Edited: 0019500
2017-03-07 12:00 x42 Note Added: 0019501
2017-03-07 12:01 x42 Status assigned => resolved
2017-03-07 12:01 x42 Resolution open => fixed
2017-03-07 14:03 mike-overtonedsp Note Added: 0019502
2017-03-07 14:04 mike-overtonedsp Note Edited: 0019502
2017-03-07 14:07 mike-overtonedsp Note Edited: 0019502
2017-03-07 14:08 mike-overtonedsp Note Edited: 0019502
2017-03-07 14:09 mike-overtonedsp Note Edited: 0019502
2017-03-07 14:47 x42 Note Added: 0019503
2017-03-07 15:29 mike-overtonedsp Note Added: 0019504
2017-11-09 18:40 x42 Note Added: 0020082
2017-11-09 18:59 x42 Note Added: 0020083
2017-11-09 20:41 x42 Note Edited: 0020083
2017-11-09 21:06 x42 Note Edited: 0020083
2017-11-09 21:09 x42 Note Edited: 0020083
2017-11-09 21:26 x42 Note Edited: 0020082
2017-11-09 22:36 mike-overtonedsp Note Added: 0020084
2017-11-10 02:44 x42 Note Added: 0020087
2017-11-10 02:47 x42 Note Edited: 0020087
2017-11-10 02:52 x42 Note Edited: 0020087
2020-04-19 20:18 system Note Added: 0023730
2020-04-19 20:18 system Status resolved => closed