Wishlist: Any chance of trowaSoft multiSeq port?

Plugins
21

ok, the key to the problem seems to be this module creates new light widgets.

in particular they derive from rack::app::ModuleLightWidget (which comes from LightWidget)

they then override

	void drawLight(const DrawArgs &args) override
	void drawBackground(const DrawArgs& args) override

however, these methods never get called.
in fact I can also override draw(const DrawArgs &args) and that never gets called either.

these are correctly added via addChild(), and are kind of present, as I can change the colour, as I can see that circle to change colour.

my guess?
something is losing the type of these objects, and is treating them as basic LightWidget, which is what the circle is likely to be, and hence why if I setColour() on it, it will change.

but no other overridden drawing is being done, due to lost type.

note: since they use the override in declaration, the compiler is happy with the inheritance hierarchy.

this overriding of ModuleLightWidget is being done for a number of its custom widgets, hence why we see these ‘circles’ instead of intended graphics.
Id guess, if the overridden methods start to get called, most of the issues will be fixed.

to double check, Id need to create a new test plugin to ensure there is not something else odd going on within the plugin.

however, given this plugin does work on the desktop with this code, it looks like its likely something in the firmware

thoughts @danngreen ?

what has made this pretty tricky to track down, and created a few false ‘leads’ is there is so much redundant code within the module, stuff thats not being used, but looks like it might :frowning:

22

Ah… ok, so the MM does not call the draw*() functions for every widget (doing so makes the GUI unusably slow). It strategically calls draw() and drawLayer() only for widgets that it doesn’t know how to render natively. Which means anything that it recognizes as a LightWidget, ParamWidget, or PortWidget will be rendered natively, and only widgets that are unknown will be drawn. Basically, anything that’s added via addChild and doesn’t get caught by one of the overloads in app/ModuleWidget.hpp in the SDK, will be added as a “graphical display”. In addition, if the ModuleWidget itself has an overload for draw() or drawLayer(), it’ll be a “graphical display”. All “graphical displays” get their draw() and drawLayer() functions called when visible on the screen, and all other widgets are rendered natively without ever calling draw*().

ModuleLightWidget is sort of a border-case. If the widget has a non-zero number of colors (widget->getNumColor() != 0) then the MM will use it as a light. But if has 0 colors then the MM can’t really render it as a light so it renders it as a “graphic display” and therefore will call that module’s draw() function. I’m not sure the reasoning for the practice of creating lights with 0 color, but some plugins are doing that so I added that bit to support them.

The default overload for LightWidget::drawLayer(args, 1) will call drawLight(args), so that should work. But I don’t think drawBackground is called from anywhere.

Also, keep in mind drawLayer() is only called for layer==1, never for any other layers.

Edit: some docs on this (less detailed than what I just wrote): metamodule-plugin-sdk/docs/graphic-displays.md at main · 4ms/metamodule-plugin-sdk · GitHub

And yeah, the way the MM natively renders a light is with a circle. So that explains the circles.

23

hmm, thats quite a deviation from vcv behaviour…
I did notice your implementation of LightWidget was ‘lighter’ than the vcv implementation, but assumed it was taking a different approach.

I’ll have to review this info, and think if anything can be done.
this plugin is doing this a lot as a means to create ‘custom components’.
my fear is, even if I can hack around it, without butchering the code base - its sounds like, the MM might have an issue with rendering performance.

but I’ll have to get some time to play, to understand a bit better what MM is doing, then see if I can find an approach that might work for these plugins.