It seems (based on tests with a carla-patchbay plugin) that “bypass” and “disable” have the following intended functionalities:
“bypass” returns the input signal rather than the processed signal
“disable” stops the plugin processing anything (which can be great for reducing processor load)
At the moment, using both ”bypass” and “disable” at the same time results in the plugin becoming silent. My suggestion is that it should result in the normal bypass behaviour, but with the added benefit of no longer processing audio. This would be especially useful for processor-intensive plugins (such as patchbays containing many other plugins).
Having said that, the current behaviour might be more useful to some people, and a new one-click option for the behaviour I suggest could also be useful (to be used like “bypass” but with the benefit of reducing processor load).
It seems (based on tests with a carla-patchbay plugin) that “bypass” and “disable” have the following intended functionalities:
At the moment, using both ”bypass” and “disable” at the same time results in the plugin becoming silent. My suggestion is that it should result in the normal bypass behaviour, but with the added benefit of no longer processing audio. This would be especially useful for processor-intensive plugins (such as patchbays containing many other plugins).
Having said that, the current behaviour might be more useful to some people, and a new one-click option for the behaviour I suggest could also be useful (to be used like “bypass” but with the benefit of reducing processor load).