Change Note OFF to Note TUNE

The 5-byte idea causes too many problems, and RPNs cause
some other issues. MIDI harpsichordists may not like this, but
since Note OFF is unofficially an orphan message sitting there
first on the list, having long ago been replaced by Note ON
velocity 0, what about changing the Note OFF message into
a Note TUNE message? The format could be just like Pitch Bend:

1000nnnn 0ccccccc 0fffffff

n = channel
c = course tuning
f = fine tuning

But this message would work independent of Pitch Bend (meaning
Pitch Bend would have the expected effect on any TUNEd Note), and
it would apply only to the note message that follows it on the given
channel. The TUNE range would also be independent of the channel
bend range and would be _fixed at + / - a quartertone, not requiring
any new RPNs for messing with the TUNE range, giving 196,608
steps per octave.

Tuning a note would then be done in 2 messages, just like is done
using Pitch Bend, but the results would be exactly what is needed:
every note independently tunable (and also bendable after being tuned).
No sysex or any other messages needed.

This would of course require recoding of all Note OFF message
interpretations in all future software and firmware. I guess it is
essentially the same as Robert Walker's idea using RPNs, except that
instead of an RPN which is out there in a list of other obscure RPN
messages, it is the first message on the basic channel message list.
Both this idea and new RPN require a change in the spec.

I guess the response to this will be "it's too radical a change, and RPNs
make more sense for something new in the spec". But consider this:

I think this would be better, because I feel if the spec has to change, the
visibility of the message within the spec will have an impact on its
adoption. It would be hard to miss it as a basic channel message, and
the first message in the spec, to boot.

Yours,
Aaron Hunt
H-Pi Instruments

It's a clever idea, but then how would you tune a note that is already
on? You cannot send another note-on. The Midi Tuning Standard allows
retuning of sounding notes, but it does not prescribe what happens.

Manuel

Hi Manuel. Good point; the message alone would not allow retuning after
a note is sounding. But, if portamento is turned on, couldn't that be
achieved? Alternatively, a new message could be added: a 'Sans
Articulation Note ON' message, maybe as a RPN.

Aaron Hunt
H-Pi Instruments

--- In tuning@yahoogroups.com, "Manuel Op de Coul"
<manuel.op.de.coul@...> wrote:
>
> It's a clever idea, but then how would you tune a note that is already
> on? You cannot send another note-on. The Midi Tuning Standard allows
> retuning of sounding notes, but it does not prescribe what happens.
>
> Manuel
>

Hi Aaron,

If one is considering the poss. of a radical change in the spec - I just had another thought - as an alternative to RPNs - there are the reserved, undefined system status messages 0xF4, 0xF5, 0xF9 and 0xFD.
http://www.midi.org/about-midi/table2.shtml

I've never heard of them used for anything - are they used for anything ever, or been taken up in any existing extension of Midi, anyone know?

Since each has its own separate status byte, if you say that they should expect two data bytes, you have one extra data byte to play around with, so they are more efficient than using RPN controllers where you would need both the coarse and fine controllers to send a single bend, and best practice is to null the active parameter with another pair of messages when finished using them.

E.g. 0xF4 could expect only one data byte, and give the note number to retune, and 0xF5 could give the bend.

Or 0xF4 could expect two data bytes, with the second data byte used to set the type of tuning - so the second byte can be set to, perhaps:
0 - that the next 0xF5 is a single note type bend
1 - it applies to all notes in the channel, but only to notes not yet played, (in which case first data byte for 0xF4 is ignored) - same as "polyphonic pitch bends".
2 - it applies to that note and the note in all octaves above and below (useful mainly for retuning twelve tone music as an accidental),

Then there is lots of flexibility to add other ways of using these pitch bends to the spec later on (like the rpns). Specify that a synth should ignore the bend if it doesn't recognise the type in the second data byte of the 0xF4 message.

The slight drawback is that the message applies to all the channels in play - so doesn't allow you to tune different channels to different tunings by just retuning all the notes for each channel and then leaving the bends in place for the rest of the piece.

You could work around that, e.g. by letting 0xF4 include the channel + the type of tuning packed together in the second status byte.

Sort of a little kludgy, but has its advantages.

Robert

Hi Robert.

For going the unused message route, getting two data
bytes is a good find, but judging from their location in the
message list, my guess is that these are probably used in
synthesizer workstations for sequencer control. Just a hunch.

As you know, there are also plenty of unused CC messages
having just one data byte available. These could be used
in sucession to give a note, tuning MSB and tuning LSB.
Such a series of messages could prepare new notes as well
as act on notes already sounding. The unused CCs are listed
in MSB, LSB pairs, 20-31 and 52-63.

http://www.midi.org/about-midi/table3.shtml

The CC message already has the channel in the status byte,
So, the following would be controller numbers:

CC20: 1011hhhh 00010100 0nnnnnnn
CC52: 1011hhhh 00110100 0ccccccc
CC21: 1011hhhh 00010101 0fffffff

h = channel
n = note
c = tune coarse
f = tune fine

The order in which these are sent would matter,
since the synth has o know which note is to be tuned.

This would then be folowed by a Note ON message.

The CCs above could work for individual notes. A next
batch of CCs could work in the same way, but tune notes
already sounding. A next batch could work as octave
tuning messages. Thare are enough there to do several
different kinds of things.

CCs make a bit more sense to me than using the system
messages. The idea of Controlling the tuning makes sense.

A problem with using CCs as note messages might
seem at first to be that for every tuned note, there
would be 12 bytes, but considering that the tuning would
be independent of the note message, are are not many more
bytes than are sent using pitch bend, which works fine.
CCs are assumed to be channel messages, so using them as
note messages is unusual, but that's what we need.

Actually this looks pretty good. Then again there may
be something obvious I'm missing here which makes the
whole proposal useless.

Aaron Hunt
H-Pi Instruments

--- In tuning@yahoogroups.com, "Robert walker" <robertwalker@...> wrote:
>
> Hi Aaron,
>
> If one is considering the poss. of a radical change in the spec - I just had another
thought - as an alternative to RPNs - there are the reserved, undefined system status
messages 0xF4, 0xF5, 0xF9 and 0xFD.
> http://www.midi.org/about-midi/table2.shtml
>
> I've never heard of them used for anything - are they used for anything ever, or been
taken up in any existing extension of Midi, anyone know?
>
> Since each has its own separate status byte, if you say that they should expect two data
bytes, you have one extra data byte to play around with, so they are more efficient than
using RPN controllers where you would need both the coarse and fine controllers to send a
single bend, and best practice is to null the active parameter with another pair of
messages when finished using them.
>
> E.g. 0xF4 could expect only one data byte, and give the note number to retune, and
0xF5 could give the bend.
>
> Or 0xF4 could expect two data bytes, with the second data byte used to set the type of
tuning - so the second byte can be set to, perhaps:
> 0 - that the next 0xF5 is a single note type bend
> 1 - it applies to all notes in the channel, but only to notes not yet played, (in which case
first data byte for 0xF4 is ignored) - same as "polyphonic pitch bends".
> 2 - it applies to that note and the note in all octaves above and below (useful mainly for
retuning twelve tone music as an accidental),
>
>
> Then there is lots of flexibility to add other ways of using these pitch bends to the spec
later on (like the rpns). Specify that a synth should ignore the bend if it doesn't recognise
the type in the second data byte of the 0xF4 message.
>
> The slight drawback is that the message applies to all the channels in play - so doesn't
allow you to tune different channels to different tunings by just retuning all the notes for
each channel and then leaving the bends in place for the rest of the piece.
>
> You could work around that, e.g. by letting 0xF4 include the channel + the type of
tuning packed together in the second status byte.
>
> Sort of a little kludgy, but has its advantages.
>
> Robert
>

Aaron Andrew Hunt wrote:
> Hi Robert. > > For going the unused message route, getting two data > bytes is a good find, but judging from their location in the
> message list, my guess is that these are probably used in > synthesizer workstations for sequencer control. Just a hunch.

It says they're reserved, so they can be used for future expansion. But they're also non-channel messages. It's evil to use them for channel data.

> As you know, there are also plenty of unused CC messages > having just one data byte available. These could be used
> in sucession to give a note, tuning MSB and tuning LSB. > Such a series of messages could prepare new notes as well > as act on notes already sounding. The unused CCs are listed > in MSB, LSB pairs, 20-31 and 52-63.
> > http://www.midi.org/about-midi/table3.shtml

They aren't unused -- they're undefined. Any given synth is free to use them however it likes.

> The CC message already has the channel in the status byte,
> So, the following would be controller numbers:
> > CC20: 1011hhhh 00010100 0nnnnnnn
> CC52: 1011hhhh 00110100 0ccccccc
> CC21: 1011hhhh 00010101 0fffffff
> > h = channel
> n = note
> c = tune coarse
> f = tune fine
> > The order in which these are sent would matter,
> since the synth has o know which note is to be tuned.

It looks like you're reinventing (N)RPNs.

> This would then be folowed by a Note ON message.
> > The CCs above could work for individual notes. A next
> batch of CCs could work in the same way, but tune notes > already sounding. A next batch could work as octave > tuning messages. Thare are enough there to do several > different kinds of things.

Then it duplicates the existing standard. Why have another way to do it?

> CCs make a bit more sense to me than using the system > messages. The idea of Controlling the tuning makes sense.

Given that system exclusive messages have been defined to do exactly the same job why not use them?

> A problem with using CCs as note messages might
> seem at first to be that for every tuned note, there > would be 12 bytes, but considering that the tuning would
> be independent of the note message, are are not many more
> bytes than are sent using pitch bend, which works fine. > CCs are assumed to be channel messages, so using them as
> note messages is unusual, but that's what we need.

You're actually saving 3 or 4 bytes compared to the system exclusives. But you aren't able to address different tuning tables or specify all channels to change. In the worst case you'd lose another 3 bytes for true (N)RPNS but if you're doing a lot of tuning you can share the MSB. And retuning a dyad means sending 18 tuning bytes whereas the MTS Single Note Tuning Change (Real-Time) is actually quite capable of retuning multiple notes, and only requires 15 bytes for a dyad, with more efficiency the bigger the chord gets.

Regardless of the message format, dynamic tuning tables are the most efficient way of sending the tuning data. Most of the time you won't need to retune every note every time it's played. So you only need to send the tuning messages when the tuning table actually changes. This is harder with pitch bends because you've got one per channel instead of one per note per channel.

> Actually this looks pretty good. Then again there may
> be something obvious I'm missing here which makes the
> whole proposal useless.

I'm sure it'll work fine as an ad hoc way of managing a tuning table. But it's not going to replace the existing standard because the standard is already good enough.

Graham

--- In tuning@yahoogroups.com, Graham Breed <gbreed@...> wrote:
> They aren't unused -- they're undefined. Any given synth is
> free to use them however it likes.

Quite, thanks Graham.

>
> > The CC message already has the channel in the status byte,
> > So, the following would be controller numbers:
> >
> > CC20: 1011hhhh 00010100 0nnnnnnn
> > CC52: 1011hhhh 00110100 0ccccccc
> > CC21: 1011hhhh 00010101 0fffffff
> >
> > h = channel
> > n = note
> > c = tune coarse
> > f = tune fine
> >
> > The order in which these are sent would matter,
> > since the synth has o know which note is to be tuned.
>
> It looks like you're reinventing (N)RPNs.

CCs don't have RPN timing issues, do they?

> > This would then be folowed by a Note ON message.
> >
> > The CCs above could work for individual notes. A next
> > batch of CCs could work in the same way, but tune notes
> > already sounding. A next batch could work as octave
> > tuning messages. Thare are enough there to do several
> > different kinds of things.
>
> Then it duplicates the existing standard. Why have another
> way to do it?

I don't know. To have a way to do it that isn't a scary "system
exclusive" message?

> > CCs make a bit more sense to me than using the system
> > messages. The idea of Controlling the tuning makes sense.
>
> Given that system exclusive messages have been defined to do
> exactly the same job why not use them?

Yes, why not? Why aren't the sysex messages used?

1. they are "sysex" which initially is a bad place for them;
"system exclusive" status scares everyone away.
2. they are confusing; there are too many dedicated messages
which appear to duplicate the same functions in different
ways, so nobody can figure out how to implement them.

I think I understand why there are so many messages, but I don't
have the patience for them all, nor do most manufacturers. Choose
this message or that message? Support which one? Support them
all? It's frustrating.

Why does it all have to be so bleeding complicated? The functionality
needed is ridiculously simple: TUNE EVERY NOTE. So why are there
so many bloody sysex messages? It's like a tuning circus, with no ring
leader! Show this grab bag of stuff to one of the designers of the
first warehouse-sized RCA synthesizer and they'll ask you why on
earth it is so needlessly complicated.

I have this crazy idea that if a simple basic message set were offered,
it would get more implementation. (insert an audience laughing here)

> > A problem with using CCs as note messages might
> > seem at first to be that for every tuned note, there
> > would be 12 bytes, but considering that the tuning would
> > be independent of the note message, are are not many more
> > bytes than are sent using pitch bend, which works fine.
> > CCs are assumed to be channel messages, so using them as
> > note messages is unusual, but that's what we need.
>
> You're actually saving 3 or 4 bytes compared to the system
> exclusives. But you aren't able to address different tuning
> tables or specify all channels to change. In the worst case
> you'd lose another 3 bytes for true (N)RPNS but if you're
> doing a lot of tuning you can share the MSB. And retuning a
> dyad means sending 18 tuning bytes whereas the MTS Single
> Note Tuning Change (Real-Time) is actually quite capable of
> retuning multiple notes, and only requires 15 bytes for a
> dyad, with more efficiency the bigger the chord gets.
>
> Regardless of the message format, dynamic tuning tables are
> the most efficient way of sending the tuning data. Most of
> the time you won't need to retune every note every time it's
> played. So you only need to send the tuning messages when
> the tuning table actually changes. This is harder with
> pitch bends because you've got one per channel instead of
> one per note per channel.

The idea is simple: a dedicated source level pitch bend for
every note of + / - a quartertone, giving 196608 steps per octave
tuning. Tuning messages control note tuning independant of
channel pitch bending.

>
> > Actually this looks pretty good. Then again there may
> > be something obvious I'm missing here which makes the
> > whole proposal useless.
>
> I'm sure it'll work fine as an ad hoc way of managing a
> tuning table. But it's not going to replace the existing
> standard because the standard is already good enough.
>

I don't know, Graham. Maybe it is. Maybe we should just pack
up and go home. MTS has been out there for, what, 10 years?
It's old news. It's been picked up by the ones who care. The
others will never come around. Why bother?

I mean, if you want to do something with tuning, MIDI is not
the way to go! We've known that for a long time. Go program in
C-Sound or MSP, or Bidule or Supercollider. Heck, get yourself
a Commodore 64 and you've got 3 voices easy to program for
Just Intonation! Just write a few lines of BASIC; who cares about
MIDI! While you're at it, just forget hardware. Hardware is just
going to control software from now on, right?

So why is it that all the software is still supporting MIDI? And
why is it that CCs are supported and tuning sysexes aren't? Is
it really a matter of people not caring about tuning? The majority
rules? We're up against the 12ET establishment and all that? I'm
not sure...

Pitch Bend exists. People use it. In Eur-Asia MIDI Pitch Bend is used
for on-the-fly monophonic tuning. As early as 1983 microtonal
polyphony using Pitch Bend was experimented with. A lot of
software has been written to use it that way. You wrote one such
program, Graham. Why? I assume because you wanted a way to make
some microtonal music, and the blasted MIDI spec didn't make it so
easy, so you went and wrote your own program to hack around MIDI
and get the job done. And as you know, you're not the only one. And
you didn't do it using sysex.

Yours,
Aaron Hunt
H-Pi Instruments

--- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aahunt@...> wrote:
> CCs don't have RPN timing issues, do they?

Oh, I guess RPNs, being CCs, would mean the other CCs I'm
suggesting would probably have the same timing issues. Right.

Aaron Hunt
H-Pi Instruments

Hi Aaron and Graham,

Graham - the way I'm understanding this is - that the reason the system messages have to be non channel messages is because they use the lower two bits to distinguish between the different messages, so there is nowhere to put the channel number there. I'm not sure if it is actually a policy decision on their part, or just a pragmatic thing that there is nowhere to put the channel number. If it is a purely pragmatic thing, then utting a channel number into the data bytes is a possible solution - but is confusing however, and it is a kludge agreed.

Aaron - On the idea of the note off as a retune, another idea is to use a special RPN which switches on Note off retuning.

e.g.
coarse rpn 10 data 1 - changes note off to note tune

note off <note number> <tuning type> - selects note to retune, and type of tuning (note specific, 12tone accidental, polyphonic pitch bends, and any other type one might add to the spec)

note off <bend high> <bend low> - bends it

coarse rpn 127 - null the active parameter - note off reverts to its usual function
There - any other rpn would also switch off this "note off retuning" - so the note off counts as a note tune only for as long as 10 is the active coarse rpn.

Then repeat the process for each note you want to retune:
coarse rpn 10 data 1 - changes note off to note tune
note off <note number> <tuning type> - selects note to retune
note off <bend high> <bend low> - bends it
coarse rpn 127 - null the active parameter

etc so you expect a pair of note offs each time, first to select the note then to retune the selected note.

You could go on doing alternate pairs of note offs - receiving software would treat note offs as alternately selecting the note to retune and tuning type, then retuning it, until the active parameter is changed or nulled. But it would be good practice to null the active parameter after each pair of note off type note tunes for the usual reason that otherwise if a cable is unplugged before the rpn is nulled, then note off retuning would stay active from then on in the receiving synth.

On the sysexes, the tricky thing about them is that they are variable length, so there is a bit more coding involved. In the windows API then you have a separate set of function calls to send Sysexes, and also to prepare your program to receive them (you have to create a sysex buffer to receive the sysexes and have to prepare it using special Windows routines for that as well).

So - prob. because of the extra coding to detect and send them - some midi relaying software doesn't relay sysexes (e.g. the Maple virtual midi cable) and some software isn't programmed to send or receive them. For instance originally FTS couldn't send or receive any sysexes, and it was only a few years after the program was originally written that I added in that capability.

So using ordinary short messages for pitch bends instead of sysexes does simplify the coding all round, so I think it might lead to more take up for the retuning than for the tuning sysexes. In my case, I could have added that in at an early stage in FTS before adding the code for sysexes, so it is also kind of friendly to Midi programmers whose programs are at a fairly early stage of development.

On using portamento to achieve a bend by playing the note again without articulation - it's poss. but support for it is patchy, and it may require monomode to be on, if so then you only have one note playing in the channel.

Robert

Hi Aaron,

Yes I think so, BTW sysexes can be sent asynchronously in a separate data stream (perhaps to avoid large sysexes blocking the stream of short messages) so there is a concern about whether they will always be tied in serially with the stream of short messages which is another advantage of using short messages instead of the sysexes.

So if you send a midi tuning sysex immediately before the note to be retuned, you don't know for sure that it will be received in time - so it is best usually to retune it well in advance.

So the CCs are better in that respect - there the thing is the CCs will be received in strict serial order since they are always sent in the same data stream as the note ons, but the synth receiving them might re-order them or a midi file parser might re-order them - but that is fixable by recoding the midi file parser or synth if the author is enthusiastic about it, and in many cases they won't re-order them so then no recoding is needed.

Robert

................
Oh, I guess RPNs, being CCs, would mean the other CCs I'm
suggesting would probably have the same timing issues. Right.

Aaron Andrew Hunt wrote:

>>>This would then be folowed by a Note ON message.
>>>
>>>The CCs above could work for individual notes. A next
>>>batch of CCs could work in the same way, but tune notes >>>already sounding. A next batch could work as octave >>>tuning messages. Thare are enough there to do several >>>different kinds of things.
>>
>>Then it duplicates the existing standard. Why have another >>way to do it?
> > I don't know. To have a way to do it that isn't a scary "system > exclusive" message?

What's scary about them? They're a string of bytes like any other message.

>>>CCs make a bit more sense to me than using the system >>>messages. The idea of Controlling the tuning makes sense.
>>
>>Given that system exclusive messages have been defined to do >>exactly the same job why not use them?
> > Yes, why not? Why aren't the sysex messages used?

They are.

> 1. they are "sysex" which initially is a bad place for them;
> "system exclusive" status scares everyone away.

Nonsense. Tuning tables have traditionally been sent using sysexes. The standard was simply formalizing existing practice.

> 2. they are confusing; there are too many dedicated messages > which appear to duplicate the same functions in different > ways, so nobody can figure out how to implement them.

There are three -- count 'em -- three system exclusive messages defined in the MIDI Tuning Specification. And two RPNs.

> I think I understand why there are so many messages, but I don't > have the patience for them all, nor do most manufacturers. Choose
> this message or that message? Support which one? Support them > all? It's frustrating.

For your purposes, of the original messages, single note tuning change with a per-channel tuning table will be fine. How will adding more ways to do it make it easier to decide which to support?

> Why does it all have to be so bleeding complicated? The functionality > needed is ridiculously simple: TUNE EVERY NOTE. So why are there > so many bloody sysex messages? It's like a tuning circus, with no ring
> leader! Show this grab bag of stuff to one of the designers of the > first warehouse-sized RCA synthesizer and they'll ask you why on > earth it is so needlessly complicated.

There are so many messages (originally 3) because the functionality they wanted wasn't that simple. It was geared to hardware synthesizers with static tuning tables, not smart keyboards generating tuning data. If that's what you want, you only need one message -- the single note tuning change.

I think the reason for there being so many messages, as well as the general behavior of committees, is:

Bulk Tuning Dump Request -- because you may want to save the tunings to a sequencer or librarian application.

Bulk Tuning Dump -- to make it efficient to send a whole tuning table.

Single Note Tuning Change -- to allow the tunings to change in real time, this being the one you want, and the most innovative at the time (hence most likely to be left out).

Tuning Program Select RPN -- because hardware synths that support tuning tables always have more than one, and it's useful to have a standard way of switching between them remotely, even if the numbers mean nothing in general.

Tuning Bank Select RPN -- committee bloat. Somebody thought they wanted this.

That covers the original MTS specification (1996?). The MIDI Tuning Bank and Dump Extensions were later (1999?) added:

Bulk Tuning Dump Request (Bank) -- whoever wanted tuning banks noticed they couldn't do much with them.

Key-Based Tuning Dump -- ditto

Single Note Tuning Change (Real-Time) (Bank) -- ditto

Single Note Tuning Change (Non Real-Time) (Bank) -- so that you can be sure currently sounding notes won't be affected. You suggested this approach with your CCs.

Scale/Octave Tuning Dump, 1 byte format -- manufacturers insist on 12 note tuning tables, so they think this will be useful.

Scale/Octave Tuning Dump, 2 byte format -- ditto

I don't think any of these supplemental messages add anything I'd want. Non-real time messages may seem enticing but the real-time ones (with suitable behaviour) are more resilient to being sent out of order with the notes.

> I have this crazy idea that if a simple basic message set were offered, > it would get more implementation. (insert an audience laughing here)

What's complicated about the existing messages?

>>Regardless of the message format, dynamic tuning tables are >>the most efficient way of sending the tuning data. Most of >>the time you won't need to retune every note every time it's >>played. So you only need to send the tuning messages when >>the tuning table actually changes. This is harder with >>pitch bends because you've got one per channel instead of >>one per note per channel.
> > The idea is simple: a dedicated source level pitch bend for > every note of + / - a quartertone, giving 196608 steps per octave > tuning. Tuning messages control note tuning independant of > channel pitch bending. A 128 note tuning table with full, dynamic tuning is also pretty simple. And it allows for small intervals to be played on the same channel even if different streams get mixed together.

>>>Actually this looks pretty good. Then again there may
>>>be something obvious I'm missing here which makes the
>>>whole proposal useless.
>>
>>I'm sure it'll work fine as an ad hoc way of managing a >>tuning table. But it's not going to replace the existing >>standard because the standard is already good enough.
> > I don't know, Graham. Maybe it is. Maybe we should just pack > up and go home. MTS has been out there for, what, 10 years?
> It's old news. It's been picked up by the ones who care. The > others will never come around. Why bother?

Why bother doing what?

> I mean, if you want to do something with tuning, MIDI is not > the way to go! We've known that for a long time. Go program in > C-Sound or MSP, or Bidule or Supercollider. Heck, get yourself > a Commodore 64 and you've got 3 voices easy to program for > Just Intonation! Just write a few lines of BASIC; who cares about > MIDI! While you're at it, just forget hardware. Hardware is just > going to control software from now on, right?

Well, yes, I use Csound these days.

Software controls hardware. No change there.

> So why is it that all the software is still supporting MIDI? And > why is it that CCs are supported and tuning sysexes aren't? Is
> it really a matter of people not caring about tuning? The majority > rules? We're up against the 12ET establishment and all that? I'm
> not sure...

The software supports MIDI because it's the standard, and always backwards compatible. Hence any proposal that breaks backwards compatibility is dead in the water. CCs are supported because everybody needs them. Tuning sysexes aren't supported because blue pixies took them away -- which is to say they are supported.

> Pitch Bend exists. People use it. In Eur-Asia MIDI Pitch Bend is used > for on-the-fly monophonic tuning. As early as 1983 microtonal
> polyphony using Pitch Bend was experimented with. A lot of > software has been written to use it that way. You wrote one such > program, Graham. Why? I assume because you wanted a way to make
> some microtonal music, and the blasted MIDI spec didn't make it so > easy, so you went and wrote your own program to hack around MIDI
> and get the job done. And as you know, you're not the only one. And
> you didn't do it using sysex.

I wrote a program to use MIDI pitch bend tuning because I wanted to play with microtonality and the MIDI spec made it easy. Nobody told me about Csound back then. Later on I made some money and could afford hardware synthesizers with tuning tables. That's a much better way of doing it. Supporting MTS isn't that important for making your own music.

Graham

Robert walker wrote:
> Hi Aaron and Graham,
> > Graham - the way I'm understanding this is - that the
> reason the system messages have to be non channel
> messages is because they use the lower two bits to
> distinguish between the different messages, so there
> is nowhere to put the channel number there. I'm not
> sure if it is actually a policy decision on their
> part, or just a pragmatic thing that there is nowhere
> to put the channel number. If it is a purely pragmatic
> thing, then utting a channel number into the data bytes
> is a possible solution - but is confusing however, and
> it is a kludge agreed.

It's based on a simple rule: F starts a global message, anything else (with parity bit set) starts a channel-specific message. As simplicity's good, it's nice to keep it that way. Although, of course, system exclusive messages using the channel number as a device ID already break the rule. Such is the imperfect world we live in.

> Aaron - On the idea of the note off as a retune, another
> idea is to use a special RPN which switches on Note off
> retuning.
> > e.g.
> coarse rpn 10 data 1 - changes note off to note tune

Great! Then you can be sure nobody would ever support it.

> On the sysexes, the tricky thing about them is that they
> are variable length, so there is a bit more coding
> involved. In the windows API then you have a separate set
> of function calls to send Sysexes, and also to prepare
> your program to receive them (you have to create a sysex
> buffer to receive the sysexes and have to prepare it using
> special Windows routines for that as well). That's a particular problem with Windows. Fortunately it's better documented now than when I was hacking with it.

> So - prob. because of the extra coding to detect and send
> them - some midi relaying software doesn't relay sysexes > (e.g. the Maple virtual midi cable) and some software isn't
> programmed to send or receive them. For instance originally
> FTS couldn't send or receive any sysexes, and it was only a
> few years after the program was originally written that I
> added in that capability.

Yes, that's a problem.

> On using portamento to achieve a bend by playing the note
> again without articulation - it's poss. but support for it
> is patchy, and it may require monomode to be on, if so then
> you only have one note playing in the channel.

Portamento does work in poly mode if it's supported.

Graham

--- In tuning@yahoogroups.com, Graham Breed <gbreed@...> wrote:
> What's scary about them? They're a string of bytes like any
> other message.

Graham, like both you and Robert have said, sysex are not simple
MIDI messages. They require more coding, and there are also possible
problems with timing. Also, and this is the thing I have been arguing,
there is a very basic problem that the simple categorical definition
of sysex as a "system exclusive" message set makes them all sound
like manufacturer specific options which do not need to be supported
universally.

A bunch of sysexes in an otherwise normal data stream is just weird
and ugly and scary. Someone looks at a MIDI stream not hearing
the file: (What are all those sysexes doing there? Those are for
specific hardware... Hmm, OK the header says all hardware...
what's this other number? ... let me find my MIDI spec... Ah, Tuning!
What does this message do? ... Um, er, let me check this list... not
there... let me check this other list... not there... OK, there it is....
Oh, good grief, that's ugly!) Make tuning messages basic messages
and all that scariness is avoided for the better. (What's this CC...
let me check the CC list... Note Tuning. OK, that's different, but
at least it didn't take me 20 minutes to figure out what the *&% it was.)

Easy human readable also = easy machine readable in this case;
easier to code, easier to work with all around.

> >>>CCs make a bit more sense to me than using the system
> >>>messages. The idea of Controlling the tuning makes sense.
> >>
> >>Given that system exclusive messages have been defined to do
> >>exactly the same job why not use them?
> >
> > Yes, why not? Why aren't the sysex messages used?
>
> They are.

Then I must be living in a parallel universe. They aren't used in the
mainstream.

> > 1. they are "sysex" which initially is a bad place for them;
> > "system exclusive" status scares everyone away.
>
> Nonsense. Tuning tables have traditionally been sent using
> sysexes. The standard was simply formalizing existing practice.

Not nonsense. Exactly the problem! See argument above.

> > 2. they are confusing; there are too many dedicated messages
> > which appear to duplicate the same functions in different
> > ways, so nobody can figure out how to implement them.
>
> There are three -- count 'em -- three system exclusive
> messages defined in the MIDI Tuning Specification. And two
> RPNs.

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11. I count eleven.

> > I think I understand why there are so many messages, but I don't
> > have the patience for them all, nor do most manufacturers. Choose
> > this message or that message? Support which one? Support them
> > all? It's frustrating.
>
> For your purposes, of the original messages, single note
> tuning change with a per-channel tuning table will be fine.
> How will adding more ways to do it make it easier to
> decide which to support?

Same as above. Because the new ways are simple messages, not sysex.

> > Why does it all have to be so bleeding complicated? The functionality
> > needed is ridiculously simple: TUNE EVERY NOTE. So why are there
> > so many bloody sysex messages? It's like a tuning circus, with no ring
> > leader! Show this grab bag of stuff to one of the designers of the
> > first warehouse-sized RCA synthesizer and they'll ask you why on
> > earth it is so needlessly complicated.
>
> There are so many messages (originally 3) because the
> functionality they wanted wasn't that simple. It was geared
> to hardware synthesizers with static tuning tables, not
> smart keyboards generating tuning data. If that's what you
> want, you only need one message -- the single note tuning
> change.

OK, agreed. So a needed thing would be a PDF and ASCII and HTML
white paper all about this message, why it needs to be supported
everywhere, and exactly how to support it. A campaign for one
message, sent to every major music company on the planet, to all
the developers as well as company executives. Glossy flyers. Websites.
Maybe even lobbys in congresses, parliaments, etc. I'm joking, but
not joking. Somehow we need to get everyone to recognize one
simple way of doing this and make it the standard.

> I think the reason for there being so many messages, as well
> as the general behavior of committees, is:
>
> Bulk Tuning Dump Request -- because you may want to save the
> tunings to a sequencer or librarian application.
>
> Bulk Tuning Dump -- to make it efficient to send a whole
> tuning table.
>
> Single Note Tuning Change -- to allow the tunings to change
> in real time, this being the one you want, and the most
> innovative at the time (hence most likely to be left out).
>
> Tuning Program Select RPN -- because hardware synths that
> support tuning tables always have more than one, and it's
> useful to have a standard way of switching between them
> remotely, even if the numbers mean nothing in general.
>
> Tuning Bank Select RPN -- committee bloat. Somebody thought
> they wanted this.
>
> That covers the original MTS specification (1996?). The
> MIDI Tuning Bank and Dump Extensions were later (1999?) added:
>
> Bulk Tuning Dump Request (Bank) -- whoever wanted tuning
> banks noticed they couldn't do much with them.
>
> Key-Based Tuning Dump -- ditto
>
> Single Note Tuning Change (Real-Time) (Bank) -- ditto
>
> Single Note Tuning Change (Non Real-Time) (Bank) -- so that
> you can be sure currently sounding notes won't be affected.
> You suggested this approach with your CCs.
>
> Scale/Octave Tuning Dump, 1 byte format -- manufacturers
> insist on 12 note tuning tables, so they think this will be
> useful.
>
> Scale/Octave Tuning Dump, 2 byte format -- ditto
>
> I don't think any of these supplemental messages add
> anything I'd want. Non-real time messages may seem enticing
> but the real-time ones (with suitable behaviour) are more
> resilient to being sent out of order with the notes.

Yes.

> > I have this crazy idea that if a simple basic message set were offered,
> > it would get more implementation. (insert an audience laughing here)
>
> What's complicated about the existing messages?

I've given my answer for that many times now.

> >>Regardless of the message format, dynamic tuning tables are
> >>the most efficient way of sending the tuning data. Most of
> >>the time you won't need to retune every note every time it's
> >>played. So you only need to send the tuning messages when
> >>the tuning table actually changes. This is harder with
> >>pitch bends because you've got one per channel instead of
> >>one per note per channel.
> >
> > The idea is simple: a dedicated source level pitch bend for
> > every note of + / - a quartertone, giving 196608 steps per octave
> > tuning. Tuning messages control note tuning independant of
> > channel pitch bending.
>
> A 128 note tuning table with full, dynamic tuning is also
> pretty simple. And it allows for small intervals to be
> played on the same channel even if different streams get
> mixed together.

OK. If the thing needed is a table, then this can be a sysex
dump of 3 bytes per note;

[sysex header]
<table number>
...
0nnnnnnn 0ccccccc 0fffffff (128 times)
...
[sysex stop]

n = note
c = coarse tuning
f = fine tuning

Which is exactly the format used in H-Pi stuff.
This kind of table makes much more sense than
a frequency table. A frequency table requires too much of the
hardware. Leave frequency conversion for the software that
makes the tables. Hardware have global frequency settings
and there are other MIDI messages to set frequency tunings
for global system tuning and channel tuning, and the format
is different from the MTS table format, so the frequencies in
the MTS table are very confusing and in basic conflict with the
MIDI spec. The format should be MIDI friendly and use MIDI
logic, as shown above.

Thereafter the tuning should be done with simple messages
looked up from the table, and the new message set retunes
notes independently at the source level. Everything
can be done using this, keeping sysex as simple as possible
and keeping it to a minimum, only for tables, where large
amounts of data are required.

Every MIDI device and MIDI compatible software should have
at least 512 table arrays standard. Simple messages can be sent
to choose the tables for each channel, and tune all the notes.
The tuning messages are still needed because standard source
arrays are never going to be in anything but 12 tone ET, and
putting the tuning directives in the message stream means that
the data will reproduce correctly on other devices that do not
have the tuning table which generated the file in memory.

This idea is basically a built in TBX1 for every device, the only
difference being that the retuning is not limited to 16 voices
polyphony and does not use dynamic channel allocation.

> >>>Actually this looks pretty good. Then again there may
> >>>be something obvious I'm missing here which makes the
> >>>whole proposal useless.
> >>
> >>I'm sure it'll work fine as an ad hoc way of managing a
> >>tuning table. But it's not going to replace the existing
> >>standard because the standard is already good enough.
> >
> > I don't know, Graham. Maybe it is. Maybe we should just pack
> > up and go home. MTS has been out there for, what, 10 years?
> > It's old news. It's been picked up by the ones who care. The
> > others will never come around. Why bother?
>
> Why bother doing what?
>
> > I mean, if you want to do something with tuning, MIDI is not
> > the way to go! We've known that for a long time. Go program in
> > C-Sound or MSP, or Bidule or Supercollider. Heck, get yourself
> > a Commodore 64 and you've got 3 voices easy to program for
> > Just Intonation! Just write a few lines of BASIC; who cares about
> > MIDI! While you're at it, just forget hardware. Hardware is just
> > going to control software from now on, right?
>
> Well, yes, I use Csound these days.
>
> Software controls hardware. No change there.
>

Touché, I meant hardware keyboards are controlling software
synthesizers, so forget about hardware synthesizers. <- (a lot
of people say this but they forget that dedicated hardware has
tremendous ease-of-use advantages and is not going to go
away.)

> > So why is it that all the software is still supporting MIDI? And
> > why is it that CCs are supported and tuning sysexes aren't? Is
> > it really a matter of people not caring about tuning? The majority
> > rules? We're up against the 12ET establishment and all that? I'm
> > not sure...
>
> The software supports MIDI because it's the standard, and
> always backwards compatible. Hence any proposal that breaks
> backwards compatibility is dead in the water. CCs are
> supported because everybody needs them. Tuning sysexes
> aren't supported because blue pixies took them away -- which
> is to say they are supported.

I don't follow. The blue pixies did take them away and they hid
them somewhere, which is to say they are supported here and there
if you don't mind going putting on your boots and going on a long
scavenger hunt to find them.

> > Pitch Bend exists. People use it. In Eur-Asia MIDI Pitch Bend is used
> > for on-the-fly monophonic tuning. As early as 1983 microtonal
> > polyphony using Pitch Bend was experimented with. A lot of
> > software has been written to use it that way. You wrote one such
> > program, Graham. Why? I assume because you wanted a way to make
> > some microtonal music, and the blasted MIDI spec didn't make it so
> > easy, so you went and wrote your own program to hack around MIDI
> > and get the job done. And as you know, you're not the only one. And
> > you didn't do it using sysex.
>
> I wrote a program to use MIDI pitch bend tuning because I
> wanted to play with microtonality and the MIDI spec made it
> easy. Nobody told me about Csound back then. Later on I
> made some money and could afford hardware synthesizers with
> tuning tables. That's a much better way of doing it.
> Supporting MTS isn't that important for making your own music.
>

Right. If you don't have $1300 lying around to buy a microtonal
capable synth, just use pitch bends and get the job done, and if you
aren't a programmer or you just don't want to spend forever in a year
to get any results, you can spend a few hundred dollars and use a
cheap synth and TBX1 to do it all for you and make life much easier.

Yours,
Aaron Hunt
H-Pi Instruments

--- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aahunt@...> wrote:

> The idea is simple: a dedicated source level pitch bend for
> every note of + / - a quartertone, giving 196608 steps per octave
> tuning. Tuning messages control note tuning independant of
> channel pitch bending.

And it's a good idea. I'm told I should be happy
with the "flexibility" of midi, where midi notes
don't actually mean anything tuning-wise. I'm not.
I think any system which does not support note-by-note
tuning of individual notes sucks badly.

--- In tuning@yahoogroups.com, Graham Breed <gbreed@...> wrote:

> A 128 note tuning table with full, dynamic tuning is also
> pretty simple. And it allows for small intervals to be
> played on the same channel even if different streams get
> mixed together.

Any system which does not allow the tuning of rach
individual note to be easily determoined by looking
at information only about that note is a bad system.

> The software supports MIDI because it's the standard, and
> always backwards compatible.

So we cannot create a new standard just for ourselves
because we'll be ignored. But we are ignored anyway.

> Hence any proposal that breaks
> backwards compatibility is dead in the water.

So midi is eternal? In the year 2200 we will still
be using it and only it, because it is carved in
stone?

> I wrote a program to use MIDI pitch bend tuning because I
> wanted to play with microtonality and the MIDI spec made it
> easy. Nobody told me about Csound back then. Later on I
> made some money and could afford hardware synthesizers with
> tuning tables. That's a much better way of doing it.

Tuning tables are a rotten way of doing it if you
work like me. But I guess a system flexible enough
for everyone doesn't matter.

BTW, if tuning tables are so great, and Csound is
so great, why doesn't Csound using tuning tables?

--- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aahunt@...> wrote:

> Easy human readable also = easy machine readable in this case;
> easier to code, easier to work with all around.

Also it means easy to recover the tuning data *from*.
Why is recovering the 128 midi notes so damned easy,
and everything else so damned hard? Because the 128
midi notes use a system which makes sense.

Gene, Graham, et al. Remember the transition from PCI to AGP? Or the
development of USB? Jump from CD to DVD? Looks like we need dual support for
both MIDI and the "new microtonal sound port" implemented for the time
being, but it would replace MIDI in the end.

Oz.

SNIP

> > Hence any proposal that breaks
> > backwards compatibility is dead in the water.
>
> So midi is eternal? In the year 2200 we will still
> be using it and only it, because it is carved in
> stone?

SNIP

--- In tuning@yahoogroups.com, "Gene Ward Smith" <genewardsmith@...> wrote:
>
> --- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aahunt@> wrote:
>
> > Easy human readable also = easy machine readable in this case;
> > easier to code, easier to work with all around.
>
> Also it means easy to recover the tuning data *from*.
> Why is recovering the 128 midi notes so damned easy,
> and everything else so damned hard? Because the 128
> midi notes use a system which makes sense.
>

Exactly. The tuning data needs to accompany every note. Otherwise
it's just like looking at a scordatra score without a clue as to the actual
pitches that will sound. Tune every note, and make every pitch plain as
day. If a tuning table is used, fine, but put the tuning data in the data
stream the same as if the table was not being used. A tuning table
should never be needed to proplerly reproduce a MIDI file.

Aaron Hunt
H-Pi Instruments

Aaron Andrew Hunt wrote:
> --- In tuning@yahoogroups.com, Graham Breed <gbreed@...> wrote:
>>> This would then be folowed by a Note ON message.
>>>
>>> The CCs above could work for individual notes. A next
>>> batch of CCs could work in the same way, but tune notes >>> already sounding. A next batch could work as octave >>> tuning messages. Thare are enough there to do several >>> different kinds of things.
>> Then it duplicates the existing standard. Why have another >> way to do it?
> > > > I don't know. To have a way to do it that isn't a scary "system > exclusive" message?

It's not so much that system exclusive messages are "scary", but that certain MIDI editors refuse to let you edit them (or otherwise make them unnecessarily difficult to edit). There could also be other kinds of software issues with them (e.g. I haven't been able to retune my DX7II from my Windows XP system, which used to work just fine with my old Windows 95 system).

> Why does it all have to be so bleeding complicated? The functionality > needed is ridiculously simple: TUNE EVERY NOTE. So why are there > so many bloody sysex messages? It's like a tuning circus, with no ring
> leader! Show this grab bag of stuff to one of the designers of the > first warehouse-sized RCA synthesizer and they'll ask you why on > earth it is so needlessly complicated.
> > I have this crazy idea that if a simple basic message set were offered, > it would get more implementation. (insert an audience laughing here)

I'm not familiar with the existing standard, but even before the tuning standard there were parts of the MIDI standard that often went unimplemented (e.g. polyphonic aftertouch, Note Off velocity). Would it be possible to support just a part of the tuning standard, enough to be minimally usable, without needing to support the whole thing? Assuming that publishers of MIDI editing software could be persuaded to actually provide an interface for editing the tuning tables?

Aaron Andrew Hunt wrote:
> --- In tuning@yahoogroups.com, Graham Breed <gbreed@...> wrote:
> >>What's scary about them? They're a string of bytes like any >>other message.
> > Graham, like both you and Robert have said, sysex are not simple
> MIDI messages. They require more coding, and there are also possible
> problems with timing. Also, and this is the thing I have been arguing,
> there is a very basic problem that the simple categorical definition > of sysex as a "system exclusive" message set makes them all sound > like manufacturer specific options which do not need to be supported > universally. If you really care about the single note retuning messages, you can special-case them in your MIDI parser and treat them as simple messages. Then they're no harder to deal with than anything else you propose. Unless you have to squeeze everything into 32 bits in which case some precision will have to go.

If somebody wants to implement tuning in a standard way it shouldn't take long to find out how. If they don't, at least they'll know how to ignore sysexes. This is nowhere near as difficult as implementing a synthesizer, sequencer, or whatever.

> A bunch of sysexes in an otherwise normal data stream is just weird > and ugly and scary. Someone looks at a MIDI stream not hearing
> the file: (What are all those sysexes doing there? Those are for > specific hardware... Hmm, OK the header says all hardware... > what's this other number? ... let me find my MIDI spec... Ah, Tuning!
> What does this message do? ... Um, er, let me check this list... not > there... let me check this other list... not there... OK, there it is.... > Oh, good grief, that's ugly!) Make tuning messages basic messages > and all that scariness is avoided for the better. (What's this CC... > let me check the CC list... Note Tuning. OK, that's different, but > at least it didn't take me 20 minutes to figure out what the *&% it was.)

No. What you're talking about is voodoo. Make tuning messages basic messages and they won't be in the reference our "someone" uses because it'll most likely be out of date. They won't make any sense at all. Looking up an RPN is no easier than looking up a sysex. The MIDI Tuning Specification does use RPNs anyway so they would give the clue.

> Easy human readable also = easy machine readable in this case;
> easier to code, easier to work with all around.

MIDI file aren't human readable. Just give up on that one. If you want a human readable file format, work one out from scratch, and write a program to convert it to MIDI files.

I don't see why a machine cares if its simple message is a special case to the standard or implemented as a system exclusive. They all have to be able to parse system exclusives.

>>>>>CCs make a bit more sense to me than using the system >>>>>messages. The idea of Controlling the tuning makes sense.
>>>>
>>>>Given that system exclusive messages have been defined to do >>>>exactly the same job why not use them?
>>>
>>>Yes, why not? Why aren't the sysex messages used?
>>
>>They are.
> > Then I must be living in a parallel universe. They aren't used in the
> mainstream.

They are used.

>>>1. they are "sysex" which initially is a bad place for them;
>>> "system exclusive" status scares everyone away.
>>
>>Nonsense. Tuning tables have traditionally been sent using >>sysexes. The standard was simply formalizing existing practice.
> > Not nonsense. Exactly the problem! See argument above.

Then define a new simple message but make it look exactly like the existing single note retune message and hope nobody gets scared.

>>>2. they are confusing; there are too many dedicated messages >>> which appear to duplicate the same functions in different >>> ways, so nobody can figure out how to implement them.
>>
>>There are three -- count 'em -- three system exclusive >>messages defined in the MIDI Tuning Specification. And two >>RPNs.
> > 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11. I count eleven.

I count three. Here's my reference:

http://www.midi.org/about-midi/tuning.shtml

Let's see yours.

>>>I think I understand why there are so many messages, but I don't >>>have the patience for them all, nor do most manufacturers. Choose
>>>this message or that message? Support which one? Support them >>>all? It's frustrating.
>>
>>For your purposes, of the original messages, single note >>tuning change with a per-channel tuning table will be fine. >> How will adding more ways to do it make it easier to >>decide which to support?
> > Same as above. Because the new ways are simple messages, not sysex.

Redefine "simple message" then. It's easier to change the language than the substance.

> OK, agreed. So a needed thing would be a PDF and ASCII and HTML > white paper all about this message, why it needs to be supported > everywhere, and exactly how to support it. A campaign for one > message, sent to every major music company on the planet, to all > the developers as well as company executives. Glossy flyers. Websites. > Maybe even lobbys in congresses, parliaments, etc. I'm joking, but
> not joking. Somehow we need to get everyone to recognize one > simple way of doing this and make it the standard. There is a community-agreed wish list. It should be here:

http://www.microtonal-synthesis.com/synthhelp.html

but I can't reach it today. It's been very helpful in getting soft synths supporting microtonality. Unfortunately we haven't made any progress with hardware manufacturers. If you want to revise it in the light of these discussions we can talk about that.

>>>I have this crazy idea that if a simple basic message set were offered, >>>it would get more implementation. (insert an audience laughing here)
>>
>>What's complicated about the existing messages?
> > I've given my answer for that many times now.

No you haven't. Which of the 12 bytes you have to send to retune a note is an impracticable complication?

> OK. If the thing needed is a table, then this can be a sysex > dump of 3 bytes per note;
> > [sysex header]
> <table number>
> ...
> 0nnnnnnn 0ccccccc 0fffffff (128 times)
> ...
> [sysex stop]
> > n = note
> c = coarse tuning
> f = fine tuning
> > Which is exactly the format used in H-Pi stuff. > This kind of table makes much more sense than
> a frequency table. A frequency table requires too much of the
> hardware. Leave frequency conversion for the software that
> makes the tables. Hardware have global frequency settings
> and there are other MIDI messages to set frequency tunings
> for global system tuning and channel tuning, and the format
> is different from the MTS table format, so the frequencies in > the MTS table are very confusing and in basic conflict with the > MIDI spec. The format should be MIDI friendly and use MIDI > logic, as shown above.

How is it different to the MTS table format? Because you call it 0nnnnnnn 0ccccccc 0fffffff instead of [xx yy zz] and there's no checksum? Was that the problem all this time?

> Thereafter the tuning should be done with simple messages > looked up from the table, and the new message set retunes > notes independently at the source level. Everything
> can be done using this, keeping sysex as simple as possible
> and keeping it to a minimum, only for tables, where large > amounts of data are required. > > Every MIDI device and MIDI compatible software should have
> at least 512 table arrays standard. Simple messages can be sent > to choose the tables for each channel, and tune all the notes.
> The tuning messages are still needed because standard source
> arrays are never going to be in anything but 12 tone ET, and > putting the tuning directives in the message stream means that
> the data will reproduce correctly on other devices that do not
> have the tuning table which generated the file in memory.

512??? That's 512*128*3=196,608 bytes just to hold the tuning tables. Hardware manufacturers are not going to accept that. The MTS page already complains about 8k.

I don't get the bit about 12 tone Et. Obviously microtonal data won't reproduce correctly on synths that don't support the relevant messages.

> This idea is basically a built in TBX1 for every device, the only > difference being that the retuning is not limited to 16 voices
> polyphony and does not use dynamic channel allocation.

The idea is basically MTS in new clothes.

> Touch�, I meant hardware keyboards are controlling software
> synthesizers, so forget about hardware synthesizers. <- (a lot
> of people say this but they forget that dedicated hardware has
> tremendous ease-of-use advantages and is not going to go > away.)

We don't forget that. We know that the hardware doesn't support what we want. If you want to use the MIDI tuning standard you'll find it's easier to give up the advantages of hardware synthesizers and get your work done in software.

>>>So why is it that all the software is still supporting MIDI? And >>>why is it that CCs are supported and tuning sysexes aren't? Is
>>>it really a matter of people not caring about tuning? The majority >>>rules? We're up against the 12ET establishment and all that? I'm
>>>not sure...
>>
>>The software supports MIDI because it's the standard, and >>always backwards compatible. Hence any proposal that breaks >>backwards compatibility is dead in the water. CCs are >>supported because everybody needs them. Tuning sysexes >>aren't supported because blue pixies took them away -- which >>is to say they are supported.
> > I don't follow. The blue pixies did take them away and they hid
> them somewhere, which is to say they are supported here and there
> if you don't mind going putting on your boots and going on a long > scavenger hunt to find them.

Tuning sysexes are supported, so any argument based on them not being supported is valid regardless of the conclusion.

>>>Pitch Bend exists. People use it. In Eur-Asia MIDI Pitch Bend is used >>>for on-the-fly monophonic tuning. As early as 1983 microtonal
>>>polyphony using Pitch Bend was experimented with. A lot of >>>software has been written to use it that way. You wrote one such >>>program, Graham. Why? I assume because you wanted a way to make
>>>some microtonal music, and the blasted MIDI spec didn't make it so >>>easy, so you went and wrote your own program to hack around MIDI
>>>and get the job done. And as you know, you're not the only one. And
>>>you didn't do it using sysex.
>>
>>I wrote a program to use MIDI pitch bend tuning because I >>wanted to play with microtonality and the MIDI spec made it >>easy. Nobody told me about Csound back then. Later on I >>made some money and could afford hardware synthesizers with >>tuning tables. That's a much better way of doing it. >>Supporting MTS isn't that important for making your own music.
> > Right. If you don't have $1300 lying around to buy a microtonal > capable synth, just use pitch bends and get the job done, and if you
> aren't a programmer or you just don't want to spend forever in a year
> to get any results, you can spend a few hundred dollars and use a
> cheap synth and TBX1 to do it all for you and make life much easier.

My TX81Z didn't cost $1300. More like $130. But yes, when I started working with pitch bends I didn't have that kind of money. It's much easier for kids today because they can use Scala. If enough people care about any of this you'll see the hardware support arriving.

Graham

Gene Ward Smith wrote:
> --- In tuning@yahoogroups.com, Graham Breed <gbreed@...> wrote:
> >>A 128 note tuning table with full, dynamic tuning is also >>pretty simple. And it allows for small intervals to be >>played on the same channel even if different streams get >>mixed together.
> > Any system which does not allow the tuning of rach > individual note to be easily determoined by looking
> at information only about that note is a bad system.

Then forget about MIDI because it's a binary standard.

>>The software supports MIDI because it's the standard, and >>always backwards compatible. > > So we cannot create a new standard just for ourselves
> because we'll be ignored. But we are ignored anyway.

No, we can't make backwards-incompatible changes to MIDI and expect to keep the advantages of supporting MIDI.

>>Hence any proposal that breaks >>backwards compatibility is dead in the water. > > So midi is eternal? In the year 2200 we will still > be using it and only it, because it is carved in
> stone?

Don't break up my paragraphs.

>>I wrote a program to use MIDI pitch bend tuning because I >>wanted to play with microtonality and the MIDI spec made it >>easy. Nobody told me about Csound back then. Later on I >>made some money and could afford hardware synthesizers with >>tuning tables. That's a much better way of doing it.
> > Tuning tables are a rotten way of doing it if you
> work like me. But I guess a system flexible enough
> for everyone doesn't matter.

What is it that you want to do that can't be supported by the MIDI Tuning Specification?

> BTW, if tuning tables are so great, and Csound is
> so great, why doesn't Csound using tuning tables?

Blue pixies again: Csound does use tuning tables. Partly for MIDI compatibility. Everything I've seen for microtonality in Csound talks about tuning tables.

Graham

Ozan Yarman wrote:
> Gene, Graham, et al. Remember the transition from PCI to AGP? Or the
> development of USB? Jump from CD to DVD? Looks like we need dual support for
> both MIDI and the "new microtonal sound port" implemented for the time
> being, but it would replace MIDI in the end.

Because everybody else will keep using MIDI as it always was. Best to do what we want within the standard (or really do our own thing, in Csound, OSC, or whatever).

Graham

Herman Miller wrote:
> Aaron Andrew Hunt wrote:
> >>--- In tuning@yahoogroups.com, Graham Breed <gbreed@...> wrote:
>>
>>>>This would then be folowed by a Note ON message.
>>>>
>>>>The CCs above could work for individual notes. A next
>>>>batch of CCs could work in the same way, but tune notes >>>>already sounding. A next batch could work as octave >>>>tuning messages. Thare are enough there to do several >>>>different kinds of things.
>>>
>>>Then it duplicates the existing standard. Why have another >>>way to do it?
>>
>>I don't know. To have a way to do it that isn't a scary "system >>exclusive" message?
> > It's not so much that system exclusive messages are "scary", but that > certain MIDI editors refuse to let you edit them (or otherwise make them > unnecessarily difficult to edit). There could also be other kinds of > software issues with them (e.g. I haven't been able to retune my DX7II > from my Windows XP system, which used to work just fine with my old > Windows 95 system).

Any software without microtonal support will be a pain for microtonal music. (N)RPNS broke in my old sequencer (either Cakewalk or Cubasis) because the CCs got reordered. The cleanest solution is a fixed 128 note tuning table where you can live with that.

I don't mean to pour cold water on NRPNs. They do make sense for retuning and if you want to implement a sequencer/synth combination you may find them useful. But don't expect them to be standardized.

Graham

But who is going to support those?

----- Original Message -----
From: "Graham Breed" <gbreed@gmail.com>
To: <tuning@yahoogroups.com>
Sent: 09 Nisan 2007 Pazartesi 5:05
Subject: Re: [tuning] Re: Change Note OFF to Note TUNE

> Ozan Yarman wrote:
> > Gene, Graham, et al. Remember the transition from PCI to AGP? Or the
> > development of USB? Jump from CD to DVD? Looks like we need dual support
for
> > both MIDI and the "new microtonal sound port" implemented for the time
> > being, but it would replace MIDI in the end.
>
> Because everybody else will keep using MIDI as it always
> was. Best to do what we want within the standard (or really
> do our own thing, in Csound, OSC, or whatever).
>
>
> Graham
>

--- In tuning@yahoogroups.com, Graham Breed <gbreed@...> wrote:
> No. What you're talking about is voodoo. Make tuning
> messages basic messages and they won't be in the reference
> our "someone" uses because it'll most likely be out of date.
> They won't make any sense at all. Looking up an RPN is no
> easier than looking up a sysex. The MIDI Tuning
> Specification does use RPNs anyway so they would give the clue.

OK, the RPNs would explain what's going on. And anyone reading
a file is probably using something like MIDIOX which comments all the
messages anyway.

> > Easy human readable also = easy machine readable in this case;
> > easier to code, easier to work with all around.
>
> MIDI file aren't human readable. Just give up on that one.
> If you want a human readable file format, work one out
> from scratch, and write a program to convert it to MIDI files.

OK, a lot of people have done that. The MAX/MSP text to MIDI
system is probably the simplest example I've used.

> I don't see why a machine cares if its simple message is a
> special case to the standard or implemented as a system
> exclusive. They all have to be able to parse system exclusives.

It does care because it has to have a buffer for Sysex, right?

> > Then I must be living in a parallel universe. They aren't used in the
> > mainstream.
>
> They are used.

OK, Graham. I give up. You win. They are used. So why are we having
this discussion?

>
> >>>1. they are "sysex" which initially is a bad place for them;
> >>> "system exclusive" status scares everyone away.
> >>
> >>Nonsense. Tuning tables have traditionally been sent using
> >>sysexes. The standard was simply formalizing existing practice.
> >
> > Not nonsense. Exactly the problem! See argument above.
>
> Then define a new simple message but make it look exactly
> like the existing single note retune message and hope nobody
> gets scared.
>

haha :)

> >>>2. they are confusing; there are too many dedicated messages
> >>> which appear to duplicate the same functions in different
> >>> ways, so nobody can figure out how to implement them.
> >>
> >>There are three -- count 'em -- three system exclusive
> >>messages defined in the MIDI Tuning Specification. And two
> >>RPNs.
> >
> > 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11. I count eleven.
>
> I count three. Here's my reference:
>
> http://www.midi.org/about-midi/tuning.shtml
>
> Let's see yours.
>

Same page, plus links. You actually outlined all 11 of them in that
very post.

> >>>I think I understand why there are so many messages, but I don't
> >>>have the patience for them all, nor do most manufacturers. Choose
> >>>this message or that message? Support which one? Support them
> >>>all? It's frustrating.
> >>
> >>For your purposes, of the original messages, single note
> >>tuning change with a per-channel tuning table will be fine.
> >> How will adding more ways to do it make it easier to
> >>decide which to support?
> >
> > Same as above. Because the new ways are simple messages, not sysex.
>
> Redefine "simple message" then. It's easier to change the
> language than the substance.
>

Which would change nothing.

> > OK, agreed. So a needed thing would be a PDF and ASCII and HTML
> > white paper all about this message, why it needs to be supported
> > everywhere, and exactly how to support it. A campaign for one
> > message, sent to every major music company on the planet, to all
> > the developers as well as company executives. Glossy flyers. Websites.
> > Maybe even lobbys in congresses, parliaments, etc. I'm joking, but
> > not joking. Somehow we need to get everyone to recognize one
> > simple way of doing this and make it the standard.
>
> There is a community-agreed wish list. It should be here:
>
> http://www.microtonal-synthesis.com/synthhelp.html
>
> but I can't reach it today. It's been very helpful in
> getting soft synths supporting microtonality. Unfortunately
> we haven't made any progress with hardware manufacturers.
> If you want to revise it in the light of these discussions
> we can talk about that.
>

OK, let's talk about that. I've seen that before, and I think it's
great that the page is even up there, but it's kind of slap-dash.
To make an impact it needs to be really solid.

> >>>I have this crazy idea that if a simple basic message set were offered,
> >>>it would get more implementation. (insert an audience laughing here)
> >>
> >>What's complicated about the existing messages?
> >
> > I've given my answer for that many times now.
>
> No you haven't. Which of the 12 bytes you have to send to
> retune a note is an impracticable complication?
>

If you haven't read my reasons, then the only thing I can imagine is that
you are reading and responding selectively. I've actually repeated myself
many times, and I think I have been making coherent statements about
all this from one post to the next.

> > OK. If the thing needed is a table, then this can be a sysex
> > dump of 3 bytes per note;
> >
> > [sysex header]
> > <table number>
> > ...
> > 0nnnnnnn 0ccccccc 0fffffff (128 times)
> > ...
> > [sysex stop]
> >
> > n = note
> > c = coarse tuning
> > f = fine tuning
> >
> > Which is exactly the format used in H-Pi stuff.
> > This kind of table makes much more sense than
> > a frequency table. A frequency table requires too much of the
> > hardware. Leave frequency conversion for the software that
> > makes the tables. Hardware have global frequency settings
> > and there are other MIDI messages to set frequency tunings
> > for global system tuning and channel tuning, and the format
> > is different from the MTS table format, so the frequencies in
> > the MTS table are very confusing and in basic conflict with the
> > MIDI spec. The format should be MIDI friendly and use MIDI
> > logic, as shown above.
>
> How is it different to the MTS table format? Because you
> call it 0nnnnnnn 0ccccccc 0fffffff instead of [xx yy zz]
> and there's no checksum? Was that the problem all this time?
>

The data are completely different than MTS...

> > Thereafter the tuning should be done with simple messages
> > looked up from the table, and the new message set retunes
> > notes independently at the source level. Everything
> > can be done using this, keeping sysex as simple as possible
> > and keeping it to a minimum, only for tables, where large
> > amounts of data are required.
> >
> > Every MIDI device and MIDI compatible software should have
> > at least 512 table arrays standard. Simple messages can be sent
> > to choose the tables for each channel, and tune all the notes.
> > The tuning messages are still needed because standard source
> > arrays are never going to be in anything but 12 tone ET, and
> > putting the tuning directives in the message stream means that
> > the data will reproduce correctly on other devices that do not
> > have the tuning table which generated the file in memory.
>
> 512??? That's 512*128*3=196,608 bytes just to hold the
> tuning tables. Hardware manufacturers are not going to
> accept that. The MTS page already complains about 8k.
>

So what?

> I don't get the bit about 12 tone Et. Obviously microtonal
> data won't reproduce correctly on synths that don't support
> the relevant messages.
>

The bit about 12ET is paramount. Sample sets (still popular) can be
especially constructed for microtonality, but industry standard sample-
based music gear and software is never going to change from a 12ET
based source set, at least not in our lifetimes. Sure, the cheapest type
use the same sample over wide interval range, but the best use one
sample per 12ET pitch. Maybe someday that will change to one sample
per quartertone or something, but it's highly unlikely. Synthesis is a
different issue, but related because it shares the field with samples.
The point is that source calls should assume 12ET. Therefore tuning
messages should assume 12ET. A tuning table as I outline it is totally
different from an MTS table because it defines deviations from
the 12ET source set, in the same way that pitch bend does this, except
that the MSB and LSB define a range of + / - a quartertone to give
196608ET.

> > This idea is basically a built in TBX1 for every device, the only
> > difference being that the retuning is not limited to 16 voices
> > polyphony and does not use dynamic channel allocation.
>
> The idea is basically MTS in new clothes.

I hope you see it isn't. The architecture is completely different. The
tuning messages are always in the data stream. It's not MTS as all.
It's a note-specific pitch bend for every note on every channel in the
data stream. MTS doesn't have that. Tables in my outline do not obviate
the need for all the note tuning messages. They would still be there in
the data stream. Again, MTS doesn't do that.

> > We know that the hardware doesn't
> support what we want. If you want to use the MIDI tuning
> standard you'll find it's easier to give up the advantages
> of hardware synthesizers and get your work done in software.
>

Fine, but that doesn't solve any of the problems being discussed. If
you really feel that MTS is good enough and using the software that
supports it is the way to go, that's great. I still think hardware needs
to be standardized, and it should talk to the software, and it should
all be simplified and made as easy as possible, and MIDI and MTS in
their present forms are impeding this goal.

>
> My TX81Z didn't cost $1300. More like $130. But yes, when
> I started working with pitch bends I didn't have that kind
> of money. It's much easier for kids today because they can
> use Scala. If enough people care about any of this you'll
> see the hardware support arriving.

Who knows, but I don't think the hardware will start arriving until
everything is simplified and makes much more sense than it does
now.

Aaron Hunt
H-Pi Instruments

Aaron Andrew Hunt wrote:

>>I don't see why a machine cares if its simple message is a >>special case to the standard or implemented as a system >>exclusive. They all have to be able to parse system exclusives.
> > It does care because it has to have a buffer for Sysex, right?

No. You don't need a buffer if you read the MIDI data as a stream. It would help to be sure the sysex is always sent in one chunk, though, because you can break them up. You do need a buffer to receive a sysex through the Win32 API. But those nice people at Microsoft could get around this by treating the real-time messages as simple messages. They're not likely to do so, but it's no harder to do in principle than updating the API to deal with completely new simple messages.

>>>>>2. they are confusing; there are too many dedicated messages >>>>> which appear to duplicate the same functions in different >>>>> ways, so nobody can figure out how to implement them.
>>>>
>>>>There are three -- count 'em -- three system exclusive >>>>messages defined in the MIDI Tuning Specification. And two >>>>RPNs.
>>>
>>>1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11. I count eleven.
>>
>>I count three. Here's my reference:
>>
>>http://www.midi.org/about-midi/tuning.shtml
>>
>>Let's see yours.
> > Same page, plus links. You actually outlined all 11 of them in that > very post.

That one page outlines the MIDI Tuning Specification (MTS). The other messages I posted were from the MIDI Tuning Extensions (MTE). There's nothing on the MTE page to say it belongs to the MTS. The MTS does everything we want and if there's confusion that's what we want to turn to. We can't help it if the committees went and complicated it.

It's also trivial to support both the bank and non-bank equivalents. The octave-based messages are irrelevant for heavy microtonality and we don't need the dump requests. So there aren't that many relevant messages to choose between. You may as well say there's confusion with the MMC and MSC messages.

>>>>>I think I understand why there are so many messages, but I don't >>>>>have the patience for them all, nor do most manufacturers. Choose
>>>>>this message or that message? Support which one? Support them >>>>>all? It's frustrating.
>>>>
>>>>For your purposes, of the original messages, single note >>>>tuning change with a per-channel tuning table will be fine. >>>> How will adding more ways to do it make it easier to >>>>decide which to support?
>>>
>>>Same as above. Because the new ways are simple messages, not sysex.
>>
>>Redefine "simple message" then. It's easier to change the >>language than the substance.
> > Which would change nothing.

So where's the beef?

>>There is a community-agreed wish list. It should be here:
>>
>>http://www.microtonal-synthesis.com/synthhelp.html
>>
>>but I can't reach it today. It's been very helpful in >>getting soft synths supporting microtonality. Unfortunately >>we haven't made any progress with hardware manufacturers. >>If you want to revise it in the light of these discussions >>we can talk about that.
> > OK, let's talk about that. I've seen that before, and I think it's > great that the page is even up there, but it's kind of slap-dash.
> To make an impact it needs to be really solid. Certainly. But you'll need to copy the text here because I can't get at it.

>>>>>I have this crazy idea that if a simple basic message set were offered, >>>>>it would get more implementation. (insert an audience laughing here)
>>>>
>>>>What's complicated about the existing messages?
>>>
>>>I've given my answer for that many times now.
>>
>>No you haven't. Which of the 12 bytes you have to send to >>retune a note is an impracticable complication?
> > If you haven't read my reasons, then the only thing I can imagine is that
> you are reading and responding selectively. I've actually repeated myself
> many times, and I think I have been making coherent statements about
> all this from one post to the next.

You keep repeating, yes, but not advancing. To get new messages defined you have to say why you need them, why the existing messages aren't good enough, and why they're so important that you need them to be core messages, ahead of things like SMPTE synchronization that are more obviously useful.

>>>OK. If the thing needed is a table, then this can be a sysex >>>dump of 3 bytes per note;
>>>
>>>[sysex header]
>>><table number>
>>>...
>>>0nnnnnnn 0ccccccc 0fffffff (128 times)
>>>...
>>>[sysex stop]
>>>
>>>n = note
>>>c = coarse tuning
>>>f = fine tuning
>>>
>>>Which is exactly the format used in H-Pi stuff. >>>This kind of table makes much more sense than
>>>a frequency table. A frequency table requires too much of the
>>>hardware. Leave frequency conversion for the software that
>>>makes the tables. Hardware have global frequency settings
>>>and there are other MIDI messages to set frequency tunings
>>>for global system tuning and channel tuning, and the format
>>>is different from the MTS table format, so the frequencies in >>>the MTS table are very confusing and in basic conflict with the >>>MIDI spec. The format should be MIDI friendly and use MIDI >>>logic, as shown above.
>>
>>How is it different to the MTS table format? Because you >>call it 0nnnnnnn 0ccccccc 0fffffff instead of [xx yy zz] >>and there's no checksum? Was that the problem all this time?
> > The data are completely different than MTS...

How?

>>>Every MIDI device and MIDI compatible software should have
>>>at least 512 table arrays standard. Simple messages can be sent >>>to choose the tables for each channel, and tune all the notes.
>>>The tuning messages are still needed because standard source
>>>arrays are never going to be in anything but 12 tone ET, and >>>putting the tuning directives in the message stream means that
>>>the data will reproduce correctly on other devices that do not
>>>have the tuning table which generated the file in memory.
>>
>>512??? That's 512*128*3=196,608 bytes just to hold the >>tuning tables. Hardware manufacturers are not going to >>accept that. The MTS page already complains about 8k.
> > So what?

So they're not going to agree to 192k of RAM as a standard if they were worried about 8k as an upper limit.

>>I don't get the bit about 12 tone Et. Obviously microtonal >>data won't reproduce correctly on synths that don't support >>the relevant messages.
> > The bit about 12ET is paramount. Sample sets (still popular) can be > especially constructed for microtonality, but industry standard sample-
> based music gear and software is never going to change from a 12ET > based source set, at least not in our lifetimes. Sure, the cheapest type > use the same sample over wide interval range, but the best use one
> sample per 12ET pitch. Maybe someday that will change to one sample
> per quartertone or something, but it's highly unlikely. Synthesis is a > different issue, but related because it shares the field with samples.
> The point is that source calls should assume 12ET. Therefore tuning > messages should assume 12ET. A tuning table as I outline it is totally > different from an MTS table because it defines deviations from > the 12ET source set, in the same way that pitch bend does this, except
> that the MSB and LSB define a range of + / - a quartertone to give > 196608ET. The MTS table plainly does define deviations from the 12ET source set. It's hardly difficult to convert from one format to the other. The MTS format has the advantage that pitches are naturally ordered.

>>>This idea is basically a built in TBX1 for every device, the only >>>difference being that the retuning is not limited to 16 voices
>>>polyphony and does not use dynamic channel allocation.
>>
>>The idea is basically MTS in new clothes.
> > I hope you see it isn't. The architecture is completely different. The
> tuning messages are always in the data stream. It's not MTS as all. > It's a note-specific pitch bend for every note on every channel in the > data stream. MTS doesn't have that. Tables in my outline do not obviate
> the need for all the note tuning messages. They would still be there in > the data stream. Again, MTS doesn't do that.

It don't see the difference. MTS does have what you want. Does does does.

>>>We know that the hardware doesn't >>
>>support what we want. If you want to use the MIDI tuning >>standard you'll find it's easier to give up the advantages >>of hardware synthesizers and get your work done in software.
> > Fine, but that doesn't solve any of the problems being discussed. If
> you really feel that MTS is good enough and using the software that
> supports it is the way to go, that's great. I still think hardware needs
> to be standardized, and it should talk to the software, and it should
> all be simplified and made as easy as possible, and MIDI and MTS in
> their present forms are impeding this goal.

Hardware is standardized. It's standardized by the MTS. How would you make it simpler or easier? You keep saying MTS is so complicated but not what the complication is.

Graham

--- In tuning@yahoogroups.com, Graham Breed <gbreed@...> wrote:
> No. You don't need a buffer if you read the MIDI data as a
> stream. It would help to be sure the sysex is always sent
> in one chunk, though, because you can break them up. You do
> need a buffer to receive a sysex through the Win32 API. But
> those nice people at Microsoft could get around this by
> treating the real-time messages as simple messages. They're
> not likely to do so, but it's no harder to do in principle
> than updating the API to deal with completely new simple
> messages.

This is going to be a non-issue when 64 bits becomes the
API standard, right?

> That one page outlines the MIDI Tuning Specification (MTS).
> The other messages I posted were from the MIDI Tuning
> Extensions (MTE). There's nothing on the MTE page to say it
> belongs to the MTS. The MTS does everything we want and if
> there's confusion that's what we want to turn to. We can't
> help it if the committees went and complicated it.

If it really is simple then what matters is clearing things up. It
certainly does not look simple to a manufacturer.

...
> > OK, let's talk about that. I've seen that before, and I think it's
> > great that the page is even up there, but it's kind of slap-dash.
> > To make an impact it needs to be really solid.
>
> Certainly. But you'll need to copy the text here because I
> can't get at it.

OK, we should start a new thread about it.

...
> You keep repeating, yes, but not advancing. To get new
> messages defined you have to say why you need them, why the
> existing messages aren't good enough, and why they're so
> important that you need them to be core messages, ahead of
> things like SMPTE synchronization that are more obviously
> useful.

The reasons have been stated in my first post, and the next one,
and the next one, and in this one...

> >>512??? That's 512*128*3=196,608 bytes just to hold the
> >>tuning tables. Hardware manufacturers are not going to
> >>accept that. The MTS page already complains about 8k.
> >
> > So what?
>
> So they're not going to agree to 192k of RAM as a standard
> if they were worried about 8k as an upper limit.

OK, so maybe it's asking a lot, but check Microchip EEPROMs;
they are not that expensive.

> > The bit about 12ET is paramount. Sample sets (still popular) can be
> > especially constructed for microtonality, but industry standard sample-
> > based music gear and software is never going to change from a 12ET
> > based source set, at least not in our lifetimes. Sure, the cheapest type
> > use the same sample over wide interval range, but the best use one
> > sample per 12ET pitch. Maybe someday that will change to one sample
> > per quartertone or something, but it's highly unlikely. Synthesis is a
> > different issue, but related because it shares the field with samples.
> > The point is that source calls should assume 12ET. Therefore tuning
> > messages should assume 12ET. A tuning table as I outline it is totally
> > different from an MTS table because it defines deviations from
> > the 12ET source set, in the same way that pitch bend does this, except
> > that the MSB and LSB define a range of + / - a quartertone to give
> > 196608ET.
>
> The MTS table plainly does define deviations from the 12ET
> source set. It's hardly difficult to convert from one
> format to the other. The MTS format has the advantage that
> pitches are naturally ordered.

The MTS page on the MIDI site is the official reference for
this, and it is contradictory, confusing, and even in conflict with
the MIDI spec. Early in the MTS introduction it says that tuning
units should not be Hz but should be cents. But then it refers to
tuning data as "Frequency Data" and MTS table data values are
given in Hz. Hz are used elsewhere, with cents appearing to be
an afterthought. The basic formulas needed for anyone wanting
to implement anything are also missing. It's muddled!

The MTS table is basically incorrect as a MIDI addressing system
because each source is always and only tuned upwards. It may be
elegant to have only rising values, but it is a bad way to handle
12ET sources. The default value for each note tuning needs to be
in the MIDDLE, just like Pitch Bend, so that the source always remains
as near to the original data as possible, and a source should never
be retuned more than a quartertone up or down. There appears to be
no way to retune a source down according to MTS. The best one can
hope for is that a manufacturer knows this and does not use the first
byte as a NOTE number, because it is only masquerading as a Note
number, and instead interprets it as is only obliquely hinted at in the
text, that the first byte gives the CLOSEST MIDI Note.

> >>The idea is basically MTS in new clothes.
> >
> > I hope you see it isn't. The architecture is completely different. The
> > tuning messages are always in the data stream. It's not MTS as all.
> > It's a note-specific pitch bend for every note on every channel in the
> > data stream. MTS doesn't have that. Tables in my outline do not obviate
> > the need for all the note tuning messages. They would still be there in
> > the data stream. Again, MTS doesn't do that.
>
> It don't see the difference. MTS does have what you want.
> Does does does.

No, it doesn't. The difference should be as plain as day!

(1) No sysex
(2) Every Note TUNED independently by simple messages only
(3) All source calls + / - a quartertone from 12ET in 196608ET
(4) No tables required
(5) If tables are used, they are transparent, so the data stream
still contains all the tuning messages.

How is that the same as MTS? MTS provides none of that.

Yours,
Aaron Hunt
H-Pi Instruments

Hi Graham and Aaron,

As I see it, the advantages of rpn or note off -> note tune over MTS would be:

1. they are guaranteed to be in the same data stream as the notes, so you can be sure that they are synchronised so you can place them immediately before the notes and at least not worry that they could be disordered during transmission from one program to another. Only the sending and receiving programs have to preserve the order, and it would be made a requirement of any implementation of the new rpns that the receiving synth has to keep them in the correct serial order with the note numbers. That's not a big thing to ask of a synth it seems to me, since after all it is already a requirement for e.g. the instrument selection (patch change) messages.

2. they can be handled using the same programming code you use for other simple midi messages.

That's just for Windows programming, but a web search for asynchronous sysex brings up entries for other operating systems so may be a more general problem.

As for implementing the idea, one could do it more or less straight away in software if the option to use the rpns was clearly labelled as beta in the software - then if it turned out to be very useful, users and developers together could lobby for the extra rpns to be included in the midi spec.

Since it works by using the mechanism already in the spec to extend its capabilities then there is no need to e.g. ask the Microsoft programmers to change the midi messages API.

In the case where one wants to work within a particular tuning and it is sufficient to tune all the notes you need right away, then the timing problems don't matter that much, as you can just send a big sysex right away at the start.

But if you have options that permit types of adaptive tuning, or you want to play the entire midi range with additional accidentals (e.g. permitting the user to use a controller for accidentals, or note volume or whatever) - or are playing computer generated e.g. fractal music that has more than 128 pitches to play during the course of the piece - then you have more potential notes to tune than there are note numbers available in the midi range from 0 to 127, and then the timing issues with the MTS sysexes are more of a problem.

BTW the real time system messages are sent in the same stream as everything else - the only ones sent in the system exclusive stream in Windows are the variable length sysexes. All the ones with no more than two bytes of data are sent and received in the same way as the other short messages.

Robert

Robert walker wrote:
> Hi Graham and Aaron,
> > As I see it, the advantages of rpn or note off -> note tune over MTS would be:
> > 1. they are guaranteed to be in the same data stream as the notes, so you
> can be sure that they are synchronised so you can place them immediately
> before the notes and at least not worry that they could be disordered
> during transmission from one program to another. Only the sending and
> receiving programs have to preserve the order, and it would be made a
> requirement of any implementation of the new rpns that the receiving
> synth has to keep them in the correct serial order with the note
> numbers. That's not a big thing to ask of a synth it seems to me, since
> after all it is already a requirement for e.g. the instrument selection
> (patch change) messages.

Sysex messages are already in the same stream as the notes as far as the MIDI standard's concerned. The MTS also specifies that notes should be retuned without glitches so it shouldn't be a problem if they do arrive (or get processed) out of order.

> 2. they can be handled using the same programming code you use for other
> simple midi messages.

No. RPNs can't. You have to add code to remember the current RPN and MSB.

> That's just for Windows programming, but a web search for asynchronous
> sysex brings up entries for other operating systems so may be a more
> general problem.

Not in the top 10 of Google it doesn't.

> As for implementing the idea, one could do it more or less straight
> away in software if the option to use the rpns was clearly labelled
> as beta in the software - then if it turned out to be very useful,
> users and developers together could lobby for the extra rpns to be
> included in the midi spec.

No need to label it beta. Use NRPNs and change to RPNs in the unlikely event you get them registered.

> Since it works by using the mechanism already in the spec to extend
> its capabilities then there is no need to e.g. ask the Microsoft
> programmers to change the midi messages API.

Yes.

> In the case where one wants to work within a particular tuning and it
> is sufficient to tune all the notes you need right away, then the
> timing problems don't matter that much, as you can just send a big
> sysex right away at the start. Yes.

> But if you have options that permit types of adaptive tuning, or you
> want to play the entire midi range with additional accidentals (e.g.
> permitting the user to use a controller for accidentals, or note
> volume or whatever) - or are playing computer generated e.g. fractal
> music that has more than 128 pitches to play during the course of the
> piece - then you have more potential notes to tune than there are note
> numbers available in the midi range from 0 to 127, and then the timing
> issues with the MTS sysexes are more of a problem.

No they aren't. A single note tuning change is the same length as a (N)RPN (12 bytes). Sending lots of NRPNs with the same MSB simplifies this, so that would be 25% more efficient. But if you can send more than one note's tuning per sysex, that becomes more efficient.

Sending the new tunings for notes that change will almost always be more efficient than sending a message with every note on. Also easier to optimize so that the tuning messages get sent when nothing else is happening.

> BTW the real time system messages are sent in the same stream as everything
> else - the only ones sent in the system exclusive stream in Windows are the
> variable length sysexes. All the ones with no more than two bytes of data
> are sent and received in the same way as the other short messages.

I thought it was all the same stream but a different message type.

Graham

Aaron Andrew Hunt wrote:
> --- In tuning@yahoogroups.com, Graham Breed <gbreed@...> wrote:
> >>No. You don't need a buffer if you read the MIDI data as a >>stream. It would help to be sure the sysex is always sent >>in one chunk, though, because you can break them up. You do >>need a buffer to receive a sysex through the Win32 API. But >>those nice people at Microsoft could get around this by >>treating the real-time messages as simple messages. They're >>not likely to do so, but it's no harder to do in principle >>than updating the API to deal with completely new simple >>messages.
> > This is going to be a non-issue when 64 bits becomes the
> API standard, right?

In what sense is it an issue now?

>>That one page outlines the MIDI Tuning Specification (MTS). >> The other messages I posted were from the MIDI Tuning >>Extensions (MTE). There's nothing on the MTE page to say it >>belongs to the MTS. The MTS does everything we want and if >>there's confusion that's what we want to turn to. We can't >>help it if the committees went and complicated it.
> > If it really is simple then what matters is clearing things up. It > certainly does not look simple to a manufacturer.

It's manufacturers who wrote the standard, so they don't have anybody else to blame.

>>>OK, let's talk about that. I've seen that before, and I think it's >>>great that the page is even up there, but it's kind of slap-dash.
>>>To make an impact it needs to be really solid. >>
>>Certainly. But you'll need to copy the text here because I >>can't get at it.
> > OK, we should start a new thread about it.

You should start a new thread ;)

>>You keep repeating, yes, but not advancing. To get new >>messages defined you have to say why you need them, why the >>existing messages aren't good enough, and why they're so >>important that you need them to be core messages, ahead of >>things like SMPTE synchronization that are more obviously >>useful.
> > The reasons have been stated in my first post, and the next one, > and the next one, and in this one...

You haven't given any good reasons.

> The MTS page on the MIDI site is the official reference for > this, and it is contradictory, confusing, and even in conflict with > the MIDI spec. Early in the MTS introduction it says that tuning > units should not be Hz but should be cents. But then it refers to > tuning data as "Frequency Data" and MTS table data values are > given in Hz. Hz are used elsewhere, with cents appearing to be > an afterthought. The basic formulas needed for anyone wanting > to implement anything are also missing. It's muddled!

It does not say they should or should not be in Hz or cents. It says they can be linear frequency (constant Hertz), but "strongly suggests" exponential frequency (constant cents). I don't see anything unclear about that. Stupid, in that a tuning standard doesn't strictly standardize the tuning, but perfectly clear.

It's only contradictory later on in that it drops the supidity and only talks about the exponential frequency (constant cents) case. It explicitly says the tuning is by .0061-cent steps in case you had trouble working that out.

I don't see anything confusing or contradictory about Hz. They're a common unit of frequency. SI standard I believe.

Confusion is in the eye of the beholder. But if anybody has trouble they can always ask here.

> The MTS table is basically incorrect as a MIDI addressing system > because each source is always and only tuned upwards. It may be
> elegant to have only rising values, but it is a bad way to handle
> 12ET sources. The default value for each note tuning needs to be > in the MIDDLE, just like Pitch Bend, so that the source always remains
> as near to the original data as possible, and a source should never
> be retuned more than a quartertone up or down. There appears to be
> no way to retune a source down according to MTS. The best one can
> hope for is that a manufacturer knows this and does not use the first
> byte as a NOTE number, because it is only masquerading as a Note
> number, and instead interprets it as is only obliquely hinted at in the > text, that the first byte gives the CLOSEST MIDI Note.

If the manufacturer's to dumb to tune their samples the right way, does it really matter? Ooh, you might get the partials within a semitione or the Nyquist frequency aliased. Well, that'll annoy the discerning cat, won't it?

Usually it's better to tune *either* sharp *or* flat, depending on the nature of the samples and interpolation algorithm. It's trivial to do the correction to go down: add 1 to the note number and negate the tuning offset. You don't even need a microprocessor for that.

>>>>The idea is basically MTS in new clothes.
>>>
>>>I hope you see it isn't. The architecture is completely different. The
>>>tuning messages are always in the data stream. It's not MTS as all. >>>It's a note-specific pitch bend for every note on every channel in the >>>data stream. MTS doesn't have that. Tables in my outline do not obviate
>>>the need for all the note tuning messages. They would still be there in >>>the data stream. Again, MTS doesn't do that.
>>
>>It don't see the difference. MTS does have what you want. >>Does does does.
> > No, it doesn't. The difference should be as plain as day!
> > (1) No sysex

What we're talking about here does use sysex. Follow the thread back.

> (2) Every Note TUNED independently by simple messages only

MTS can tune each note independently by 12 byte messages.

> (3) All source calls + / - a quartertone from 12ET in 196608ET

Compared to up to a semitone, now that you've defined that.

> (4) No tables required

What we're talking about here does use tables. Follow the thread back.

> (5) If tables are used, they are transparent, so the data stream > still contains all the tuning messages.

In what way does the data stream not contain the MTS messages?

> How is that the same as MTS? MTS provides none of that.

It's all the same. Except for the bit about quartertones. And a checksum, I think. To me that's clothing.

Graham

--- In tuning@yahoogroups.com, Graham Breed <gbreed@...> wrote:
> > The reasons have been stated in my first post, and the next one,
> > and the next one, and in this one...
>
> You haven't given any good reasons.

Graham, you seem to be very fond of MTS for some reason. I think my
reasons for wanting something else would be ridiculously obvious by
now to anyone reading these posts. You don't think they're good
reasons, fine. This is the first time you've even conceded that I _have
reasons.

> > The MTS page on the MIDI site is the official reference for
> > this, and it is contradictory, confusing, and even in conflict with
> > the MIDI spec. Early in the MTS introduction it says that tuning
> > units should not be Hz but should be cents. But then it refers to
> > tuning data as "Frequency Data" and MTS table data values are
> > given in Hz. Hz are used elsewhere, with cents appearing to be
> > an afterthought. The basic formulas needed for anyone wanting
> > to implement anything are also missing. It's muddled!
>
> It does not say they should or should not be in Hz or cents.
> It says they can be linear frequency (constant Hertz), but
> "strongly suggests" exponential frequency (constant cents).
> I don't see anything unclear about that. Stupid, in that
> a tuning standard doesn't strictly standardize the tuning,
> but perfectly clear.

Unclear in that it can't even be consistent with the language it
uses, and the language it uses is unlike the language used for
pitch in the rest of the MIDI spec.

> It's only contradictory later on in that it drops the
> supidity and only talks about the exponential frequency
> (constant cents) case. It explicitly says the tuning is by
> .0061-cent steps in case you had trouble working that out.

Yes, I read it. The passage is unnecessarily obtuse.

> I don't see anything confusing or contradictory about Hz.
> They're a common unit of frequency. SI standard I believe.

Sure, but Hz are not the common unit for measuring pitch in
the MIDI spec.

> Confusion is in the eye of the beholder. But if anybody has
> trouble they can always ask here.

Yikes, that is a disconcerting thought. Fine if they want to get
pounced on. Do you know how many people consciously stay
away from this group?

> > The MTS table is basically incorrect as a MIDI addressing system
> > because each source is always and only tuned upwards. It may be
> > elegant to have only rising values, but it is a bad way to handle
> > 12ET sources. The default value for each note tuning needs to be
> > in the MIDDLE, just like Pitch Bend, so that the source always remains
> > as near to the original data as possible, and a source should never
> > be retuned more than a quartertone up or down. There appears to be
> > no way to retune a source down according to MTS. The best one can
> > hope for is that a manufacturer knows this and does not use the first
> > byte as a NOTE number, because it is only masquerading as a Note
> > number, and instead interprets it as is only obliquely hinted at in the
> > text, that the first byte gives the CLOSEST MIDI Note.
>
> If the manufacturer's to dumb to tune their samples the
> right way, does it really matter?

Blame the manufacturers again... Whether or not you think only your
cat is going to notice, it's a serious issue and can be very noticable.
The MTS spec should not only say something about it, but the
portocol should require it to be handled properly. The first byte
should be a note number (it should call it a MIDI Note like everywhere
else in the MIDI spec, not the nearest semitone) and the following
bytes should work like pitych bend, as I have described over and over
but you keep ignoring.

> Usually it's better to tune *either* sharp *or* flat,
> depending on the nature of the samples and interpolation
> algorithm. It's trivial to do the correction to go down:
> add 1 to the note number and negate the tuning offset. You
> don't even need a microprocessor for that.

+ / - a quartertone from center is the best. It sould be made
clear in the spec.

> >>>>The idea is basically MTS in new clothes.
> >>>
> >>>I hope you see it isn't. The architecture is completely different. The
> >>>tuning messages are always in the data stream. It's not MTS as all.
> >>>It's a note-specific pitch bend for every note on every channel in the
> >>>data stream. MTS doesn't have that. Tables in my outline do not obviate
> >>>the need for all the note tuning messages. They would still be there in
> >>>the data stream. Again, MTS doesn't do that.
> >>
> >>It don't see the difference. MTS does have what you want.
> >>Does does does.
> >
> > No, it doesn't. The difference should be as plain as day!
> >
> > (1) No sysex
>
> What we're talking about here does use sysex. Follow the
> thread back.
>
> > (2) Every Note TUNED independently by simple messages only
>
> MTS can tune each note independently by 12 byte messages.
>
> > (3) All source calls + / - a quartertone from 12ET in 196608ET
>
> Compared to up to a semitone, now that you've defined that.
>
> > (4) No tables required
>
> What we're talking about here does use tables. Follow the
> thread back.
>
> > (5) If tables are used, they are transparent, so the data stream
> > still contains all the tuning messages.
>
> In what way does the data stream not contain the MTS messages?
>
> > How is that the same as MTS? MTS provides none of that.
>
> It's all the same. Except for the bit about quartertones.
> And a checksum, I think. To me that's clothing.

Please follow the thread back yourself and you will see that
I have been talking about a different (and I believe better) way to
do things, as I stated above in plain language and have stated
many times by now.

Aaron Hunt
H-Pi Instruments

--- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aahunt@...> wrote:

> The MTS table is basically incorrect as a MIDI addressing system
> because each source is always and only tuned upwards.

Eh? It says no such thing. It's simply a pitch
measurement, and no more tells you to tune up
or down than giving the frequency in Hertz would.

--- In tuning@yahoogroups.com, "Robert walker" <robertwalker@...> wrote:
>
> Hi Graham and Aaron,
>
> As I see it, the advantages of rpn or note off -> note tune over MTS
would be:

3. Since the tuning is associated with the note,
you can easily determine what the note is by
looking at the midi file. Not only easier for
humans, but also for programs.

--- In tuning@yahoogroups.com, Graham Breed <gbreed@...> wrote:

> MTS can tune each note independently by 12 byte messages.

(1) Where does it say that?

(2) Has anyone tried?

> BTW the real time system messages are sent in the same stream
> as everything else - the only ones sent in the system exclusive
> stream in Windows are the variable length sysexes. All the ones
> with no more than two bytes of data are sent and received in the
> same way as the other short messages.
>
> Robert

Hi Robert (and all),

Just a quick question. Above, are you referring to DirectMusic?
One could also use ReWire, or ... ?

-Carl

Hi there

Carl - This is something I came across a while back, then the problem went away. Anyway I've looked up the information available and my old notes, and also tested it again.

I've just tested the timing right now, using virtual midi cables (LoopBe1 and Midi Yoke NT on XP), and the sysexes and note ons are getting transmitted in sequence currently on my laptop. So it is no longer happening.

According to the Microsoft help for MidiOutLongMsg, whether it happens synchronously or asynchronously depends on the device driver:
http://msdn2.microsoft.com/en-us/library/ms711629.aspx
"The MIDI output device driver determines whether the data is sent synchronously or asynchronously."

If sent asynchronously, then the receiving program would be told (by return value of midiOutUnprepareHeader) that it is okay to continue, while the device driver continues to send the sysex - and then the concern is that if your program is permitted to continue sending midi messages while the device driver sends on the sysex in the background, and you then send a short message to the device driver before it has finished sending the long sysex message, it may reasonably enough interpolate it into the stream before the original sysex has been completely sent. All depends on how the device driver is written, but seems from the Microsoft help that it is at least permitted to write one like that.

I'm not totally sure that this was the problem, just suspected it at the time. I may be wrong about that, and whatever it was, it may now be fixed.

Google search for asynchronous sysex brings up posts that suggests it may possibly be a possibility on other OSs as well, if I understand the posts correctly (not sure I do).
http://www.google.co.uk/search?sourceid=navclient&ie=UTF-8&rls=GGLJ,GGLJ:2006-39,GGLJ:en&q=asynchronous+sysex

Yes I know you have to keep track of the state of the active rpn. That's a bit extra code yes but hardly anything compared with the extra work to process MIM_LONGDATA and to set up all the sysex handling code in Windows. If one processes any of the other rpns already then you have already coded for that.

In Windows XP it is hard to find a virtual midi cable to relay sysexes from one software progr. to another if you want to use Giga (which is incompatible with Midi Yoke Junction NT) - you can't use Maple virtual cable - but can use LoopBe1.

The point about the number of notes you can retune was to do with the timing issues. If the timing order is preserverd it is no problem. But if you need to retune notes well in advance, and can't predict when a particular pitch may be required, then you are limited to a table of 128 notes you can retune right away before any notes are played at all - if user suddenly plays a note not in the table so far, you need to be able to add a new pitch to the table instantly - and can't do that with MTS sysexes if it is possible the sysex could be delayed in transmission to after the note on.

NRPNs are supposed to be hardware or application specific, and you risk the possibility that they may already be defined to mean something else on the user's equipment.

Better support of MTS sysexes, and requiring that all drivers keep the timing order of the sysexes and note Ons would do as well from programming point of view as the RPN apart from the issue that there is also rather more involved in the code for sending and receiving sysexes than is needed for sending and receiving rpns. In the early days of FTS I could have added support for RPN tuning much more quickly than adding support for sysexes and that would surely be the case for anyone who is in the early days of programming a midi app. for Windows.

Perhaps the timing issue isn't a problem nowadays, and I may be wrong that it ever was, on Windows - unless someone else comes up with an example of the sysexes getting transmitting out of seq. with the note ons. The help for MidiOutLongMsg seems to suggest it is acceptable for a driver to relay the sysexes it receives asynchronously - well I expect it is not really in a separate stream, but interpolated as fragments into the current midi stream. But I may be misreading that as well. If anyone knows more I'm interested to hear about it.

Thanks,

Robert

Correction:

If sent asynchronously, then the SENDING program would be told (by return value of midiOutUnprepareHeader) that it is okay to continue, while the device driver continues to send the sysex - and then the concern is that if your program is permitted to continue sending midi messages while the device driver sends on the sysex in the background, and you then send a short message to the device driver before it has finished sending the long sysex message, it may reasonably enough interpolate it into the stream before the original sysex has been completely sent. All depends on how the device driver is written, but seems from the Microsoft help that it is at least permitted to write one like that.

Robert

Aaron Andrew Hunt wrote:
> --- In tuning@yahoogroups.com, Graham Breed <gbreed@...> wrote:
> >>>The reasons have been stated in my first post, and the next one, >>>and the next one, and in this one...
>>
>>You haven't given any good reasons.
> > Graham, you seem to be very fond of MTS for some reason. I think my > reasons for wanting something else would be ridiculously obvious by
> now to anyone reading these posts. You don't think they're good > reasons, fine. This is the first time you've even conceded that I _have > reasons.

I gave counterarguments where you gave arguments. It shouldn't be difficult to understand each other but you keep coming back with the same arguments. I'm running out of novel ways to respond to them.

>>It does not say they should or should not be in Hz or cents. >> It says they can be linear frequency (constant Hertz), but >>"strongly suggests" exponential frequency (constant cents). >> I don't see anything unclear about that. Stupid, in that >>a tuning standard doesn't strictly standardize the tuning, >>but perfectly clear.
> > Unclear in that it can't even be consistent with the language it
> uses, and the language it uses is unlike the language used for
> pitch in the rest of the MIDI spec.

Okay, so what language does the rest of the MIDI spec use?

>>It's only contradictory later on in that it drops the >>supidity and only talks about the exponential frequency >>(constant cents) case. It explicitly says the tuning is by >>.0061-cent steps in case you had trouble working that out.
> > Yes, I read it. The passage is unnecessarily obtuse.

I'm not really interested in arguing about the wording of the standard. If you've never seen an obtuse standard before you've lived a charmed life.

>>Confusion is in the eye of the beholder. But if anybody has >>trouble they can always ask here.
> > Yikes, that is a disconcerting thought. Fine if they want to get > pounced on. Do you know how many people consciously stay > away from this group?

No.

>>>The MTS table is basically incorrect as a MIDI addressing system >>>because each source is always and only tuned upwards. It may be
>>>elegant to have only rising values, but it is a bad way to handle
>>>12ET sources. The default value for each note tuning needs to be >>>in the MIDDLE, just like Pitch Bend, so that the source always remains
>>>as near to the original data as possible, and a source should never
>>>be retuned more than a quartertone up or down. There appears to be
>>>no way to retune a source down according to MTS. The best one can
>>>hope for is that a manufacturer knows this and does not use the first
>>>byte as a NOTE number, because it is only masquerading as a Note
>>>number, and instead interprets it as is only obliquely hinted at in the >>>text, that the first byte gives the CLOSEST MIDI Note.
>>
>>If the manufacturer's to dumb to tune their samples the >>right way, does it really matter? > > Blame the manufacturers again... Whether or not you think only your > cat is going to notice, it's a serious issue and can be very noticable.
> The MTS spec should not only say something about it, but the > portocol should require it to be handled properly. The first byte > should be a note number (it should call it a MIDI Note like everywhere > else in the MIDI spec, not the nearest semitone) and the following > bytes should work like pitych bend, as I have described over and over > but you keep ignoring.

Who else am I supposed to blame for poor manufacture?

MTS is the MIDI Tuning Specification. MIDI is the Musical Instrument Digital Interface. Hence MTS is a specification for tuning in an interface for digital musical instruments. It isn't supposed to be an advice sheet on the implementation of digital musical instruments. I don't see that it has any business telling manufacturers how to handle the messages, only stating what the messages mean.

>>Usually it's better to tune *either* sharp *or* flat, >>depending on the nature of the samples and interpolation >>algorithm. It's trivial to do the correction to go down: >>add 1 to the note number and negate the tuning offset. You >>don't even need a microprocessor for that.
> > + / - a quartertone from center is the best. It sould be made > clear in the spec.

Reference? I remember the Csound book saying it's better to always sharpen samples these days. RAM is cheaper than processor overhead so you interpolate the sample to the lowest note you need. Different criteria apply in different situations I'm sure but you're being very dogmatic here.

>>>>>>The idea is basically MTS in new clothes.

<snip>

>>It's all the same. Except for the bit about quartertones. >>And a checksum, I think. To me that's clothing.
> > Please follow the thread back yourself and you will see that > I have been talking about a different (and I believe better) way to > do things, as I stated above in plain language and have stated > many times by now.

I made the much indented comment above in a message send on the 9th of April at 9:58 (probably Chinese time). I left a large quote from you intact which included

"""
OK. If the thing needed is a table, then this can be a
sysex dump of 3 bytes per note;

[sysex header]
<table number>
...
0nnnnnnn 0ccccccc 0fffffff (128 times)
...
[sysex stop]

n = note
c = coarse tuning
f = fine tuning
"""

Your original message was dated Sun, 08 Apr 2007 16:40:34 -0000.

According to English as I understand it you are using a sysex message and a tuning table here. As English is my job I'd certainly be interested in how I'm supposed to interpret this passage so as not to involve sysexes or tables. Until then I stand by my comment that it's very similar to the MTS.

Graham

Gene Ward Smith wrote:
> --- In tuning@yahoogroups.com, Graham Breed <gbreed@...> wrote:
> >>MTS can tune each note independently by 12 byte messages.
> > (1) Where does it say that?

http://www.midi.org/about-midi/tuning.shtml

> (2) Has anyone tried?

Dunno. Isn't this an option with Scala and Timidity that you never use?

Graham

Carl Lumma wrote:
>>BTW the real time system messages are sent in the same stream
>>as everything else - the only ones sent in the system exclusive
>>stream in Windows are the variable length sysexes. All the ones
>>with no more than two bytes of data are sent and received in the
>>same way as the other short messages.
>>
>>Robert
> > > Hi Robert (and all),
> > Just a quick question. Above, are you referring to DirectMusic?
> One could also use ReWire, or ... ?

Oh yes, DirectMusic. I looked that up. Here's "Using DirectMusic Messages":

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/DMusicC/htm/messagecreationanddelivery.asp

It says "There is no guarantee that messages with the same time stamp will be processed in any particular order." This applies to notes and control data. So check those timestamps!

There's an example of sending a sysex under IDirectMusicPerformance8::SendPMsg

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/DMusicC/htm/idirectmusicperformance8sendpmsg.asp

AFAICT you don't need to manage the buffer yourself to receive a sysex message.

The short messages are sent with a much richer structure than under the Windows API. So if Microsoft wanted to they could easily send tuning data as short messages.

Graham

Robert walker wrote:
> Hi there
> > Carl - This is something I came across a while back, then the problem went
> away. Anyway I've looked up the information available and my old notes, and
> also tested it again.

I think it should be me. Nice to see it's working now, anyway.

> According to the Microsoft help for MidiOutLongMsg, whether it happens
> synchronously or asynchronously depends on the device driver:
> http://msdn2.microsoft.com/en-us/library/ms711629.aspx > "The MIDI output device driver determines whether the data is sent
> synchronously or asynchronously."

I don't know if "asynchronously" here means that the messages can arrive out of order. It may simply mean that the function returns immediately. MIDI is a serial, asynchronous protocol, after all.

> If sent asynchronously, then the receiving program would be told (by
> return value of midiOutUnprepareHeader) that it is okay to continue,
> while the device driver continues to send the sysex - and then the
> concern is that if your program is permitted to continue sending midi
> messages while the device driver sends on the sysex in the background,
> and you then send a short message to the device driver before it has
> finished sending the long sysex message, it may reasonably enough
> interpolate it into the stream before the original sysex has been
> completely sent. All depends on how the device driver is written, but
> seems from the Microsoft help that it is at least permitted to write
> one like that.

Okay, yes, it's possible to send other messages in the middle of a sysex message. I don't think that would mean messages sent internally within windows would arrive out of order because sysexes are sent as a single chunk (one of the nice things about the Windows API). It also doesn't mean that messages from a hardware stream would arrive out of order. They should arrive in order of the *end* of the messages in the original stream.

It may mean that a note-on could occur in the middle of a tuning message in an output hardware stream. That'd be annoying. It'd mean the synth would know that a retuning message was being sent but we can't expect the programmers to think of this situation.

It'd be nice if the driver would recognize a real-time sysex message and not interrupt it. But I wouldn't bet money on this working. I wouldn't expect a 12 byte message to be interrupted but, again, if my life depended on it I'd certainly be careful ;)

> Google search for asynchronous sysex brings up posts that
> suggests it may possibly be a possibility on other OSs as
> well, if I understand the posts correctly (not sure I do). I'll check your link to see if it gives different results to mine. I remember some things about OSX. But it said only non-channel data could be sent during sysexes. So that definitely doesn't affect us. Otherwise there were hits for draft protocols. UNIX machines usually give you MIDI as a stream of bytes so you know the order, but have to parse it yourself.

I did check PortMidi as well. This is the best cross-platform MIDI library I know of (and I'm afraid still not quite there). This is the only documentation:

http://www.cs.cmu.edu/~music/portmusic/portmidi/portmidi.h

It says sysexes are delivered as chunks of short messages, similar to the USB protocol.

> Yes I know you have to keep track of the state of the
> active rpn. That's a bit extra code yes but hardly anything
> compared with the extra work to process MIM_LONGDATA and to
> set up all the sysex handling code in Windows. If one
> processes any of the other rpns already then you have already
> coded for that.

So let's be clear that this is a problem with the Windows API, not the MIDI standard.

> In Windows XP it is hard to find a virtual midi cable to
> relay sysexes from one software progr. to another if you
> want to use Giga (which is incompatible with Midi Yoke
> Junction NT) - you can't use Maple virtual cable - but
> can use LoopBe1.

I never got virtual cables working in XP. I don't blame the MMA.

> The point about the number of notes you can retune was to
> do with the timing issues. If the timing order is preserverd
> it is no problem. But if you need to retune notes well in
> advance, and can't predict when a particular pitch may be
> required, then you are limited to a table of 128 notes you
> can retune right away before any notes are played at all -
> if user suddenly plays a note not in the table so far, you
> need to be able to add a new pitch to the table instantly -
> and can't do that with MTS sysexes if it is possible the
> sysex could be delayed in transmission to after the note on.

If the MTS is followed correctly it should still work. The synthesizer will receive the tuning message right after the note-on and do a glitch-free retuning. This will happen too fast for the listener to notice the old pitch.

Graham

> > NRPNs are supposed to be hardware or application specific, and you risk the possibility that they may already be defined to mean something else on the user's equipment.
> > Better support of MTS sysexes, and requiring that all drivers keep the timing order of the sysexes and note Ons would do as well from programming point of view as the RPN apart from the issue that there is also rather more involved in the code for sending and receiving sysexes than is needed for sending and receiving rpns. In the early days of FTS I could have added support for RPN tuning much more quickly than adding support for sysexes and that would surely be the case for anyone who is in the early days of programming a midi app. for Windows.
> > Perhaps the timing issue isn't a problem nowadays, and I may be wrong that it ever was, on Windows - unless someone else comes up with an example of the sysexes getting transmitting out of seq. with the note ons. The help for MidiOutLongMsg seems to suggest it is acceptable for a driver to relay the sysexes it receives asynchronously - well I expect it is not really in a separate stream, but interpolated as fragments into the current midi stream. But I may be misreading that as well. If anyone knows more I'm interested to hear about it.
> > Thanks,
> > Robert

Gene Ward Smith wrote:
> --- In tuning@yahoogroups.com, "Robert walker" <robertwalker@...> wrote:
> >>Hi Graham and Aaron,
>>
>>As I see it, the advantages of rpn or note off -> note tune over MTS > > would be:
> > 3. Since the tuning is associated with the note,
> you can easily determine what the note is by
> looking at the midi file. Not only easier for
> humans, but also for programs.

Oh Lordy, not this one again. I said before that MIDI files were not human readable and nobody disagreed. I also asked you what was difficult for programs and you said Manuel had trouble, and he said he didn't. But now here you are making the same assertion as if it were valid.

Graham

--- In tuning@yahoogroups.com, Graham Breed <gbreed@...> wrote:
> I gave counterarguments where you gave arguments. It
> shouldn't be difficult to understand each other but you keep
> coming back with the same arguments. I'm running out of
> novel ways to respond to them.

I'm sorry, but you don't appear to be listening.

> > Unclear in that it can't even be consistent with the language it
> > uses, and the language it uses is unlike the language used for
> > pitch in the rest of the MIDI spec.
>
> Okay, so what language does the rest of the MIDI spec use?

MIDI Notes = 12ET

> >>It's only contradictory later on in that it drops the
> >>supidity and only talks about the exponential frequency
> >>(constant cents) case. It explicitly says the tuning is by
> >>.0061-cent steps in case you had trouble working that out.
> >
> > Yes, I read it. The passage is unnecessarily obtuse.
>
> I'm not really interested in arguing about the wording of
> the standard. If you've never seen an obtuse standard
> before you've lived a charmed life.

The rest of the MIDI spec is not so obtuse as this.

> MTS is the MIDI Tuning Specification. MIDI is the Musical
> Instrument Digital Interface. Hence MTS is a specification
> for tuning in an interface for digital musical instruments.
> It isn't supposed to be an advice sheet on the
> implementation of digital musical instruments. I don't see
> that it has any business telling manufacturers how to handle
> the messages, only stating what the messages mean.

Yes, it should state exactly what the message means, and it
should state it in language which is consistent with the rest of
the spec. So what does the first byte of the MTS table sysex
mean? Is it a MIDI Note? No. But it's a "note". It's a "semitone".
It's "the nearest semitone". This is not MIDI-speak. If it is
anything to do with a "note" in MIDI, then it's a MIDI Note, and
the data should give a MIDI Note number. But it doesn't directly
specify a MIDI Note number. It's left to the manufacturer to
figure out which MIDI Note number is meant by a byte which
could so easily otherwise give a MIDI Note number directly.
That's just silly and anti-MIDI.

> > + / - a quartertone from center is the best. It sould be made
> > clear in the spec.
>
> Reference? I remember the Csound book saying it's better to
> always sharpen samples these days. RAM is cheaper than
> processor overhead so you interpolate the sample to the
> lowest note you need. Different criteria apply in different
> situations I'm sure but you're being very dogmatic here.

Dogmatic because it's economical and it represents the existing
MIDI pitch bending logic. The MIDI spec is the reference. It is the
language of MIDI.

> According to English as I understand it you are using a
> sysex message and a tuning table here. As English is my job
> I'd certainly be interested in how I'm supposed to interpret
> this passage so as not to involve sysexes or tables. Until
> then I stand by my comment that it's very similar to the MTS.

It's a strange opinion if you acknowledge the rest of what I
have been attempting to say in plain English. I gave you a tuning
table saying "here it is if you have to have one". It uses sysex,
yes. It is a table, yes. I gave you a table because you seemed to
want one. So, sure, there is a table, and the most logical way to
send a table is through sysex. You choose to ignore the fact that I
said before that and after it and all around it, from the beginning
of this thread, that tables and sysex should never be required to
accomplish tunings. I explained more than once that if a table
is used, it should be transparent, meaning all the tuning messages
for every note still get put into the data stream. I even outlined
point by point in the last post the differences between what I'm
proposing and what is MTS. You keep coming back to tell me it's
just like MTS and MTS does what I want anyway. Well, it's not and it
doesn't. I've said it enough times now.

Aaron Hunt
H-Pi Instruments

Thanks for the details, Robert, but this doesn't answer
which API you're using. Looks like win32 has some MIDI
functions built in. Are these separate from DirectSound's
MIDI stuff?

-Carl

--- In tuning@yahoogroups.com, "Carl Lumma" <clumma@...> wrote:
>
> Thanks for the details, Robert, but this doesn't answer
> which API you're using. Looks like win32 has some MIDI
> functions built in. Are these separate from DirectSound's
> MIDI stuff?
>
> -Carl

DirectMusic I mean. Looks like they are separate. -Carl

Hi Carl,

Yes I work in plain C rather than C++ and use the low level Midi API.

It doesn't require DirectX or DirectMusic.

Robert

--- In tuning@yahoogroups.com, Graham Breed <gbreed@...> wrote:
>
> Gene Ward Smith wrote:
> > --- In tuning@yahoogroups.com, Graham Breed <gbreed@> wrote:
> >
> >>MTS can tune each note independently by 12 byte messages.
> >
> > (1) Where does it say that?
>
> http://www.midi.org/about-midi/tuning.shtml

That's a retuning message, not a note by note tuning
message. Now, I wonder what would happen if you always
sent such a message for every note?

> > (2) Has anyone tried?
>
> Dunno. Isn't this an option with Scala and Timidity that
> you never use?

Not as far as I know. I think Scala just does a new
bulk dump when it needs to.
>
> Graham
>

--- In tuning@yahoogroups.com, Graham Breed <gbreed@...> wrote:
>
> Gene Ward Smith wrote:

> > 3. Since the tuning is associated with the note,
> > you can easily determine what the note is by
> > looking at the midi file. Not only easier for
> > humans, but also for programs.
>
> Oh Lordy, not this one again. I said before that MIDI files
> were not human readable and nobody disagreed.

You were wrong. MIDI is human-readable if you convert
the binary to an ascii equivalent, which a number
of programs do. I recommend mf2t.exe from the gnmidi
suite of DOS programs.

> I also asked
> you what was difficult for programs and you said Manuel had
> trouble, and he said he didn't.

Oh, really? Care to give a message number?

Whatever Manuel said, and I don't recall him saying
any such thing, the above claim is false. We know
that how? Because Manuel flatly refuses to do it.
If it was easy, he would.

> But now here you are making
> the same assertion as if it were valid.

If it's so damned easy, take my challege:

(1) Get Manuel to do it, or

(2) Write a program which does something of the
kind yourself.

I don't expect either of these are going to happen,
Mr. Easy, because it ain't easy. That's just complete
horseshit.

--- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aahunt@...> wrote:

> MIDI Notes = 12ET

Manuel gets pissed when I say stuff like that. But,
of course, out in the real world, it's true.

--- In tuning@yahoogroups.com, "Gene Ward Smith" <genewardsmith@...>
wrote:
>
> --- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aahunt@> wrote:
>
> > MIDI Notes = 12ET
>
> Manuel gets pissed when I say stuff like that. But,
> of course, out in the real world, it's true.

I'd sort of agree, in that theoretically, a MIDI Note number can be
any pitch. But when I had a fretless MIDI guitar, the Note Number
system turned out to be pain in the butt.

Hi there,

FTS has an option to use the real time MTS sysexes to retune as many notes as need to be retuned, including possibly just a single note - useful for adaptive tuning or for fractal tunes where you don't know which pitches are going to be needed until the note is played. I've used it with the FM7. The size of the sysex depends on the number of notes to retune, and can be very small, not sure of the minimum number of bytes needed.

If relaying internally in Windows from one program to another using Midi Yoke NT then you can send a single sysex very quickly, on my laptop with windows XP, its about 0.1 milliseconds to transmit a sysex through the virtual cable, doesn't seem to depend on its size. Though a single note on takes only 0.02 milliseconds to transmit to another program.

Robert

--- In tuning@yahoogroups.com, "Gene Ward Smith" <genewardsmith@...>
wrote:
> I don't expect either of these are going to happen,
> Mr. Easy, because it ain't easy. That's just complete
> horseshit.

Man, you just have to love this list. Attitudes like this leave one
all warm and fuzzy. Let's see if Carl calls you a "nice fellow" for
this one...

Cheers,
Jon

--- In tuning@yahoogroups.com, "Jon Szanto" <jszanto@...> wrote:
>
> --- In tuning@yahoogroups.com, "Gene Ward Smith" <genewardsmith@>
> wrote:
> > I don't expect either of these are going to happen,
> > Mr. Easy, because it ain't easy. That's just complete
> > horseshit.
>
> Man, you just have to love this list. Attitudes like this leave one
> all warm and fuzzy. Let's see if Carl calls you a "nice fellow" for
> this one...

Are you under some delusion that Graham and I
are very different? And do you have a comment
to make which is remotely relevant to the topic?

--- In tuning@yahoogroups.com, "Robert walker" <robertwalker@...> wrote:
>
> Hi there,
>
> FTS has an option to use the real time MTS sysexes to retune as many
notes as need to be retuned, including possibly just a single note -
useful for adaptive tuning or for fractal tunes where you don't know
which pitches are going to be needed until the note is played.

So what happens when every note comes with an MTS retuning
command? Is that practical?

paolovalladolid wrote:
> --- In tuning@yahoogroups.com, "Gene Ward Smith" <genewardsmith@...>
> wrote:
>> --- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aahunt@> wrote:
>>
>>> MIDI Notes = 12ET
>> Manuel gets pissed when I say stuff like that. But,
>> of course, out in the real world, it's true.
> > I'd sort of agree, in that theoretically, a MIDI Note number can be
> any pitch. But when I had a fretless MIDI guitar, the Note Number
> system turned out to be pain in the butt.

Not just theoretically. Certain Roland synthesizers had some percussive sounds that were tuned to finer degrees than 12-ET, and in the general case most General MIDI systems use channel 10 for a drum kit (where the pitch of the drum doesn't have anything to do with the note number).

You might assume that MIDI note 60 = Middle C is pretty well established, but some MIDI devices use note 72 for middle C. Some keyboards have a transposition option or a fine-tuning option. So the only way to describe an actual pitch is to compare with a standard pitch reference like 440 Hz (i.e. something independent of the MIDI note number system).

Still, it's true that for most practical purposes, you can assume MIDI is 12-ET.

--- In tuning@yahoogroups.com, Herman Miller <hmiller@...> wrote:
> Not just theoretically. Certain Roland synthesizers had some percussive
> sounds that were tuned to finer degrees than 12-ET, and in the general
> case most General MIDI systems use channel 10 for a drum kit (where the
> pitch of the drum doesn't have anything to do with the note number).
>
> You might assume that MIDI note 60 = Middle C is pretty well
> established, but some MIDI devices use note 72 for middle C. Some
> keyboards have a transposition option or a fine-tuning option. So the
> only way to describe an actual pitch is to compare with a standard pitch
> reference like 440 Hz (i.e. something independent of the MIDI note
> number system).
>
> Still, it's true that for most practical purposes, you can assume MIDI
> is 12-ET.
>

Hi Hermann. All MIDI devices are suppose to use Note=60 as middle C.
It's the patches that transpose up or down an octave, which is annoying.
Bass patches often transpose down an octave, like a standard upright bass
transposes written notation, which makes some sense. For tuning,
he MIDI spec says MIDI Note 69 is assumed to be A = 440 Hz, and the
notes are expected to be tuned in 12ET. Some devices support the device
global and channel tuning RPNs, which may alter the frequency data of any
MTS messages.

Aaron Hunt
H-Pi Instruments

--- In tuning@yahoogroups.com, "Gene Ward Smith" <genewardsmith@...>
wrote:
> Are you under some delusion that Graham and I are very different?

You are actually quite different in some important aspects, and it is
too bad you can't see that.

> And do you have a comment to make which is remotely relevant to the
topic?

No, just to behavior, which I have.

--- In tuning@yahoogroups.com, "Jon Szanto" <jszanto@...> wrote:
>
> --- In tuning@yahoogroups.com, "Gene Ward Smith" <genewardsmith@>
> wrote:
> > Are you under some delusion that Graham and I are very different?
>
> You are actually quite different in some important aspects, and it is
> too bad you can't see that.

Graham may be a tad crankier than I am, but not
not by much. The difference is that you don't have
a multi-year vendetta going in that case.

Hi Gene,

> So what happens when every note comes with an MTS retuning
command? Is that practical?

Yes that's practical.

Main Disadvantage: If you tune notes one at a time then tuning tables tend to get rather scrambled eventually - e.g. pitches don't increase always as the note number increases.

Each time you have to find a free note number to tune to the desired pitch (since with MTS any midi note number can be tuned to any pitch). You can always do that of course if you have no more than 128 distinct pitches sounding at once - but after doing this for some time, maybe the number you would like to use is already taken up by a note currently in play. So in a demanding tuning situation, after a good many tunings like that you can end up with a very scrambled up tuning table.

That's no problem for the sending program. It is easy enough in software to keep track of which Midi note number needs to be sent for which desired pitch on the output synth. Also it is no problem for a user who plays keyboard tuned by the sending program. But it can be confusing for anyone who tries to play notes on the receiving synth directly.

The main advantage of doing a single big tuning table all at once is that you can tune the receiving device in a more intuitive way - e.g. that as the note numbers increase, the pitch increases.

Robert

--- In tuning@yahoogroups.com, Herman Miller <hmiller@...> wrote:
>
> paolovalladolid wrote:
> > --- In tuning@yahoogroups.com, "Gene Ward Smith" <genewardsmith@>
> > wrote:
> >> --- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aahunt@> wrote:
> >>
> >>> MIDI Notes = 12ET
> >> Manuel gets pissed when I say stuff like that. But,
> >> of course, out in the real world, it's true.
> >
> > I'd sort of agree, in that theoretically, a MIDI Note number can be
> > any pitch. But when I had a fretless MIDI guitar, the Note Number
> > system turned out to be pain in the butt.
>
> Not just theoretically. Certain Roland synthesizers had some percussive
> sounds that were tuned to finer degrees than 12-ET, and in the general
> case most General MIDI systems use channel 10 for a drum kit (where the
> pitch of the drum doesn't have anything to do with the note number).
>
> You might assume that MIDI note 60 = Middle C is pretty well

No, I don't assume this, especially as I'm trying to help someone else
test a Scala-loading tool for a certain synth.

>
> Still, it's true that for most practical purposes, you can assume MIDI
> is 12-ET.

It does seem to be designed with 12TET in mind, which leads to the
problem with fretless MIDI guitar. The idea of turning off pitch bend
to play chords in tune on that instrument without your fretting
fingers being in exactly the right places works best with 12TET.

--- In tuning@yahoogroups.com, "Gene Ward Smith" <genewardsmith@...>
wrote:
> Not as far as I know. I think Scala just does a new
> bulk dump when it needs to.

It creates one bulk dump when retuning a midi file with MTS, and
tries to put multiple single-note tuning messages together in a single
sysex message when it can when translating a seq file.

Robert wrote:
>If relaying internally in Windows from one program to another using
>Midi Yoke NT then you can send a single sysex very quickly, on my
>laptop with windows XP, its about 0.1 milliseconds to transmit a
>sysex through the virtual cable, doesn't seem to depend on its size.
>Though a single note on takes only 0.02 milliseconds to transmit to
>another program.

Still it doesn't seem desirable to send redundant single-note tuning
sysex messages with every note during a fast trill for example,
especially with a physical wire in between.

Manuel

paolovalladolid wrote:
> --- In tuning@yahoogroups.com, Herman Miller <hmiller@...> wrote:
>> paolovalladolid wrote:
>>> --- In tuning@yahoogroups.com, "Gene Ward Smith" <genewardsmith@>
>>> wrote:
>>>> --- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aahunt@> wrote:
>>>>
>>>>> MIDI Notes = 12ET
>>>> Manuel gets pissed when I say stuff like that. But,
>>>> of course, out in the real world, it's true.
>>> I'd sort of agree, in that theoretically, a MIDI Note number can be
>>> any pitch. But when I had a fretless MIDI guitar, the Note Number
>>> system turned out to be pain in the butt.
>> Not just theoretically. Certain Roland synthesizers had some percussive >> sounds that were tuned to finer degrees than 12-ET, and in the general >> case most General MIDI systems use channel 10 for a drum kit (where the >> pitch of the drum doesn't have anything to do with the note number).
>>
>> You might assume that MIDI note 60 = Middle C is pretty well > > No, I don't assume this, especially as I'm trying to help someone else
> test a Scala-loading tool for a certain synth. "One" might assume..... Argh.

--- In tuning@yahoogroups.com, Herman Miller <hmiller@...> wrote:
e
> >> You might assume that MIDI note 60 = Middle C is pretty well
> >
> > No, I don't assume this, especially as I'm trying to help someone else
> > test a Scala-loading tool for a certain synth.
>
> "One" might assume..... Argh.

Wow, everyone is stressed at tax time. Sorry bout that. Have a
virtual beer on me, man.

Aaron Andrew Hunt schrieb:

> The default value for each note tuning needs to be
> in the MIDDLE, just like Pitch Bend, so that the source always remains
> as near to the original data as possible, and a source should never
> be retuned more than a quartertone up or down. You repeatedly insisted on this +- 50 cent range. May I ask why? A wider tuning range is needed if you want to get away from the 12 notes/octave paradigm.

In my own (slight) keyboard experience with 19 and 29 the "transposing octaves" posed no problem at all, certainly compared to learning all the new intervals. Your approach eliminates the possibility of having access to the complete tonal range with ETs larger than 24 (I can imagine situations where a split keyboard with up to 12 pitches for each hand is useful).

klaus

Hi Klaus. You misunderstood if you drew the conclusion that tunings
outside of 12 - 24 are impossible according to what I've said. What I
describe is a situation where any key can be mapped to any MIDI note
and be tuned + / - a quartertone from that note. This allows complete
retuning of 12 pitches to anything. All tunings are possible.

Yours,
Aaron Hunt
H-Pi Instruments

--- In tuning@yahoogroups.com, Klaus Schmirler <KSchmir@...> wrote:
>
> Aaron Andrew Hunt schrieb:
>
> > The default value for each note tuning needs to be
> > in the MIDDLE, just like Pitch Bend, so that the source always remains
> > as near to the original data as possible, and a source should never
> > be retuned more than a quartertone up or down.
>
> You repeatedly insisted on this +- 50 cent range. May I ask why? A
> wider tuning range is needed if you want to get away from the 12
> notes/octave paradigm.
>
> In my own (slight) keyboard experience with 19 and 29 the "transposing
> octaves" posed no problem at all, certainly compared to learning all
> the new intervals. Your approach eliminates the possibility of having
> access to the complete tonal range with ETs larger than 24 (I can
> imagine situations where a split keyboard with up to 12 pitches for
> each hand is useful).
>
> klaus
>

--- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aahunt@...> wrote:
>
> Hi Klaus. You misunderstood if you drew the conclusion that tunings
> outside of 12 - 24 are impossible according to what I've said. What I
> describe is a situation where any key can be mapped to any MIDI note
> and be tuned + / - a quartertone from that note.

That means + / - WITHIN a quartertone at high precision, not always
a quartertone!

Aaron Andrew Hunt schrieb:
> Hi Klaus. You misunderstood if you drew the conclusion that tunings > outside of 12 - 24 are impossible according to what I've said. What I > describe is a situation where any key can be mapped to any MIDI note > and be tuned + / - a quartertone from that note. This allows complete > retuning of 12 pitches to anything. All tunings are possible.
> I'm still not sure if I get it. You want to restrict the detuning range to get smaller incements? And set eg with 72et the same note number to 6 keys, each time with a different offset?

klaus

> Yours,
> Aaron Hunt
> H-Pi Instruments
> > --- In tuning@yahoogroups.com, Klaus Schmirler <KSchmir@...> wrote:
>> Aaron Andrew Hunt schrieb:
>>
>> > The default value for each note tuning needs to be
>>> in the MIDDLE, just like Pitch Bend, so that the source always remains
>>> as near to the original data as possible, and a source should never
>>> be retuned more than a quartertone up or down. >> You repeatedly insisted on this +- 50 cent range. May I ask why? A >> wider tuning range is needed if you want to get away from the 12 >> notes/octave paradigm.
>>
>> In my own (slight) keyboard experience with 19 and 29 the "transposing >> octaves" posed no problem at all, certainly compared to learning all >> the new intervals. Your approach eliminates the possibility of having >> access to the complete tonal range with ETs larger than 24 (I can >> imagine situations where a split keyboard with up to 12 pitches for >> each hand is useful).
>>
>> klaus

--- In tuning@yahoogroups.com, Klaus Schmirler <KSchmir@...> wrote:
> I'm still not sure if I get it. You want to restrict the detuning
> range to get smaller incements?

Correct.

> And set eg with 72et the same note
> number to 6 keys, each time with a different offset?

Yes. In your example the same source would be called for
those 6 keys, each tuned precisely within the + / - quatertone
bandwidth as an inflection of a MIDI Note = 12ET source pitch.

Yours,
Aaron Hunt
H-Pi Instruments

Aaron Andrew Hunt schrieb:
> --- In tuning@yahoogroups.com, Klaus Schmirler <KSchmir@...> wrote:
>> I'm still not sure if I get it. You want to restrict the detuning >> range to get smaller incements? > > Correct. > > >> And set eg with 72et the same note >> number to 6 keys, each time with a different offset?
> > > Yes. In your example the same source would be called for > those 6 keys, each tuned precisely within the + / - quatertone > bandwidth as an inflection of a MIDI Note = 12ET source pitch.

The advantage being ...

... that at least the software can still handle the whole 8 octave range?

... that (this immediately has me thinking of a purely microtonal music base on beats) in common practice music you'd never need two incarnations of the same note number anyway?

Have I got it?

klaus

--- In tuning@yahoogroups.com, Klaus Schmirler <KSchmir@...> wrote:
>
> Aaron Andrew Hunt schrieb:
>In your example the same source would be called for
> > those 6 keys, each tuned precisely within the + / - quatertone
> > bandwidth as an inflection of a MIDI Note = 12ET source pitch.
>
> The advantage being ...
>
> ... that at least the software can still handle the whole 8 octave range?

It should be able to do that in any case.

> ... that (this immediately has me thinking of a purely microtonal
> music base on beats) in common practice music you'd never need two
> incarnations of the same note number anyway?
>
> Have I got it?

I guess you are suggesting that each of the 6 keys in the example
above might have its own note number in some undefined system
instead of each having a 12ET note number plus tuning information.
12 pitches is the expected norm, of course. 12ET is the default
tuning for good historical, theoretical and practical reasons, and
there is no need to get rid of it. Music that requires more than the
standard incarnation of one of the 12 just makes a call to that source
and tunes it before sounding. So, if that is how you were thinking
of it, then you've got it.

Yours,
Aaron Hunt
H-Pi Instruments