I would really appreciate if there was a possibility to switch through the available Knob Sets through external MIDI CC or (probably even better) MIDI Note messages.
In a live performance scenario I find it hard to quickly and precisely go to a specific Knob Set with the Knob Set key combo (hold back button, turn the knob). Especially if you have all Knob Sets mapped.
This would also come in handy with the MM button expander, as you could use the buttons to switch to the available knob sets quickly.
Hey @danngreen any chance for this to become a thing before/until superbooth? I will be working in the neuzeit instruments tent with Thomas this year with a performance showcase with my rack. The metamodule has a big role in my setup so being able to change the knob set pages easier would be great.
Hey, yeah actually it wouldn’t be too hard at this point.
Tell me specifically, like would it be mapping values of certain CC## on a certain channel to steps? E.g
Channel 15 CC0=1 → Knobset 1
Channel 15 CC0=2 → Knobset 2
Channel 15 CC0=3 → Knobset 3
…
Channel 15 CC0=8 → Knobset 8
Or MIDI Notes:
Channel 15 Note C0 On → Knobset 1
Channel 15 Note C#0 On → Knobset 2
…etc
Hey @danngreen thanks so much for your reply!
So I think the Neuzeit Drop can do both midi cc or note for every control so it wouldn’t matter that much but I feel like that CC is more flexible than note cause this way you could use an endless encoder to just scroll through alle pages (for example mapping with a range of 1-8) to create something like this with MIDI Notes instead of CC wouldn’t be possible (on the drop that is).
So all in all I think MIDI CC is the better choice.
thanks for the fast implementation! It works really well
The only little bug that I found is that when you enable MIDI Knob Set Select, you cant use the shortcut on the MetaModule itself to change knobset pages (hold back button while turning the endless encoder).
What do you think about my idea of creating fixed midi mappings for the Knobset Knobs?
This would be the last missing link for my superbooth setup.
Good catch! I fixed that. I’ll post a link to the fixed version. I also changed it so it only responds to MIDI CC values that are the exact knob set number minus 1. So if a patch has 3 knobsets then it only responds to MIDI CC values 0, 1, and 2, and ignores 3 and up. Previously it would change to knobset 3 if you sent CC value 127 for example.
Re: CC mappings to knobs, there currently isn’t any concept of mappings from MIDI to physical knobs, we only have mappings from physical knobs to virtual knobs and mappings from MIDI to virtual knobs. So this is a new type of thing (not just a new way to control an existing thing). It also has to happen at audio rate, so doing it without impacting CPU is critical.
I have questions about how it would work if the user is using the knobs and CC at the same time: There needs to be some thought about how to handle “catchup” modes. We already have user-selectable catchup modes for knobs->virtual knobs, so would doing this mean we need a second kind of catchup mode for CC ->virtual knobs? Or how exactly will that work?
I just had a thought, it could maybe work at the patch file level. I was thinking it would be easy to feed a patch yaml file into an AI agent and tell it “For each knob mapping you see in this patch file, create a new MIDI CC mapping to the same virtual module parameter(s) using MIDI CC 1-12 for the knobs in Knob Set 1, …”. That’s probably the fastest path to making this happen.
Another idea is a tiny command-line script that does this (or a web app). I could make this easily (or Claude could).
My next thought was that we could do that exact thing in the firmware. It could process the patch yaml to add these mappings. I’m not sure where a button to do that lives and how to really describe it, but it’s possible.
Regarding the original idea, having direct CC->Knob mapping has another road block I just thought of. How I understand your request is that MIDI CC 1-96 would control knobs A-Z in Knob Sets 1-8 at all times (regardless of what Knob Set is active), right? The way the firmware works is that knobs only control virtual mappings in the active knob set. Inactive knob sets are ignored. So doing a direct MIDI CC → physical knob control is probably not the way to go. It would require an overhaul of the already highly-optimized audio hot path (for a feature that’s useful but still pretty niche and there are existing methods of getting the same end result).
I think we can achieve the effect that you want (using MIDI CCs to control 96 parameters) by using already existing feature of MIDI mappings to virtual knobs. The only issue with doing it this way is that it’s a lot of work to manually create up to 96 MIDI mappings on every patch, so having a way of automating that would make it easier (either via AI, or a script/web app, or even some firmware feature). What do you think?
Yes it is possible right now to do it with multiple midi to cv modules but there are two big catches (which was the initial reason why I wanted a native solution)
To create 96 midi cc mappings you need 6 MIDI to CV devices with at least 96 patch cables just for the mapping. As every patch cable adds to the patches latency and CPU load, this seems to overly demand the CPU for a quiet undemanding task. Come to think of it: Do the patchcables that go to the cv to midi interface (in the vcv patch) add to the latency of a patch on the meta? On the meta the patchcables get transformed to midi mappings so there are no (visible) patch cables on the MetaModule.
Right now the only way to create mappings for parameters that don’t have a dedicated cv in (only a knob/fader) on the module or to map multiple knobs at the same time is through the knobsets knobs mapping (as there is no stoermelder on the MM). So mapping one cc to multiple parameters requires again more patch cables and also cv mixers, which again increases the load of a patch.
So just that you get an idea why this is a real problem for me right now: In my current patch I have only one cv to midi module, 9 VCA Mix (to mix multiple CVs pre MIDI to CV module), 2 8verts and a randloops8. My samplerate is at 24k/64 (as I’m not prcoessing audio) and I’m already at 27 % CPU Load ^^ So no special/demanding proccessing mostly just the routing/mapping and the randloops8 (which makes only 1 % difference in CPU load when bypassed).
My hope was that when you pre-map every knob in every knobset to a CC in the firmware itself, that it would run more effecient than when doing it in the patch. Another great benefit is that you only need to map your MIDI Controller once to the MetaModule. Even when you change patches on your MM, you always have the knobsets already mapped to your controller, no matter what. (like automapping in ableton live).
I just had a thought, it could maybe work at the patch file level. I was thinking it would be easy to feed a patch yaml file into an AI agent and tell it “For each knob mapping you see in this patch file, create a new MIDI CC mapping to the same virtual module parameter(s) using MIDI CC 1-12 for the knobs in Knob Set 1, …”. That’s probably the fastest path to making this happen.
I like the idea but I don’t know if this would solve the issue of creating tons of latency/cpu load for the mapping.
Also:
How would a script like this handle for example mapping 3 knobs (of three different modules in the patch) with every knob having a different range to one knob on the metamodule? It’s not impossible but not perfect.
Yeah thats a real bummer that I hoped wouldn’t be the case ^^
I think a script would probably better for a case like this, as it would defenitely lead to unnecessary token usage for such a problem and when you create midi mappings like this, you need to test a lot burning through tokens (and water) like its nothing.
I will definitely give this task to claude to develop such a script but this unfortunatley won’t solve the performance/latency impact problem, I fear.
No, this kind of mapping does not add (much) CPU load or latency. There are patch cables on the VCV version but these get translated to direct mappings on the MM that are well optimized (no CPU load unless a CC event arrives, and in that case there’s going to be some CPU load no matter what we do since it’s turning a knob/switch/etc).
That’s why I suggest using this existing feature of direct MIDI CC → parameter mappings. It’s already time-tested, highly optimized, and flexible (you could use different MIDI channels for each knob set if you wanted, or use CC 10-106 if you wanted, etc..)
Actually you can use the MIDI MAP module (the Fundamental one) to assign a single CC to control multiple parameters. Or you also can add multiple MIDI mappings from the same CC from within MM. What you can’t do from VCV is give each one a custom min/max range (you have to do that from within MM). These kind of mappings are outside of the KnobSet, so they are the optimized kind I’ve been talking about.
I guess we won’t know how it effects performance until we try. I think the method I’m describing is the most optimized possible, but with performance you don’t know for sure until you’ve measured it.
So, send me a patch file you want to have this work with, and I’ll see how it performs.
I just made a quick test and copy/pasted the midi part (including the mix vcas) 6 times and I can confirm now that it wouldn’t really work with the current way how midi mappings are done as the patch wont even load.
Actually you can use the MIDI MAP module (the Fundamental one) to assign a single CC to control multiple parameters.
Oh wow I kind of totally forgot that MIDI MAP is a thing for the MM.
Good to know! So my CPU load probably comes from the many VCA Mix instances…
I will send you my patch in private.
Maybe I also need to look for other modules to achieve what I am after but at the moment where I created my mod matrix, this was the best I came up with ^^.
I think it’s a great idea to assign fixed MIDI values to all knobs in the MetaModule. Right now, whenever I finish a patch, I always have to remap all the knobs again.
I’m using the Faderfox UC-4, and it works perfectly in combination with the MetaModule knobs.
What could be very useful is to use a separate MIDI channel per knob set. For example:
Knob set 1 = MIDI channel 1
Knob set 2 = MIDI channel 2
Then assign all knobs within a set to CC#1 through CC#12, and use CC#13 or higher to quickly switch between different knob sets.
I just confirmed with an example patch that adding maps for CC control over all the knobs in 2 knobsets had < 1% impact on CPU usage. So it looks like this is the way to go. It no surprise, the built-in MIDI maps are well optimized (no cables, minimal latency, almost no overhead when not in use). I’d like to do a more robust test, with the maximum number of maps (8 knob sets x all 12 knobs mapped x each mapping → 8 virtual knobs) and see the load increase, but I’m not too worried about it.
Yeah that makes a lot of sense. Using the channel for the knobset # and using the CC number for the knob makes it easy to remember what’s mapped to what.
Or if it’s preferred to keep it all on one channel, then using CC1-12, 13-24, 25-36 etc for the knob sets is an option too.
One way this could work is to do it from the VCV Rack side. The Hub module could have an option for “Automatically link CCs to knob mappings” along with options for how the CC/Channel numbers are laid out.
Then these mappings get automatically put into the patch file when you save the file or transfer via Wi-Fi.
There can be a similar button on the patch view if you are making patches directly on the MetaModule.
The nice thing about this is that the mappings will show up in the same places MIDI CC mappings show up already.
So did you do the midi mapping on the metamodule or in vcv? because in vcv I can only map one knobset. When I try to MIDI map a second knobset, it removes the mappings from the first knobset.
Yes it makes it easy to remember but I think (especially in modular) it is not ideal to spend 8 channels of MIDI just for the mapping of knobsets. (with only the first 12 ccs being mapped) I’d rather have it all in one channel, so I can use the other channels for different MIDI information.
This sounds like a really great idea and would bypass the problem, that you can’t MIDI Map multiple meta knobsets in VCV Rack!
PS: In the meantime I vibecoded my first VCV Rack Module (and porting it to MetaModule as we speak) with the help of @mmmmmmmadman <3 So I can get my weird setup going
I added the mappings manually, just a copy/paste in the .yml file and then changed the IDs from the physical knobs to the MIDI CCs. I manually did what I’m proposing we have the firmware (or VCV Rack hub module) do automatically. It’s not easy to do this from within VCV Rack from the user’s point of view, but it’s trivial to do it from within the firmware or hub module code.
Right, I think we can have options for different channel/cc assignments methods
yeah don’t know why I thought MIDI Note would have been better than CC.
and when you create midi mappings like this, you need to test a lot burning through tokens (and water) like its nothing.
