Bypass and lights

Development
1

Hello,

I have just ported over some modules from V1 to V2. I tried to support all new features of V2 needed to work according to the standards and feature set. That’s why I tried to implement proper “Bypass” rules and “Light” support.

Current situation (in my modules and also other modules): In “Bypass” mode the module gets grayed out and all lights remain bright.

My expectation: When setting the module into “Bypass” mode I would expect that the module gets grayed out and all lights should be turned off or grayed out.

What do you think? From my point of view it would be helpful/needed to define the “standard” behavior, whether it is the current one or any other one.

Regards, Alexander

2 Likes
2

I agree with this. It seems it’s been left up to the dev to turn off the lights when the module is bypassed. This can be done as detailed here: VCV Manual - Migrating v1 Plugins to v2

void processBypass(const ProcessArgs& args) override {
		lights[LIGHT_ID].setBrightness(0.0f);
        ...
}
3

According to the latest Rack 2 Changelog the lights (and most likely any light-emitting widget) have to be turned off.

2.0.2 (2021-12-06)

  • Turn off lights if module is bypassed.
4

That revision added this commit: Don't assert if ModuleLightWidget accesses out of bounds lights, simp… · VCVRack/Rack@02cceec · GitHub

So it seems that the lights now go off automatically if a module is bypassed.

5

It is now working perfectly for “real” lights after I implemented processBypass:

	void processBypass(const ProcessArgs &args) override
	{
		// * lights
		lights[LED_IN].setBrightness(0.0f);

		// * call this to make the default behavior work
		EntfernerBase::processBypass(args);
	}

For my other custom light-emitting widgets, I had to implement some changes in my “Widget::Draw()” code to make it work. In pseudo code:

if module->isBypassed() turn the light off.
6

Sorry, why are you doing this? Like Steve said “the lights now go off automatically if a module is bypassed” which I also see happening in my modules. Or am I missing something?

7

If your custom widget is linked to a light, then the brightness of that light will be set automatically in bypass. But if you have some other sort of widget which you have made light emitting, it might need additional code changes.

8

That is the second part of his answer, but I mean in his example the override of processBypass. That looked to me as setting standard lights. But doesn’t matter as long as we all understand what needs to be done .

9

I see what you mean. That should be completely unnecessary.

10

Exactly. Since that commit, one only needs to override processBypass if you want to “turn off” some other light emitting widget. Standard LightWidget lights/LEDs are now handled by Rack, unless drawn by drawLayer for DarkMode.

11

Correct, my mistake! For “standard” lights it works without implementing processBypass().