I mistakenly created a support ticket for this issue, rather than just posting to this forum. So I will summarize my discussions with Roli thus far, and maybe other folks can weigh in. Thanks to Roli for promptly responding to my questions/suggestions.
I discussed my dilemma of wanting to be able to layer a piano or organ type instrument with an MPE instrument. I suggested it might be nice for the seaboard to be able to send out Piano-mode data (basically note ons and offs only) on a single channel, while simultaneously sending MPE data on multiple other channels.
I further wondered if that data couldn't be sent out the global control channel. The Roli rep said that would be a problem, as control data is sent out that channel, but I still don't understand why that is a problem. After all, control and note data is sent out the same channel all the time. I'm not sure what data it is, but surely it is not noteon/off data? And if sustain or other control data that needs to be sent to all MPE channels is included, I'm not sure why it's a problem for that data to co-exist with single-channel note data, as happens with normal controllers every day.... for that matter, I'm curious why there is a dedicated global channel, rather than sending such data out the first of the MPE channels. Maybe someone can answer that.
In the meantime, it does mostly work to just rechannelize the MPE to a single channel, but there are lots of edge cases where it does not work quite the same as piano mode. I'm using it now, though, and it is servicable.
Anyway, if nobody else considers this interesting, I will pipe down ;)
I started this thread because I am trying to use the seaboard to control hammond organ.
I used the seaboards live for the first time this weekend, and actually got decent functionality leaving the boards in mpe mode, and rechannelizing to one channel in my host for the organ (which has no pb response at all....)
The biggest problem is that a grace note that doesn't involve lifting the finger will not trigger a new note on the hammond. Similarly, if I briefly hit a note a half-step off while going for a particular note, the wrong note will persist even if my finger is now clearly on the right note.
Support suggested that a mode that created new notes based on pb messages would cause too many extra triggers, but I'm going to try it in my host anyway. I think I can figure out how to script it. If it works, it's easy enough for me to create multiple layers of data with different response patterns, so I can layer mpe and organ or piano sounds together.
If it does work, I'll post about my solution here.
Basically, I convert PB data to note data. I have the notion of a 'sweet spot' within which the bend must fall in order to trigger a note. Roli's PB slides seem to trigger really well. This enables me to play hammond far more accurately than before. Often, I would grace a note a 1/2 step off, and that note would stick, even though my finger had moved to the correct note. That problem is gone now. I suppose piano would work similarly, although I haven't tried it yet.
No skin off my back if this is not implemented, but somebody else might enjoy having the capability.
Here is the meat of my logic:
if midi.msg = PITCH_BEND then begin //we store note ons,velocities and bend amounts in arrays by source channel, and use that info to send noteoffs... if noteOns[chan] > -1 then begin bendAdjust := 8192/bendRange; //fdebug('bend adjustment',bendAdjust); //should be 170.667 for +/-48 midiBend := midi.data1 + (midi.data2 * 128); rawBendval := midiBend/bendAdjust; //fdebug('raw bend val =', rawbendval); bendVal := round(rawBendVal); // need a 'sweet spot'. Ignore other pb values. Should make the width easy to adjust... if (abs(rawBendval - bendVal)) < sensitivity then begin // when we enter the sweet spot, refer to bent notes array to send a note off for the held note bendInterval := bendval - (bendRange); //center PB newPitch := bendInterval + noteOns[chan]; if newPitch - bentNotes[chan] <> 0 then //pb results in new note begin // send a note off for the old bent note idebug('sending note off for old note', bentNotes[chan]); midi.data1 := bentNotes[chan]; midi.msg := NOTE_OFF; midi.data2 := 0; //arbitrary low vel for note off.... writeToMidiArray(); // then send a noteOn for the new value and store the new note on value in the note array. bentNotes[chan] := newPitch; idebug('sending note on for new bend', newPitch); midi.msg := NOTE_ON; midi.data1 := newPitch; midi.data2 := 100;//todo: should be noteVels[chan]; writeToMidiArray(); end; end; //create notoff & new note end; // discarded PB vals end; //PB loop
Thanks for bringing this up. While I'll step aside and let others weigh in on the usefulness of this, just a few notes about why MPE uses a Global Channel and Note ("Member") Channels. The Global Channel is used for messages that are to apply to all voices equally. For example, if you use a sustain pedal to sustain all currently held notes, this sustain message would be sent on MIDI CC 64 of the Global Channel in order to apply to all the voices of the Note Channels.
Similarly, if you're using a conventional pitch bend wheel and want the pitch bend wheel to control all notes equally, this would also be sent on the Global Channel.
In contrast, if you're playing a Seaboard with MPE, for example, and you're holding a chord with your left hand and Glide to change the pitch of a note in your right hand, this Glide gesture would be sent on the Note Channel of that particular note only, as you don't want the pitch bend of the held notes to be affected.
A potential problem with using MPE and conventional MIDI simultaneously on the same MIDI port, as you propose, would be that control messages sent on the Global Channel – like sustain, or global pitch bend – would apply to both the conventional MIDI instrument on Channel 1 and the MPE instrument using Note Channels. Now, if you're only sending note-ons and note-offs on the Global Channel, this might not be a problem, although as the MPE spec has been approved, developers of instruments using MPE (including ROLI) need to adhere to the spec itself.
For more details on MPE, you can check out the spec attached.
Thanks for your reply. One thing that might be useful to know is that the MPE specification allows for multiple zones, such that when using channels 1–16, for example, a lower zone could comprise 1–8 and the upper zone channels 9–16. This might help achieve some of what you're interested in, and we plan on including this functionality in a future release of ROLI Dashboard.