The big picture of MTS

[Mike Battaglia]

I did some more thorough research into MTS, and I now understand the entire standard completely. The reference that I'm using is here: http://www.midi.org/techspecs/midituning.php

I don't find this document to be very well written, and it took a few hours of going over everything to make sure I understood how everything works, what things are useful and not useful in 2013, and what the deal with the "extension" is (which should have partly been called an "erratum").

The summary of what I've figured out about is:

There are only two messages that are crucial for the modern tuning paradigm, and those are

• "Single note" tuning change real-time (with bank)
• "Single note" tuning change non-real-time (with bank)
  

This "single note" name is a terrible misnomer, as these messages can be used to update all of the notes in the tuning table at once, in one message - or only part of it, down to as little as one note at a time. This should really be called "modify tuning table," or something. This is the only way to actually update notes in some tuning table (the bulk dump thing didn't work as I expected, as I'll explain below).

The realtime one is effectively a polyphonic pitch bend. If you have a note that's sounding, and a realtime message is sent affecting that note, the note should immediately change, without the attack playing again or anything. It seems to be the consensus that release trails should retune as well.

The non-realtime one is the same sort of thing, except it doesn't retune notes that are already sounding. So if you're doing a lot of tuning changes on the fly, you might want to work with non-realtime messages, since release trails aren't affected, which can make it sound like things are ricocheting off the walls sometimes. (I think Timidity understands realtime tuning changes, but processes them as though they were non-realtime).

The "with bank" thing deserves some talking about. The original MTS standard had specified "tuning bank/program select" functionality, which I'll talk about below. However, all of the actual tuning change messages, and tuning dump messages, only had parameters specifying the tuning "program" and not the "bank." They seem to have acknowledged that the original spec totally fubars this in an addendum to the MTS spec, which outlines some extensions that "correct that oversight." In it, they come up with new versions of all of the previously defined message that have parameters for both the tuning bank and the tuning program. The older ones, which fail to allow you to address the bank at all, should probably be considered deprecated.

In addition to the Big Two, there's also a semi-useful message:

• Tuning bank/program select (only real-time exists)

You can use "single-note" changes to program the tuning table that lies in a specific bank and program. Once you do that, you can use the above message (actually a pair of RPN's) to switch between tuning tables that you've already defined. Possibly useful in certain circumstances, though it isn't that important.

There's a few other marginally useful things that might be helpful in niche circumstances:

• Tuning dump request
• Tuning dump

These are mainly useful for synchronizing tuning tables between devices. One device can request a tuning dump from another, and the other can send along a list of its tuning tables, called the "bulk dump." Other than the single-note changes, this seems to be the only way to change a tuning table at all. Also, the MTS spec seems to specify that bulk dumps are generally only sent in response to a bulk dump request, so it isn't like you just send unsolicited tuning dumps to program things (you use single note changes for that). This might be useful when synchronizing different synths running in different environments (e.g. in Linux) or something like that, but also isn't terribly important in a world where everything is usually taking place in some DAW.

Finally, there's some "scale/octave stuff," which is almost completely useless unless you don't plan on straying too far from 12:

• Scale/octave tuning dump, 1- and 2-byte formats
• Scale/octave tuning change, 1- and 2-byte formats, realtime
• Scale/octave tuning change, 1- and 2-byte formats, non-realtime

These messages are for programming 12-note tuning tables that repeat every octave. I guess the idea is that it helps you save bandwidth. I find this feature to be completely useless.

That's what I've figured out. The single-note tuning changes seem to constitute the meat of it, and everything else is either a less important minor feature, something which just isn't useful, or deprecated.

Mike

[Carl Lumma]

Excellent summary, thanks! I completely agree about the bank etc. abstractions being archaic. The designers assumed the synth would be the most powerful computer onstage.

-Carl

[Mike Battaglia]

Thanks, glad you found it useful. There's some background I should get
into here...

There's been a lot of discussion about tuning standards recently - we
don't really have one, and it sucks. Manufacturers aren't supporting
us because we aren't telling them what to support, but we aren't
telling them what to support because there's no standard for them to
support. Everyone agrees that we need a way to bootstrap ourselves out
of this crummy situation. So, I sought out to see if MTS was actually
viable as a standard for us to get behind. Turns out it does have all
the features we need - actually, it has too many, most of which are
useless.

I worked in isolation on this for a while, and then started talking
with Graham on Gchat about it too. We made some good progress,
especially in identifying some lurking issues with naive MTS
implementations that really screw things up. Even with just the two
tuning change messages, naive implementations can run into all sorts
of characteristic problems:

- artifacts where release trails bounce around (what I've termed the
"Doppler effect"),
- artifacts where samples are "pitch bent up" like three octaves (the
"Mickey Mouse" effect),
- where the register becomes absurdly small ("register cramp"),
- where "voice stealing" occurs, utterly destroying polyphony unless
you play certain chords that stick closely to a skeleton of 12-EDO or
other arbitrary requirements,
- others, etc.

These artifacts are so common and endemic to the architecture that
they should be treated similarly to how "aliasing" and "imaging"
artifacts are treated in wavetable synthesis. Everyone should know
about them and how to avoid them, but the problem is that a naive MTS
implementation can inadvertently lead to one or more of the above
behaviors in very common situations.

The core issue is: while MTS outlines how synths should respond to
tuning messages, it doesn't outline any sort of best-practice for how
controllers should generate those messages. This unfortunate problem
is compounded by the fact that the spec leaves open certain key things
about the synth's behavior which should have really been nailed down.
If synths and controllers don't agree on these key unspoken things,
you end up with artifact hell.

I've run into every single one of these issues at one point or
another. These situations turn out to be *very* non-trivial, and
difficult to avoid unless you really think through the details of an
implementation carefully. If you aren't careful, you end up with a
useless piece of junk which sounds great, but which I can't actually
use to play music in, say, 31-EDO. Unfortunately, no document exists
that outlines all of this clearly, so synth manufacturers are forced
to work all of this crap out on their own from scratch and fill in the
gaps however they randomly do it.

What's sorely needed is something stating clearly what synths should
expect from controllers and vice versa, and both sides need to know
the proper high-level paradigm so they can understand *why* things are
set up the way they are.

I'd like to work towards some kind of community consensus on a
"clarification" of the MTS standard which outlines clearly which
messages are useful, which are deprecated, which are basically
useless, what the best practices are for controllers, what synths
should know to avoid and to comply with (even if not explicitly
outlined in the MTS standard), etc.

It should especially detail clearly the high-level paradigm through
which MTS is viewed from the perspective of a modern microtonalist -
features we need, features we don't care about, etc. Things as basic
as "we don't only care about 12-note tunings" are likely to be a
revelation to many synth manufacturers.

Whether this is called an MTS "clarification," or a set of "best
practices" for MTS, or a "new protocol" that's really just a
standardized way of using MTS plus some additional restrictions, etc -
all of that's largely a matter of selling the idea, so none of it
matters to me. It's all the same idea - MTS is a framework for
transmitting tuning-related information, but does not clearly and
completely specify how controllers and synths should generate and
interpret such information, so that's what I want to work towards.

So, I'll be periodically writing posts here that are in line with
that.

Mike

> --
> --
> You received this message because you are subscribed to the
> "Making Microtonal Tools" Google group.
>
> To unsubscribe from this group, send email to
> microtools-...@googlegroups.com
>
> For more options, visit this group's web site at
> http://groups.google.com/group/microtools
> ---
> You received this message because you are subscribed to the Google Groups
> "Making Microtonal Tools" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to microtools+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Carl Lumma]

I also think MTS is sufficient, and I think a best-practices guide is a great idea. "MTS: The Good Parts"

It would be great to wind Werner Mohrlock in on this. He's gotten Hermode tuning into tons of hardware and software over the years, and IIRC was instrumental in getting the single-note messages added to MTS. The language barrier has been a bit of an issue in the past... maybe you will be better at working around that.

-Carl

On Saturday, September 14, 2013 1:37:12 AM UTC-7, Mike Battaglia wrote:

[Mike Battaglia]

I say bring him into the fold, but I think it'd be better to wait
until the hubbub has died down everywhere first and we come to a
conclusion regarding what we want, then he can comment on it. There's
this parallel discussion happening on Facebook right now, and it's
like this explosion of thousands and thousands of comments. I'm trying
to focus it in and see if we can reach consensus.

The current point of discussion is that Robert and Kite have found
some weird nuances of how SysEx interacts with MIDI-USB that might
cause some weird issues with realtime tuning changes with MTS, so I'll
report back after the next 1,000 comments if that really makes a
difference or if it just turns out to be FUD...

Mike

[Carl Lumma]

On Monday, September 16, 2013 1:52:45 PM UTC-7, Mike Battaglia wrote:

I say bring him into the fold, but I think it'd be better to wait
until the hubbub has died down everywhere first and we come to a
conclusion regarding what we want, then he can comment on it. There's
this parallel discussion happening on Facebook right now, and it's
like this explosion of thousands and thousands of comments. I'm trying
to focus it in and see if we can reach consensus.

He can implement it? No, he doesn't make any synths. I was suggesting he'd be a good person to ask about the ins and outs of MTS.
 

The current point of discussion is that Robert and Kite have found
some weird nuances of how SysEx interacts with MIDI-USB that might
cause some weird issues with realtime tuning changes with MTS, so I'll
report back after the next 1,000 comments if that really makes a
difference or if it just turns out to be FUD...

 

I can already tell you that's FUD and I haven't even looked at the thread yet.

-Carl