MPE bug on preset recall (from DAW)

there seems to be a bug in MPE mode when vitals state is recalled within a host.

whenever i open up Element with a vital instance that has an MPE preset loaded, MPE does not work correctly. pitch-bend on the channels 2 to 16 is not set to 48semitones, and global pitch-bend on channel 1 does nothing. i can see the pitchbbend wheel moving in vital, but the sound is not affected.

now here comes the strange part:

if i recall another MPE preset (from elements state saving, not in vital) it works flawlessly from now on, general pitchbend works correctly, channel pitchbend is set to 48, great. switching back to the first state and this works as well now.

so in summary:

whenever vital is first opened in a host, and the first state is an MPE patch, it works not correctly. after switching to another preset and back, it then works for the whole session…

ok, i got it wrong there. actually MPE never works when recalled from a session in a DAW (i am using element, but i guess it is the same everywhere) if i recall a patch (not from vital, from the daw) MPE is not working. as soon as i go to the advanced tab and click twice on MPE enabled (it already shows it is enabled) it works again. so graphically the mode gets set, but internally it is not working. can somebody check/confirm?

@Tytel

can you comment on this? or can somebody else confirm this is indeed not working?

what happens is:

if an MPE enabled state (the one a host saves) is recalled on first opening of the plugin (as in, when i open the host), the MPE state is not recalled. if i go to advanced, MPE is enabled in the UI, so i click it twice and it works. subsequently loaded states which are also MPE now work fine.

I can confirm that while it now visually looks like the ‘MPE enabled’ option is restored when restoring plugin state, the option is still disabled and actually enabling it requires disabling and then re-enabling the MPE enabled option. Tested with the VST3 version of Vital 1.0.7 in Bitwig Studio 3.3.4 on Linux.

1 Like

Thanks for confirming!

Hmm thought I had fixed this in the latest but I’ll revisit.
Thanks for the report.

@Tytel thanks for looking into this…

btw. would it be more appropriate to post bug reports on GitHub?

Confirmed, happening here as well in Reaper (Win64).

I’m keeping use bugs here on the forum. Using the github issues for just for code/building.

@Tytel is it reproducible on your end, or did you need screencaps?

Problem seems to persist, Bitwig beta 4 (latest) Win10

Any updates on this? Having to seek out every instance of Vital and disable-enable MPE every time you open a project is a bit rough … one of those “can’t rely on this plugin until this is fixed” situations that hasn’t been resolved in many months :frowning:

Same here. It’s making the plugin need me to bounce everything down that I do in it and then check back here each week.

Do we have potentially a rough idea of when this might be fixed? Thanks

Kinda don’t get it guys…can this not be fixed?

It’s not “guys” it’s just Matt. As he has posted he is working on a major update.

Matt:
“I’m working on a new graphics engine. It’s a pretty large undertaking and it will mostly speed up development for me in the future because it’s a lot easier to use. As a plus it will also will let me make prettier apps and improve a bunch of general user experience stuff like window opening time, memory usage, etc”.

How we doing on this potentially 10 seconds of effort fix?

Like I quoted from Matt above “it’s a pretty large undertaking” so even if it’s only a ten second fix there are other issues to be addressed in the update.

So all we can do is have patience. We’re all anxious to see what the update brings.

1 Like

This is like buying a new car, the car has CarPlay, but the wire that connects it becomes detached every time you turn on the car. It’s unreasonable to have to wait for a complete redesign when you can just fix the wire in the meantime, no? Put a little piece of tape on it, we can’t get inside to do it ourselves. It’s been over a year, we want to use CarPlay.

Well to put it in perspective not everyone has an MPE device. I don’t so couldn’t possibly care less about this issue.

I’d much rather Matt work on issues of stability and efficiency that may affect the vast majority of users than a small niche of the market.

There have only been five people report the MPE issue in this thread but I’ve seen far more reports concerning graphics issues which Matt is addressing as he works on a new graphics engine.

It comes down to priorities. Like I said we’re all anxious to see the update and we all have different reasons. Yours is no more important than any other…

Totally fair, but the fact that Vital has MPE means he clearly thought it was important enough to include. And the fact is, it’s broken, and it’s broken in such a simple way that can be hacked to work simply by drawing in automation to “force” the MPE button to be on. So yes, it’s a workaround, but if the issue can literally be hack-fixed by a single automation point, I’d imagine it would be preferable to take 10 seconds to fix properly and not have broken software?

…or at the very least comment on it! Literally anything…