First of all, thanks for reporting. This is part feature, part bug: MIDI-CAT automatically copies the settings from the previous mapping slot. The assumption is, that multiple controls will have the same settings when mapped in a row. For the 14bit CC flag, this should not happen for CCs 32 and above, because it makes no sense for these controls. This is now fixed.
I’ve implemented a “fix” for this situation, but I can’t comprehend all side effects and I’m a bit scared a did break something else. I would really appreciate someone doing intense testing of MIDI-CAT and the different modes. I tried several scenarios and everything seems fine, but there may be cases I did not cover…
I’m planing to do a complete rewrite of MIDI-CAT sometime in 2026, because its internal design has become a huge mess and is barely maintainable 
2 Likes
Thanks for reporting anyway. 2.1.0 had a few issues in different modules. I had a plan to release 2.2.0 in December with several fixes and stability improvement, but I’m taking more time testing and fixing issues.
1 Like
I will get your latest dev build tomorrow and give it a try.
I am in the process of redoing my MIDI controller mapping anyway, replacing encoder relative mode with MIDI feedback (as you suggested elsewhere a while ago), couldn’t do it without MIDI CAT.
Took me a while to get there, since MIDI Rx on the Intech Studio modules is not built in, you have to get into LUA coding to evaluate incoming MIDI messages yourself. Sigh.
P.S. About the flags copied from previous mappings in the siot: I could live with it if the 14 bit menu option weren’t greyed out, so I could change it. I might want a 7 bit fader in a slot <32 that held a 14 bit mapping before. In theory. Not a showstopper though.
Just played around with yesterday’s dev build.
- The button sync problem when using the mouse appears to be resolved. I have only tried turning it on and off with mouse while it is in the respective other state, will use it now in my patches and will report any issues that pop up.
- The 14bit flag is reset for a button with cc > 32 in a slot previpusly used with a 14 bit encoder/
- The Snap pickup still works in the latest dev build
If you really end up doing a major revamp of MIDI CAT, I’d like to put in my humble vote for relative encoder mode since not all devices support MIDI feedback. My AKAI MPK Mini Plus keyboard doesn’t. Relative mode is much nicer than the pickup options, AKAI actually recommends relative mode for their endless encoders.
1 Like
Here’s another issue, a strange one. I can only reproduce it with my chained mixer Master and Aux modules, not with the normal channel modules. And it only happens with the latest dev build (2.1.0-0d2ee8a), it doesn’t happen with 2.1.0-90d57b9 that I downloaded on Dec 31.
I have the fader mapped 7 bit with MIDI feedback. If I start at CC value 0 I cannot move the fader up, it seems whenever the encoder sends CC value 1 it gets a CC value 0 in return and the fader is grounded again. The only way to get the fader up is to turn the encoder real quick so it does a few steps up before the first MIDI feedback comes in. And the strangest thing: as long as the parameter is mapped, I cannot move the fader up with the mouse either, it keeps jumping back to CC value 0 when I push it up with the mouse.
As I said, I have yet to find another module showing the same behaviour other than my Chained Mixer AUX and MASTER modules. So I cannot say with certainty that it isn’t a problem at my end. But they have the same ParamQuantity class as the channel faders that work just fine. There is no fiddling with parameter values or such, it’s all straight forward. And it didn’t happen with last year’s 
build of MIDI CAT.
Hmmmm….
Now we can randomize the shape of the xy pad module and use it as an oscillator with audio rate… drones galore and even in low frequencies can still be great evolution! Although to be simple it could’ve also been solved by simply adding trigger inputs to the random shape and variation controls as well. Perhaps you could modify the xy pad module into a separate standalone audio rate oscillator that’s tunable and smooth? That way we have one for modulation and one to modulate with the other!
2 Likes
More news: the problem with the faders in my Main/Aux modules goes away, if I set snapEnabled to false. It was false (in error really) in the channel module. But in fact it should be true, since the parameter float values are integers in disguise indexing a table of dB values.
Plus MIDI-CAT crashes in ~MidiCATChoice() if you shut down Rack while parameter mapping is active.
On further thought: I can see the problem with the fader curve. It has 769 entries, so the parameter range is 0.f through 768.f. Several values would probably map to 0 in a MIDI 0..127 range. I am not sure why that works without snapEmabled and not with snapEnabled=true. And why it worked in the Dec 31 build and not in the latest.
Thanks, I fixed this.
I have no answer right now, why it worked before, but I have the feeling that “snapEnabled” is not the intended use here. I would prefer the indexing on the lookup table to happen in the dsp processing and not “inside the parameter”. But this is just my personal taste/opinion.
I can change that part, in fact the channel module proves that it works without snapEnabled. So I am good.
But MIDI-CAT should work with any possible parameter. What I suspect is that CC value 1 from MIDI translates to some float value, by snapping that value gets a little smaller so that it is converted back to CC value 0. This could happen with other snapping parameters as well.
Also moving the fader with the mouse should not be affected by the mapping to MIDI-CAT at all,
Yes, I think you are right, that it is caused by some rounding/floating point issue. But I think it is ok as long the number of snapped values is equal or less than 128. I will check, but I suspect this might be a rare edge case and there are not many parameters with more snapped values.
Well, in theory yes, unfortunately there are some very special instances out there: parameters without ParamQuantity or endless encoders (unbounded ParamQuantity) for example…
Just downloaded yesterday’s dev build 2.1.0-5524b35.
- I can confirm that the crash on shutdown while mapping parameters is gone
- MIDI input for my Main and Aux mixer module faders works now, even if snapEnable==true. Thank you! Mouse movement of the fader when mapped and snap is enabled is still broken though.
P.S. Mapping the VCV OCT module to an encoder with MIDI CAT doesn’t work, it just does nothing. Mouse control when mapped is ok.
Edit: I notice that I do not get a MIDI feedback message for the OCT mapping, unlike all other encoder mappings for the same MIDI device.
Looks ok to me (Library version and development build)?
1 Like
Because of these issues I started implementing unit tests a few days ago. It took me a while to set everything up, but I’m at a point I can write a test for this scenario, which confirms the issue. I won’t fix this right now, because I consider it a minor issue and I want to get 2.2.0 out, but the tests will ensure less bugs long term and less need for testing everything manually 
3 Likes
Very good!
I do not enjoy being the bearer of bad news. I have a real use case for MIDI CAT so I am glad to help with testing.
As to the OCT mapping: I did some more testing, it appears only to happen for an encoder in 7 bit mode with CC address 31. Sometimes, but not always it doesn’t seem to recognize it during mapping despite the MIDI messages showing up in MIDI MON. If I then turn encoder 30 it is immediately recognized. Is there any special treatment for CC address 31 in your code?
1 Like