View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007266ardourfeaturespublic2017-03-04 09:512017-03-07 07:29
Assigned Tox42 
PlatformArdour5OSLinuxOS VersionUbuntu 14.04 LTS
Product Version5.8 
Target VersionFixed in Version 
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.
Attached Files

- Relationships

-  Notes
x42 (administrator)
2017-03-05 16:44

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 [^] build should do.

Thanks for brining this to our attention! click-free bypass is a very nice feature.
mike-overtonedsp (reporter)
2017-03-07 03:21
edited on: 2017-03-07 03: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 (administrator)
2017-03-07 04:00

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 [^]

[1] reported to the u-he forum at [^]
mike-overtonedsp (reporter)
2017-03-07 06:03
edited on: 2017-03-07 06: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 (administrator)
2017-03-07 06:47

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 (reporter)
2017-03-07 07:29

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.

- Issue History
Date Modified Username Field Change
2017-03-04 09:51 mike-overtonedsp New Issue
2017-03-05 16:44 x42 Note Added: 0019492
2017-03-05 16:44 x42 Assigned To => x42
2017-03-05 16:44 x42 Status new => feedback
2017-03-07 03:21 mike-overtonedsp Note Added: 0019500
2017-03-07 03:21 mike-overtonedsp Status feedback => assigned
2017-03-07 03:22 mike-overtonedsp Note Edited: 0019500 View Revisions
2017-03-07 03:23 mike-overtonedsp Note Edited: 0019500 View Revisions
2017-03-07 04:00 x42 Note Added: 0019501
2017-03-07 04:01 x42 Status assigned => resolved
2017-03-07 04:01 x42 Resolution open => fixed
2017-03-07 06:03 mike-overtonedsp Note Added: 0019502
2017-03-07 06:04 mike-overtonedsp Note Edited: 0019502 View Revisions
2017-03-07 06:07 mike-overtonedsp Note Edited: 0019502 View Revisions
2017-03-07 06:08 mike-overtonedsp Note Edited: 0019502 View Revisions
2017-03-07 06:09 mike-overtonedsp Note Edited: 0019502 View Revisions
2017-03-07 06:47 x42 Note Added: 0019503
2017-03-07 07:29 mike-overtonedsp Note Added: 0019504

Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker