Awesome update! 10.2
For me, it freezes quite often, especially when scrolling through the Fundamental section to choose a module. Everything stays frozen, even after waiting for 2 minutes.
Ah ok I’ll check that out. You’re using the v2.0-dev-10.0 Fundamental plugin, not the dev-9.0 plugins?
Edit: confirmed it’s on the latest Fundamental plugin.
OK, this should be fixed in the latest plugins: v2.0.0-dev-10.2.
1 Like
I’ve again encountered the bug I mentioned upthread, where knobs freeze and can’t be adjusted even using the encoder and the Adjust button. This is on dev-10.2, so I guess it wasn’t an artifact of the preferences size limit as we had hoped.
Some background:
– created a patch in VCV, loaded it in, everything worked fine.
– did a bunch of stuff, including turning the machine off, removing the USB drive with the plugins on it, futzing with a MIDI controller that I never got working, replacing the USB drive and reloading the plugins, making some changes to the jack assignments on the Meta
– ran into a situation where all the faders on the Bogaudio Mix8 are locked at 0, and neither the assigned knobs nor the Adjust button can budge them.
– saved the patch and uploaded it here.
Drum Kit.yml (16.4 KB)
Ok… so the bug is still lurking. And you were in Track on Equal mode the whole time, or did you switch modes at any point? I’ll try to reproduce with that patch file.
Yes, Track on Equal. I never changed any preferences.
I posted a new dev-2.x firmware: v2.0.0-dev-10.3. This includes the audio overrun preference, and various minor features from v1.6.4.
I’m going to find this eventually!
1 Like
OMG, I jonly just noticed Instruo released their long awaited ARM update, are these going to be available for metamodule in the future? That would be a very exiting module collection to have in the metamodule arsenal.
EDIT: nevermind, just found the answer here by searching (which I should have done before posting this message).
Putting this here as I’m running 2.0-dev currently. I have some weird issues with core balancing on some patches. I’ve attached a patch which reads out about 63% on the CPU meter but which also constantly flashes the red over too and obviously doesnt work as it sounds super broken up.
It also has some kind of weird issue with the knob set which means that they seem never to be able to be moved, I can see the inner indicator moving around before they latch onto the currently set value, but once they do latch on they then never move . Maybe these two things are related? VCV patch also attached for you to check over.
Infernal2_3.yml (9.7 KB)
infernal2.vcv (3.0 KB)
If I set the block size to 256 or less, I get CPU spikes that cause an overload. But block size of 256 or 512 runs fine. The CPU load sits at 63% or so when there’s no trigger in the Gate In jack, but as soon as I start triggering it, it jumps to 92% or so (at 256 or 512 block).
So I imagine one or more of the modules in the patch is doing block-based processing, that is it collects >128 samples and then processes them in a batch, hence the CPU spikes.
I have a branch I’m going to merge into v2.0-dev soon, and it does actual load balancing and improved CPU usage quite a bit. It’s the load-balance-precalc-2 branch if you want to check it out.
Running on that branch, the patch consumes 50% unpatched, then jumps to 76% with Gate In and the two audio outs patched. It’s steady at 72-76% even at block size 64.
I profiled this patch with my scope and Warps is the culprit. It spikes the CPU every 64 blocks.
You’re running the latest v2.0-dev commit (80403cc22dab1fba96be6d83590234bc49b52320), right?
I do see one weird thing, the knob F mapping has Min=0%, Max=0%. So it never moves, but that’s how the patch file is set.
You’re seeing this issue on all the knobs, right?
The other knobs seem to be working for me, which is unfortunate because this sounds like a similar bug to what gabrielroth has reported (scroll up a bit), and I’ve yet to have it happen to me.
Oh, but – there is an issue with knobs not being updated when a patch is overloading. In order to “clear” the overload, the engine steps the patch without inputting any new knob or jack data. I’m not able to get this patch to do it, but it’s possible if the patch is overloading so much that it’ll have a hard time reading the knobs. Though, I would think it eventually would respond to a knob change, just with a lot of lag.
Can you see if you can come up with a list of steps to reproduce the error, starting with powering on the module? I’ll keep trying.
oh brilliant, i’ll definitely check this out!
Would you mind sharing how you are doing that? I’ve got a Saleae analyzer which I might be able to use for the same purpose and it would be amazing to have this level of information when working on my own plugins.
I am.
I was.
Weirdly since then with loading the same patch i’ve not seen the same issue, I’ll keep trying it though and see if I can come up with a way to reproduce it.
I refined and squashed it, so checkout this: Load balancing of modules and internal cables by danngreen · Pull Request #451 · 4ms/metamodule · GitHub
I’m on the load-balancer branch, and I added some lines to the firmware to set one of the debug pins high when each module is run, and set it low when it’s done. I used a different debug pin for each core. Like this:
In aux_core_player.hh, play_modules()
for (auto module_i : module_ids) {
Debug::Pin1::high();
patch_player.step_module(module_i);
Debug::Pin1::low();
}
In patch_player.hh, update_patch()
for (auto module_i : core_balancer.cores.parts[0]) {
Debug::Pin0::high();
step_module(module_i);
Debug::Pin0::low();
}
Then you attach your logic analyzer to the pins on the Control Expander header. Bottom row, second pin is Debug0; third pin is Debug1. Ground for each is the pin right above it in the top row.
This will show you pulses whose widths are equal to the time of execution for each module.
To figure out which module is which, what I did was use the UART console. See this doc: metamodule/docs/firmware-debugging.md at main · 4ms/metamodule · GitHub
And scroll down to the photo of the PCB which shows the location of the TX/RX pins (Console UART). You need to get a USB-UART cable and connect it to TX and GND (RX is not needed). Then open a console program on your computer and connect to it.
Note that the Debug pins have the wrong numbers in this picture (the ones I told you to use are labelled Debug1 and Debug2 – I just renamed them all and haven’t updated the diagram).
Anyways, when debugging/developing I always have a UART-USB cable attached, and a terminal console open on my computer so I can monitor messages as they happen. You have to use firmware you built yourself, either with make configure or otherwise make sure you enable LOG_LEVEL=DEBUG with the cmake flags (using make configure does this for you).
In the load-balance branch, when you load a patch it times all the modules and then spits out the list of modules and how they were divided up for each core and in what order they’re being run. So I used that to figure out which module was the one that was that had intermittent huge pulses.
I just posted v2.0-dev-11, which has just one big feature: CPU optimizations.
This processes patches more efficiently, and it can make a big difference for patches with lots of modules.
To test real-world patches, I tried everything in the Patch Gallery and also all the factory patches, side-by-side on a unit with v2.0-dev-10.3 and a unit with this firmware.
Some notable patches:
-
Orcas Heart Octo-Djembe: 76% => 64%
-
cvFunkStrings3c: From 62% => 43% (at 32kHz). So now it can be run at 48kHz (69%) whereas before it would overload occasionally.
-
Dr. StrangeTones1: 73% => 66% (knobs in default positions)
-
Benjolin: 71% => 53% (oversample setting at 4x)
-
Devinetechre: 80% => 64%
-
EnterTheVoids: 82% => 77%
-
Generative: @32k: 69% => 51% – also can be run at 48kHz now
Etc… many more… Note that there’s not any difference for single-module patches. The optimizations change how the cores split up the duties for running multiple modules in parallel and processing their internal cables.
Two changes make this happen:
-
When you load a patch, it runs it for 5-20ms and measures the load of each module, and then that information is used to split modules up between cores equally.
-
Internal cables are now updated on both cores, simultaneously.
Note that the plugins must also be updated (this is an API-breaking change from v2.0-dev-10). The links on the Downloads page are all pointing to the latest, so just make sure to update your firmware and plugins at the same time.
6 Likes
HUGE win! Way to go.
I’m curious about your thinking on when to make the v2 branch the official release. There’s a lot of great stuff in there that seems pretty stable, as well as a lot of stuff in progress.
Not sure if this has been raised but I found a bug with the display in the Scope module: When I adjust the gain, the yellow signal line moves above and below the screen and onto the module panel. It’s hard to see in the video because it’s a yellow line on a white background, but you can see it clearly when it crosses the black knobs. Here’s a video: Dropbox
That looks like the same issue I had with the Step Wave sequencer
Yep, there are two things with the nanovg port that don’t work: clipping to the parent widget box, and drawing filled concave polygons.
As for v2 release, my rough todo has these graphics things, plus finding that knob pickup mode bug you’ve run into, filesystem support (for the STSP), and filling in all the little holes where the Rack Adaptor API doesn’t exactly match the Rack API.
3 Likes
Hello, I’m new here, got my MM only last week.
For me, the “catchup mode” is the feature that made test the V2 firmware, as I use a lot of Knob Set and it was not playable with the v1 firmware, with all values that jump after each knob set changes. I’m very happy with this V2 version and the “Track when equal” catchup mode. And I can confirm the decrease of CPU usage : I’m working on a multi-FX patch with a matrix mixer, Plateau, 2 DDLY (Kocmoc), a MIX8 (Bogaudio)n and attenuverters from Count Modula, and the CPU usage decrease from 70% to 55% after installing this last v2.0-dev11 version.
Thank you Dan, really good job.
Just one remark : the link to the firmware dev11 in the first post didn’t work for me (page not found), but I found the version here in Git :
Release Firmware Version: firmware-v2.0.0-dev-11.0 · 4ms/metamodule · GitHub
Thanks! I fixed the link
Wow this was much anticipated!
Thank you!