The Hapax and MPE Stupport: Discussion

Hapax
1

I know this has been discussed a couple of times before but I want to bring it up again, because I’m realizing this is the biggest sticking point for using the Hapax exactly how I would like. I plan to continue editing this post with updates, and use it as a resource to help others who would like to use the Hapax in conjuction with an MPE compatible controller (eg. the ROLI Seaboard).

Now I would like to preface with the disclaimer that I am not an expert on MIDI or MPE, and am really not much more than a novice. So if there is any incorrect information contained in this post, please comment so I can update accordingly. Now, on to the good stuff.

Brief Outline of MPE

In 2018 the MIDI Manufacturers Associations adopted the MIDI Polyphonic Expression (MPE) ehancement into the official MIDI Specification. What does this mean?

MPE allows controllers to send additional expression information along with each note. In MPE, each note is assigned its own MIDI channel so the expressions can apply to each note individually, rather than as a global control. For example an “aftertouch” or “pressure” expression being sent to a chord of a polyphonic MPE synthesizer can apply that expressions to each voice individually, rather than the synthesizer output as a whole.

Generally, MIDI Channel 1 is reserved for “global” controls, and then channels 2-16 are reserved for sending Note ON/OFF messsages and Expression data for each individual note. It appears some controllers pre-assign a midi channel to each note on the piano roll, and others assign a new channel to each new note played in unison (ie. the first note played is Ch. 2, then additional notes are on Ch. 3, 4, 5, etc.).

While MPE is generally sent over 16 channels, the control can be “zoned” to a subset of MIDI Channels, reducing the number of simultaneous voices that be controlled with expressions individually. For example, with my Seaboard I can restrict the number of MIDI Channels to 1 in the ROLI Dashboard. When I do this, every note played is sent over MIDI Ch. 2 (remember Ch. 1 is reserver for global controls), and the expressions of any note will apply to all active notes because they are all on the same MIDI Channel.

These are the expressions sent from the ROLI Seaboard:

  • Channel Pressure, recognized by the Hapax as “aftertouch”, achieved by applying pressure downwards on the keys.
  • “Brightness”, recognized by the Hapax as CC74, achieved by sliding upwards and downwards on the keys.
  • Pitch Wheel, recognized by the Hapax as pitchbend, achieved by sliding left to right on the keys.
  • Strike or Velocity, recognized by the Hapax as Note ON Velocity, achieved by the initial impact on the key
  • Lift or Release Velocity, recognized by the Hapax as Note OFF Velocity, achieved by the speed with which a key is released

Current MPE Support with Squarp Hapax

The Squarp Hapax does not presently support MPE in any practical capacity. I will discuss why I believe this to be the case, as well as what possible features we may be added to have MPE support be more effective by the Hapax.

The foremost issue is the defining factor of MPE: it (most often) utilizes all 16 MIDI Channels simulatenously. This poses a number of problems with the current features and configuration of the Squarp Hapax:

  1. The Hapax does not support “zoning” of the MPE midi-out, so an MPE Track in a project must have a dedicated MIDI out port that cannot be shared with any other track. This could potentially be solved by the incoming midi information being already zoned, however that is not always controllable. This limits the total possible number of MPE tracks in a Project to 5, assuming that one of the 6 available MIDI-Out ports is reserved for the other non-MPE tracks in a Project.

  2. The inverse of the above: each MPE Track must have a dedicated MIDI input port, otherwise the same issue as above occurs in reverse: notes sent by the MPE controller will trigger any given Track listening only on MIDI Channel X, and any other MIDI data intended only for Channel X on that port would also trigger the MPE track.

  3. Furthermore, because of the way input routing currently works on the Hapax, assuming you have set up multiple MPE tracks with different output ports as discussed above: an MPE Controller will trigger Note data on all of the MPE tracks simultaneously. Another way of thinking about this is that the MPE controller will trigger Notes for all Tracks listening to the input port with which it is connected.

  4. Finally, there is no partial MPE Support. What do I mean by this? Well, for non-MPE synths, an MPE controller can still apply its expressions to various parameters on the synth globally, rather than on a per-note basis. In Bitwig this is done with the Expressions modulator. So, for example, I could map the Pressure expression to the volume of my synth, and applying pressure to notes will cause the instrument to play louder. This is not on a per-note basis, so lightly holding the first two notes of a chord and smashing down on the third will cause all the voices to play more loudly. However this is still a desirable effect to control.

Desired Functionality for Hapax MPE Support

This section is of course very subjective. I will try to consolidate the community’s feedback for the other MPE users out there. I’ll start with what I think are the lowest-hanging-fruit feature requests that get us the most immediate improvement, and end with what are probably far-fetched desires for the future of the Hapax.

1. Individual “Active MIDI Only” settings for each Track.

This is in regards to problem 3 above, and will do wonders for utilizing an MPE controller with the Hapax. Presently, the “All Active” Track Input Setting is the only setting which allows filtering of incoming MIDI notes to that Track while it is not the Active (selected) Track. If I want multiple Tracks to receive MPE data (related to problem 4 above), and have set their Input to the port with the MPE controller, playing the controller will trigger all of these Tracks at once. Using “All Active” is not a solution here, as there may be other controllers/midi-thru’s/etc on other input ports that should not be sent to these Tracks while selected. Instead I believe each Track should have an individual setting whether or not it accepts MIDI only when the Track is selected. I have already opened up a feature request for this, as I believe it is both very achievable and also useful for the Hapax community as a whole.

2. Ability to “Squash” MPE MIDI Out Data

This is in regards to problem 4 above, and will allow the wonderful expressions provided by MPE to control non-MPE synths. In combination with solution 1 this would make MPE controllers actually useful with the Hapax, as the polyphonic expressions could be used to control instruments on any of the 16 Tracks.

Proposal: The MPE Tracks on the Hapax can choose to “squash” all incoming MIDI information down to a single selected channel. ie, I play a chord on my MPE controller and Expression information is coming in on Channels 2, 3, & 4. The output of the Hapax will keep all of the MIDI information the same, and just change the MIDI Channel of each midi-message to be that selected by the user. You lose the polyphonic element of the expressions, but you lose that anyway with non-MPE synths and this allows the expressions to have an effect on 16 different instruments across the 16 different Hapax Tracks, one for each MIDI channel.

3. The ability to “Zone” the MPE midi-out channels for Hapax MPE Tracks.

This would give the ability to have multiple MPE Tracks on the same midi-output port, and allow for a greater total of full MPE tracks to be controlled by the Hapax. However I recognize the complexity and depth of the changes required by this ask.

For one, where the various zones must be selectable as different inputs within a DAW. For example now it is possible to select either an individual Hapax MIDI Channel as input (eg. HAPAX Channel 6), or ALL of the Hapax Channels. If a 8 and 4 Channel zones were to be available for MPE Tracks, then these would have to be selectable in the DAW as well. Examples: Hapax Channels 1-4, …Channels 12-16, Hapax Channels 1-8, Channels 9-16

Secondly, it cannot be guaranteed how the incoming MPE data will distribute the notes across MIDI Channels. So far I have seen two strategies: each key on the piano roll pre-mapped to specific MIDI channels, and each new active note increases the Channel number. These varying strategies would need to be mapped to the MPE output MIDI-Zone, and this mapping may prove to be complex.

Final Thoughts

Solutions 1 and 2 above should be very achievable, and would go a long way to enabling expressive control of instruments via an MPE controller connected to the Hapax. Again, for anyone with more knowledge or additional information, please comment below and I will regularly check-in and edit this post.

4 Likes
2

Hear, hear.

My Hapax lives right beneath my Linnstrument, but ironicly I have only tried the Hapax MPE mode once. It only took my a few seconds to realise that there was no ch 1-8 / ch 9-16 setting, and then I quietly went on with other things, as it would be a complete disruption for my current setup if it was to sit on all 16 channels.

1 Like
3

Ive discussed much of this with Squarp very early on (during beta).

I suspect the way it’ll likely be handled is it’d be one MPE zone per track…
this would be the same as you’d do on a daw, or even when you split a normal keyboard.
technically, its need too, due to the way you’d need to handle things like pb ranges.

so I guess, we have MPE zone on track input, and MPE zone on track output.

that said, MPE is (unfortunately) pretty niche still, and there’s arguably bigger fish to fry…

and its only a subset of mpe devices/instruments that even handle zoning :frowning:

also the hapax MPE implementation at the moment is just kind of record/playback.
we are really waiting on the MPE per note editing features of hapax.

the other side, Ive asked for is supporting usb (virtual) midi port… a usb (host and device) cable can carry up to 16 ports, this means assign all 16 channels is not such a big problem.

anyway… squarp are aware of it, I believe, but not sure how high MPE is on the priorities.
(I have a number of MPE controllers, and another on its way … so Im as keen as anyone :wink: )

btw: for zoning, if you have spare ports (hence the USB request), what you can do is use a midi processor (something like Blokes midihub), to move midi around between channels.
its not ideal, as you can easily run out of midi ports, but its works in some case.

anyway for now…
I don’t use the Hapax much for MPE… without decent editing, there is no real point for me.
I just do what Ive done for years, and record audio when using mpe controllers.

… and, tbh, I kind of like that, there’s something about expressive controllers, that make me what to ‘perform’ with them, so record and edit in details, is just not something I often feel compelled to do.
so I just multi track audio into a daw or into my octatrack.

3 Likes
4

That would be very cool. I actually don’t care too much about the editing function yet, though that would be useful. My primary use-case is that I would like my HAPAX to store all of the patterns for my songs, and be able to record into using my Seaboard to control both MPE and non-MPE tracks in my DAW. (it’s important that the hapax can store and then “squash” the MPE data for the non-MPE tracks so that the pressure and slide information can still be used to control parameters on the soft synths)

So, the routing I want goes something like Seaboard → Hapax → DAW, but presently the Hapax eats all that midi data so I just have it as a separate input into the DAW for drum tracks.

5

I havent used MPE with the Hapax for a while but when I first tried it, with earlier firmware version than currently available, I was happy enough. If the setup is simple enough then I would not agree with your statement that the Hapax does not presently support MPE in any practical capacity. If I only want one MPE synth in my collection of tracks, or want to have a couple but am happy to only record to one at a time, and to use separate output ports, then I think everything is fine and workable. And I would not dismiss such simple setups from the spectrum of possibilities of what some users want - its good enough for me for now.

However that doesnt mean I disagree with the merits of the more complex stuff you are mentioning. But I do think we need to keep things as simple as possible, and to moderate our expectations somewhat. And in some cases what you are asking for is for Hapax to fix some issues that are caused by the way DAWs, synths or the MPE controllers themselves presently tend to handle stuff. Maybe it can be done, but I think we need to take care and to talk about this detail more and see if we can refine any of your ideas or push the problems off to other parts of the chain rather than expect Hapax to solve every possible tricky issue.

To give one example, I think more care is required with your ‘MPE squishing’ solution than you have described, although please forgive me if I have misunderstood or overlooked something you already said about this. When squishing all the data to one channel, it is not sufficient to leave all the expression data in place. Because for example if you squish a particular form of expressive data down from multiple notes to a single channel, a non-MPE aware synth will end up seeing it as one stream of values and it will get into a wrestling match between them and parameters will jump all over the place. Lets remove Hapax from this equation and consider three ways that this is solved traditionally:

  1. If the MPE-capable DAW has some clever processing (eg Bitwig) then it can squish this data intelligently, eg by giving the most recent notes expressive data priority and throwing away the expression from other notes. Or for pressure, converting channel aftertouch data into per-note polyphonic pressure midi data that is attached to individual note values all on the same channel.

  2. By the synth itself being clever enough to do the same sort of things as the clever DAW can in this respect (probably rare, might only expect this for synths that are MPE aware in the first place and then they wouldnt normally need to bother except in circumstances where we run out of unique MPE channels and need to share more than one note per channel)

  3. Probably the most common thing people are used to already - you change the settings on your MPE controller so that it no longer transmits MPE but rather the more traditional forms of MIDI in the first place. eg it will have an option where you can send poly aftertouch midi all on one channel instead of channel aftertouch on multiple channels as sent with MPE. And it will have things like last note priority config options to dictate which fingers touches end up sending a single pitch bend message and a single MPE Y cc74 message on a single channel, throwing the rest away before its ever sent. And your DAWs and synths are set to non-MPE mode to work with this traditional midi data.

So yes, it is possible to imagine a world where Hapax is performing that sort of intelligent processing to squish the data down to MPE, throwing away any notes expressivity that would cause a tug of war, using approaches such as last note priority. Whether we will actually get that from Squarp at some point I cannot say. I agree its worth discussing, I just wanted to attempt to lay it out in more detail.

There is something else to talk about with the Hapax in this sort of area. When I tried the Hapax with MPE some months ago, I was impressed that it already has one useful MPE channel reallocation feature which have a practical impact, that solve a particular problem. I believe that it is not just recording all the data with the same midi channels as the MPE controllers are originally using. My test was very basic:

Use an MPE controller that tends to always use the same channel for the first note that is pressed at any one moment in time, eg channel 2.
Record one note at a time being played from this MPE controller into a Hapax MPE track.
Now overdub another ‘one note at a time’ sequence being played onto this same Hapax track.
The Hapax wont give these overdubbed notes the same midi channel, which would cause a big messy conflict. Instead it intelligently gives that additional layer of notes their own new midi channels, not just the channel used by the MPE controller, maintaining the integrity of the MPE data and keeping the expressivity attached to the right notes/channels.
In the simple scenario of recording a set of single notes at a time on the first record, and then another single set of notes in the overdub, if all these notes were sent by the MPE controller on channel 2, they end up coming out of the recorded Hapax MPE track on channels 2 & 3 = success!

Like I said, I did that test some time ago and have not attempted to repeat it with more recent firmware, nor have I attempted more complex varieties of this test. But I recall being pleased that Hapax was intelligently processing things in this overdub scenario, was making its own choices about what channels to use rather than just a plain dumb method of always using the same channels as the MPE controller used when first playing those notes into the Hapax.

In regards MPE zones and the ability to tell the Hapax what range of midi channels each MPE track should record and send, I agree that would be useful. At this stage in the evolution of MPE I would probably like to keep it simple and let users pick the range themselves rather than rely on the formally defined concept of MPE upper and lower zones. That would make the channels completely explicit and would also cater for synths like the OB6 which only listen for channels 2-7 in MPE mode, one for each of that synths voices. Likewise some other hardware synths which can be made to work with MPE via a ‘one voice per midi channel’ mode that was built into their design years before MPE even existed.

2 Likes