@danngreen Im creating some modules that are specifically designed to be used on the MM
and have noticed a couple of things / suggestions
a) I need a way to reset/reload plugins on MM
during test/dev I can upload plugin via wifi, thats ok.
but frankly, Im getting pretty concerned with the ‘wear’ on the module (and others in the same case), by the frequent power cycles.
I try to minimise by mostly doing dev on desktop vcv, but even so… I really want to see, hear and feel what it’s like to use on the MM hardware, so a certain amount of back n’ forth is inevitable.
b) Auto Map
Ive got it setup so that ‘auto map’ knobs (or all) gives a really nice/usable layout.
so the user doesn’t have to map things, reduce user load
i) knob naming
can we map it so that, at least, auto map knobs - knobset, does NOT include the module name
its unnecessary, as the module name is already the title page, and it looks really bad.
(way too much text on the ‘performance’ screen, makes it cluttered/ugly)
ii) SDK support for auto mapping suggestion
so for now, I just ordered my param enums so I get the mappings as I want them.
which is kind of ok.
however, it doesn’t allow for not mapping certain parameters.
also whilst changing the enum is not a big deal, if you were porting code (Im not), then you’d probably not want to do this.
overall, I think a callback where module could suggest an automap would be pretty useful.
That’s cool Wifi works, must be a small file size.
So in theory you should be able to do “unload plugin” and then “scan disks” and then load the plugin. But I’ve found sometimes it crashes and I’m not sure why… might be some global destructor not getting called? I haven’t dug into it. But sometimes it does work, I usually try that first, then if it crashes, well, time to reboot.
Flipping power on the MetaModule is not a problem – I’ve been doing it hundreds of times a day for years now… Worst that can happen is you get a bad block on the USB drive if it was writing when you power down. Rare and easy to fix with any OS disk tools. But I do understand other modules in the case is not OK. I have my development MM in a separate Pod for that reason.
But yeah, I think the real workflow is unload/reload without powering down. I guess I should figure out why that doesn’t work sometimes!
Ah, good idea.
This came up a long time ago and I still think it’s a good idea to have a way a module can suggest its preferred automappings without modifying the IDs of the elements.
For native modules, it could be done in the call to register_module(), giving it a span of some Automap type or something. Not sure exactly what it would need, but maybe it’s an array of pairs of panel knob IDs with param IDs.
Or, it could work like how Presets work in VCV: there are factory Presets and user Presets, and really they’re just json files stored in the plugin or in the user’s dir. That actually might be the strongest idea: the developer could store the automap as a json file in the plugin assets. And/or the user could make their own and save it on their SD Card with some “save mapping” feature. Then the “automap” menu item could scan if there are any json files around and present a list to choose from if so. Or else fall back to the current behavior.
oh, I really like the idea of a json file - no extra code, and as you say, possibility to have a user variant.
wifi, yeah, its not 100% reliable, and as I add more modules, indeed its getting less reliable
(
I was looking yesterday, at the fb scheme, and was thinking about writing my own command line app to do the upload - as obviously command line is more useful during dev (using the browser is a bit - meh) - presumably then, I can just extend the timeout ?!
yeah, reloading often works, but its still bit menu divvy.
perhaps you could add a new message to force a reload of a particular plugin?
(we don’t need this as a user facing option)
ofc, the ‘perfect workflow’ for a dev is.
upload plugin, reload pluging/patch.
(as the current patch will usually be your ‘test’ patch)
all that said, I recognise this is all for devs only, and more important user facing tasks.
perhaps also with more modules under my belt, I’ll be doing less on the MM itself, and more within vcv.
but I generally, don’t like to dev getting to 'disconnected ’ from hardware, whilst its more practical, then end user experience is on hardware… i.e if I regularly test on MM, I’ll know early on if its fiddly, something I might miss if I use with vcv on a desktop.
Yeah, maybe a “force reload” plugin for development. For our hardware-in-loop tests we recently setup we started using special files on the disk which tell the firmware to do things like automatically run the CPU load tests or automatically update firmware on boot. We could add a file for this, i.e. metamodule-auto-refresh-plugin.txt which contains the filename to be watched.
Though – I do need to figure out why they crash on re-load sometimes first.
Wifi will be inherently limited. It’s not so much the actual wifi bandwidth but the UART bandwidth going between the MM and the Wifi Expander.
Have you been using the simulator? You can load the plugin as a built-in. It’s still not hardware but it’s 1:1 pixels and UI and the audio (usually) is the same.
no, I did look at it, but was put off by the lack of dynamic loading and having to alter code to get it to work. so im just using vcv for desktop testing which is ok.
I recommend trying that out. It’s fairly easy to do at this point – two lines of code in simulator/ext-plugins.cmake, and then two lines to change in your plugin.cpp (which can be surrounded by #ifdef METAMODULE_BUILTIN if you want to compile for VCV, simulator, and hardware without any code modifications).
