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.
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.
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 )
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+)
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
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?
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.
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ā?
)