Firmware-v2.0.0-dev-13.4

[danngreen]

Firmware v2.0.0-dev13.4

This is a bugfix for dev-13:
Again, it requires dev-13 plugins (will not work with dev-12 plugins).

• Fix Autoload Current button crashing or wrong modules displaying later after pressing
• Fix GUI freeze sometimes when reloading a patch file via Wifi
  Fix widgets with no size specifed in Rack, that have children that should be drawn graphically, not having fonts drawn and/or having the wrong size pixel buffer
• Entering fullscreen mode scrolls module to left side
• Fix some timeouts when sending a file from VCV Rack over wifi. If file is received correctly by the MM, the confirmation back to VCV Rack is more likely to arrive now. This fixes the MM Hub in VCV Rack saying “Failed to send file” even though the file was sent.
• Fix plugin tab not scrolling to the selected item after loading a plugin or re-visiting the tab
• Address an error when the currently playing patch is missing modules, and then the user loads a new plugin with those modules while the patch is still playing. An issue still remains with the patch not refreshing automatically, but there is no error or potential crash now.

Download:
https://github.com/4ms/metamodule/releases/download/firmware-v2.0.0-dev-13.4/metamodule-firmware-v2.0.0-dev-13.4-firmware-assets.zip

[etcetc]

Not sure if this is related to dev-13.4 specifically, but just reporting more broadly that I seem to be getting plagued with more and more missing faceplates, even with the officially released ports.

All of my Venom and SonusModular faceplates are now missing as well, they were working prior.

Note this usually happens when I am uploading new compiled plugins and loading them to test, but I don’t understand why it would break other plugins.

@danngreen - I’ve uploaded my plugins here - if you autoload all of them, the last 2-3 plugins will sometimes be missing their faceplates, but if you unload everything, and load those specific plugins, they will load the faceplates just fine. Given that I have an absolutely huge list of plugins, wondering if we’re hitting some sort of resource limit on preloading faceplates or something.

I tried downgrading to 13.2 as well, but same problem.

https://www.dropbox.com/scl/fi/s4xqosx8qqpxnj88iez4b/metamodule-plugins.zip?rlkey=ngsnm2merorm6vynbwjwn21q6&st=8ro4hh19&dl=0

[danngreen]

Yes, that must be it. We’ve suddenly surpassed the point where you can no longer load all plugins automatically. The limit is the internal RAM disk (not the same RAM used for modules), which holds the png files and the plugin binary code itself.

I can increase the ramdisk size a little bit, but we’ll hit that point eventually no matter what, so I need to have a warning pop up when it realizes it’s out of space.

[etcetc]

Interesting. Well sorry to have made this a problem haha. Perhaps we could have a more aggressive form of compression for faceplates or dynamically load some day?

[danngreen]

Ah, it was bound to happen! No memory is infinite. Besides people will eventually just load the plugins they need, or else startup time becomes a big deal.

I consolidated some space and made the ram disk about 2x as large (69MB now) but we’ll still run out. So my next move is to display the available space and have an error pop up if you hit the limit.

The idea for automatically loading plugins for missing modules would be useful, too. I.e. “Lazy Loading”

[Starscream]

+1 for lazy loading

[TheTechnobear]

@danngreen

The idea for automatically loading plugins for missing modules would be useful, too. I.e. “Lazy Loading”

+1 , I think more than ‘useful’ … it’s an unnecessary cognitive overhead for the user to have to know which modules are loaded or not.
yes, performance is important, but so is usability.

id add, that there should be an option for this, that when a patch is unloaded (so new patch loaded) , it can optionally unload modules no longer used.
(or perhaps this should be the norm?)

basically for live performance, there needs to be a way that modules can be locked in, so that patches can be switched quickly without an overhead of module loading.

however, this should not be at the expense of non-live performance where this is unnecessary… Id wager 90% of the time, the MM is being used in a non-live context.

its one of the reason I don’t use my MM at the moment, and its just gathering dust

[mwx]

+2 for lazy loading

[offthesky]

+1 also for lazy load option in prefs! and also, like technobear mentions, it could ideally unload any unused ones when the next patch is loaded then run.

this would also maybe pair well with the ‘per patch buffer/rate’ settings request:

Per Patch Buffer+Rate Settings

Some patches run great at lower buffer/latency settings, others can only run at higher buffer settings. Could be nice to have a way to specify ‘ideal buffer/rate setting’ within the yml of a patch that temporarily changes the system settings right when that patch is loaded, so that if anybody tries out a shared new a hoggy patch that runs best on 128-512, they won’t ever have any issue just loading and running it. Or they won’t have to go to their system settings and change the buffer manually …

so anyone could just easily drop in any yml(from the gallery here, patchstorage, or wherever) and quickly load them up and the patch just works… without all the extra steps of possibly having to reconfig the system from patch to patch.

[danngreen]

Yeah, it would make for a more streamlined workflow now that you can’t have all plugins loaded all the time.

Per-patch buffer size and sample rate, also a good idea. It’s a different thing (effects the patch file format) but also would help streamline the workflow of going from patch to patch.

The one glitch is that some plugins take a long time to load. Valley is one of them, which I’ve been meaning to address (the slow down is in a lookup-table generation). Seaside is the other noticeably one. That will make for a bad UX if you want to pop over to another patch real quick. Maybe it should have a pop-up dialog box “Some modules are in plugins that aren’t loaded, do you want to load them from disk?”.

[offthesky]

@danngreen

That will make for a bad UX if you want to pop over to another patch real quick. Maybe it should have a pop-up dialog box “Some modules are in plugins that aren’t loaded, do you want to load them from disk?”.

that would certainly be great!

[TheTechnobear]

@danngreen

That will make for a bad UX if you want to pop over to another patch real quick. Maybe it should have a pop-up dialog box “Some modules are in plugins that aren’t loaded, do you want to load them from disk?”.

this feels unnecessary…(and will be tedious in general use, if you use many modules) - if you want fast loading, e.g. for performance, you can use the pre-loading module feature already present.

I think the only UX issue here, is that it’d be a little unclear which modules are slow to load. I guess you could time init times and have on module info, but seems a bit OTT… perhaps just include in your cpu time spreadsheet?

[danngreen]

@TheTechnobear

this feels unnecessary…(and will be tedious in general use, if you use many modules) - if you want fast loading, e.g. for performance, you can use the pre-loading module feature already present.

I can add a few options in the preferences: “Do not load plugins automatically” (current behavior), “Ask to load from disk”, “Always load from disk”.

Also the way I’m envisioning it is that it will only unload plugins if it runs out of space. So if you have enough space on the ram disk, then it will only ask you to load plugins the very first time you open a patch with a new type of module. After that, the plugin will stay loaded even if you switch back and forth between patches. It would only unload the plugin if it needs to do so in order to make room for a new plugin. Sort of like “Recently opened”, where it keeps everything in memory until you get too many and it starts kicking the oldest entries out.

Just another thought, I like the term “preload” you used. We might need to call the boot-time automatic loading “preload” and then this new feature can be “auto load”… Not sure if that will be confusing to have the same name refer to a different feature.

[TheTechnobear]

@danngreen

Also the way I’m envisioning it is that it will only unload plugins if it runs out of space.

hmm… how does this work?
e.g. imagine we have a plugin that wants to use more RAM for say loading sample, or long delay lines, reverbs… will this be able to kick out unused plugins?

generally, Im not so keen on hidden mechanics like this, esp. on small controller platforms (where resources are scarce) - I tend to prefer knowing whats going on… so KISS.
in this case, this would be… modules that are within the patch, and marked as ‘pre-loaded’

probably the only optimisation I would look for is… when you load a new patch, you don’t unload a module that was in the existing patch.

note: users could use pre-load on modules they use a lot, to reduce load times.
(as well as the performance use-case)

note: Im assuming no initialisation code is run during loading, as otherwise this dynamic loading/unloading could be a really nasty source of bugs, that would be very hard to reproduce.

btw: for performance workflow, it might be nice to have a have a menu option to add all module in current patch to the pre-load.
so workflow for setting up for a performance would be:

• clear pre-load list
• load patch 1, add patch modules to pre-load
• load patch 2, add patch modules to pre-load
• etc.

then user could pre-load list (IF necessary, due to memory constraints), by removing modules they know load quickly.

anyway, generally the way I tend to think about these things is less about what I think is ‘useful’ , and more about use-cases. and try to use KISS to avoid complexity, and too many options (which confuses, non hardcore, users)

---

pre-load/auto-load… Id go for terms which you think fit, people will adapt.
I think auto-load is natural for loading modules when they are needed, and pre-load seems to fit well.
(also 2.0 is a good time to change terms, as many new things are introduced)

Id also consider… do you really need to make auto-load an ‘option’. I really don’t see why any user would turn it off. I dont see a use-case?
I guess, when prepping for a performance it’d be useful to know you’d not forgotten to pre-load a module… but even there is dubious, and I think there’d be better ways to tackle that use-case.

[danngreen]

@TheTechnobear

hmm… how does this work?
e.g. imagine we have a plugin that wants to use more RAM for say loading sample, or long delay lines, reverbs… will this be able to kick out unused plugins?

I was just referring to being able to kick out the assets from the RAM disk (PNGs, etc), which is separate from the RAM used by modules and the actual plugin code. Disk access is always a bottleneck, so minimizing it is what’s making me want to try it this way.

But you bring up a good point that the plugin code remaining in memory will compete with space available for samples and delay buffers etc. That’s the same as the case we have right now, and if a user wants to maximize the memory available for samples then they need to load only the plugin(s) they need and no extras.

@TheTechnobear

note: Im assuming no initialisation code is run during loading, as otherwise this dynamic loading/unloading could be a really nasty source of bugs, that would be very hard to reproduce.

Unfortunately we have to run the plugin’s init() function and static/global init when loading a plugin. The plugins that load slowly are slow because of the init taking a long time. 20 seconds or so is the max, but hopefully we can cut that down

@TheTechnobear

btw: for performance workflow, it might be nice to have a have a menu option to add all module in current patch to the pre-load.

Sounds good. I just added a button like that called “Autoload current set”, which makes your list of preloaded plugins equal to the set of currently loaded plugins. Combined with autoloading-when-patch-opens (and not unloading plugins after the patch is closed), this would let you do that quickly. Open up a few patches, then click the button.

@TheTechnobear

Id also consider… do you really need to make auto-load an ‘option’. I really don’t see why any user would turn it off. I dont see a use-case?

Yeah, we might not need that option. We’ll see how it goes in practice.
My thinking is that for non-performance situations where you’re exploring patches, you might prefer to have a patch open up quickly (and be OK with it not displaying a few modules), instead of potentially waiting 5-10 seconds for the plugins to load.

[TheTechnobear]

@danngreen

The plugins that load slowly are slow because of the init taking a long time. 20 seconds or so is the max, but hopefully we can cut that down

yeah, that’s problematic… though its always going to be the case that some plugins will suit the MM more than others. nature of the beast.

one advantage of using dynamic loading, is users will get a feel for which plugins load quickly and which don’t… this may inform their decision for which to preload (or not use)
this is something you dont get if you do preload lots at startup, and you dont know which plugin is causing the long load time.

@danngreen

patch open up quickly (and be OK with it not displaying a few modules), instead of potentially waiting 5-10 seconds for the plugins to load.

hmm, interesting… thats saying that many plugins are taking 1 second to load? given probably average patch is 5-10 plugins? that seems pretty long…

but again, thats more about pre-load than turning off autoload option.
one you have pre-load, really all the auto-load option does it make a patch “fail”" to load if it contains a module thats not already pre-loaded.

(but perhaps we are talking at cross purposes, and im misunderstanding)

anyways, I do get your point, its a trade-off of processing time (of init) vs ram.
so I guess, really, I really prefer the idea that dynamic loading + pre-load allows me to build up a feeling for each plugin, and then choose the compromise.
… in the same was as I do for generally processing load of plugins.

[danngreen]

@TheTechnobear

hmm, interesting… thats saying that many plugins are taking 1 second to load? given probably average patch is 5-10 plugins? that seems pretty long…

Not including the two outliers (Valley and Seaside), loading from the same SD card we include with the MM, average time is 1.15 seconds. That’s loading 32 plugins in 37 seconds. Slower cards/USB will take longer of course.

I just cleaned up Valley, so it loads super fast now. I might integrate it into the main firmware for v2.0. So Seaside the only outlier now.

So, yeah I think some of it will come down to average patch, how it feels to wait when you open a patch. I guess I need to write the code, see how it performs and feels to use.

[etcetc]

@danngreen Happy to take a look if there’s a good way to profile/triage Seaside.

Also - @offthesky and I both have noticed some strangeness - sometimes the Options for modules will disappear. It’s very erratic on my end as to how to reproduce it - usually older patches will not load the options menu on modules.

[danngreen]

@etcetc

sometimes the Options for modules will disappear. It’s very erratic on my end as to how to reproduce it - usually older patches will not load the options menu on modules.

Hmm… Is this on 13.4? I just fixed a bug with the options menu in 13.6. It was the reason plugins sometimes crashed after you unloaded and reloaded a different version.
The only other thing I can think of is that if a patch is not the currently loaded patch, then the options menu won’t be shown. The reason is that the module and module widget have to be constructed in order to query the module widget for its contextMenu. And modules are only constructed when they are in the currently playing patch. So the menu won’t show up until you play the patch. If you pause/mute the audio then the menu still shows up until you play a different patch (because the module is still loaded in memory).

[offthesky]

@danngreen

I just fixed a bug with the options menu in 13.6

awesome, will try to give 13.6 a spin this weekend to see if i hit this no-options issue. with latest bidoo v1.0.4-dev-13. the issue was definitely occurring in a presently running patch with only 1 canard module in it, after an 80s sample was loaded and playing in the module.

i also hit a weird issue last night : was playing with a patch that used a lot of canard instances (this one: 12x sample loop player). the patch loaded and was playing audio fine, i went to the settings menu to check the ram use. it showed 167/278mb. still a lot of ram left. then when i went back to the patch view, as it was trying to draw all the wav forms on the canard screens, the mm screen froze. but i could still hear the audio and control things with the mm param knobs(the function knobs did not work of course). i know canard is now utilizing async stuff… not sure if that has anything to do with it. but i’ll see if i can repro and report back with patch/samples/steps.