computerscare modules v2 migration cries for help

Development
1

Hi! I’m trying to build computerscare modules for v2, I’ve run into this error upon running make:

../../include/engine/Module.hpp:122:15: error: assigning to 'ComputerscareMenuParamModule *' from incompatible type 'rack::engine::Module *'
                q->module = this;
                            ^~~~
src/MenuParams.hpp:183:3: note: in instantiation of function template specialization
      'rack::engine::Module::configParam<MultiselectParamQuantity>' requested here
                configParam<MultiselectParamQuantity>(paramId, 0, size - 1, defaultValue, label);
                ^
1 error generated.
make: *** [build/src/Computerscare.cpp.o] Error 1

I have multiple subclasses here which might be relevant. I have ComputerscarePolyModule inheriting from Module

struct ComputerscarePolyModule : Module { //...

And then ComputerscareMenuParamModule inheriting from ComputerscarePolyModule

struct ComputerscareMenuParamModule : ComputerscarePolyModule { //...

I’m defining this struct which inherits from ParamQuantity:

struct MultiselectParamQuantity : ParamQuantity {
	ComputerscareMenuParamModule* module;
	std::string getDisplayValueString() override {
		int index = Quantity::getValue();
		return module->getOptionValue(paramId, index);
	}
};

And the error comes from attempting to call configParam, passing this class as a template:

configParam<MultiselectParamQuantity>(paramId, 0, size - 1, defaultValue, label);

(line 183: computerscare-vcv-modules/MenuParams.hpp at v2.0.0 · freddyz/computerscare-vcv-modules · GitHub)

As the error message says, ParamQuantity doesn’t want me to set its module to an instance of ComputerscareMenuParamModule. This worked in v1 any ideas on what my problem is here?

Thanks in advance for any help anyone could offer!

2

I’m no developer but as it seems to be related to paramQuantity, could it be something to do with this?

https://vcvrack.com/manual/Migrate2#1-2-ParamWidget-paramQuantity-has-been-replaced-by-getParamQuantity

3

I don’t think so because in this case I’m not using a ParamWidget but… maybe?

4

@Vortico

5

Your ParamQuantity subclasses shouldn’t define module because you can already get the Module instance from them. It’s bad practice to store redundant references to objects because you have to do twice as much work to keep up with them. Simply remove your module member and use the existing one, casting as necessary.

6

Father in help. Man youre genius

7

I had the same issue on many of my ParamQuantity classes as they change behavior depending on properties of their modules. I renamed my own module reference and took the bad practice-way because I was worried about dynamic_cast on the dsp-thread.

Q1. Am I right about avoiding dynamic_cast on the dsp-thread? I think I read about this somewhere, maybe in Bruce‘s paper (@Squinky).

Q2. Is there a chance you could convert the type of ParamQuantity::module to a template parameter which defaults to Module?

8

dynamic_cast is pretty slow, but at least it doesn’t involve allocations, so it’s okay to use on the audio thread, but there’s a better way…

If you can guarantee that you know the derived type of a pointer, you can use reinterpret_cast for free.

9

Thanks. I assumed reinterpret_cast does not work in this case for some reason but I need to look into it again.

10

Thanks again, reinterpret_cast does work fine :+1:

11

Makes sense, thank you for the reply and explanation!

12

wasn’t me! although is seems like it’s a good point. In these cases I think the types are related so perhaps static_cast would work, too? If so, it’s slightly less hacky looking, although pretty much the same thing?