PITCH CONTROLS
Control Changes 102 and 103 are defined as the Pitch LSB and MSB controls. Either or both may precede a Note On on the same channel to alter its pitch. If both are specified, they may be in either order. The MSB specifies the semitone pitch, making the note number a mere label by which the note is identified when turning it off, or when addressing a control to it. The LSB provides a bipolar offset, where 0 is 50 cents flat, 64 is neutral, and 127 is almost 50 cents sharp. The Note On consumes the Pitch controls so that they have no further effect.
On output, Pitch MSB is only necessary if the pitch rounded to a semitone doesn't match the note number, and Pitch LSB is only necessary if the pitch has a fractional part.
Pitch controls may also be combined with a High Resolution Velocity Control Change 88 in any order.
NOTE CONTROLS
Control Change 104 is defined as the Note control. It's value is interpreted as a note number, and causes the next message on the same channel to be addressed only to that note, if possible. If that message isn't a Control Change 0 to 31, it also consumes the Note control, so that it has no further effect. If it is a Control Change 0 to 31, it tags the record of the note number so that it will only still be effective on the corresponding Control Change LSB, so that LSBs that follow their corresponding MSBs will not need a second Note control.
A regular message with no preceding Note control overrides any earlier messages addressed to individual notes, just as a Channel Pressure overrides any earlier Poly Pressures. Typically, a Note control will work with a limited set of other Control Changes (or MSB and LSB in that order), or a Pitch Bend. It should not work with Channel Pressure, since Poly Pressure is available for that purpose. If an NRPN is to be addressed to a note, the Note control must precede the Data, not the NRPN. If a Note control precedes a control that doesn't support it, the Note control should still be consumed, but the following control should be ignored, rather than interpreting it as a mono control.
Forgive me if I misunderstand your proposal but how do I then ...
Start all notes of a played chord "on pitch", then modify just one note of the chord, changing its pitch, its timbre and its dynamics until note off.
The other notes must continue, as long as held, without modification.
>I've read the thread on the MPE working group, and found a couple of draft specs online. I think the proposal is insanely awful.
insanely awful is an understatement. Especially considering the fact MIDI *already* has a per-note tune message (14-bit resolution). I am using it my VSTi synths to support microtuning, stacked unison, MIDI guitars etc.
https://www.midi.org/specifications/item/the-midi-1-0-specification
[SINGLE NOTE TUNING CHANGE (REAL-TIME)]
The single note tuning change message (Exclusive Real Time sub-ID#1 = 08) permits on-the-fly adjustments to any tuning
stored in the instrument's memory. These changes should take effect immediately, and should occur without audible artifacts
if any affected notes are sounding when the message is received.
F0 7F <device ID> 08 02 tt ll [kk xx yy zz] F7
F0 7F Universal Real Time SysEx header
<device ID> ID of target device
08 sub-ID#1 (MIDI Tuning)
02 sub-ID#2 (note change)
tt tuning program number (0 – 127)
ll number of changes (1 change = 1 set of [kk xx yy zz])
[kk] MIDI key number
[xx yy zz] frequency
Likewise MIDI *already* supports per-note controllers. I am using them to provide, for example, per-note panning (very cool).
[UNIVERSAL REAL TIME SYSTEM EXCLUSIVE]
KEY-BASED INSTRUMENT CONTROL
F0 7F <device ID> 0A 01 0n kk [nn vv] .. F7
F0 7F Universal Real Time SysEx header
<device ID> ID of target device (7F = all devices)
0A sub-ID#1 = “Key-Based Instrument Control”
01 sub-ID#2 = 01 Basic Message
0n MIDI Channel Number
kk Key number
[nn,vv] Controller Number and Value
F7 EOX
The specs are here on the MIDI website. How the heck is an entire workinggroup proceeding without knowing this???
>I've read the thread on the MPE working group, and found a couple of draft specs online. I think the proposal is insanely awful.
insanely awful is an understatement. Especially considering the fact MIDI *already* has a per-note tune message (14-bit resolution). I am using it my VSTi synths to support microtuning, stacked unison, MIDI guitars etc.
....
MMA does not publish specs until they have been adopted by a vote of MMA Members (and our partners in Japan, AMEI). The "current version" referred to in that link is the current draft for MMA Members to discuss... it is not an adopted spec and is not intended for use in any commercial products.
Roli published some early drafts on their own before coming to MMA with the proposal, and some companies may have released products based on those drafts, but there are no products that comply with the MMA MPE Specification yet because the MMA MPE Specification has not been finished yet. When it is finished it will be published here (http://www.midi.org) and then anyone can read it.
In short:
Each finger becomes a traditional single channel MIDI device. Existing messages of the MIDI 1.0 spec (note on/off, pitchbend, channel pressure, CC74) all function the same way and become assigned to a particular finger for the duration of a note on a particular MIDI channel.
This leaves two issues to be solved:
* global messages like for a pitchbend wheel, sustain pedal, sostenuto pedal, breath, ... need to apply to all fingers and are put on a separate main channel so that their intent is clear and can be properly handled in DAWs (Logic Pro X has already been supporting this for years in their MIDI mono mode with common base channel)
As an example, you can very well craft your own synth that responds to MPE controllers by taking a series of analog mono synths. Setting them to the same patch and pitchbend range, having each one respond to a dedicated MIDI channel, and you're set.
I hope that clarifies the approach that we've taken with MPE.
MPE has been designed to be as minimal a leap as possible for existing product developers and existing MIDI users.
If you play an expression source that doesn't have per-note capabilities (like most traditional keyboard), all the messages are backwards compatible.
In short:
Each finger becomes a traditional single channel MIDI device. Existing messages of the MIDI 1.0 spec (note on/off, pitchbend, channel pressure, CC74) all function the same way and become assigned to a particular finger for the duration of a note on a particular MIDI channel.
(most controllers capable of generating the appropriate real-time expression data naturally gravitated to this model before the MPE spec but with slight variations: Continuum, Eigenharp, Seaboard, LinnStrument, ...)
This leaves two issues to be solved:
* global messages like for a pitchbend wheel, sustain pedal, sostenuto pedal, breath, ... need to apply to all fingers and are put on a separate main channel so that their intent is clear and can be properly handled in DAWs (Logic Pro X has already been supporting this for years in their MIDI mono mode with common base channel)
* devices need to agree upon a number of things: which channels to listen on, what the pitchbend range is and whether MPE is active or not. This is planned to be captured in an RPN for convenience. It's still completely possible though for users to configure this themselves.
We've received a lot of feedback from product manufacturers and this approach does indeed seem to make it very easy to add MPE support to existing products, and to integrate MPE into an existing MIDI setup without having to change anything. This can be seen by the number of products already claiming MPE support even before a final version of the spec has been released, just by working from old drafts that existed before the MME Working Group.
As an example, you can very well craft your own synth that responds to MPE controllers by taking a series of analog mono synths. Setting them to the same patch and pitchbend range, having each one respond to a dedicated MIDI channel, and you're set.
I hope that clarifies the approach that we've taken with MPE.