MPE+ in VCV Rack

I was interested in whether any Rack modules support MPE+. I found one that has a Haken MPE+ mode but that mode was broken for me, it only output very low and erratic voltages for MPE Y and Z in that mode.

However source code for that module is available, and I was able to find the fault and fix it. But this does mean that at the moment people need to compile that plugin from source in order to be able to make use of MPE+ using it.

Here is me talking about the fix if anyone does want to try this: Haken MPE+ mode broken but I figured out the fix · Issue #27 · dllmusic/moDllz · GitHub

2 Likes

It’s always good to mention which ones you’re working with explicitly. Nobody can help much unless you say exactly which module you’re talking about.

Have you tried Ahornberg’s Midi Poly? I found that he is pretty responsive to issues, if given a good issue report.

Thanks but I wasnt asking for help, I was saying that I found a module that does MPE+, not just normal MPE. And that it had an issue that I was able to fix because the source code is available. I linked to a post describing the issue and my fix for it, and the title of the link should make it clear what module I was referring to. Since then the author of the module replied and will be including the fix in the next update. I will post here again when that version is available, and/or when I’ve had more of a chance to do interesting things with it in VCV Rack.

And just to be clear, the Osmose can output MPE+ and this means that 14 bit rather than 7 bit numbers can be turned into the ‘voltages’ in VCV rack for MPE Y and Z when using a MPE+ module rather than a MPE module.

1 Like

I had a look at the source code, it does not support MPE+ - though would be pretty trivial to add.

It may be worth approaching him, as the UI (using WXYZ) look likely it was inspired by the haken cvc module… so he may be familiar with it, and so continuum/mpe+.

I do like the Ahornberg modules , very unassuming/focused… and this one is so small compared to the factory/modll offering.

I guess with the number of Osmose buyers, they may be more interest in supporting mpe+.
(though of course, currently actually shipped number are still relative low :wink: )

I do like moDlls too, I used to use it, when the factory module had a few mpe related bugs, and also its v/oct didn’t include pitchbend… so that was a faff… don’t use it so much now these are fixed in factory.

btw: just notice that both moDll and factory have an issue with pitch bend range…
factory is max -/+48, moDll is -+60
almost all factory presets on Osmose (and Continuum) assume +/-96 , so this is not ideal.
(it can be worked around easy enough, but a bit more ‘fiddling’)

if your’re in the code @SteveElbows might be worth upping this to -/+96 too…
(Ive not checked the code… I assume its using the extend 21 bit pb for mpe+)

1 Like

Ah I’ve been meaning to talk to you about that in a broader context. I only looked briefly, but when I was inspecting the MPE+ output from Osmose in a midi monitor, I didnt see any evidence that Osmose was actually using CC87 with pitch bend messages to get the extra resolution. And the Haken MPE+ page does imply its only used rarely. But I probably only checked this in conjunction with whatever factory patch I happened to have active on the Osmose at the time. Need to check this more thoroughly, I wonder since you have looked into the EaganMatrix editor, whether you’ve found any options in there that would influence whether it is used at all and under what circumstances.

It will be important to know for sure, because at the moment I believe moDlls only uses it for MPE Y and Z. And that would create an issue if it were ever used for pitch bend, because any CC87s that were sent with the intention of influencing the pitch bend values would be stored but then not used and reset upon receiving a pitch bend midi message, and so would end up getting applied to Y or Z in error next time one of those CCs/channel pressure messages arrived.

I havent explicitly verified that its sending the correct voltages, but when I put moDlls into Haken mode, the next line on its display does include ‘PBend: 96’ so thats probably good news.

Im a bit surprised if the 21bit pb is not being sent, I thought this was always done for 96 pbr, and looking in the Editor, almost all osmose presets Ive seen are using this.

… so I guess, if your not seeing it, the question is… is it being filtered out?!
(id like to compare this to a continuum… to double check!)

as for 96 semis, yeah, the motivation behind this was for the largest continuum, where 14 bit was too ‘crunchy’ (192 / 14 bit)

so, whilst PBR is setting the ‘resolution’, really it can be thought of as ‘max slide range’.
and there are not many controllers that can slide 96 semis…
(nor, frankly, many use-cases you’d want to even then)
hence why ±48 became the ‘default’ within MPE.

to get max resolution, really you want to use the small PBR you can as resolution is PBR/14 bit

when we come to the osmose its interesting,
for normal ‘pitch bending’ really something like 2-4 would be enough, but of course with the weighted portamento we can actually slide the entire keyboard.

I was a bit surprised to see Osmose presets defaulting to 96, 48 would seem a better fit.
I can only think its perhaps ‘inherited’ from what’s done with Continuum’s, which are like this to retain max compatibility for the entire continuum range including the largest ones.
… but without talking to Edmund (and the Osmose preset design ) , its of course just a guess.


its kind of an interesting topic, as really PBR has always been a ‘pain’ in this area, trying to match surface to synth, whilst trying to maximise resolution… I think it was a large part of the motivation behind MPE, the pbr msg is the main difference to multi channel midi.
but even today, its still not really ‘solved’, and frankly the main reason more don’t get into issues with it, is the ±48 default being used , and no-one really caring about if its ‘perfect’ or not :wink:

1 Like

that’s me!
Test:

  • same preset, same note (play, slide up and stop)

Good?

1 Like

Isn’t were MPE Configuration Message (MCM) comes into play nice?

1 Like

yay… what I’d like to know is…

the same preset on from osmose,
for the osmose (usb port 2!) . and continuum
do you see CC87 being sent?

as described on p98 of Continuum User Guide

now caveat… Ive not looked into this in any depth, or looked at what the Osmose is (or is not) sending.
I purely going on @SteveElbows statement above, that he is not seeing cc87
it could be there are some ‘settings’ or other use-cases in play here.

(oh, be a bit careful if you have been playing with ‘preserve’ midi encoding… as we are talking ‘out of the box’ where its off)

exactly, that was my point … thats what MPE primarily ‘added’

however, looking around theres alot of things that don’t really support it.
I’ve got vst and hardware than just assume, “oh its MPE, its 48 semis”, lazy , I know… but true. ( * )
so Ive generally found MPE is least ‘hassle’ if you set everything to 48 semis, and forget it.

and as we have seen in this topic… what range to allow for PBR is seems far from standardised.

but the confusion goes further… who’s role is it to send MCM?
I always assumed it was the surfaces… but bitwig control scripts (for linnstrument?) have it reversed, where Bitwig tells the Linnstrument what the PBR is. ( ** )

I guess you can argue midi is (often!) bi-directional, so either can specify it… but really that fudging the question, it should be defined who’s role it is.
(the problem with the bi-directional , is not all controllers have inputs esp. if they are din based… but obviously with usb midi this is increasing a non-issue)

so yeah… its still a bit confused… and I think that 48 semi tone default has been a bit the saviour.

hey, but roll on midi 2.0… and it could all get another shake up… not only with changes in the may micro pitch is handled, but also with midi-ci passing information about capabilities (of controllers and synths)

… but as discussed on this forum before,
it looks like its going to be a very long time before we see this in any (mainstream) DAW, and there is the chicken n’ egg scenario to contend with too.


( * ) I should say that PRB is far from the only ‘non-conformance’ issue… there are many others,
lack of split support, not allow multiple notes on same channel, only support CC74 on touch channel… the list is kind of endless.

Im not taking a dig at MPE, it has improved things a LOT… I’m grateful for it…but it’s not (yet?) ‘solved’ expressive midi’s issues.

( ** ) an aside, talking continuums/osmose/Eagan Matrix.
I know it has its own (CC) messages for setting PBR /MPE etc. (discussed in other topic)
but does it support MPE MCM?

1 Like

Funnily enough I’ve just been reading that same page 98 in the manual.

I think it implies that the first set of options including the first 96 option in that dropdown is not actually MPE+, so not 21 bit. So if Osmose presets are set to that 96 value, this explains why there is no CC87 for them.

For MPE+ you actually have to select one of the later options after the separator in that dropdown list, eg 96 : 2 (MPE+ :ch1). I havent actually managed to get this to yield the expected result yet though, but this is also my first time messing around with that part of the editor so it may be my mistake.

Oh and if anyone is studying the data in a midi monitor, just establishing that you see some CC87 messages wont be enough, because those CC87 messages will be sent for MPE+ for MPE Y and Z, things that are certainly working on the Osmoses MPE+ output. Its the absence of CC87 for the pitch bend messages that I’m on about. Thought I better clarify that.

Well I found some Osmose presets which are set to Bend 96 (which I dont think is MPE+) and most set to 96 : 12 (which I think should be MPE+) and it makes no difference, so I’m going to stick with the assumption that there are no CC87 pitch bend MPE+ messages from the Osmose at the moment.

I’ve also found bugs in the Haken output from the Osmose: Set the individual key bending range to something rather high like 48 or 96 inside the sensitivity settings in the osmoses own synthesiser settings. Then start with a note which is sufficiently high up the scale that bending fully upwards with a key will go past a certain upper frequency limit, then past a certain point of bend the pitch bend messages will flip from positive numbers to negative numbers and make a big mess. This bug doesnt just affect the midi port 2 output, it affects the sound being generated by the internal synth too.

It might be the Osmoses bending sensitivity settings that were eliminating the CC87 messages. I am experimenting with this section now and will report more detail later.

No it made no difference, although I suppose the fact this section/layer exists might be part of the reason why the Osmose doesnt have the MPE+ resolution of pitch. Or the Osmose simply doesnt generate that resolution of messages internally in the first place, even before this layer further processes them.

Anyway having now experienced what it is like to play the Osmose with the pitch bend curve flat and the stabilization turned down to zero, I am even more inclined to think it doesnt matter, that in many circumstances the extra resolution would only add to a picture that is already arguably too sensitive with those things turned off. Even when it comes to pressure I’ve been a bit skeptical how much difference MPE+ really makes compared to normal MPE and its 7 bit limitations, and thats one of the reasons I wanted to find something that could handle MPE+ so I could test my opinion further with something other than the internal synth engine.

The MPE Configuration Message only has to do with channel allocation in the lower and upper zones. RPN 0 is used to set the pitch bend range.
(All this per the MPE Spec)

FWIW, I see over in the VCV forum, that Osmose and it’s MPE have come to Ahornberg’s attention.
Looks like he may be interested in getting one – he currently uses a Linnstrument to drive his module.

MPE control module - Plugins & Modules - VCV Community (vcvrack.com)

1 Like

Tried on Osmose, Cmini and Continuum (classic)
NO. not for Pitch bend. My fingers just “bottom down” then slide up/down = only see PB messages.

  • I see CC87 but for Z and Y

Bellow if from Continuum (classic) (DIN MIDI with UM-ONE)

Maybe on the new Slim models?

Over FB group, Im sure Richard Kram can say something about this…

-.-.

eheh, I casually reply to him about the “lack of Y-axis”

1 Like

Thanks for executing that test. Only if its very convenient for you to do so, can you confirm that this is also the case on the Continuum even if the currently loaded patch has its X set to something like 96 : 12 rather than ‘Bend 96’?

Yes, the above screenshot IS the Continuum (classic) as shown no CC87 tied to PB, in any of the possible PB config ranges.