Unbelievable structural defects in MTS that I didn't realize

[Mike Battaglia]

I wrote:
> Turns out it does have all the features we need - actually, it has too many, most of which are useless."

Looks like I spoke way too soon on that. I just found found two things
which are absolutely and utterly ridiculous about the MTS standard:

First, the non-realtime tuning change is actually sent, literally, as
a non-realtime SysEx message. Non-realtime SysEx messages aren't
supposed to be processed immediately, respecting their order in
relation to surrounding events in the queue. Rather, they're just
supposed to be processed whenever the synth "gets around to it."

So you might end up sending a non-realtime tuning message before a
note-on, but then it might get processed AFTER the note-on. This is
especially true if the message is being passed around between several
MIDI relays or daisy-chained devices. You never know when it's going
to end up getting processed by the synth.

This totally destroys the utility of this message for things like
retuners, which is the only situation in which that message would have
ever be useful to begin with. Thus, non-realtime tuning changes are
utterly useless.


That leaves us with one useful MTS message: the realtime standard
tuning change message - specifically, the non-deprecated version with
bank. But look very, very, very carefully at the structuring of this
message (http://www.midi.org/techspecs/midituning.php#bank_ext), and
you'll notice something ridiculous is missing. There's no channel
number!! God damn it, how did they forget that?

Turns out this really changes things a bit. Though they never actually
say this anywhere, as far as I can tell, the desired workflow is
supposed to be:

1) You use one of these realtime/non-realtime tuning changes to update
a particular tuning "bank/program".
2) Then, on the channel you want, you send the tuning select RPN to
select the bank/program that you want for that specific channel.
3) Thus, by convention, you might immediately set channels 1-16 to
tuning programs 1-16 on bank 1. Then, when you send realtime tuning
changes to bank 1, programs 1-16, channels 1-16 instantl update.

This is an extremely silly and cumbersome setup for 2013, but it ends
up working. So this changes my analysis a bit:

1) The non-realtime messages are now worse than useless, since there's
no guarantee that they're going to actually be processed at the right
time, a problem made worse if things are being relayed and
daisy-chained.

2) The realtime messages are still OK, but since you can't specify a
channel, you're forced to specify a "bank and program" instead, and
then load the bank and program on the channel you want via the tuning
bank/program select RPN. Once you've done this one time per channel,
you can then just send realtime tuning changes to the proper
bank/program to update things without having to send another RPN.

Thus, the only things useful in any way to us are realtime tuning
changes, and the bank/program RPN. Non-realtime messages get demoted
to "useless" status, and the bank/program select RPN gets promoted to
"critical" status.

Damn.

Mike

[Carl Lumma]

Not sure I follow. There's no channel selector because it's not a channel message. That's the whole point of MTS. There's pitch bend if you want a channel message.

The messages, it seems to me, are perfectly adequate. As you said before, it's a matter of how synths respond to them.

Another point worth making is that MIDI is like TCP/IP. Web users don't usually inspect TCP packets, and musicians shouldn't have to think about tuning banks or any of this MTS stuff. Each synth should implement an appropriate UI and translate UI actions into MTS messages. A synth designed to work with the Terpstra might be different than one designed to provide multi-Halberstadt root-change functionality, which might be different than one designed to explore the relationship between timbre and tuning.

The reason none of this exists isn't because MTS is no good, it's because alt tuning is a miniscule niche where even people in it are interested in vastly different things.

-Carl

[Mike Battaglia]

On Mon, Sep 16, 2013 at 4:49 PM, Carl Lumma <clu...@gmail.com> wrote:
> Not sure I follow. There's no channel selector because it's not a channel
> message. That's the whole point of MTS. There's pitch bend if you want a
> channel message.

I don't think we're using "channel message" the same way. I was saying
that the MTS SysEx message applies to all channels at once, whereas
your pitch bend example applies to all notes on one channel.

But as it stands, it's not an issue anyway - you can still get
different tuning tables per channel by setting each channel to a
different bank/program and just updating the bank/program you want. I
shouldn't have labeled it a "structural defect" in the subject - that
was cruft from an earlier version of the message that I forgot to
change, so my bad.

The real "defect" was in the non-realtime message, which no longer seems useful.

> Another point worth making is that MIDI is like TCP/IP. Web users don't
> usually inspect TCP packets, and musicians shouldn't have to think about
> tuning banks or any of this MTS stuff. Each synth should implement an
> appropriate UI and translate UI actions into MTS messages. A synth designed
> to work with the Terpstra might be different than one designed to provide
> multi-Halberstadt root-change functionality, which might be different than
> one designed to explore the relationship between timbre and tuning.

No arguments there...

Mike

[Carl Lumma]

On Monday, September 16, 2013 2:09:48 PM UTC-7, Mike Battaglia wrote:

On Mon, Sep 16, 2013 at 4:49 PM, Carl Lumma <clu...@gmail.com> wrote:
> Not sure I follow. There's no channel selector because it's not a channel
> message. That's the whole point of MTS. There's pitch bend if you want a
> channel message.

I don't think we're using "channel message" the same way. I was saying
that the MTS SysEx message applies to all channels at once, whereas
your pitch bend example applies to all notes on one channel.

Yup, that's what I said. So why would there be a channel selector in the MTS message?
 

But as it stands, it's not an issue anyway - you can still get
different tuning tables per channel by setting each channel to a
different bank/program and just updating the bank/program you want.

Sure.
 

I shouldn't have labeled it a "structural defect" in the subject - that
was cruft from an earlier version of the message that I forgot to
change, so my bad.

The real "defect" was in the non-realtime message, which no longer seems useful.

It's very useful, for exactly the reason you wrote in your original message: when you want to retune only new notes, with no effect on tails.

-Carl

[Mike Battaglia]

On Mon, Sep 16, 2013 at 5:20 PM, Carl Lumma <clu...@gmail.com> wrote:
>>
>> I don't think we're using "channel message" the same way. I was saying
>> that the MTS SysEx message applies to all channels at once, whereas
>> your pitch bend example applies to all notes on one channel.
>
> Yup, that's what I said. So why would there be a channel selector in the MTS
> message?

No, there wouldn't be, but it's just worth noting that the
bank/program select RPN's, which I had previously described as
"useless" or "marginally useful" or something like that, are now
required to set different channels up differently.

> It's very useful, for exactly the reason you wrote in your original message:
> when you want to retune only new notes, with no effect on tails.

It isn't useful if the note on's are processed before the non-realtime
tuning change.

Mike

[Carl Lumma]

> Yup, that's what I said. So why would there be a channel selector in the MTS
> message?

No, there wouldn't be, but it's just worth noting that the
bank/program select RPN's, which I had previously described as
"useless" or "marginally useful" or something like that, are now
required to set different channels up differently.

Ah, OK.
 

> It's very useful, for exactly the reason you wrote in your original message:
> when you want to retune only new notes, with no effect on tails.

It isn't useful if the note on's are processed before the non-realtime
tuning change.

Just because it's got the non-realtime header doesn't mean modern synths can't respond immediately. As the page says, the purpose is to allow "the sender to specify a new tuning change that will NOT update the currently sounding notes". That's exactly what we want. It's the perfect thing to call out in an "MTS: The good parts" document. Which by the way, is a reference to Crockford's famous "Javascript: The Good Parts".

-Carl