MPE+ support feasible?

[NothanUmber]

Have been experimenting with using just pressure for modulating gain instead of velocity+ADSR.
Out of the box this didn't work too well, because pressure is set to 0 before the note-on and the first pressure event is apparently sent 10+ milliseconds after the note on. If the synth then additionally applies some hysteresis it takes even longer until the effective pressure value goes up. So sharp attacks without velocity(+ADSR) is not easy.

Have tried to work around this by setting pressure to velocity via a script:
https://community.gigperformer.com/t/af ... acks/945/4

This seems better. But of course it would be optimal if the attack could be sent to the synth as it occurred, instead of having the entire attack phase essentially be represented by just one value.

Read the article about MPE+ on the Hakenaudio page now which comes to similar conclusions:
https://www.hakenaudio.com/mpe/

Could such an MPE+ mode also make sense for the Linnstrument?
According the the FAQ touch-to-MIDI latency is about 2 ms - thus the scan frequency has to be > 500 Hz(*). According to that the Linnstrument could shape an attack envelope with 20 datapoints instead of the 40 ms of velocity+ADSR scripted attack the MPE+ article is talking about.

If some MIDI interfaces cannot handle the full data rate continuously - would perhaps a "burst" just around the attack be feasible?

Don't really know how many synths beside the Hakenaudio stuff support this though. On first sight this doesn't sound like a lot of work for a synth that already speaks MPE - so if Linnstrument would support this I guess some synth authors might consider to add it. (Perhaps EaganMatrix supporting it and ContinuuMini becoming available could be reason enough for considering MPE+ - should make a great hardware module for Linnstrument )

(*) If one touches the surface right after the last scan cycle then I would assume the touch cannot reach the computer before the next scan cycle was done, so the worst case latency has to be longer than the scan cycle - or the scan cycle faster than the worst case latency. Would further assume that the midi interface has to be fast enough to send at least one midi event per 2 ms without getting buffer overruns, otherwise the touch wouldn't go to the computer in < 2 ms. That's behind the perhaps confusing conclusion from worst case latency to throughput.
Not really sure whether all these assumptions hold though... (e.g. whether these 2 ms are really worst case latency, whether always a full scan cycle is necessary etc.
If the maximally achievable data rate is too low then MPE+ wouldn't help anymore at least for the attack stuff. If it *is* fast enough though then this addition could be really neat indeed!)

[Roger_Linn]

Hi NothanUmber,

Thank you for this interesting post. I wasn't aware of MPE+, but its focus seems to be overcoming the slewing of volume or filter frequency that usually occurs in synths. Note that if you strike a LinnStrument hard, the Pressure signal will immediately jump from the initial 0 (necessary to clear the synth's voice of its previous value) to the full 127, so LinnStrument is fully capable of instant attacks, but it is the sound generator that slews that instant jump into a soft ramp and thereby prevents sharp attacks from continuous pressure messages alone.

However, as you also point out, in LinnStrument the first non-zero pressure value occurs about 10 mS after the strike. Perhaps we can improve that in future, but given that all synths slew volume or filter frequency, it seems more practical to use velocity and envelopes for sharp attacks, for which synths do not slew the volume or filter frequency. This gives you the same desired result now on all synths.

The page you referenced doesn't discuss if any synths use this MPE+ messaging, so I suspect it only works between Continuum's touch surface and its built-in synth. Like all of Lippold Haken's ideas, MPE+ is a great idea, but it also seems that the same thing could be accomplished merely by the synth removing slewing on fast transients. That way, slewing would smooth out any zippering only on the movements where you hear them--slower ones--but leave the fast ones alone. This would achieve the same thing as demonstrated in the first audio example on that page.

[NothanUmber]

Thanks for your response!
As far as I understood this is (besides an overhauled handling of 14 bit values) the key idea behind MPE+: The instrument can specify how much smoothing the synth should apply. Like with voice-per-channel capable synths (that existed long before MPE) a synth doesn't have to be MPE+ compatible to stay away from extensive smoothing - if it is MPE+ compatible then it just guarantees that it supports this smoothing control feature.

It's probably a hen-and-egg problem again, like with VpC before. (Few controllers support it, so few synth devs implement it - and the other way around). This was imho the big accomplishment of MPE (being official and pragmatic/not too exotic to add as a feature to an existing synth).
Thus MPE+ could be similarly helpful, but currently it's not adpoted by the MIDI standardization comitee but specified and implemented by one(?) company atm. We'll see.

Will use the velocity+envelope approach for the timebeing - or experiment with stuff that supports audio-rate modulation, these also shouldn't apply too much smoothing.
Just modulating the timbre with pressure on top of velocity has the disadvantage that the initial attack has an impact on the sound of the note for it's entire duration. So you cannot get a note with an initial hard attack fading into silence or make a note that started with the slightest touch really loud.
But many synths (with support for several freely assignable modulation envelopes) allow to fade out velocity based timbre/volume etc. control after the attack phase and switch to a pure pressure based control afterwards - so these should work.

Would be interesting in how far and often a measured attack curve deviates from one that can be modelled with an envelope (being a function of one velocity value) - and whether this would be a usual ADSR or something more sophisticated. The Rise examples shown on the Hakenaudio page apparently don't even use an ADSR but jump straight to the velocity value, stay there for 40 ms and then jump to the pressure value. Would expect that with a more appropriate envelope you can get at least closer to the measured attack curve in many cases.

[Tj Shredder]

Interesting discussion...
I read the introduction to your script. There you state the VCV MPE module understands only poly aftertouch. You know you can set the Linnstrument to send poly at?
I havent looked at recent VCV modules, where do I find the MPE module? Some time ago I did create a 4 voive VCV set...

[NothanUmber]

There are 1x and 4x MPE modules from ErraticInstruments and an 8x MPE module from moDllz. Both are free packs. The 8x module doesn't work for me on Windows, it works on Mac though.

Regarding aftertouch:The posting in the GigPerformer page was about GigPerformer not supporting the generation of PolyAftertouch messages (it can only create Channel Aftertouch atm.) And VCV on the other side needs Poly Aftertouch.
I was mistaken though, it is possible to generate Poly Aftertoch with GigPerformer with the MakeMidiMessage function (this expects raw event data so I'll have to look up the MIDI spec which bytes to send for poly aftertouch). Will do this next week.

[BobDog]

There are 1x and 4x MPE modules from ErraticInstruments and an 8x MPE module from moDllz. Both are free packs. The 8x module doesn't work for me on Windows, it works on Mac though.

Regarding aftertouch:The posting in the GigPerformer page was about GigPerformer not supporting the generation of PolyAftertouch messages (it can only create Channel Aftertouch atm.) And VCV on the other side needs Poly Aftertouch.
I was mistaken though, it is possible to generate Poly Aftertoch with GigPerformer with the MakeMidiMessage function (this expects raw event data so I'll have to look up the MIDI spec which bytes to send for poly aftertouch). Will do this next week.

Poly aftertouch is very similar to a NoteOn message, there are three bytes:

byte 1 - High 4 bits need to be set to 0x1010, bottom 4 bits are the channel.
byte 2 - The note number, 0 - 127
byte 3 - 7 bit pressure value, 0 = none, 127= max.

[NothanUmber]

Thanks!

[Roger_Linn]

the key idea behind MPE+: The instrument can specify how much smoothing the synth should apply.

I still don't see the point in MPE+ because smoothing in a sound generator's volume or filter frequency changes works fine except for the single case where you want to use pressure only (not velocity) for an instant rise resulting from a hard strike. So if the sound generator recognizes sharp rises in pressure and doesn't smooth them, the problem is solved without any new MIDI protocols.

Am I missing something?

[John the Savage]

the key idea behind MPE+: The instrument can specify how much smoothing the synth should apply.

I still don't see the point in MPE+ because smoothing in a sound generator's volume or filter frequency changes works fine except for the single case where you want to use pressure only (not velocity) for an instant rise resulting from a hard strike. So if the sound generator recognizes sharp rises in pressure and doesn't smooth them, the problem is solved without any new MIDI protocols.

Am I missing something?

I have to agree here. I think this is another example of wanting the controller to compensate for the shortcomings of the sound generator at the expense of elegance.

Cheers!

[NothanUmber]

As far as I understood the idea was that if the controller tells the synth how fast it can deliver data then the synth can adapt it's smoothing accordingly, so interpolation is as smooth as possible and as reactive as necessary (to consider all details the controller can deliver):
"Data smoothing is not a bad thing for the synthesizer to do — in fact, the Sampling Theorem tells us that smoothing is always necessary to avoid aliasing! Aliasing is not a problem unique to audio sample streams, but also X,Y,Z control streams encoded in Midi. [...somemorecontinuumisgreatmarketing...] MPE+ lets the controller specify the best amount of smoothing to avoid update noise (aka zipper noise or aliasing) but still retain the finger motion information in the data."

Question is: Which behavior is desirable? With MPE+ a controller with not-super-high data rate would not be able to produce sharp attacks without an envelope generator, because the MPE+ synth would smoothly interpolate between the (fewer) events the controller can deliver. If the synth would on the other side always smooth to a high frequency (e.g. 2 kHz) then you could still have sharp attacks with just pressure on controllers with slower datarates. It would essentially be a step function with slightly curved edges instead of an interpolation between the measured anchor point events. (Then of course pressure would have to be sent instantly and not 10+ ms after the note on to avoid latency).
If 2 kHz smoothing would still be ok from an aliasing perspective then just using this approach in any case (without having to get informed about the data rate of the controller MPE+-style) might also have it's merrits.
But if synth devs *want* things as smooth as possible instead of step-function-like for usual keyboards and thus smooth as appropriate for a 25 Hz rate then MPE+ would indeed be better - instead of assuming a hardcoded (too low) datarate of usual modwheels and expression pedals etc the controller could tell what it prefers. And if you want the step function approach the controller could still return 2 kHz - even if it cannot deliver such high data rate.

[Roger_Linn]

Sorry, I still don't see the need. The synth has the advantage of being able to adapt the smoothing based on received MIDI data. So it doesn't have to have a fixed 2 khz smoothing. It can opt to treat a fast 0 to 127 pressure transition as no smoothing if it so chooses. And it can smooth differently on high- or low-frequency content because it knows what the content is.

The only problem that the MPE+ page addressed by its demo recordings was the inability to achieve sharp attacks from hard strikes, which may be because it's more difficult to achieve sharp attacks from Continuum's spongy surface, I don't know. One of the reasons I used a less soft surface in LinnStrument is I find it difficult to play sharp-attack rhythmic parts on a spongy surface. Note that a hard hit on LinnStrument produces a jump in pressure from zero to 127, albeit with 10ms between as you pointed out. But Continuum's software could be altered to accelerate fast attacks, resulting in the requisite fast rise in pressure needed to hear a sharp pressure-based attack in the synth. I'm not knocking Continuum because it's an incredible instrument and essentially started the entire MPE controller revolution. I'm just saying that each surface has its plusses and minuses.

So my point is that given the perceived problem can be solved in the synth by adaptive smoothing, that's a whole lot easier to accomplish that than trying to change the MIDI spec. Notice how hard it was to add MPE to MIDI and it wasn't even necessary, merely specifying an alternate use of 1984 MIDI 1.0, and still almost no synth makers are even implementing a Master Channel.

But it's an interesting discussion and thanks for bringing it up. There's really nothing more I can add.

[NothanUmber]

Sorry, I still don't see the need. The synth has the advantage of being able to adapt the smoothing based on received MIDI data. So it doesn't have to have a fixed 2 khz smoothing. It can opt to treat a fast 0 to 127 pressure transition as no smoothing if it so chooses. And it can smooth differently on high- or low-frequency content because it knows what the content is.

Adaptive smoothing based on start/end value and measured rate sounds plausible (and would already be possible here and now, without changing controllers - if the devs consider it worthwhile). Not as easy to advertize with than a Whatever or even Whatever+ label - but right, a label only helps if it is widely accepted, which isn't the case here.
Will play around with synths where I have all these aspects in my own hands then.

But it's an interesting discussion and thanks for bringing it up. There's really nothing more I can add.

Sure, thanks for taking the time, much appreciated!

[48cube]

In my experience, combining velocity modulated short envelope amount and pressure modulated gain/volume of the voice works perfectly. I was able to set such modulation mapping in nearly all synths I used with Linnstrument, be it soft or hardware ones. On some you can even map the attack speed of the envelope to velocity so you get really responsive transients.

[NothanUmber]

In my experience, combining velocity modulated short envelope amount and pressure modulated gain/volume of the voice works perfectly. I was able to set such modulation mapping in nearly all synths I used with Linnstrument, be it soft or hardware ones. On some you can even map the attack speed of the envelope to velocity so you get really responsive transients.

Thanks for the feedback! So you don't combine velocity and pressure for gain control (fading one impact out and the other in) but just do attack via velocity and gain via pressure? What is the target gain of the attack envelope? My problem is that the adsrs of many synths have a built in "gain knob" that defines the target gain of the sustain phase. This built in gain is hardwired to velocity. So if modulating the DAC gain with pressure I am essentially multiplying the velocity based adsr gain with the pressure modulated DAC gain.
So a low velocity attack and full pressure results in lower maximum gain during the entire note duration than high velocity attack and full pressure.
Optimally velocity shouldn't affect the note after attack anymore. Only a few synths allow to directly modulate the target gain of the ADSR instead of the DAC gain. Alternatively some modular environments allow to use two ADSRs - one with velocity based gain and without sustain and one with fixed gain and a slow attack, with pressure controlling the DAC gain. This doesn't work with most non-modular synths.
But perhaps I am just thinking too complicated How do you work around the dependency of max gain from velocity? Or do you not care and just live with it?

[Dark Barn]

The Haken EaganMatrix is now available as a standalone eurorack unit with a MIDI input, and I have one. Most of the presets sound truly fantastic controlled by Linnstrument, except the ones that may expect a pressure value at note on, an assumption based on what I’m reading here. These ones make almost no sound. I may explore editing the presets at some point but I wanted to add another request for Linnstrument to send pressure at note on, perhaps as a user selectable option if this would impact the normal function of Linnstrument. I do not think that Linnstrument needs to adopt the full Haken MPE+ spec (whatever that implies) to play nicely with the EaganMatrix, it would only need to send pressure at note on.