re-instantiate modules to "unstuck"

Development
1

I am still beta testing my NLS plugin. It works as it supposed to except for one thing: sometimes when I open the patch these modules have some outlets (LFOs, triggers) that are “stuck”. They start working again is I delete/undo them, sometimes I have to do it several times. The most problematic one seems T2G (trigger to gate). I thought this was related to some un-initialized variable. I went over the code multiple times and added default values. I am using the Vult language to generate the cpp code. At this point I am at a loss as to what is causing this random behavior. Here is the plugin release link Any feedback or direction to resources related to this issue is much appreciated!

2

Parameter values get saved and restored by rack automatically. I suspect you may be observing a knock-on effect of that. Implement dataToJson and dataFromJson to hook into the serialization steps and take control of how/when your parameters are initialized.

2 Likes
3

That makes sense, though I am not familiar with those steps. I will look around this forum to find out more about it. Thanks

4

You might also read the development API guide on the subject: Data serialization

5

I’ve always used the “automagical” serialization of parameters. There may be some cases where it isn’t what you want, but I think it would be misleading to suggest to people that they need to implement their own json serialization to make their module work. yes?

6

Even when you implement the serialization overrides, you still get all the autoserialization for parameters. If the automatic stuff isn’t giving you the right results, then it’s an option to consider, along with considering making more settings that aren’t a knob into a param, like Squinky did for menu options. Making most things params enables more of the ecosystem that is based on params, like the pamoply of Stoermelder mods.

7

I hoped that would be true. But I could not get Transit to recognize widgetless parameters when mapping the entire module.

BTW - pampoly ??? → panopoly ?

I was shocked that dictionary.com does not include an entry for panopoly.

But merriam-webster.com and some others do include the word.

8

‘panoply’ I think it is, not ‘panopoly’ :wink:

2 Likes
9

There it is! Thanks. My mind played tricks on me when I looked at the Merriam-Webster site.

I’m surprised dictionary.com did not pick up panoply with my misspelling.

10

Don’t beat yourself up over this, it is a common misspelling, have seen it here and there over the decades…

11

I incorporated a paramsFromJson function

void paramsFromJson(json_t* rootJ) override {
		params[FREQ_PARAM].setValue(1.f);
		params[RATE1_PARAM].setValue(1.f);
		params[RATE2_PARAM].setValue(1.f);
		params[AMT1_PARAM].setValue(1.f);
		params[AMT2_PARAM].setValue(1.f);
		

		Module::paramsFromJson(rootJ);
	}

It seems a bit more stable but not quite completely reliable. I am trying to also incorporate

json_t* dataToJson() override {
		json_t* rootJ = json_object();
		json_object_set_new(rootJ, "mode", json_integer(mode));
		return rootJ;
	}

	void dataFromJson(json_t* rootJ) override {
		json_t* modeJ = json_object_get(rootJ, "mode");
		if (modeJ)
			mode = json_integer_value(modeJ);
	}

What is the difference between the first function and these two? Should I also initialize inputs?

12

For your first code example, you’re calling the base class after your implementation, so it is probably overwriting whatever you set.

The second example is doing something completely different from the first (it doesn’t address any params, for example), so not comparable.

There’s probably nothing you need to do to initialize inputs, unless you’re using values from inputs that aren’t connected. IIRC these are initialized by Rack to zero in any case.

What you recommend is that you first debug precisely what’s causing the issues with the plugin, and only then take corrective action with an understanding what it is that is your module requires to operate consistently.

1 Like
13

That’s what happens when I’m replying on the phone - a ‘pamopoly’ of typos :wink:

14

I am doing this now: declaring the parameter variable as global to the module.cpp then updating it in the process and using the dataFrom-dataTo /json to initialize it correctly. I also got rid of the paramsFromJson function.

float freq;

Then in process

void process(const ProcessArgs& args) override {
		freq      = params[FREQ_PARAM].value;

Finally

json_t* dataToJson() override {
		json_t* rootJ = json_object();
		json_object_set_new(rootJ, "freq",      json_real(freq     ));

and

void dataFromJson(json_t* rootJ) override {
		json_t* freqJ = json_object_get(rootJ, "freq");
		if (freqJ){
			freq       = json_real_value(freqJ);

I think this should take care of it.

15

Usually if you make a global you have problems with more than one instance of your module. Mackie it a member variable of some class.

1 Like
16

The params variables are declared in the

struct MyModule : Module {

So not actually global to the module.cpp: do I still need to make a dedicated class you think?

17

No, Module sounds right.

1 Like