It works! For future reference: Here is what I did (pseudocode):
struct RectLightWidget : LightWidget
{
void drawLight(NVGcontext *vg) override
{
//copy/paste implementation from LightWidget::drawLight
//change circle to rect
nvgRect(vg, 0, 0, box.size.x, box.size.y);
}
};
struct RectMultiLightWidget : RectLightWidget
{
//copy/paste implementation from MultiLightWidget , no changes required
};
struct RectModuleLightWidget : RectMultiLightWidget
{
//copy/paste implementation from ModuleLightWidget, no changes required
};
struct GrayRectModuleLightWidget : RectModuleLightWidget
{
//copy/paste implementation from GrayModuleLightWidget
//replace
template <typename T = RectModuleLightWidget>
};
//optional: define light dimensions
template <typename BASE>
struct TinyRectLight : BASE {
LSR3TinyLight() {
this->box.size = Vec(5,3);
}
};
//define colours
//example: red light
struct RectRedLight : GrayRectModuleLightWidget {
RectRedLight() {
addBaseColor(COLOR_RED);
}
};
I am not sure if this is the most elegant solution though. All structs that inherit from the light widget have to be defined again for every desired light style while their implementations remain unchanged. That causes redundancy. A better solution would be to make the the light widget class more general so that it can represent different light styles.
Because I was in a hurry and had other tasks while doing this. That is why I put that caveat note below the code, too. Consider it work in progress
Thanks for taking time to read and comment on this stuff!
I think I know why I intuitively went for LightWidget: A modification of LightWidget, maybe so that there are not just circles but several options to choose from, would eliminate the need for subclassing (unless you want something exotic). Then again, this is code outside the plugin, so I can not modify it. So the solution is subclassing. The last missing step was to do this at the lowest possible level.
Updating the lights in every step seems to be expensive (~20 millisamples in my case). It is also unnecessary since the UI frame rate is much lower.
A solution would be to have a counter that is incremented each time step() is called. Once the desired number of steps (maybe corresponding to 10ms intervals) has been counted, the lights are updated and the counter is set back to 0 again.
The counter works but brightness decay is VERY slow now. I suppose there is a time constant somewhere that needs to be adjusted.
Found it:
engine.hpp -> struct Light -> void setBrightnessSmooth(float brightness, float frames = 1.f);
The time constant and its default setting: float frames = 1.f
It needs to be set to the number of frames per counter reset.
Example:
sample rate 44.1kHz
10 ms @44.1kHz is 441 frames
set lights[…].setBrightnessSmooth(vuMeter.getBrightness(j),framesPerCounterReset);
Just performed a little experiment: Set frames to 441, 44.1 and 4.41 for one light each.
Result: Brightness decays in roughly ~200 ms, ~2 s, ~20s.
So the decay is corrected for time scaling as expected.
I’ll take a look at VuMeter2 tomorrow (it is now almost 11:00 p.m. here).
I’d like to display the coloured “plate” (note or fundamental) by night (Room brightness < 100%).
These plates are all .SVG - 24 files total, two for each sector (12 for minors + 12 for majors), each having both grey (off) or coloured (selected note).
My goal is to display the coloured plate even when dark room / night mode condition. Other 23 grayed can stay “hidden” by night.
I’ve done it for displays (via drawLayer, on layer 1), but I’m lost about SVGs…
void Display::drawLayer(const DrawArgs& disp, int layer) {
if (layer == 1) {
// avoid lightened stuff when you module is bypassed
ModuleWidget* parentWidget = dynamic_cast<ModuleWidget*>(getParent());
if (parentWidget && !parentWidget->isBypassed()) {
// draw the lightened stuff here
}
} else {
// draw the other stuff here
}
Widget::drawLayer(disp, layer);
}
please
