On v2.3.1
I tried first removing the module from the patch and unloading it from Settings > Plugins before uploading the new binary, but all of MM still crashes.
Hmm, is the crash a frozen UI? Any sound?
You should be able to just upload the rebuilt plugin, and it’ll automatically stop the patch, unload the old plugin, and load the new plugin. See if it still happens. I can try to make it happen here if you send me the before and after .mmplugin files, and the patch yml.
The whole UI is frozen and as far as I can tell there is no more processing. Don’t see the device on USB etc.
I’ll try to test audio next time (in my latest tests I wasn’t testing any audio but jack i/o responses using LEDs)
OK, I hit this bug and figured it out. If the currently playing patch contains a module in the plugin that’s reloaded (which is probably the case), and you’re on the PatchView or ModuleView pages, and a module in the patch has some GUI elements that reference a module (like a dynamic display element), then there can be a condition where the modules are unloaded before the GUI page has a chance to clean up the elements, and it ends up referencing a pointer to the deleted module.
I merged the fix in, in case you’re tracking the main branch or the dev releases, but otherwise it’ll be part of v2.4.0
Oh I see! so the issue was related to my test-module using LEDs? thank you for investigating this.
I’m on holiday right now and didn’t have a chance to replicate with some example binaries to share before I left.
When I get back I’ll try the dev release, or if you release v2.4.0 before then I’ll upgrade and test.
Sorry I was on holidays and when I got back it took me a bit to get back into MM development!
I just updated to v2.4.0 and still have the same issue. I thought it maybe had to do with the package version, so I changed it. But the new build still hangs the device.
I’ve uploaded the plugin here: https://mrtoasted.com/~dreamer/test/metamodule/jacktest.mmplugin
This module simply lights up LEDs when jack inputs or outputs are connected.
[edit: I realize that I didn’t update the sdk yet. So I just tried this, but no change either.]
Maybe useful, I checked the serial console when uploading the plugin again and it gives:
[abort] prefetch abort: pc 0xeafffffc addr 0xeafffffc fsr 0x5
[rescue] prefetch abort in proc 2: no rescue scope armed
Still responsive on the console, but the plugin (that should be printing a counter) definitely no longer works.
On it, I can confirm the same behavior (running v2.4.1 firmware).
Looks like the patch is not stopped, because some confusion over the brand name “jacktest” vs “Jack Test”. I’ll get to the bottom of it and report back.
1 Like
Ah, I will also need to improve how these settings are processed then. It’s been a bit yolo so far 
It’s bit of a bad design on my part to allow overriding the brand slug in the register_module() call.
I can add a helper in the SDK that doesn’t take any brand slug string, and instead uses the one from plugin.json or the override in plugin-mm.json. Then I’ll deprecate the other register_module() overloads that take a brand slug. It also warn if the slug doesn’t match the PLUGIN_NAME argument to the cmake create_plugin() function doesn’t match. None of that will be an API change, just a header-only helper and cmake checks.
Then in firmware I can add a console warning when a plugin registers modules with mis-matched brand names.
I think that will do it…
1 Like