MPE support public preview revision 15139 (ACE, Bazille, Diva, Hive)

[Ploki]

ugh, so i discovered on old bounces that this has been present for a while now, apparently i just never compressed a track so hard it would pose as a problem.
The click is about -50dBFS.
Cubase 13.0.1 (apple silicon) + bazille 15139 VST3, same issue, also @ about -50dB.
Everytime I start playback with "Dist" module enabled, click. (also prints on bounce/mixdown)
So it's not logic related.

[Urs]

Ugh, ok. Distortion Module in Bazille (and Zebra 2) has been, you know, "fingers crossed it is okay". If it isn't, I will need to make the time to look into it - not my code originally, but my responsibility now -, but that isn't going to happen anytime soon as I'm crunching elsewhere, then take some time off, then crunch elsewhere until certain things are done, then maybe squeeze it in, certainly not before mid of next year.

Until then maybe simply automate the compressor at the beginning of the song? Just for a few milliseconds?

[Ploki]

Ugh, ok. Distortion Module in Bazille (and Zebra 2) has been, you know, "fingers crossed it is okay". If it isn't, I will need to make the time to look into it - not my code originally, but my responsibility now -, but that isn't going to happen anytime soon as I'm crunching elsewhere, then take some time off, then crunch elsewhere until certain things are done, then maybe squeeze it in, certainly not before mid of next year.

Until then maybe simply automate the compressor at the beginning of the song? Just for a few milliseconds?

Short muting will have to do, now that i know it’s there I can’t unhear it anymore

[fear83]

Sorry, if this question has already been answered but do the plugins work with the MPE+ mode of the Osmose(and Continuum)?
https://www.hakenaudio.com/mpe
I think until now only the onboard engine of these synths work that way, but it opens up so much more expression if you can shape the attack of the sound with mpe+ instead of just having a single "strike" value as attack.

[Urs]

My eyes got all hazy when I glanced at the MPE+ specs. We decided to first get MPE right, then take another look at those specs.

It is already difficult enough to create patches that play equally as well on the three MPE controllers we have (a Linnstrument, an Osmose and a Rise, soon to be joined by a Key Stage). It is a whole other thing to support additional fragmentation of controllers that may (or may not) require somewhat different synthesis paradigms. So we're quite open to look into higher resolution of control that MPE+ offers, but some stuff seemed a little esoteric during my quick review, we have to see if that is something that fits with Synthesizers-As-We-Know-Them.

[EvilDragon]

My takeaways from MPE+:

- Velocity should always be 127, patches shouldn't have any velocity modulation done via MIDI note on velocity, instead it should be a continuous modulation
- Pitch bend resolution is 21-bit by utilizing another CC (especially important for the 96 semitone bend range of the Continuum)
- 14-bit CCs are to be synchronously updated, rather than the flawed way they were implemented in the MIDI 1.0 spec


It probably makes more sense to implement support for MIDI 2.0 features and then eventually Haken and others will also support that in their firmwares and then we can forget about the crudeness of these solutions.

[Urs]

Yeah, well our entire framework and all of the hundreds of DSP modules we have are written with an event paradigm that is "Velocity is only one value, known at note start". The rewrite to make this different would be humungous, for a feature that I presume has very little overlap with our user base.

(unlike CLAP, some of these standards and extensions seem to be devised without consulting the people who make the actual sound engines. Or maybe they don't care because they see them as unique selling points for their hardware, even taking into account that people can't properly use them with all generators. And then they slap a label - "plus" - on them, pretending that the rest of the industry will follow. It's IMHO a bit awkward coming from the people who also file patents for the precious little trivialities they wish to keep to themselves.)

[pdxindy]

Yeah, well our entire framework and all of the hundreds of DSP modules we have are written with an event paradigm that is "Velocity is only one value, known at note start". The rewrite to make this different would be humungous, for a feature that I presume has very little overlap with our user base.

MPE+ does not require velocity to be a continuous value. It ignores velocity and uses pressure for continuous velocity.

[Urs]

Yeah, well our entire framework and all of the hundreds of DSP modules we have are written with an event paradigm that is "Velocity is only one value, known at note start". The rewrite to make this different would be humungous, for a feature that I presume has very little overlap with our user base.

MPE+ does not require velocity to be a continuous value. It ignores velocity and uses pressure for continuous velocity.

Yes, but surely it needs to control the parameters that velocity normally controls. Velocity typically is hard wired to many things, envelopes in particular, and it's often wired in a different way than other modulation sources. And some of the envelope models, such as Diva's, are kind of ultra-modified to react to velocity, and it might not be all that easy to change this to a dynamic behaviour.

[EvilDragon]

Right, from Continuum's perspective you're generally not really even advised to use envelopes in the first place. Your fingers are the envelopes.

[pdxindy]

Yeah, well our entire framework and all of the hundreds of DSP modules we have are written with an event paradigm that is "Velocity is only one value, known at note start". The rewrite to make this different would be humungous, for a feature that I presume has very little overlap with our user base.

MPE+ does not require velocity to be a continuous value. It ignores velocity and uses pressure for continuous velocity.

Yes, but surely it needs to control the parameters that velocity normally controls. Velocity typically is hard wired to many things, envelopes in particular, and it's often wired in a different way than other modulation sources. And some of the envelope models, such as Diva's, are kind of ultra-modified to react to velocity, and it might not be all that easy to change this to a dynamic behaviour.

MPE+ is a marketing term. It isn't MPE plus something. MPE- might be more accurate

It is ignoring velocity and not using a predefined amp envelope. Pressure from your finger is what creates an amp envelope shape.

MPE+ offers a lovely sounding result for "expressive playing", but it also cannot do a bunch of stuff we take for granted. I wouldn't want MPE+ only.

With Bazille, Output 1 can be set to Env's 1-4 or Gate (defaults to Env1). For MPE+ it could use Gate or Env1 with attack=0 sustain=100. Then pressure would be wired to level. Bazille doesn't currently have a global per voice level control that can be internally modulated (no input for controlling output level). I can get around that with CLAP in Bitwig using the Expressions modulator to modulate output level per voice via pressure. So with output level set to 0 and pressure controlling it, it is basically MPE+ with less resolution.

[Lbdunequest]

My takeaway with MPE, i don't have and never will. I also wonder how many people actually have mpe controllers. It feels kinda niche to me and more focused towards player.

P.s. if i play mpe with its nifty features and i set to record what i play, does instrument with mpr gets automated?

[SteveElbows]

MPE+ is a marketing term. It isn't MPE plus something. MPE- might be more accurate

It is ignoring velocity and not using a predefined amp envelope. Pressure from your finger is what creates an amp envelope shape.

MPE+ offers a lovely sounding result for "expressive playing", but it also cannot do a bunch of stuff we take for granted. I wouldn't want MPE+ only.

With Bazille, Output 1 can be set to Env's 1-4 or Gate (defaults to Env1). For MPE+ it could use Gate or Env1 with attack=0 sustain=100. Then pressure would be wired to level. Bazille doesn't currently have a global per voice level control that can be internally modulated (no input for controlling output level). I can get around that with CLAP in Bitwig using the Expressions modulator to modulate output level per voice via pressure. So with output level set to 0 and pressure controlling it, it is basically MPE+ with less resolution.

Yes. I already ignore velocity when designing certain kinds of MPE patches for synths that do allow me to use pressure to affect amplification instead. Even when they dont allow that in a suitable way for amps, theres a temptation to hardwire the amp and then use a filter instead. So I never really thought about this as something that requires MPE+ as opposed to MPE. And I think they go on about this on their MPE+ page because with MPE+ they are also promoting the idea that you send expressive messages at a higher rate during the important initial phase. And so MPE+ is not just about higher resolution of messages, but also higher frequency of messages at the start, ie temporal resolution changes too.

Personally for a lot of sounds and synths I'm not convinced the higher resolution is worth the effort at this time. Especially if the synths are also doing some smoothing/slewing (or whatever the right term is) on all the data they receive anyway. There is a VCV Rack module that has a MPE+ mode if someone really wanted to analyse any advantage, I was going to do more with this but I lost interest. And so I prefer to think of MPE+ as just being something that Haken did to offer some advantage to their own sound engine, not something thats going to catch on beyond that.

And in this particular era, even if synth developers wanted to support MPE+, there will be other issues caused by DAWs. ie in DAWS that are pro-active about MPE support rather than just letting all MIDI channels & their messages pass through to the synth. eg Ableton and Bitwig. They arent likely to pass all the required data through to the synth, and they arent going to combine and store the CC87 messages with the normal MPE data for individual notes in a way that makes sense when editing the MPE data in the timeline/piano roll. Perhaps if I actually understood Bitwig scripting and what resolution Bitwig internally stores things at, I could claim that it would be possible to write a controller script for Bitwig that can harness and preserve the nuances of MPE+ at that stage and successfully pass the expressivity to plugins, but I'm pretty ignorant about that side of things and didnt know where to look to find the required info when I was curious about this in the past.

I would agree that most likely if there is ever momentum in this sort of area, its very unlikely to come via some new found developer love for MPE+. It will likely come from a combination of MIDI 2.0 and progress on other fronts such as plugin per-note expressivity improvements that we've already seen in the current era. If every required piece fall into place on that side of things in future (from MIDI 2.0 input through to the DAW and on to the plugin via per-note expression plugin standards), then even if the Osmose didnt get MIDI 2.0 itself, it actually wouldnt be insanely hard for someone to write a program that converted incoming MPE+ data to MIDI 2.0.

[SteveElbows]

My takeaway with MPE, i don't have and never will. I also wonder how many people actually have mpe controllers. It feels kinda niche to me and more focused towards player.

P.s. if i play mpe with its nifty features and i set to record what i play, does instrument with mpr gets automated?

As long as what you are using to record the MPE MIDI data actually supports MPE, then yes. There are even a few hardware sequencers that support MPE these days (and old-school sequencers would also work if they can record all MIDI data from all MIDI channels at once, and dont choke on the sheer volume of data).

[Urs]

Well, if MPE+ is merely a question of sound design (use Pressure to control volume instead of Velocity) then I guess there's not much we need to do.