There is nothing in the official MPE spec about velocity not being used. What you are describing is likely EaganMatrix-specific. And even when talking about the Osmose, likely just the Haken (EaganMatrix) MIDI output works that way, with the Ext MIDI output (that is MPE not MPE+) still providing velocity.
But I would certainly agree that in many circumstances, when designing MPE-specific sound presets on a synth, I would tend not to actually make use of velocity values. I dont know if everyone else has the same attitude or not.
I must admit that despite hanging around here for several years, I never read up on MPE. I followed thetechnobear across from the old Eigenharp forum and stayed for the gadgets. Itās interesting though. I guess itās still ahead of the curve, and there seem to be a variety of different approaches.
indeed, most MPE implementations I know supply velocity.
velocity is pretty common to see in MPE presets.
whilst its true many will use Z to directly drive a vca/amp, this doesnāt work well on all surfaces, as some are somewhat slowā¦ so whilst great for pads, they are not good f you want a more plucky sound, youād use it.
also not all mpe synths support the ability to drive the amp gain directlyā¦ so common to use velocity there tooā¦ (e.g. I used to do this a lot with u-he diva)
@BJG145 calculating velocity. perhaps look at the eigenharp code as this is open source.
simplistically, what it does is take a couple of pressure of sample e.g. say first and N, it knows sample time to can essentially know d/T , then uses a curve to translate that into velocity.
in practice to get a nice response is a bit more fiddly, and also will depend on surface (e.g. is it linear response)
The Osmose has 2 MIDI ports - one classic MIDI, that I expect to have velocity (same for EM when MPE is turned off), and the other port is EM, which is standard EM output which is normally MPE+, but can be configured.
As for attitudes about getting velocity, the Osmose forums are full of people asking about how to get it
The second port is slightly off spec for MPE+, though that might change with a firmware update someday.
Specifically, itās not sending the higher resolution pitch bend. (Which Iād argue does matter, because itās using a range of +/- 96 steps, and because pressure glide allows for larger bends than one might use in wiggling the keys.)
No, there are no settings that affect the emission of extended resolution of pitch bend emitted for MPE+ in the Haken Editor. When set to MPE+, the device does what it does ;-).
On the Osmose, there are parameters that affect the range that key wiggle will cover, but the engine is still set to the full range which is used for the weighted portamento.
it depends on your midi encoding settingā¦ can be preserve or replace.
all that said, I doubt 21bit pitch bend is much use on the Osmose, as it seems doubtful the sensors would be that accurateā¦
(also given the small range of travel, frankly, id be surprised if you could utilise much more than 14bit with any real accuracy ;))
the reason its needed on a continuum is that its continuous, and so the note-on can be at one end of the surface and slide to the other end (with same note on)ā¦ so its over multiple sensors.
even thenā¦ Lippold only really introduced it for the full size continuum, where 14 bits was not enough for a full surface slide.
so back on topicā¦ id stick to normal 14 bit midi for PB for non-continuous surface (or anything thats not quite large).
as for 14bit (mpe+) for Y/Z, depends on accuracy of your sensors.
if its 10bit (common-ish) , I guess, you can argue, but often even then really its only 8-9 bit accurate, as lower bits are often pretty noisy ( * ) ā¦ so really 7 bits is usually plenty.
given, its only EM supporting MPE+, id probably not botherā¦
perhaps once we get to midi 2.0, then for sure, upgrading to the full 10bits might be worth it.
( * ) you have to be careful hereā¦ more is not always better, ive seen some synths not respond well to noise in the lower bits, with that ānoiseā becoming amplified.
If you are talking about MPE+ then I dont know why youād say that, as both Y and Z can produce 14 bit values.
Not that I have studied how these are used in practice by the pressure-weighted portamento stuff, Iām just speaking more generally about the messages that can be sent by MPE+ for these two zones of key travel in the normal way.
I dont think anything changed on this front in the last year so if there is a difference in our experiences then there is a different explanation for it.
My own testing was also long ago and I dont know if my real experience memories have faded and been replaced with what the documentation for MPE+ in general says. It will also be EaganMatrix-preset specific since you can fiddle around with which dimensions of exprression use higher resolution in there, as far as I remember. I havent had much reason to bother with the MPE+ side of things since then, as opposed to normal MPE, and Iāve also not been using pressure-weighted portamento Haken MPE port output, I was waiting for them to add that feature to the Ext MIDI output thats handled by Expressive Es own firmware instead.
yeahā¦ that I didnāt dispute ā¦ rather the need for +/- 48 on an osmose.
even with pressure glide its still only 49 keys.
(oohā¦ unless it allows you to switch octave during a pressure glideā¦ but thats a edge case)
as for being steppyā¦Im surprised youād notice this - Id expect the sound engine to be doing a slew on pitch(bend) in the same way as other midi parameters.
(i.e. between each 14 bit value sent)
essentially, making the 21/14 bit more about resolution at the end of slide. which is important for microtonal work.
ok, this is ignoring intermediate values for simplicity sake hereā¦ as doesnāt really mean much in this context (slew will work here too) - but does raise an interesting questionā¦
on pressure glide does it really send every intermediate value, or does it do some āthinningā, which it might need in the case of very long pressure glides over a large octave range esp. over din.
also for pressure glide, even with mpe+ using 14bit for Z, this means the users control is at 14bit resolution even it the intermediate PB can be sent at 21bit.
interesting stuffā¦
though, Iāll freely admit, its rather academic for meā¦
I dont do extreme (4+ octave) glides, so happy to have smaller PBR range.
also, frankly, even if the osmose Z sensor has 10-14 bit, I donāt have the control in my fingers to use that precision over such a small travel distance. ( * )
( * ) again, my thoughts are that the sound engine should be slewing values, so intermediate stepping should not be a thing. rather its resolution of āstoppingā points.
Not sure on thinning. Itād be extremely difficult to measure, because of finger accuracy. And then the gesture takes two fingers, which probably doubles the chances. So, youāre probably right.
Along with slew, āstoppingā resolution should be easily covered by a small degree of āroundingā (pitch quantization).
Itās interesting though. I guess itās still ahead of the curve, and there seem to be a variety of different approaches.
