Coming soon: MIDI support for Rationale

Hi folks.

I'm working through the knots of implementing MIDI support for my JI sequencer Rationale, and I'm wondering what kinds of information need to be options for sending. So far it seems like it needn't be complicated (from the user's point of view). I expect the parameters for each Rationale MIDI instrument will be:

-MIDI device/channel combinations (whether you overlap the same device-channel combo with more than one Rationale instrument is up to the user)
-pitchbend, note-on, velocity, note-off (all sent automatically, not requiring any choice from the user)
-program change message (optional, and can be set to either a constant or a variable set separately per note in the score)
-continuous controllers (optional, unlimited, can be set to constant or separate variables per note)

I'm foreseeing pitchbend always going first, then program and CC's in whatever order the user wants, before or after note-on. I've read that a bank change is typically a specific CC, so I'll let that up to the user to set up, if they want to. I'll recommend that people use different device/channels for each instrument, rather than sending program changes for each note, but that'll be up to users.

Keeping in mind that I myself won't get much use out of MIDI support, and will be wincing while adding the code to my program, is there anything else that's absolutely necessary? Very little checking will be done, not because I don't love you all, but because I trust you to look after yourselves.

Great news, Chuckk. Will you be using pitchbend for tuning?

If I had my way, it'd work like this:

1. User specifies some very accurate equal temperament
(e.g. 72 ala Prent Rodgers or 441 ala Gene Ward Smith).

Actually user specifies something called a val, which shows
how many steps of the ET to use for each prime. So for 72-ET
in the 13-limit, it would be
< 72 114 167 202 249 266 |
where each entry is the number of steps to that prime,
e.g. 167 steps to 5:1.

2. The program takes each ratio in the score, factors it,
multiplies each term by the terms in the val, and then adds
through to get the number of ET steps for that interval.

3. This number is simply the MIDI note number offset.
If we go over 128, it just wraps around to the next MIDI
channel/device (specified by the user in advance).
The user tunes his synth(s) in advance to the ET in step 1.

This avoids pitchbend retuning (yuck) and users can choose
from any synth ever made that supports full scale retuning
(there are quite a few).

Not only that. Users can also retune their compositions
at any time in a single step. If they get a faster computer
that can run more instances of their synth, they can use
a larger, more-accurate ET. Or, they can purposely try a
less-accurate ET to get fun and interesting effects.

What do you make of this? Or am I all wet?

-Carl

At 09:58 AM 1/31/2010, you wrote:
>Hi folks.
>
>I'm working through the knots of implementing MIDI support for my JI
>sequencer Rationale, and I'm wondering what kinds of information need
>to be options for sending. So far it seems like it needn't be
>complicated (from the user's point of view). I expect the parameters
>for each Rationale MIDI instrument will be:
>
>-MIDI device/channel combinations (whether you overlap the same
>device-channel combo with more than one Rationale instrument is up to the user)
>-pitchbend, note-on, velocity, note-off (all sent automatically, not
>requiring any choice from the user)
>-program change message (optional, and can be set to either a constant
>or a variable set separately per note in the score)
>-continuous controllers (optional, unlimited, can be set to constant
>or separate variables per note)
>
>I'm foreseeing pitchbend always going first, then program and CC's in
>whatever order the user wants, before or after note-on. I've read that
>a bank change is typically a specific CC, so I'll let that up to the
>user to set up, if they want to. I'll recommend that people use
>different device/channels for each instrument, rather than sending
>program changes for each note, but that'll be up to users.
>
>
>Keeping in mind that I myself won't get much use out of MIDI support,
>and will be wincing while adding the code to my program, is there
>anything else that's absolutely necessary? Very little checking will
>be done, not because I don't love you all, but because I trust you to
>look after yourselves.
>

On 1 Feb 2010, at 2:58 AM, touchedchuckk wrote:

>
> Hi folks.
>
> I'm working through the knots of implementing MIDI support for my > JI sequencer Rationale, and I'm wondering what kinds of information > need to be options for sending. So far it seems like it needn't be > complicated (from the user's point of view). I expect the > parameters for each Rationale MIDI instrument will be:
>
> -MIDI device/channel combinations (whether you overlap the same > device-channel combo with more than one Rationale instrument is up > to the user)
>

What do you mean by Device? Device Number in MIDI standard is part of SysEx communication, something like a MIDI channel embedded in SysEx. It allows the addressing the same instruments on the same MIDI port individually and sending them different SysEx data.

It would be good to have a possibility to address different ports to get more than 16 channels.

> -pitchbend, note-on, velocity, note-off (all sent automatically, > not requiring any choice from the user)
>

Note Off is usually sent as Note On with velocity 0 and Running Status is used to save some bytes.

> -program change message (optional, and can be set to either a > constant or a variable set separately per note in the score)
>

Is there some special reason to send this for every note? I have never heard about. Besides filling the datastream with unnecessary bulk of data can cause problems - MIDI instruments need some time for processing this information and call the program.

> -continuous controllers (optional, unlimited, can be set to > constant or separate variables per note)
>

Again this is separate information, it's not connected to notes On/Off data. And why not to implement the other controllers as well? Including NRPN, RPN (important for Tuning Standard!!!)...

>
> I'm foreseeing pitchbend always going first, then program and CC's > in whatever order the user wants, before or after note-on.
>

MIDI standard has different priority - the most important are notes. It's upon user to program controllers carefully and place them before notes in the sequencer if they should affect the next note.

> I've read that a bank change is typically a specific CC,
>

Combination of 0 and 32.

> so I'll let that up to the user to set up, if they want to.
>

Yes, it's necessary with modern instruments which have lot of sound banks, more sounds than 128.

> I'll recommend that people use different device/channels for each > instrument, rather than sending program changes for each note, but > that'll be up to users.
>

Yes, the first case is preferred recently thanks to the multiport communication.
>
> Keeping in mind that I myself won't get much use out of MIDI > support, and will be wincing while adding the code to my program, > is there anything else that's absolutely necessary? Very little > checking will be done, not because I don't love you all, but > because I trust you to look after yourselves.
>

Another points:
- What about aftertouch? Channel aftertouch would be satisfactory.

- SysEx is necessary for setting microtuning in synthesizers and for lot of other important messages

- MTS - Micro Tuning Standard?

- MIDI Clock and Realtime Messages - Start/Stop/Continue would be good for synchronization of external devices

- Active Sensing should be implemented, too.

Daniel Forro

Howdy Carl.

Interesting method. Is this your invention?
I'm wondering two things in particular. (1) Is there no simple way to do this already? It almost seems to me it would actually be simpler to code a middle-man app that takes JI ratios (maybe through OSC) as input and outputs such messages. I've also kept Rationale pretty pure so far, in terms of JI. (2) If there isn't already a simple way to do this, how many people will want to use it? I'm not above doing it based on one request, of course; it seems to make sense, and other people would probably try it.

People have requested MIDI output, though, and they didn't mention this method. If I set up something like this and it doesn't satisfy people, I still gotta go back and add something else.
That said, it sounds like the calculations would be really simple. Funny thing about user interface programming, it would probably be simpler to compute those offsets automatically based on whichever ET is chosen than to let the user specify his own correlations. Rationale already has a ratio-bank dialog that has no upper prime limit, and the only restriction on ratios is whole numbers.

-Chuckk

--- In MakeMicroMusic@yahoogroups.com, Carl Lumma <carl@...> wrote:
>
> Great news, Chuckk. Will you be using pitchbend for tuning?
>
> If I had my way, it'd work like this:
>
> 1. User specifies some very accurate equal temperament
> (e.g. 72 ala Prent Rodgers or 441 ala Gene Ward Smith).
>
> Actually user specifies something called a val, which shows
> how many steps of the ET to use for each prime. So for 72-ET
> in the 13-limit, it would be
> < 72 114 167 202 249 266 |
> where each entry is the number of steps to that prime,
> e.g. 167 steps to 5:1.
>
> 2. The program takes each ratio in the score, factors it,
> multiplies each term by the terms in the val, and then adds
> through to get the number of ET steps for that interval.
>
> 3. This number is simply the MIDI note number offset.
> If we go over 128, it just wraps around to the next MIDI
> channel/device (specified by the user in advance).
> The user tunes his synth(s) in advance to the ET in step 1.
>
> This avoids pitchbend retuning (yuck) and users can choose
> from any synth ever made that supports full scale retuning
> (there are quite a few).
>
> Not only that. Users can also retune their compositions
> at any time in a single step. If they get a faster computer
> that can run more instances of their synth, they can use
> a larger, more-accurate ET. Or, they can purposely try a
> less-accurate ET to get fun and interesting effects.
>
> What do you make of this? Or am I all wet?
>
> -Carl
>
> At 09:58 AM 1/31/2010, you wrote:
> >Hi folks.
> >
> >I'm working through the knots of implementing MIDI support for my JI
> >sequencer Rationale, and I'm wondering what kinds of information need
> >to be options for sending. So far it seems like it needn't be
> >complicated (from the user's point of view). I expect the parameters
> >for each Rationale MIDI instrument will be:
> >
> >-MIDI device/channel combinations (whether you overlap the same
> >device-channel combo with more than one Rationale instrument is up to the user)
> >-pitchbend, note-on, velocity, note-off (all sent automatically, not
> >requiring any choice from the user)
> >-program change message (optional, and can be set to either a constant
> >or a variable set separately per note in the score)
> >-continuous controllers (optional, unlimited, can be set to constant
> >or separate variables per note)
> >
> >I'm foreseeing pitchbend always going first, then program and CC's in
> >whatever order the user wants, before or after note-on. I've read that
> >a bank change is typically a specific CC, so I'll let that up to the
> >user to set up, if they want to. I'll recommend that people use
> >different device/channels for each instrument, rather than sending
> >program changes for each note, but that'll be up to users.
> >
> >
> >Keeping in mind that I myself won't get much use out of MIDI support,
> >and will be wincing while adding the code to my program, is there
> >anything else that's absolutely necessary? Very little checking will
> >be done, not because I don't love you all, but because I trust you to
> >look after yourselves.
> >
>

Hello Daniel. Thanks for your reply! Some thoughts below...

--- In MakeMicroMusic@yahoogroups.com, Daniel Forró <dan.for@...> wrote:
> What do you mean by Device? Device Number in MIDI standard is part of
> SysEx communication, something like a MIDI channel embedded in SysEx.
> It allows the addressing the same instruments on the same MIDI port
> individually and sending them different SysEx data.
>
> It would be good to have a possibility to address different ports to
> get more than 16 channels.

OK, by device I meant "port".

> > -program change message (optional, and can be set to either a
> > constant or a variable set separately per note in the score)
> >
>
>
> Is there some special reason to send this for every note? I have
> never heard about. Besides filling the datastream with unnecessary
> bulk of data can cause problems - MIDI instruments need some time for
> processing this information and call the program.

It's optional, meaning the user can include it or not as part of the message list to be sent. If people use the same port/channel for any two instruments, they may need to make sure the program is changed. True, they probably *won't*, but I don't want to be the one to tell them they *can't*. I used this method with my previous program, JISequencer, and didn't have too many complaints. Part of my job will be not sending two notes in a row on the same port/channel with pitchbends and program changes between them. It would even not be difficult to have them always sent a little bit before note-on.

> > -continuous controllers (optional, unlimited, can be set to
> > constant or separate variables per note)
> >
> Again this is separate information, it's not connected to notes On/
> Off data. And why not to implement the other controllers as well?
> Including NRPN, RPN (important for Tuning Standard!!!)...

If people want to send CCs before notes, they set it up to do so, otherwise they don't. There are plenty of MIDI-capable audio programs out there where CCs can be assigned to anything the user wants, so I don't assume General MIDI.
NRPN, RPN; that's what I wanted to know. These are necessary? OK!

> > I'm foreseeing pitchbend always going first, then program and CC's
> > in whatever order the user wants, before or after note-on.
> >
>
> MIDI standard has different priority - the most important are notes.
> It's upon user to program controllers carefully and place them before
> notes in the sequencer if they should affect the next note.

I'm imagining a UI where these messages can not only be specified in detail, but specified according to what order they should occur in.
I forgot to mention, as far as Rationale is concerned, any kind of automations or controller messages independent of notes exist only in the future. It's just a whole lot of coding, no other reason. It'll likely go hand in hand with MIDI input, whenever that decides to happen...

> Another points:
> - What about aftertouch? Channel aftertouch would be satisfactory.
>
> - SysEx is necessary for setting microtuning in synthesizers and for
> lot of other important messages
>
> - MTS - Micro Tuning Standard?
>
> - MIDI Clock and Realtime Messages - Start/Stop/Continue would be
> good for synchronization of external devices
>
> - Active Sensing should be implemented, too.

If you're trying to scare me out of implementing MIDI output, you'll have to try harder than that! Not much harder, just a little. It starts to sound like a lot of work for something I'll never use.
Any seconds on this list? Is aftertouch useful for a sequencer without live input?

Thanks a lot for your feedback, Daniel! I'll start reading up on these.

-Chuckk

Hi Chuckk,

>Interesting method. Is this your invention?

It's from tuning-math land.

>I'm wondering two things in particular. (1) Is there no simple way
>to do this already?

Nope.

>It almost seems to me it would actually be simpler to code a
>middle-man app that takes JI ratios (maybe through OSC) as input
>and outputs such messages.

That'd be cool. Does Rationale output OSC?

On the other hand, such abstraction layers require ports, and
ports are the bugaboo of cross-platform it-just-workedness.
How would I shuffle OSC from Rationale to such an app on a
Windows box? On a Mac? etc.

>I've also kept Rationale pretty pure so far, in terms of JI.

It's always quantized to something somewhere. The big point of
this though is to avoid pitch bend tuning, which always sounds
like *$%()@. A tuning like 441 has at most 1 cent error in the
17-limit, and that's better than your piano a month after you
tune it. It also approaches the internal accuracy of many
synths, I'm sure.

>If there isn't already a simple way to do this, how many people
>will want to use it? I'm not above doing it based on one request,
>of course; it seems to make sense, and other people would
>probably try it.

Rationale looks pretty powerful. If it were compatible with
MIDI synths in a good way, and had an installer :P I think it'd
have strong appeal.

>People have requested MIDI output, though, and they didn't mention
>this method.

They probably haven't thought it as much as I have. :)

>If I set up something like this and it doesn't satisfy
>people, I still gotta go back and add something else.

What were you planning to do, pitchbend? Mention that around
here and Jon Szanto and I (at least) will cry Judas.

>That said, it sounds like the calculations would be really simple.

Sure is. And it makes a great deal more sense than what people
normally do, which is just directly converting to the nearest
quantized step. That doesn't produce a consistent mapping in
all cases. Actually you can use this method even with pitch
bends -- they are, after all, just a large ET (14,400 or something
like that, assuming the bend range on the synth is set to a whole
step or something like that).

>Funny thing about user interface programming, it would probably be
>simpler to compute those offsets automatically based on whichever ET
>is chosen than to let the user specify his own correlations.

You have to use a complete val or you're not guaranteed to get
consistent results. You can use what's called the "patent val",
which just takes the best approx to each prime

< best-to-2 best-to-3 best-to-5 best-to-7... |

The way the UI could work is by taking the 2 mapping out of the
val, putting it in a separate box and calling it the ET#. When
the composer picks it, the rest of the mapping could be autofilled
with the patent val

< best-to-3 best-to-5 best-to-7 |

but the composer could type over these fields if desired. Or
something like that.

>Rationale already has a ratio-bank dialog that has no upper prime
>limit, and the only restriction on ratios is whole numbers.

Yes, I like it. Compose in JI. Unfortunately synths don't handle
ratios.

-Carl

Chuckk wrote:

>Is aftertouch useful for a sequencer without live input?

I have no idea what you two are talking about. Where would
aftertouch or any of these other messages come from? Please,
just make the notes play and polish the composer's workflow
before worrying about this window dressing.

-Carl

Hi again.

--- In MakeMicroMusic@yahoogroups.com, Carl Lumma <carl@...> wrote:
>
> >If I set up something like this and it doesn't satisfy
> >people, I still gotta go back and add something else.
>
> What were you planning to do, pitchbend? Mention that around
> here and Jon Szanto and I (at least) will cry Judas.

That's what I was planning to do, and it'll still happen. I think your method and pitchbend tuning will be two separate options.

> You have to use a complete val or you're not guaranteed to get
> consistent results. You can use what's called the "patent val",
> which just takes the best approx to each prime
>
> < best-to-2 best-to-3 best-to-5 best-to-7... |
>
> The way the UI could work is by taking the 2 mapping out of the
> val, putting it in a separate box and calling it the ET#. When
> the composer picks it, the rest of the mapping could be autofilled
> with the patent val
>
> < best-to-3 best-to-5 best-to-7 |
>
> but the composer could type over these fields if desired. Or
> something like that.

I think that'll be the way to go; not sure what limit to go to, but I'd like to offer the option of including steps for arbitrary primes. I guess the same interface, but both the prime itself and the suggested val can be edited.

How does this sound? The user adds a Lumma-style MIDI line to the output page, and selects a range of port/channel combinations, as well as some kind of base frequency/note number correlation. Next to that are the fields you mentioned, one for the ET and the others for primes up to 13 or so, with others that can be added and removed, and all of them populating with suggested vals based on the chosen ET.
It's naturally up to the user to make sure the synths that take input from those port/channel combinations are set up in the right order. I think that'll require a separate Help menu item.

-Chuckk

Hi Chuckk,

>> < best-to-3 best-to-5 best-to-7 |
>>
>> but the composer could type over these fields if desired. Or
>> something like that.
>
>I think that'll be the way to go; not sure what limit to go to, but
>I'd like to offer the option of including steps for arbitrary primes.
>I guess the same interface, but both the prime itself and the
>suggested val can be edited.
>
>How does this sound?

That sounds awesome!! I think if you have fields for primes up to
19 that should satisfy (I'll never go beyond 17). Or you could have
one of those + buttons to add fields one at a time for people who
are into high-prime stuff.

>The user adds a Lumma-style MIDI line to the output page, and
>selects a range of port/channel combinations, as well
>as some kind of base frequency/note number correlation. Next to that
>are the fields you mentioned, one for the ET and the others for primes
>up to 13 or so, with others that can be added and removed, and all of
>them populating with suggested vals based on the chosen ET.
>It's naturally up to the user to make sure the synths that take input
>from those port/channel combinations are set up in the right order. I
>think that'll require a separate Help menu item.

Sounds perfect.

Please keep in mind that pitch bends are just 196608-ET (according
to Monzo) so they could use the same underlying interface.

-Carl