V1 MIDI-CV MPE feedback

(Steve) #1

Hi, I note that some months ago there was some MPE discussion in the now locked v1 development blog thread, which I would like to continue now (though I was not involved in the original discussion).

I have been testing using a build I created from gpl branch github a few hours ago, on a mac, with Fundamentals. Mostly using a lot of Splits at the moment since obviously some Fundamentals arent poly yet. Everything is working as expected so far, although there are a couple of issues to talk about when it comes to the official MPE specification:

The most important one is aftertouch. The standard for MPE aftertouch on the voice channels is channel pressure/aftertouch messages, not key/poly aftertouch midi messages. But I think that at the moment the MIDI-CV module is responding only to key/poly aftertouch messages. Unless there is a reason not to, it would be good to support channel aftertouch messages for MPE mode.

Most MPE controllers on the market do allow their users to change the aftertouch messages to be polyAt messages rather than channel ones, but the actual standard and default is usually channel pressure/aftertouch messages, and on some devices its not necessarily going to be obvious to users how to change this (for example Roli make it somewhat obscure, in their dashboard for seaboard blocks the user needs to select ‘Multi-Channel’ in the pressure tracking mode dropdown. There is also the scenario where users MPE midi may also be sent to another MPE synth (hardware or software) at the same time, and these synths may be sticking to the channel pressure MPE standard. Or the MPE may be coming from a DAW like Bitwig, which uses channel pressure in MPE mode and I believe ignores poly/key aftertouch midi completely when in MPE mode.

The other MPE issue is that as part of the standard, the other polyphonic axis of expression that controllers tend to support sends cc74 messages on the MPE voice channels. Again, most controllers do allow this to be reconfigured, so the already working functionality of poly MW output from MIDI-CV module can be used with most controllers, by changing their y axis midi output to cc1. But still much of what I said in the aftertouch paragraph about MPE standard, other instruments, DAW etc could still be applied to this cc1 vs cc74 business. So perhaps consider some way to let this module output cc74 poly cable? Perhaps menu config option to switch MW port to cc74, or some other solution? Other possible solution of making MIDI-CC module polyphonic seems perhaps wrong and overkill given that people would only likely use it for the scenario of grabbing cc74 from MPE controllers etc?

Anyway, I will do more testing in coming days, slowly wiring up more and more channels, and using some other MPE controllers, will post again if I discover anything else. Thanks for listening, and thanks for the excellent poly & MPE stuff which I really like the design and implementation of from what I have seen so far.

(Steve) #2

I think there are also some scenarios where it would be exceedingly useful to have the CV-MIDI module work in a polyphonic & MPE mode too, so people could process MPE signals with VCV Rack and then send them back out to other stuff that responds to MPE. Or generate their own MPE stuff from scratch and then send it on its merry way. But its not for me to say what sort of priority this feature should have, please consider it for some stage in future though, thanks!

(Andrew Belt) #3

I’ll get back to you with the other issues, but for aftertouch, MIDI-CV currently supports both key pressure and channel pressure simultaneously, by allowing MIDI messages of either type to overwrite the value. For example, if your controller sends only key pressure, it should send those values to the AFT output. If it sends only channel pressure, same thing. If both, the result is unspecified.

Since I don’t have access to an MPE controller, could you uncomment the DEBUG("MIDI line in MIDI_CV.cpp and post a sample of the terminal output that includes some aftertouch messages?

(Steve) #4

Thanks!

Probably a bug then, perhaps due to channel pressure midi messages putting their value in the first data byte, not the 2nd one (unlike per key aftertouch where 1st data is note number, 2nd is aftertouch value)…

Some example channel aftertouch messages from the debug output:
MIDI: d 1 5d 00
MIDI: d 1 20 00
MIDI: d 1 00 00

So although I havent tried it yet, I’m sort of expecting it to start working if I change the code to read the channel aftertouch data via msg.getNote() instead of msg.getValue().

So, nothing MPE specific causing this, would also expect it not to work for standard controllers, DAWs etc that send channel aftertouch messages either.

(Steve) #5

OK I can confirm what I said in my last message. I changed the code so that channel aftertouch values came from msg.getNote instead of msg.getValue and everything is now working properly.

As mentioned in past message, this is a general issue with processing channel aftertouch midi messages, its nothing specific to Roli or MPE.