Moin,
Yesterday I tried the firmware v2.0-dev 11.0 but went straight back to 10.3. The update took the same time as 10.2/3. However, scanning and loading the sd card took a very long time and loading the plugins also took about 4 times longer than usual.
Restarting and reinstalling 11.0 did not change anything but took 7 minutes. Reverting back to 10.3 took about 14 minutes and now the module is running normally again, i.e. it only takes a few seconds to initialize a patch with 71% load and 5 plugins including count modular.
If you would like me to reproduce this again, please send me a small test guide. I also have a video of the update in which you can see the write speed.
Reading the sd card has only been slow since 11.0. Now that I have reinstalled 10.3 the sd card is read in less than 2 sec compared to 6-8 sec. I use the same sd card for this. As already mentioned, I can test and record certain things.
How can I upload vids ? The uploader allows only pics.
What do you mean by “the sd card is read”? Do you mean auto-loading the plugins when you power on? Or do you mean loading the list of patch files in the file browser (Patch Selector page)?
Can you send a patch file that takes a long time to load on 11.0, but loads fast on 10.3? I can see if there’s maybe a particular module that’s loading slowly or something like that.
I think you need to share them with a file sharing service (google drive, dropbox, wetransfer, etc). Or you can email to us at 4ms@4mscompany.com
This adds a much requested feature: automatic refreshing a patch when the file changes. Or put another way: semi-live patching via wifi.
If you transfer an updated patch file via wifi or disk, the patch will be updated immediately. If it’s playing, then the audio will automatically fade down and fade back up with the updated patch.
The most convenient way to use this is to click the Wifi button from the MM Hub in VCV, but it also works with the web browser and if you update the file on the USB drive or SD card.
Of course, if you edit the patch on the MM and in VCV at the same time, then it will pop up a notification that you need to save, revert, or rename your patch.
It’s not truly “live” patching because you have to click the Wifi button after each change. Before anyone echos the feature request for true “live” patching (not having the click a button), let me just say it’s something I’m considering doing, but it’s complex so it’s not going to be part of v2.0. Anyways, try this out:
@danngreen before I jump on the dev branch bandwagon, do you have a sense when you might release the 2.0 version? I definitely want to give these features a try, but also want to actively use my MM.
Hi,
I have just tried out the dev 2.0 firmware (dev-11.1) for the first time - what a fantastic upgrade - congratulations everyone at 4MS!
One minor nitpick - I am red/green colour blind and am struggling to see a few of the new “physical knob position” markers drawn on the control pages for the new takeover feature. I’ve marked out the ones I am finding particularly hard to see in the screenshot below. I’d be grateful if you could maybe make the colour of these markers configurable, or choose a neutral colour for all of them (white or black might work).
Just flagging for all that the forum now has a “Dev Firmware” category, so it might be good to start new threads for individual topics related to the dev firmware — this thread is now long enough that it’s easy for important points (like the post above) to get lost.
finally able to really sit down with the latest dev firmware+plugins. must say REALLY loving the knob pickup/patch auto refresh features! and of course the cpu refinements are huge. dan and team you all are killing it!
if true live patching is ever able to happen, that will be mind blowing.
I am blue colorblind. Interestingly, I particularly struggle to see red text on a white background or white text on a red background. I also cannot distinguish between pink and orange, and I can hardly see dark navy blue. Because of this, I requested a black background with white indicators, and @danngreen said he would add it to the to-do list.
Very nice. configurable colors are huge when you have problems with colors (not sure which variety of colorblind I am, but some colors cause issues most def.)
Yes, I’ve been getting that working all last week, using the SickoSampler as a reference module. So there is a file-browser for users to select a file, and also calls to fopen() and fread() etc work (as do opendir(), readdir()…).
CPU usage is minimal, there’s nothing for the CPU to do except wait around for the disk media to respond. But waiting for an SD Card to load a file takes a moment, depending on the file size. And the time also depends on the quality of the SD Card or USB drive (USB 3.0 drive are faster).
There’s also the potential for running out of memory. Accessing the filesystem doesn’t change anything about memory, it’s just that it’s now easy to say “let the user pick a file and then load it into memory”, and forget to check the file size before allocating the memory for it. On a desktop computer it’s not a big deal to load a 500MB file but that would consume all the RAM on the MetaModule, so extra care has to be taken to make sane limits.
Oh, CPU usage for the Sample is still pretty low, I think around 10%.
You might be able to use the gcc function mallinfo(), which is what the system Info tab calls to get the amount of memory remaining.
I could make a wrapper for this to return some indication of the amount of free memory