Debugging issues that happen when presets loaded

[AndyMac]

I have a module that exhibits some off behaviour when reloaded/loaded with a preset which is proving difficult to locate. Everything works perfectly in the debugger, and when initialised in a new preset/removed and dropped back into the preset also works fine, but has a minor issue of not correctly initialising something when loaded as part of a preset.

I can't see any way to use the debugger to track what is happening during the preset loading stage.

Do you have any suggestions (a) where to look for this sort of issue and (b) how to try to track it down - is this a case of a load of logs being setup to track variables, which obviously will change the behaviours.

Having the ability to save/restore simple presets in the debugger (and capture the activities during this process) would be really valuable. It would be ideal if you could load existing presets into the debug mode, but obviously this could be really complex.

[CherryRuss]

Hi AndyMac.

When a preset gets loaded, things should happen in this order:

* module's constructor runs
* Initialize runs
* SetStateInformation gets called for loading custom state information
* states of controls like knobs, buttons, etc., get restored. You should see various calls to Notify to let you know that knob values have been set, cables connected, etc.

So setting breakpoints in these areas might help, if you haven't tried this already. The module designer doesn't currently have the ability to load VM presets, as you're aware, and it would be tricky to make it happen, so I'm not sure it will, but the module designer will restore control settings, cable connections, etc., from your last test session, so you can emulate presets - though I expect you're already aware of this, too.

As I was getting ready to reply to this, I realized that there's an important difference between the VM and the module designer: in Voltage Modular, the module won't get calls to ProcessSample until all initialization has taken place, but in the module designer, you can get ProcessSample calls before SetStateInformation has been called. This is getting fixed, but likely won't be in the build that we're looking to release this week, which is already well along in testing.

It's also possible that control state restoration and cable connections won't occur in the same order in the module designer as in Voltage Modular, though I need to do some more research there. But if you're relying on Jack_Connected notifications to occur at a particular time before or after controls get their states restored, things might not behave exactly the same between the two apps. We'll look into shoring that up as well if it turns out to be the case.

[AndyMac]

That's really useful background - and good to understand the differences in behaviour in the current tools, and that you are looking to get this more consistent.

Anyway, from this, I don't have to worry about getting current values during Initialise phase (which I had been doing) as long as they are already being looked after by the control Notify stage? That is a good potential simplification for my code!

[AndyMac]

As I was getting ready to reply to this, I realized that there's an important difference between the VM and the module designer: in Voltage Modular, the module won't get calls to ProcessSample until all initialization has taken place, but in the module designer, you can get ProcessSample calls before SetStateInformation has been called. This is getting fixed, but likely won't be in the build that we're looking to release this week, which is already well along in testing.

For this I assume that a quick workaround in code would be to check for a flag only set in SetStateInformation before anything in ProcessSample. At least I can reproduce the behaviour as is in VM.

It's also possible that control state restoration and cable connections won't occur in the same order in the module designer as in Voltage Modular, though I need to do some more research there. But if you're relying on Jack_Connected notifications to occur at a particular time before or after controls get their states restored, things might not behave exactly the same between the two apps. We'll look into shoring that up as well if it turns out to be the case.

This one is a bit more of a challenge, and maybe would be a reason to keep any steps picking up what is connected, etc. where the order is critical in the Initialise stage, recognising that they will also get repeated in the Notify section.