Why don't we create our own damned midi standard?

Over on MMM, Aaron Hunt asked:

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

> What I am talking about is not the confusing plethora of stop-gap,
add-on, fix-it
> suggestions of MTS, though I heartily applaud everyone who has
fought for those changes,
> and I am not their enemy because we are all on the same team. Alas,
that approach has
> failed to achieve results.
>
> I'm talking about changing basic MIDI messages, changing the core
MIDI spec to cope with
> microtuning EASILY.

This arose out of a discussion of Apple's Core Audio use of a 32 bit
integer for tuning purposes. Either a 32 bit or a 21 bit (MTS style)
integer would seem to suffice.

There are open-source midi players such as tseplay. It seems to me
that with an open-source project written in a well-known language
such as C++, a decent C++ programmer (or whatever the language used
might be) is in a position to create the new standard--a midi type 3
file, let us call it--and create a relatively slight modification
which recognizes this type of file, and plays it. The difference
would simply be that instead of midi notes extending from 0 to 127,
they would extend from 0 to 2^31-1 or 2^21-1. There would be header
data which would tell the modified tseplay program what type of file
it was. And that's it.

Then, having modified an open source (or even more than one) player
to play such midi files, we put the screws on. Manuel is already a
part of the microtonal community so it's not a problem getting Scala
support. It would be nice to get Timidity and SynthFont on board, and
as many softsynths and synths as can be hosed into it. But step one,
it seems to me, is a programmer willing to write a few lines of code
modifying an open-source project and getting the damned thing to work.

Any C++ programmers out there? Other things to look at might be
PortMusic and Rosegarden. Plumstone is written in Java. And maybe
people can tell us more.

If only I knew how to assist other than deliver my heartiest
acknowledgements.

Since we are dealing with no less than 2097152 tones in such a XIDI (catchy
name, huh?) system, I am assuming multi-timbral polyphony via 2097152-tones
across 16 octaves. That would give us 131,072-EDO. Not a bad resolution, but
is it desirable? The approximation of 12-tET is this:

0: 1/1 0.000 unison, perfect prime
1: 100.003 cents 100.003
2: 199.997 cents 199.997
3: 300.000 cents 300.000
4: 400.003 cents 400.003
5: 499.997 cents 499.997
6: 600.000 cents 600.000
7: 700.003 cents 700.003
8: 799.997 cents 799.997
9: 900.000 cents 900.000
10: 1000.003 cents 1000.003
11: 1099.997 cents 1099.997
12: 2/1 1200.000 octave

Now, who would like to object to a .003 cents error? 134,217,728-EDO might
be a better approach though.

Oz.

----- Original Message -----
From: "Gene Ward Smith" <genewardsmith@sbcglobal.net>
To: <tuning@yahoogroups.com>
Sent: 27 Mart 2007 Sal� 3:24
Subject: [tuning] Why don't we create our own damned midi standard?

> Over on MMM, Aaron Hunt asked:
>
>
> --- In MakeMicroMusic@yahoogroups.com, "Aaron Andrew Hunt"
> <aahunt@...> wrote:
>
> > What I am talking about is not the confusing plethora of stop-gap,
> add-on, fix-it
> > suggestions of MTS, though I heartily applaud everyone who has
> fought for those changes,
> > and I am not their enemy because we are all on the same team. Alas,
> that approach has
> > failed to achieve results.
> >
> > I'm talking about changing basic MIDI messages, changing the core
> MIDI spec to cope with
> > microtuning EASILY.
>
> This arose out of a discussion of Apple's Core Audio use of a 32 bit
> integer for tuning purposes. Either a 32 bit or a 21 bit (MTS style)
> integer would seem to suffice.
>
> There are open-source midi players such as tseplay. It seems to me
> that with an open-source project written in a well-known language
> such as C++, a decent C++ programmer (or whatever the language used
> might be) is in a position to create the new standard--a midi type 3
> file, let us call it--and create a relatively slight modification
> which recognizes this type of file, and plays it. The difference
> would simply be that instead of midi notes extending from 0 to 127,
> they would extend from 0 to 2^31-1 or 2^21-1. There would be header
> data which would tell the modified tseplay program what type of file
> it was. And that's it.
>
> Then, having modified an open source (or even more than one) player
> to play such midi files, we put the screws on. Manuel is already a
> part of the microtonal community so it's not a problem getting Scala
> support. It would be nice to get Timidity and SynthFont on board, and
> as many softsynths and synths as can be hosed into it. But step one,
> it seems to me, is a programmer willing to write a few lines of code
> modifying an open-source project and getting the damned thing to work.
>
> Any C++ programmers out there? Other things to look at might be
> PortMusic and Rosegarden. Plumstone is written in Java. And maybe
> people can tell us more.
>
>

--- In tuning@yahoogroups.com, "Gene Ward Smith" <genewardsmith@...>
wrote:

> The difference
> would simply be that instead of midi notes extending from 0 to 127,
> they would extend from 0 to 2^31-1 or 2^21-1. There would be header
> data which would tell the modified tseplay program what type of file
> it was. And that's it.

Unless we used the new numbers to increase the range of pitches (which
I think might open up a can of worms) if we used 32 bits we would be
dividing the octave by 3*2^27 = 402653184. It's possible this is good
enough even for JI purists. One step of 402653184-edo is 2.98 * 10^(-6)
cents; at 440 Hz that gives us a step from 440 to 440.00000075744,
which has beats 15 days 6 hours and 44 minutes long. In comparison 21
bits divides the octave as 196608-edo, one step of which at 440 Hz goes
to 440.00155, giving beats of 10 minutes, 45 seconds. It seems to me 32
bits leaves pure JI enthusiasts much less to complain about.

I was excited awhile back about the ZIPI project at CNMAT, especially
its Music Parameter Description Language:
<http://www.cnmat.berkeley.edu/ZIPI/mpdl.html>. As well as somewhat
better pitch resolution, it proposed some structural changes that a
new MIDI protocol would do well to think about.

The whole project turned into OpenSoundControl which allows any
message of any size with no restraints at all about what the message
means. Lots of freedom, but it would be great to build a standard
within that for our uses. OSC allows for inter-application
communication and networking and all sorts of goodies.

Let's have an open-source project already. I'm still pretty useless as
a programmer but I have a large number of ambitious ideas for
software. So...someday.

--- In tuning@yahoogroups.com, "Gene Ward Smith" <genewardsmith@...>
wrote:
> There are open-source midi players such as tseplay. It seems to me
> that with an open-source project written in a well-known language
> such as C++, a decent C++ programmer (or whatever the language used
> might be) is in a position to create the new standard--a midi type 3
> file, let us call it--and create a relatively slight modification
> which recognizes this type of file, and plays it. The difference
> would simply be that instead of midi notes extending from 0 to 127,
> they would extend from 0 to 2^31-1 or 2^21-1. There would be header
> data which would tell the modified tseplay program what type of file
> it was. And that's it.
>
> Then, having modified an open source (or even more than one) player
> to play such midi files, we put the screws on. Manuel is already a
> part of the microtonal community so it's not a problem getting Scala
> support. It would be nice to get Timidity and SynthFont on board, and
> as many softsynths and synths as can be hosed into it. But step one,
> it seems to me, is a programmer willing to write a few lines of code
> modifying an open-source project and getting the damned thing to work.
>

--- In tuning@yahoogroups.com, "Gene Ward Smith" <genewardsmith@...>
wrote:
>
> Over on MMM, Aaron Hunt asked:
>
>
> --- In MakeMicroMusic@yahoogroups.com, "Aaron Andrew Hunt"
> <aahunt@> wrote:
>
> There are open-source midi players such as tseplay. It seems to me
> that with an open-source project written in a well-known language
> such as C++, a decent C++ programmer (or whatever the language used
> might be) is in a position to create the new standard--a midi type
> 3 file, let us call it--and create a relatively slight modification
> which recognizes this type of file, and plays it. The difference
> would simply be that instead of midi notes extending from 0 to 127,
> they would extend from 0 to 2^31-1 or 2^21-1. There would be header
> data which would tell the modified tseplay program what type of
> file it was. And that's it.
>
> Then, having modified an open source (or even more than one) player
> to play such midi files, we put the screws on. Manuel is already a
> part of the microtonal community so it's not a problem getting
> Scala support. It would be nice to get Timidity and SynthFont on
> board, and as many softsynths and synths as can be hosed into it.
> But step one, it seems to me, is a programmer willing to write a
> few lines of code modifying an open-source project and getting the
> damned thing to work.
>
> Any C++ programmers out there? Other things to look at might be
> PortMusic and Rosegarden. Plumstone is written in Java. And maybe
> people can tell us more.
>

I would be a C++ programmer - if I had the time :-(... Anyway, here
are my thoughts on the subject, where I could imagine participating:

I do not see much sense in just creating a replacement for midi - any
program that wants to be something broadly usable would have to
produce standard MIDI in the end. What I could imagine is some
intermediate format or abstract format and some conversion standard
truning the intermediate into standard midi - which, as is known,
already supports microtones using pitch-bends. The tedious thing is
just to get the pitch-bends in; here I would see some software -
maybe some extension or derivation of what Scala already does!
Another variant that I would like to have is some mapping of the
notes of each midi channel to several midi channels, for synthesizers
that support detuning of 12-tone scales only, but one for each midi
channel.

Anyway, AFAIK, there is quite some amount of software already
available doing some sort of this - Scala, on one side, and also
Blue, that editor for Csound which has a Scala-compatible piano roll.
I imagine something like this - just producing standard Midi, maybe
even in real-time (and, ideally, small latency)... I have been
thinking about trying to modify Presto (http://tamw.atari-
users.net/presto.htm) into this direction.
--
Hans Straub

Hi Hans,

--- In tuning@yahoogroups.com, "hstraub64" <hstraub64@...> wrote:

> I do not see much sense in just creating a replacement
> for midi - any program that wants to be something broadly
> usable would have to produce standard MIDI in the end.

The idea is that the new replacement for MIDI would be
entirely backwards-compatible with old MIDI, but would
have so much more capability of its own. Remember that
MIDI was created in 1983, and now try to remember what
computer technology was like back then ...

http://en.wikipedia.org/wiki/Timex_Sinclair_1000

http://en.wikipedia.org/wiki/Atari_400#The_early_machines:_400_and_800

http://en.wikipedia.org/wiki/IBM_PC

> What I could imagine is some intermediate format or
> abstract format and some conversion standard truning
> the intermediate into standard midi - which, as is known,
> already supports microtones using pitch-bends. The tedious
> thing is just to get the pitch-bends in; here I would
> see some software - maybe some extension or derivation
> of what Scala already does!

What you're describing is available with Tonescape in
its current state of development.

http://tonalsoft.com/downloads/redist/Tonescape_Studio_Den_Haag.exe

Tonescape makes it very easy to enter a score using
the mouse, using any tuning you'd like. The native
Tonescape file format contains far more data than
MIDI files, but you can export your .tonescape files
to MIDI and anything that MIDI can preserve will still
be there, except for the time-signatures.

-monz
http://tonalsoft.com
Tonescape microtonal music software

I didn't write the post below that has my name attached to it.
I've said this before; we do not need to write our own
microtuning language. All that has to happen is that the MMA
agrees to upgrade the MIDI standard in the following way:
change the Pitch Bend message from a Channel message to
a Note message. Any alternative 'standard' anybody concocts
will never be a standard, especially if it is a software-only
protocol. It has to be hardware based. Get the MMA to ratify
something as gospel, and the members of the MMA including
Roland and Yamaha and Korg will start implementing it. They
didn't do this with MTS because MTS is a grab-bag of Sysex
gobbledygook.

If you want to turn a non-microtunable synth into a microtonal
synth that you can use anywhere without hooking up to your
computer, get a Tuning Box. It also includes the most easy-to-use
tuning editor available. Download it for free and see for yourself.
http://www.h-pi.com/TBX1buy.html

Aaron Hunt
H-Pi Instruments

--- In tuning@yahoogroups.com, "hstraub64" <hstraub64@...> wrote:
>
> --- In tuning@yahoogroups.com, "Gene Ward Smith" <genewardsmith@>
> wrote:
> >
> > Over on MMM, Aaron Hunt asked:
> >
> >
> > --- In MakeMicroMusic@yahoogroups.com, "Aaron Andrew Hunt"
> > <aahunt@> wrote:
> >
> > There are open-source midi players such as tseplay. It seems to me
> > that with an open-source project written in a well-known language
> > such as C++, a decent C++ programmer (or whatever the language used
> > might be) is in a position to create the new standard--a midi type
> > 3 file, let us call it--and create a relatively slight modification
> > which recognizes this type of file, and plays it. The difference
> > would simply be that instead of midi notes extending from 0 to 127,
> > they would extend from 0 to 2^31-1 or 2^21-1. There would be header
> > data which would tell the modified tseplay program what type of
> > file it was. And that's it.
> >
> > Then, having modified an open source (or even more than one) player
> > to play such midi files, we put the screws on. Manuel is already a
> > part of the microtonal community so it's not a problem getting
> > Scala support. It would be nice to get Timidity and SynthFont on
> > board, and as many softsynths and synths as can be hosed into it.
> > But step one, it seems to me, is a programmer willing to write a
> > few lines of code modifying an open-source project and getting the
> > damned thing to work.
> >
> > Any C++ programmers out there? Other things to look at might be
> > PortMusic and Rosegarden. Plumstone is written in Java. And maybe
> > people can tell us more.
> >
>
> I would be a C++ programmer - if I had the time :-(... Anyway, here
> are my thoughts on the subject, where I could imagine participating:
>
> I do not see much sense in just creating a replacement for midi - any
> program that wants to be something broadly usable would have to
> produce standard MIDI in the end. What I could imagine is some
> intermediate format or abstract format and some conversion standard
> truning the intermediate into standard midi - which, as is known,
> already supports microtones using pitch-bends. The tedious thing is
> just to get the pitch-bends in; here I would see some software -
> maybe some extension or derivation of what Scala already does!
> Another variant that I would like to have is some mapping of the
> notes of each midi channel to several midi channels, for synthesizers
> that support detuning of 12-tone scales only, but one for each midi
> channel.
>
> Anyway, AFAIK, there is quite some amount of software already
> available doing some sort of this - Scala, on one side, and also
> Blue, that editor for Csound which has a Scala-compatible piano roll.
> I imagine something like this - just producing standard Midi, maybe
> even in real-time (and, ideally, small latency)... I have been
> thinking about trying to modify Presto (http://tamw.atari-
> users.net/presto.htm) into this direction.
> --
> Hans Straub
>

--- In tuning@yahoogroups.com, "hstraub64" <hstraub64@...> wrote:

> I do not see much sense in just creating a replacement for midi -
any
> program that wants to be something broadly usable would have to
> produce standard MIDI in the end.

You seem to be missing the point--I propose that we
adopt a minor extension of midi. It's going to happen
anyway with numbers of tracks, why not with tuning also?
The files would reasonably be considered midi files, of
which there are already several kinds.

> What I could imagine is some
> intermediate format or abstract format and some conversion standard
> truning the intermediate into standard midi - which, as is known,
> already supports microtones using pitch-bends.

It would be dead easy to convert the midi I'm proposing into a
standard midi file. Harder would be pitch bend, since that sucks,
but if the number of tracks is small that would not be a
problem either.

> The tedious thing is
> just to get the pitch-bends in; here I would see some software -
> maybe some extension or derivation of what Scala already does!

Pitch-bending is a kludge, and it's obstructing progress.

> Anyway, AFAIK, there is quite some amount of software already
> available doing some sort of this - Scala, on one side, and also
> Blue, that editor for Csound which has a Scala-compatible piano
roll.

No, not really. If there was a Scala seq file player it would
be true, but there isn't. If Timidity or SynthFont rendered
seq files it would also be true, but they don't. And a piano
roll, of all things, or Csound is irrelevant.

> I imagine something like this - just producing standard Midi, maybe
> even in real-time (and, ideally, small latency)... I have been
> thinking about trying to modify Presto (http://tamw.atari-
> users.net/presto.htm) into this direction.

What in the world do you mean by "something like this"? If
all you want to do is produce a pitch-bended midi file, Scala
can already do that.

> You seem to be missing the point--I propose that we
> adopt a minor extension of midi.

Which is?

-Carl

--- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aahunt@...> wrote:
[SNIP]
> change the Pitch Bend message from a Channel message to
> a Note message.
[SNIP]

Amen. Perfect soft solution. Could be a bit of an issue for hardware
though. What message gets sent for pitchwheel movement while there's a
5-note chord playing? For that matter, how would you handle new notes
being played while the pitchbend wheel is out of position?

--- In tuning@yahoogroups.com, "p_heddles" <p_heddles@...> wrote:
>
> --- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aahunt@> wrote:
> [SNIP]
> > change the Pitch Bend message from a Channel message to
> > a Note message.
> [SNIP]
>
> Amen. Perfect soft solution. Could be a bit of an issue for hardware
> though. What message gets sent for pitchwheel movement while there's
> a 5-note chord playing? For that matter, how would you handle new
> notes being played while the pitchbend wheel is out of position?

Pitch bend is a continuous controller. It should probably be a note
message, but it isn't well suited to use for tuning. That there
should be a 12-ET default plus pitch bends -- which also serve the
role of bending pitches -- is nonsense.

All we need is > 128 notes/channel, a standard way of transmitting
tuning data, and a way to change the tuning data of individual notes
and have them retuned either immediately, or on after their next
note-off.

Aside from the > 128 notes/channel part, I think MIDI already has all
of this.

The other problem with MIDI is the serial bus is too slow.

OSC solves that with ethernet, which is the One True Interconnect,
and I think solves everything else above, too. Everything with it is
pretty formative from what I understand, and if folks are serious
about fixing microtonality with something post-MIDI, they should
consider working on OSC.

In any case, the data standard isn't our problem. Adoption of the
standard is a greater problem. And a lack of software that we wish
would adopt the standard is the greatest.

-Carl

--- In tuning@yahoogroups.com, "Carl Lumma" <clumma@...> wrote:
>
> > You seem to be missing the point--I propose that we
> > adopt a minor extension of midi.
>
> Which is?

A midi file type where note numbers are long ints
or unsigned long ints, running from 0 to 2^32-1
instead of 0 to 2^7-1. There's no longer any
technical reason not to, and using only 128 note
numbers creates an ugly mess.

The point is--and Manuel agrees on this point, he
tells me--a change like that in an open source project
would not be terribly difficult. I suggest we go the
Nike route and Just Do It.

How do we find applications programmers who could be
enticed to do it? I've been considering email to the
tse3 people asking if they would do it.

--- In tuning@yahoogroups.com, "p_heddles" <p_heddles@...> wrote:
>
> --- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aahunt@> wrote:
> [SNIP]
> > change the Pitch Bend message from a Channel message to
> > a Note message.
> [SNIP]
>
> Amen. Perfect soft solution.

Not really, but it's certainly an alternative. I think
my proposal would be easier to implement, and would
be less trouble.

And, pitch bend is a kludge and always will be.

--- In tuning@yahoogroups.com, "Carl Lumma" <clumma@...> wrote:

> In any case, the data standard isn't our problem. Adoption of the
> standard is a greater problem. And a lack of software that we wish
> would adopt the standard is the greatest.

That's why I suggest the Just Do It approach. Get one piece of
software using long ints for note numbers, and it becomes easier
to get another.

I fully support this new trend.

----- Original Message -----
From: "Gene Ward Smith" <genewardsmith@sbcglobal.net>
To: <tuning@yahoogroups.com>
Sent: 02 Nisan 2007 Pazartesi 21:37
Subject: [tuning] Re: Why don't we create our own damned midi standard?

> --- In tuning@yahoogroups.com, "Carl Lumma" <clumma@...> wrote:
>
>
> > In any case, the data standard isn't our problem. Adoption of the
> > standard is a greater problem. And a lack of software that we wish
> > would adopt the standard is the greatest.
>
> That's why I suggest the Just Do It approach. Get one piece of
> software using long ints for note numbers, and it becomes easier
> to get another.
>
>
>

Gene Ward Smith schrieb:
> --- In tuning@yahoogroups.com, "Carl Lumma" <clumma@...> wrote:
> > >> In any case, the data standard isn't our problem. Adoption of the
>> standard is a greater problem. And a lack of software that we wish
>> would adopt the standard is the greatest.
> > That's why I suggest the Just Do It approach. Get one piece of
> software using long ints for note numbers, and it becomes easier
> to get another.

Don't all or a sizable portion of the softsynths already use floating point for pitches, with the integer part corresponding to note numbers and the decimal part to cents? All that's missing is something to control them at that level from the outside ... until you want your software to do automatic notation and your pitch is more than 100 cent off the nominal note. Of course, that could be handled by channels again, where one'd put some notes on a transposing channel. Monz, can Tonescape do this?

You may all be talking about exactly this all along, but I wasn't sure, since you don't mention that software exists.

klaus

> > > You seem to be missing the point--I propose that we
> > > adopt a minor extension of midi.
> >
> > Which is?
>
> A midi file type where note numbers are long ints
> or unsigned long ints, running from 0 to 2^32-1
> instead of 0 to 2^7-1. There's no longer any
> technical reason not to, and using only 128 note
> numbers creates an ugly mess.

Do you intend these to convey pitch? I think they
should only convey note number, which the synth should
then look up in a tuning table...

-Carl

--- In tuning@yahoogroups.com, "Carl Lumma" <clumma@...> wrote:

> Pitch bend is a continuous controller. It should probably be a note
> message, but it isn't well suited to use for tuning.

Pitch Bend isn't classified as a continuous controller; it's a basic
channel message in the same category as Note ON / Note OFF.
If updated from a 2 byte to a 3 byte message, or better yet
if the Note message is updated to a 4 byte message which includes
(optional) Pitch Bend values for every note, you see it will be suited
just fine to use for tuning. As it is, it requires dynamic channel
allocation as is done with current H-Pi microtonal hardware.
We don't need another language; we just need to update MIDI.

> That there
> should be a 12-ET default plus pitch bends -- which also serve the
> role of bending pitches -- is nonsense.

No, for musicians it certainly is not nonsense. There is very sound
theoretical and practical logic in using 12, and 12 as a basis is not
going to go away, what with several centuries of literature requiring it,
and all standard keyboard, fretted and keyed musical instruments
still being built for it, again for good reason.

> The other problem with MIDI is the serial bus is too slow.

Yes, and this is reason for abandoning it? Just upgrade the spec
and make it backward compatible.

> OSC solves that with ethernet, which is the One True Interconnect,
> and I think solves everything else above, too. Everything with it is
> pretty formative from what I understand, and if folks are serious
> about fixing microtonality with something post-MIDI, they should
> consider working on OSC.

OSC is great for things which won't be compatible with anything
else. It won't help the cause for a better MIDI standard. Nor will a
new software protocol. Consider the many different Java and C based
languages for synthesis which have not had any impact at all on
MIDI. For better or worse, MIDI rules the electronic instrument world
and MIDI is what needs to be updated.

By the way, if you happen to be browsing the magazines at your local
bookstore, check out the April issue of Keyboard magazine. On page
19 in the NEW GEAR column you'll see a Tonal Plexus.

Cheers,
Aaron Hunt
H-Pi Instruments
www.h-pi.com

--- In tuning@yahoogroups.com, "p_heddles" <p_heddles@...> wrote:

>What message gets sent for pitchwheel movement while there's a
> 5-note chord playing? For that matter, how would you handle new notes
> being played while the pitchbend wheel is out of position?

My suggestion: keep the current pitch bend as it is for the pitch wheel;
It will always be a channel message and bend all notes on a channel.

What I mean by changing Pitch Bend to a note message is this:
depricate the old 3 byte Note ON / Note OFF messages (still
support it, but depricate it officially) and create a new Note
message of 5 bytes to include the Tuning in two data bytes.
MIDI messages are in the form of a status byte followed by
data bytes; the status byte tells the synth the type of message
and which MIDI Channel the message is sent to. The data bytes
of the new Note message give the Note number, Tuning MSB,
Tuning LSB, and finally velocity. Synths will need to process
a Note tuning before turning the Note ON, and will likely have
to supply some milliseconds delay for this to be done without
audible bending.

New 5 byte Note message:

1NNNnnnn 0nnnnnnn 0ccccccc 0fffffff 0vvvvvvv

1 = status byte, NNN = the new Note message ID
n = note number, c = tuning coarse MSB, f = tuning fine LSB
v = velocity

There are in fact Sysex messages which do something like this
already, but they don't solve the problem because they are proprietary
sysex messages supported by almost nobody. Once a basic message is
officially depricated, to be replaced by a new standard, the new
standard will be adopted.

Yours,
Aaron Hunt
H-Pi Instruments

--- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aahunt@...> wrote:
>
> I didn't write the post below that has my name attached to it.

Seems I did not delete enoguh lines. Sorry about that.

> I've said this before; we do not need to write our own
> microtuning language. All that has to happen is that the MMA
> agrees to upgrade the MIDI standard in the following way:
> change the Pitch Bend message from a Channel message to
> a Note message. Any alternative 'standard' anybody concocts
> will never be a standard, especially if it is a software-only
> protocol. It has to be hardware based. Get the MMA to ratify
> something as gospel, and the members of the MMA including
> Roland and Yamaha and Korg will start implementing it.

I imagine they ask who needs that at all. Many synthesizers nowadays
already do support retuning - the only remaining thing is the limited
number of pitches.
And even if they would start implementing it, it would be for new
synths only...

> If you want to turn a non-microtunable synth into a microtonal
> synth that you can use anywhere without hooking up to your
> computer, get a Tuning Box. It also includes the most easy-to-use
> tuning editor available. Download it for free and see for yourself.
> http://www.h-pi.com/TBX1buy.html
>

Looks like a fancy thing! Seems, however, not to solve the problem of
the limited number of pitches, does it?
--
Hans Straub

----- Original Message -----
From: "Aaron Andrew Hunt" <aahunt@h-pi.com>
To: <tuning@yahoogroups.com>
Sent: 03 Nisan 2007 Sal� 6:20
Subject: [tuning] Re: Why don't we create our own damned midi standard?

> --- In tuning@yahoogroups.com, "p_heddles" <p_heddles@...> wrote:
>
> >What message gets sent for pitchwheel movement while there's a
> > 5-note chord playing? For that matter, how would you handle new notes
> > being played while the pitchbend wheel is out of position?
>
>
> My suggestion: keep the current pitch bend as it is for the pitch wheel;
> It will always be a channel message and bend all notes on a channel.
>

This is unacceptable and detrimental to microtonality. Each channel should
be assigned an immense equal resolution out of which any subset should be
extractable. Pitch-bend would then be merely a continuous reassignment of a
particular note on that channel.

SNIP

Apparently you didn't read the rest of my post.

--- In tuning@yahoogroups.com, "Ozan Yarman" <ozanyarman@...> wrote:
>
>
> ----- Original Message -----
> From: "Aaron Andrew Hunt" <aahunt@...>
> To: <tuning@yahoogroups.com>
> Sent: 03 Nisan 2007 Salý 6:20
> Subject: [tuning] Re: Why don't we create our own damned midi standard?
>
>
> > --- In tuning@yahoogroups.com, "p_heddles" <p_heddles@> wrote:
> >
> > >What message gets sent for pitchwheel movement while there's a
> > > 5-note chord playing? For that matter, how would you handle new notes
> > > being played while the pitchbend wheel is out of position?
> >
> >
> > My suggestion: keep the current pitch bend as it is for the pitch wheel;
> > It will always be a channel message and bend all notes on a channel.
> >
>
> This is unacceptable and detrimental to microtonality. Each channel should
> be assigned an immense equal resolution out of which any subset should be
> extractable. Pitch-bend would then be merely a continuous reassignment of a
> particular note on that channel.
>
> SNIP
>

You mean limited to 128 per channel? TBX1 receives over 4 channels, so each tuning table
has 512 pitches (128 x 4 layers), and all of these pitches are tunable to whatever you want
them to be.

Aaron Hunt
H-Pi Instruments

--- In tuning@yahoogroups.com, "hstraub64" <hstraub64@...> wrote:
>
> --- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aahunt@> wrote:
> >
> > I didn't write the post below that has my name attached to it.
>
> Seems I did not delete enoguh lines. Sorry about that.
>
> > I've said this before; we do not need to write our own
> > microtuning language. All that has to happen is that the MMA
> > agrees to upgrade the MIDI standard in the following way:
> > change the Pitch Bend message from a Channel message to
> > a Note message. Any alternative 'standard' anybody concocts
> > will never be a standard, especially if it is a software-only
> > protocol. It has to be hardware based. Get the MMA to ratify
> > something as gospel, and the members of the MMA including
> > Roland and Yamaha and Korg will start implementing it.
>
> I imagine they ask who needs that at all. Many synthesizers nowadays
> already do support retuning - the only remaining thing is the limited
> number of pitches.
> And even if they would start implementing it, it would be for new
> synths only...
>
> > If you want to turn a non-microtunable synth into a microtonal
> > synth that you can use anywhere without hooking up to your
> > computer, get a Tuning Box. It also includes the most easy-to-use
> > tuning editor available. Download it for free and see for yourself.
> > http://www.h-pi.com/TBX1buy.html
> >
>
> Looks like a fancy thing! Seems, however, not to solve the problem of
> the limited number of pitches, does it?
> --
> Hans Straub
>

> > Pitch bend is a continuous controller. It should probably
> > be a note message, but it isn't well suited to use for tuning.
>
> Pitch Bend isn't classified as a continuous controller; it's a
> basic channel message

I'll be dog-gone: you're right.

> > That there
> > should be a 12-ET default plus pitch bends -- which also serve
> > the role of bending pitches -- is nonsense.
>
> No, for musicians it certainly is not nonsense. There is very
> sound theoretical and practical logic in using 12, and 12 as a
> basis is not going to go away, what with several centuries of
> literature requiring it, and all standard keyboard, fretted and
> keyed musical instruments still being built for it, again for
> good reason.

I'm going to have to disagree with you here.

> > The other problem with MIDI is the serial bus is too slow.
>
> Yes, and this is reason for abandoning it? Just upgrade the spec
> and make it backward compatible.

I wasn't arguing for a new standard.

> > OSC solves that with ethernet, which is the One True
> > Interconnect, and I think solves everything else above, too.
> > Everything with it is pretty formative from what I understand,
> > and if folks are serious about fixing microtonality with
> > something post-MIDI, they should consider working on OSC.
>
> OSC is great for things which won't be compatible with anything
> else.

Why do you say this? It's supported by several popular apps
that also support MIDI.

> By the way, if you happen to be browsing the magazines at your local
> bookstore, check out the April issue of Keyboard magazine. On page
> 19 in the NEW GEAR column you'll see a Tonal Plexus.

You may know that I developed the current incarnation of the
New Gear section. I didn't have anything to do with the Tonal
Plexus appearing there this month, though. But I do have an
article in the May issue. Unfortunately, Keyboard is very
hard to find on newstands in the U.S. at the moment.

-Carl

> There are in fact Sysex messages which do something like this
> already, but they don't solve the problem because they are
> proprietary sysex messages supported by almost nobody.

Are you aware of the SINGLE NOTE TUNING CHANGE (REAL-TIME)
and SINGLE NOTE TUNING CHANGE (NON REAL-TIME) messages, which
are part of the MIDI standard.

-Carl

Yes, those are exactly what I was referring to. They
are Sysex add-ons, not core messages in the spec.

Aaron Hunt
H-Pi Instruments

--- In tuning@yahoogroups.com, "Carl Lumma" <clumma@...> wrote:
>
> > There are in fact Sysex messages which do something like this
> > already, but they don't solve the problem because they are
> > proprietary sysex messages supported by almost nobody.
>
> Are you aware of the SINGLE NOTE TUNING CHANGE (REAL-TIME)
> and SINGLE NOTE TUNING CHANGE (NON REAL-TIME) messages, which
> are part of the MIDI standard.
>
> -Carl
>

--- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aahunt@...> wrote:
> You mean limited to 128 per channel? TBX1 receives over 4
> channels, so each tuning table has 512 pitches (128 x 4 layers),
> and all of these pitches are tunable to whatever you want
> them to be.

Aaron,

As a general comment, I would say: there are freely-available
programs that do pitch-bend via channel swapping. Have been
for years. Most of us have used (or at least tried) them,
and most of us are aware of the drawbacks to this approach.

You have said part of the point of the TBX1 is to have a
dedicated hardware device for doing this, and I agree that
it's nice not to have to fuss with a PC in many settings.
But I don't think I'd buy one unless it offerred another
advantage over, say, MIDI relaying in Scala. Does it?

Reason I ask: you seem to imply that the TBX1 works very
well. I venture to say that this isn't how most people would
describe their pitch-bend retuning experiences.

Have you tried other pitch-bend retuning solutions, and would
you care to compare your product to them?

-Carl

They are not proprietary. And they are supported (or so
I hear) by:

Apple Logic
Waldorf Q
Access Virus Ti
...

-Carl

> Yes, those are exactly what I was referring to. They
> are Sysex add-ons, not core messages in the spec.
>
> Aaron Hunt
> H-Pi Instruments
>
> --- In tuning@yahoogroups.com, "Carl Lumma" <clumma@> wrote:
> >
> > > There are in fact Sysex messages which do something like this
> > > already, but they don't solve the problem because they are
> > > proprietary sysex messages supported by almost nobody.
> >
> > Are you aware of the SINGLE NOTE TUNING CHANGE (REAL-TIME)
> > and SINGLE NOTE TUNING CHANGE (NON REAL-TIME) messages, which
> > are part of the MIDI standard.
> >
> > -Carl
>

Yes, sorry; wrong word. I meant just to say that they are not
core messages.

Aaron Hunt
H-Pi Instruments

--- In tuning@yahoogroups.com, "Carl Lumma" <clumma@...> wrote:
>
> They are not proprietary. And they are supported (or so
> I hear) by:
>
> Apple Logic
> Waldorf Q
> Access Virus Ti
> ...
>
> -Carl
>
> > Yes, those are exactly what I was referring to. They
> > are Sysex add-ons, not core messages in the spec.
> >
> > Aaron Hunt
> > H-Pi Instruments
> >
> > --- In tuning@yahoogroups.com, "Carl Lumma" <clumma@> wrote:
> > >
> > > > There are in fact Sysex messages which do something like this
> > > > already, but they don't solve the problem because they are
> > > > proprietary sysex messages supported by almost nobody.
> > >
> > > Are you aware of the SINGLE NOTE TUNING CHANGE (REAL-TIME)
> > > and SINGLE NOTE TUNING CHANGE (NON REAL-TIME) messages, which
> > > are part of the MIDI standard.
> > >
> > > -Carl
> >
>

I hope you can tell from my posts that I don't believe pitch
bend is the be-all, end-all. But for the time being I have
found a way to make it work very well.

In hopes that this isn't just a silly broadcast face-off, I'll
speak to your points below...

--- In tuning@yahoogroups.com, "Carl Lumma" <clumma@...> wrote:
> As a general comment, I would say: there are freely-available
> programs that do pitch-bend via channel swapping. Have been
> for years.

I know. Keyword: programs

>Most of us have used (or at least tried) them,
> and most of us are aware of the drawbacks to this approach.
>
> You have said part of the point of the TBX1 is to have a
> dedicated hardware device for doing this, and I agree that
> it's nice not to have to fuss with a PC in many settings.
> But I don't think I'd buy one unless it offerred another
> advantage over, say, MIDI relaying in Scala. Does it?
>

Yes.

(1) It doesn't require a computer

To me this is a major advantage. To people who only
work at a desktop, it may not mean a thing.

(2) It's portable and runs on batteries

You can use it for performing actual music, meaning 'live'.

(3) It works in real-time
- again, 'live'
- realtime control over which channels receive notes
- realtime control over tunings and patches
- realtime sustain pedal support

... I think that covers the basics, not being a marketing person.

> Reason I ask: you seem to imply that the TBX1 works very
> well.

Yes; I wouldn't be selling it if it didn't work very well.

> I venture to say that this isn't how most people would
> describe their pitch-bend retuning experiences.

Before TBX1, same for me.

> Have you tried other pitch-bend retuning solutions, and would
> you care to compare your product to them?

Yes, sure. My experience with other pitch-bend systems is that
they were software based, they had problems with stuck notes
and notes bending audibly after sounding, they didn't support
the sustain pedal, and generally always gave me an uneasy feeling.
I found them frustrating and inadequate.

TBX1 isn't like that. It's solid and it works. You plug it in and you
can make music and not worry about it. It feels right. It may not
be for people who already know how to send a Sysex Tuning Dump.
It is really intended for people who want an easy link to the
world of tuning, who don't have time to mess with things that
are difficult to understand and too time-consuming and too
frustrating to use.

H-Pi products in general are are easy to use, they are offered in
complete package solutions, they are compatible with the widest
range of stuff on the market, and they give results.

Yours,
Aaron Hunt
H-Pi Instruments

--- In tuning@yahoogroups.com, "Carl Lumma" <clumma@...> wrote:
> > > OSC solves that with ethernet, which is the One True
> > > Interconnect, and I think solves everything else above, too.
> > > Everything with it is pretty formative from what I understand,
> > > and if folks are serious about fixing microtonality with
> > > something post-MIDI, they should consider working on OSC.
> >
> > OSC is great for things which won't be compatible with anything
> > else.
>
> Why do you say this? It's supported by several popular apps
> that also support MIDI.

OSC is also part of the Thummer Jammer design, although the
development of the product continues to be slowed by funding difficulties:

http://www.thumtronics.com/community/forums/88/ShowPost.aspx

They are on the right track, though, as far as putting both a USB and
a MIDI Out onto the instrument.

> > Have you tried other pitch-bend retuning solutions, and would
> > you care to compare your product to them?
>
> Yes, sure. My experience with other pitch-bend systems is that
> they were software based, they had problems with stuck notes
> and notes bending audibly after sounding, they didn't support
> the sustain pedal, and generally always gave me an uneasy feeling.
> I found them frustrating and inadequate.
>
> TBX1 isn't like that. It's solid and it works. You plug it in
> and you can make music and not worry about it. It feels right.
> It may not be for people who already know how to send a Sysex
> Tuning Dump.
> It is really intended for people who want an easy link to the
> world of tuning, who don't have time to mess with things that
> are difficult to understand and too time-consuming and too
> frustrating to use.
>
> H-Pi products in general are are easy to use, they are offered in
> complete package solutions, they are compatible with the widest
> range of stuff on the market, and they give results.

I was going to say "I'll buy one", but I thought I'd better
check the price just in case it was crazy.
I wouldn't call $350 crazy, but it's too rich for my blood.
I'd buy one for < US$200.

-Carl

--- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aahunt@...> wrote:
>
> You mean limited to 128 per channel? TBX1 receives over 4 channels,
> so each tuning table has 512 pitches (128 x 4 layers), and all of
> these pitches are tunable to whatever you want
> them to be.
>

But there is still the task of assigning the pitches to different
channels - in a "normal" sequencer, I would need a separate piano roll
for each channel instead of one microtonal one. Quite tedious... Or
does TBX1 do that mapping, too? In that case, that would be a REALLY
good thing.
In case there is no sequencer that does that, I would be willing to try
programming it.
--
Hans Straub

> http://www.thumtronics.com/community/forums/88/ShowPost.aspx
>
> They are on the right track, though, as far as putting both
> a USB and a MIDI Out onto the instrument.

Yup. -C.

Not quite sure what you're asking. TBX1 routes pitches to channels,
and you choose which ones. You can also change the channels
on-the-fly if you want.

If you are recording to a sequencer you set up multiple tracks which
receive on whatever sending channels you select on TBX1. Say you
need 3 voice polyphony. You choose 3 channels on TBX1 and create
3 tracks on your sequencer receiving on those channels.

For more info, please see the TBX1 FAQ page:

http://www.h-pi.com/TBX1faq.html

Yours,
Aaron Hunt
H-Pi Instruments

--- In tuning@yahoogroups.com, "hstraub64" <hstraub64@...> wrote:
>
> --- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aahunt@> wrote:
> >
> > You mean limited to 128 per channel? TBX1 receives over 4 channels,
> > so each tuning table has 512 pitches (128 x 4 layers), and all of
> > these pitches are tunable to whatever you want
> > them to be.
> >
>
> But there is still the task of assigning the pitches to different
> channels - in a "normal" sequencer, I would need a separate piano roll
> for each channel instead of one microtonal one. Quite tedious... Or
> does TBX1 do that mapping, too? In that case, that would be a REALLY
> good thing.
> In case there is no sequencer that does that, I would be willing to try
> programming it.
> --
> Hans Straub
>

--- In tuning@yahoogroups.com, "hstraub64" <hstraub64@...> wrote:
>
> --- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aahunt@> wrote:
> >
> > You mean limited to 128 per channel? TBX1 receives over 4 channels,
> > so each tuning table has 512 pitches (128 x 4 layers), and all of
> > these pitches are tunable to whatever you want
> > them to be.
> >
>
> But there is still the task of assigning the pitches to different
> channels - in a "normal" sequencer, I would need a separate piano roll
> for each channel instead of one microtonal one. Quite tedious... Or
> does TBX1 do that mapping, too? In that case, that would be a REALLY
> good thing.

I may or may not be asking the same question, but I have been
wondering if this TBX1 has a solution for the pitch-bend/channel
problem. If you want a 4-note chord that is tuned to a specific
tuning and you want to get it done by MIDI Pitch Bend, you have to
transmit Pitch Bend on 4 separate MIDI channels - one per note of the
chord, correct? Otherwise, all 4 notes of your chord are just
pitch-bent by the same Pitch Bend message, retaining 12-tET based
intervals.

They were initially available for $297 at the pre-order discount.
I believe I sent you notice of that sometime in January.

Aaron Hunt
H-Pi Instruments

--- In tuning@yahoogroups.com, "Carl Lumma" <clumma@...> wrote:

> I wouldn't call $350 crazy, but it's too rich for my blood.
> I'd buy one for < US$200.
>
> -Carl
>

No; it's magic, but not THAT magic. TBX1 gives you all the control
you need to make multi-channel output work for you.

Aaron Hunt
H-Pi Instruments

--- In tuning@yahoogroups.com, "paolovalladolid" <phv40@...> wrote:
>
> --- In tuning@yahoogroups.com, "hstraub64" <hstraub64@> wrote:
> >
> > --- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aahunt@> wrote:
> > >
> > > You mean limited to 128 per channel? TBX1 receives over 4 channels,
> > > so each tuning table has 512 pitches (128 x 4 layers), and all of
> > > these pitches are tunable to whatever you want
> > > them to be.
> > >
> >
> > But there is still the task of assigning the pitches to different
> > channels - in a "normal" sequencer, I would need a separate piano roll
> > for each channel instead of one microtonal one. Quite tedious... Or
> > does TBX1 do that mapping, too? In that case, that would be a REALLY
> > good thing.
>
> I may or may not be asking the same question, but I have been
> wondering if this TBX1 has a solution for the pitch-bend/channel
> problem. If you want a 4-note chord that is tuned to a specific
> tuning and you want to get it done by MIDI Pitch Bend, you have to
> transmit Pitch Bend on 4 separate MIDI channels - one per note of the
> chord, correct? Otherwise, all 4 notes of your chord are just
> pitch-bent by the same Pitch Bend message, retaining 12-tET based
> intervals.
>

Hi All

A bit late mail, but I thought I'd throw this into the discussion:

In the field of experimental music software, MIDI was a terribly
reactionary protocol (even when it was made in the early 80s)
that has now been replaced by the OSC (Open Sound Control).

All the problems of MIDI melt into thin air!

http://opensoundcontrol.org/cnmat
http://www.cnmat.berkeley.edu/OpenSoundControl/

And it is supported by most programming languages and
increasingly in hardware (it can subset MIDI in its protocol
- should anyone be interested).

thor

Ok, just wanted to make sure. If I wanted to play 5 note chords but
my receiving synth can only receive on up to 4 MIDI Channels, then
some workaround would be necessary, then.

--- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aahunt@...> wrote:
>
> No; it's magic, but not THAT magic. TBX1 gives you all the control
> you need to make multi-channel output work for you.
>
> Aaron Hunt
> H-Pi Instruments
>
>
> --- In tuning@yahoogroups.com, "paolovalladolid" <phv40@> wrote:
> >
> > --- In tuning@yahoogroups.com, "hstraub64" <hstraub64@> wrote:
> > >
> > > --- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aahunt@> wrote:
> > > >
> > > > You mean limited to 128 per channel? TBX1 receives over 4
channels,
> > > > so each tuning table has 512 pitches (128 x 4 layers), and all of
> > > > these pitches are tunable to whatever you want
> > > > them to be.
> > > >
> > >
> > > But there is still the task of assigning the pitches to different
> > > channels - in a "normal" sequencer, I would need a separate
piano roll
> > > for each channel instead of one microtonal one. Quite tedious... Or
> > > does TBX1 do that mapping, too? In that case, that would be a
REALLY
> > > good thing.
> >
> > I may or may not be asking the same question, but I have been
> > wondering if this TBX1 has a solution for the pitch-bend/channel
> > problem. If you want a 4-note chord that is tuned to a specific
> > tuning and you want to get it done by MIDI Pitch Bend, you have to
> > transmit Pitch Bend on 4 separate MIDI channels - one per note of the
> > chord, correct? Otherwise, all 4 notes of your chord are just
> > pitch-bent by the same Pitch Bend message, retaining 12-tET based
> > intervals.
> >
>

--- In tuning@yahoogroups.com, "Carl Lumma" <clumma@...> wrote:

> Do you intend these to convey pitch? I think they
> should only convey note number, which the synth should
> then look up in a tuning table...

Of course they should convey pitch. Conveying note
numbers and using tuning tables is part of the problem.

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

> Pitch Bend isn't classified as a continuous controller; it's a
basic
> channel message in the same category as Note ON / Note OFF.
> If updated from a 2 byte to a 3 byte message, or better yet
> if the Note message is updated to a 4 byte message which includes
> (optional) Pitch Bend values for every note, you see it will be
suited
> just fine to use for tuning.

What would the optional pitch bend be used for--vibrato?
I can't see a real purpose for it.

> No, for musicians it certainly is not nonsense.

Tell it to Manuel. I've been trying to claim Scala
should default to 12 (at present it defaults to nothing)
but he thinks that is anti-microtonal.

A consequence is that if you take a midi file, use
Scala to convert it to a seq file, and then convert
the seq file back to a midi file--it won't play.

--- In tuning@yahoogroups.com, "Carl Lumma" <clumma@...> wrote:

> Are you aware of the SINGLE NOTE TUNING CHANGE (REAL-TIME)
> and SINGLE NOTE TUNING CHANGE (NON REAL-TIME) messages, which
> are part of the MIDI standard.

Questions:

(1) Do you know of a midi player which supports them?

(2) Do you know of a midi file renderer which supports
them?

(3) For this question we need Manuel. But I'll ask it:
can we get Scala to use the tuning information on such
a file when creating a seq file from a midi file? At
present Scala does not support using tuning data from
midi files, which is a major problem.

(4) Can we get Scala to create such midi files from seq
files?

--- In tuning@yahoogroups.com, thor <th.list@...> wrote:

> In the field of experimental music software, MIDI was a terribly
> reactionary protocol (even when it was made in the early 80s)
> that has now been replaced by the OSC (Open Sound Control).
>
> All the problems of MIDI melt into thin air!
>
> http://opensoundcontrol.org/cnmat
> http://www.cnmat.berkeley.edu/OpenSoundControl/

I can find no mention of tuning on these pages at all. Nor
do I see anything about an alternative to a midi file. If
this is going to be relevant to the question at hand, we
need both.

That was before I heard the pitch about it not suffering
from stuck notes, bent notes, sustain-pedal problems, or
latency problems.

-Carl

--- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aahunt@...> wrote:
>
> They were initially available for $297 at the pre-order discount.
> I believe I sent you notice of that sometime in January.
>
> Aaron Hunt
> H-Pi Instruments
>
>
> --- In tuning@yahoogroups.com, "Carl Lumma" <clumma@> wrote:
>
> > I wouldn't call $350 crazy, but it's too rich for my blood.
> > I'd buy one for < US$200.
> >
> > -Carl

Actually, the Yamaha FB01 from the '80s treated pitch
bends more like note messages, due to a bug according
to Jules Siegel. It allowed him to do polyphonic
microtonality on a single MIDI channel.

-Carl

--- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aahunt@...> wrote:
>
> No; it's magic, but not THAT magic. TBX1 gives you all the control
> you need to make multi-channel output work for you.
>
> Aaron Hunt
> H-Pi Instruments

//

> > I may or may not be asking the same question, but I have been
> > wondering if this TBX1 has a solution for the pitch-bend/channel
> > problem. If you want a 4-note chord that is tuned to a specific
> > tuning and you want to get it done by MIDI Pitch Bend, you have
> > to transmit Pitch Bend on 4 separate MIDI channels - one per
> > note of the chord, correct? Otherwise, all 4 notes of your
> > chord are just pitch-bent by the same Pitch Bend message,
> > retaining 12-tET based intervals.

Can you summarize your points thus far Gene? What do we expect of a
microtonal sound control standard?

----- Original Message -----
From: "Gene Ward Smith" <genewardsmith@sbcglobal.net>
To: <tuning@yahoogroups.com>
Sent: 04 Nisan 2007 �ar�amba 1:30
Subject: [tuning] Re: Why don't we create our own damned midi standard?

> --- In tuning@yahoogroups.com, thor <th.list@...> wrote:
>
> > In the field of experimental music software, MIDI was a terribly
> > reactionary protocol (even when it was made in the early 80s)
> > that has now been replaced by the OSC (Open Sound Control).
> >
> > All the problems of MIDI melt into thin air!
> >
> > http://opensoundcontrol.org/cnmat
> > http://www.cnmat.berkeley.edu/OpenSoundControl/
>
> I can find no mention of tuning on these pages at all. Nor
> do I see anything about an alternative to a midi file. If
> this is going to be relevant to the question at hand, we
> need both.
>
>

> What would the optional pitch bend be used for--vibrato?
> I can't see a real purpose for it.

You don't see the purpose of pitch bend??

-Carl

> Questions:
>
> (1) Do you know of a midi player which supports them?
>
> (2) Do you know of a midi file renderer which supports
> them?

No and no.

> (4) Can we get Scala to create such midi files from seq
> files?

I hope so.

-Carl

> > What would the optional pitch bend be used for--vibrato?
> > I can't see a real purpose for it.
>
> You don't see the purpose of pitch bend??

Incidentally, Eric Lindemann has some things to say about
the inadequacy of pitch bend for describing string parts
that make a lot of sense. Or did, back when I could
remember exactly what they were.

-Carl

More on that...
http://www.synful.com/SynfulPitchWheel.htm

-C.

--- In tuning@yahoogroups.com, "Carl Lumma" <clumma@...> wrote:
>
> > > What would the optional pitch bend be used for--vibrato?
> > > I can't see a real purpose for it.
> >
> > You don't see the purpose of pitch bend??
>
> Incidentally, Eric Lindemann has some things to say about
> the inadequacy of pitch bend for describing string parts
> that make a lot of sense. Or did, back when I could
> remember exactly what they were.
>
> -Carl

--- In tuning@yahoogroups.com, "Ozan Yarman" <ozanyarman@...> wrote:
>
> Can you summarize your points thus far Gene? What do we expect of a
> microtonal sound control standard?

One needs to know how the tuning data is written.

--- In tuning@yahoogroups.com, "Carl Lumma" <clumma@...> wrote:
>
> > What would the optional pitch bend be used for--vibrato?
> > I can't see a real purpose for it.
>
> You don't see the purpose of pitch bend??

Not when we have a better way of specifying pitch.

Gene Ward Smith wrote:
> --- In tuning@yahoogroups.com, "Carl Lumma" <clumma@...> wrote:
> >> Do you intend these to convey pitch? I think they
>> should only convey note number, which the synth should
>> then look up in a tuning table...
> > Of course they should convey pitch. Conveying note > numbers and using tuning tables is part of the problem.

Why is that a problem? If you've got a MIDI sequence in 1/5-comma meantone and you want to hear it in 1/3-comma meantone, how would you translate the pitches without a tuning table? The problem is that 128 isn't enough notes.

> > You don't see the purpose of pitch bend??
>
> Not when we have a better way of specifying pitch.

Yo crazy, dawg.

-Carl

Ozan Yarman wrote:
> ----- Original Message -----
> From: "Aaron Andrew Hunt" <aahunt@h-pi.com>
> To: <tuning@yahoogroups.com>
> Sent: 03 Nisan 2007 Sal� 6:20
> Subject: [tuning] Re: Why don't we create our own damned midi standard?
> > >> --- In tuning@yahoogroups.com, "p_heddles" <p_heddles@...> wrote:
>>
>>> What message gets sent for pitchwheel movement while there's a
>>> 5-note chord playing? For that matter, how would you handle new notes
>>> being played while the pitchbend wheel is out of position?
>>
>> My suggestion: keep the current pitch bend as it is for the pitch wheel;
>> It will always be a channel message and bend all notes on a channel.
>>
> > This is unacceptable and detrimental to microtonality. Each channel should
> be assigned an immense equal resolution out of which any subset should be
> extractable. Pitch-bend would then be merely a continuous reassignment of a
> particular note on that channel.

Depending on the instrument the pitch wheel can do different things. It's common for the pitch wheel to bend all notes on a channel, but for instance the Yamaha DX7II has a mode where only the notes that are held down are bent. It depends on whether you're trying to imitate a steel guitar or a koto. If you need more than one pitch bend at the same time in the same MIDI channel, you'd need a message that's associated with a particular key, like polyphonic aftertouch.

Using the pitch wheel as a substitute for tuning tables is really just a hack for lack of a better method that works with most existing MIDI implementations, and interferes with the use of pitch wheel messages for expression. Changing the pitch bend message to specify a single note would just be a hack that works with even fewer MIDI implementations.

Adding a new status byte for an extended Note On (with tuning data) sounds like a good idea at first, but what would existing implementations do with it? They might just ignore the status byte and treat the following data bytes as new messages, interpreting them according to the current running status. Which probably wouldn't be very useful.

Herman Miller wrote:
> Gene Ward Smith wrote:
> >>--- In tuning@yahoogroups.com, "Carl Lumma" <clumma@...> wrote:
>>
>>
>>>Do you intend these to convey pitch? I think they
>>>should only convey note number, which the synth should
>>>then look up in a tuning table...
>>
>>Of course they should convey pitch. Conveying note >>numbers and using tuning tables is part of the problem.
> > > Why is that a problem? If you've got a MIDI sequence in 1/5-comma > meantone and you want to hear it in 1/3-comma meantone, how would you > translate the pitches without a tuning table? The problem is that 128 > isn't enough notes.

16 channels per device is practical now. USB-MIDI supports it. That would give you 2,048 notes per device. The problem is that mass market products don't support it, because hardly anybody wants it, and I don't think changing MIDI would help at all. Mass market products would still ignore all but 7 bits.

Graham

Carl Lumma wrote:
> Actually, the Yamaha FB01 from the '80s treated pitch
> bends more like note messages, due to a bug according
> to Jules Siegel. It allowed him to do polyphonic
> microtonality on a single MIDI channel.

Are you sure? The FB01 had SysEx messages for retuning single notes so it was specifically designed for microtonal polyphony. Never heard about a pitch bend bug.

Graham

We do need something like that now.

----- Original Message -----
From: "Graham Breed" <gbreed@gmail.com>
To: <tuning@yahoogroups.com>
Sent: 04 Nisan 2007 �ar�amba 6:27
Subject: Re: [tuning] Re: Why don't we create our own damned midi standard?

> Carl Lumma wrote:
> > Actually, the Yamaha FB01 from the '80s treated pitch
> > bends more like note messages, due to a bug according
> > to Jules Siegel. It allowed him to do polyphonic
> > microtonality on a single MIDI channel.
>
> Are you sure? The FB01 had SysEx messages for retuning
> single notes so it was specifically designed for microtonal
> polyphony. Never heard about a pitch bend bug.
>
>
> Graham
>

> >>>Do you intend these to convey pitch? I think they
> >>>should only convey note number, which the synth should
> >>>then look up in a tuning table...
> >>
> >>Of course they should convey pitch. Conveying note
> >>numbers and using tuning tables is part of the problem.
> >
> > Why is that a problem? If you've got a MIDI sequence in 1/5-comma
> > meantone and you want to hear it in 1/3-comma meantone, how would
> > you translate the pitches without a tuning table? The problem is
> > that 128 isn't enough notes.
>
> 16 channels per device is practical now.

It was always practical. Did you mean 32?

> USB-MIDI supports it.

MIDI-over-IEEE1394 supports like, a gagillion channels.

> That would give you 2,048 notes per device. The
> problem is that mass market products don't support it,

The problem is, they wouldn't be on the same channel,
which ruins the notion that a channel should be like
a voice. You know, in music.

-Carl

My 50th of a semitone's worth of commentary.

I messed around with pitchbend for about 15 years, and still even have a 220Volt Yamaha FBO-1 and other old midi devices somewhere around.

I came to the conclusion that there were so many hassles, ambiguities, limitations and inconsistencies with pitchbend that I "wrote it off" as "only of historical interest".

It would be great if someone could actually get it to work for a complete band or orchestra of instruments, without all the old problems, but I am not holding my breath.

In the meantime I shall continue to use the "usually reliable" set of 12 different notes, repeating each octave,
and then make multiple bounces to audio before mixing if I need more than 12 different notes in a single song.

Nevertheless, I must admit that I do still like the idea of sending a complete midi tuning dump message for every note.

I am still attempting to get Apple to improve tuning resolution in Logic and to allow different tunings to be assigned to different tracks, and to make GarageBand microtunable

At present Logic Pro 7 only allows twelve different note changes to nearest cent, with repeating octaves, and applies the changes to the complete song.

see:

http://www.lucytune.com/midi_and_keyboard/pitch_bend.html

for details.

Charles Lucy lucy@lucytune.com

----- Promoting global harmony through LucyTuning -----

For information on LucyTuning go to: http://www.lucytune.com

LucyTuned Lullabies (from around the world):
http://www.lullabies.co.uk

Skype user = lucytune

Carl Lumma wrote:

>>16 channels per device is practical now.
> > It was always practical. Did you mean 32?

I mean 16. It wasn't always practical because more channels meant more physical output devices.

>>USB-MIDI supports it.
> > MIDI-over-IEEE1394 supports like, a gagillion channels.

It supports a number of devices, each of which represents a standard MIDI stream and so listens on all 16 channels. Sequencers will naturally support one device per track.

>>That would give you 2,048 notes per device. The >>problem is that mass market products don't support it,
> > The problem is, they wouldn't be on the same channel,
> which ruins the notion that a channel should be like
> a voice. You know, in music.

Yes, it ruins that notion. Who cares? You tell the synthesizer to listen for controller messages on a specific channel (or all channels) but use different notes for different channels. That's how I used Kyma. It's a twist on omni mode, and surely easier to implement than a new MIDI message.

Graham

> > Actually, the Yamaha FB01 from the '80s treated pitch
> > bends more like note messages, due to a bug according
> > to Jules Siegel. It allowed him to do polyphonic
> > microtonality on a single MIDI channel.
>
> Are you sure? The FB01 had SysEx messages for retuning
> single notes so it was specifically designed for microtonal
> polyphony. Never heard about a pitch bend bug.

"...once the note-off comes, the fb01 ignores further bend
msgs for that note. So a new note can be started after a
different bend is sent ... The multiple notes can come so
fast that they don't even sound like the arpeggios that they
actually are ... You need to use a patch with a long decay,
and not be in monophonic mode."

-C.

> >>16 channels per device is practical now.
> >
> > It was always practical. Did you mean 32?
>
> I mean 16. It wasn't always practical because more channels
> meant more physical output devices.

Correct me if I'm wrong, but the original 1983 or whenever
spec calls for up to 16 channels per bus.

> >>USB-MIDI supports it.
> >
> > MIDI-over-IEEE1394 supports like, a gagillion channels.
>
> It supports a number of devices, each of which represents a
> standard MIDI stream and so listens on all 16 channels.

Yes.

> >>That would give you 2,048 notes per device. The
> >>problem is that mass market products don't support it,
> >
> > The problem is, they wouldn't be on the same channel,
> > which ruins the notion that a channel should be like
> > a voice. You know, in music.
>
> Yes, it ruins that notion. Who cares?

I do.

-Carl

Carl Lumma wrote:
>>>>16 channels per device is practical now.
>>>
>>>It was always practical. Did you mean 32?
>>
>>I mean 16. It wasn't always practical because more channels >>meant more physical output devices.
> > Correct me if I'm wrong, but the original 1983 or whenever
> spec calls for up to 16 channels per bus.

Yes. And the higher level protocols that encapsulate MIDI still send the 4 bits for those channels even when they're redundant.

>>>>That would give you 2,048 notes per device. The >>>>problem is that mass market products don't support it,
>>>
>>>The problem is, they wouldn't be on the same channel,
>>>which ruins the notion that a channel should be like
>>>a voice. You know, in music.
>>
>>Yes, it ruins that notion. Who cares?
> > I do.

So what's so special about those 16 legacy MIDI channels?

Graham

Actually $2760 for a TPX6 sounds like a better deal in
many ways.

-Carl

--- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aahunt@...> wrote:
>
> They were initially available for $297 at the pre-order discount.
> I believe I sent you notice of that sometime in January.
>
> Aaron Hunt
> H-Pi Instruments
>
>
> --- In tuning@yahoogroups.com, "Carl Lumma" <clumma@> wrote:
>
> > I wouldn't call $350 crazy, but it's too rich for my blood.
> > I'd buy one for < US$200.
> >
> > -Carl
> >
>

> So what's so special about those 16 legacy MIDI channels?

Nothing special about 16 of them, but sprawling a single
voice over multiple channels means you need special software
to handle it, complicates knowing which notes belong
to which voice, creates a need to send lots of patch-change
messages, etc.

While we're at it, something like MusicXML seems like a
better idea, because nothing should ever be binary.

-Carla

Hi There,

You may be interested to know that there is an alternative to the current standard implementation of midi pitch bend as a message that affects all notes currently in play in the channel.

It has its disadvantages - but also has the advantage that it can be used to achieve "pitch bend polyphony " using pitch bends, without the MTS sysexes (which are prob. the best of all within the current Midi standard, but haven't had much uptake so not much coded for) and without changing the midi standard at all.

What one can do is to have a pitch bend message that only affects notes played after the message is sent and doesn't affect notes already in play.

With that way of implementing pitch bends, you can easily get "polyphonic pitch bends" - as many simultaneous pitch bends as you like in the same channel.

To make it clear - suppose you want to play a justly tuned major chord you would do the following (translated into the relevant midi messages)

Channel 1: pitch bend 0 cents
Channel 1: Note On C
Channel 1: pitch bend -14 cents
Channel 1: Note on E
Channel 1: pitch bend +2 cents
Channel 1: Note on G

All those are sent one after another in rapid succession within a millisecond or so and the synth responds by playing a justly tuned major chord.

One advantage of this is that it is actually compatible with Midi - correct me if I am wrong, I believe the midi standard doesn't specify whether or not pitch bends should affect notes already in play. The usual implementation is that it does, but an alternative implementation is that it doesn't.

My next release of Fractal Tune Smithy (FTS 3.0) has an in-built waveform player - which specialises in playing repeating single waves - i.e. theoretical pure harmonic timbres. Anyway - I've programmed it with an option to treat pitch bends in this polyphonic fashion and it works.

With this implementation of pitch bends, then you can have every one of those 128 notes with a different pitch bend if you like, and you can do it without adding to the midi standard at all - just by choosing an alternative implementation of the pitch bend message.

It has disadvantages. One disadvantage is that you can no longer use the pitch bend wheel to bend notes already in play.

Ideally one would want to combine the two - which seems to require two pitch bend messages - one to retune only the notes not yet played, and another to bend all the notes in the channel, including ones already in play as well as ones not yet played. The first one would be the one you send to retune a note to the current tuning and the second one would be the one you use to bend notes already in play - so that all notes in the channel are simultaneously bent and kept in tune with each other (e.g. to bend an entire chord at once).

The two have to be cummulative - if you have already applied a pitch bend of -14 cents to put the E in tune, then when the pitch bend wheel is in its rest position of - 0 cents - that should give you an E at 14 cents.

So - if you want to introduce a new message, you could have these two types of pitch bend message. This would require recoding because the synth would have to respond to both types of message - so would need to keep track of two types of pitch bend. But I think it may be about the smallest change you could make to midi that would work. You still have to figure out what bytes to use to send the alternative pitch bend message. Maybe add a new rpn? The rpns seem to be the easiest mechanism available in Midi to add new messages to it without the cumbersomeness of sysexes.

Another disadvantage of these "polyphonic pitch bends" is that if you want to play lots of notes simultaneously that are very close in pitch - you may run out of notes near enough to be pitch bent to position within the standard + - two semitones pitch bend range. But you can manage a few notes all within a semitone of each other - and it isn't that often that one wants to simultaneously play a cluster of more than two or three notes so close together.

Another is that this "polyphonic pitch bend" still applies to all notes that follow from then on - if you do -14 cents, then E, then 0 cents then C then play an E then the E is at 0 cents.

If you want to retune all your Es 14 cents flat, then you need to send a -14 cents pitch bend before every E that you play.

So - to address those as well - you could have another new pitch bend message which applies to only a particular midi note, as suggested.

That could be implemented using two rpns - one rpn varies the number to apply the bend to, and the other rpn sets the amount of the bend to use for the currently selected note to bend.

I'm not particularly suggesting that this particular approach is the best way ahead. It is just an illustration, maybe it illustrates the sorts of issues one would need to address to implement this sort of change at a low level.

The proposal to use ints would require more work by way of low level coding in practice, simple though it is in principle.. The midi file format is based on 7 bit integers and 8 bit bytes in a very low level way - and if you saved a midi file with ints, then there is no doubt at all it would be unplayable, and there is no way to make it playable by standard midi players as they would go through the file incrementing by 8 bits at a time, and if it was actually 16 bit ints, rather than 8 bit bytes in the file, then the file would be nonsense.

Similarly also - in Windows anyway the way programs communicate midi messages to each other is also based on 8 bit bytes and the standard message structures of Midi in a very low level way. So in order to communicate integers via Midi Out or In, then you would need to get Microsoft to recode the Windows API for midi to accept integers, which would be a big task, and midi device drivers etc would also need to be recoded.

You could have a midi file format involving ints that is only a file format used for sharing data between newly coded apps that are able to recognise it - but then the programs themselves need to be recoded to use ints when parsing the midi file. They would also need to be recoded to e.g. accept integer ranges for the variables. Also to re-parse the "new style" midi files using ints instead of bytes. I think maybe some very enthusiastic programmers might, or if their own internal format they use in their program is already for some reason very similar for some reason - happens to also use ints instead of bytes already (and particularly ints, and not floats or doubles say) - but the take up would be likely to be rather uneven.

Robert

Hi Robert.

The idea behind a change in the standard Note message is that
it solves the problem officially and hence all manufacturers will
play by the rules, actually doing something with the tuning bytes.
Your suggestion as a workaround for softsynths makes some
sense, but nobody else is using this implementation,
and MMA won't make that a standard since the opposite usage is
already standard. I'm not sure it would be worth the effort to make
something like that which will have no data compatibility with
anything else, and the development time would probably be better
spent on something else.

Yours,
Aaron Hunt
H-Pi Instruments

--- In tuning@yahoogroups.com, "Robert walker" <robertwalker@...> wrote:
>
> Hi There,
>
> You may be interested to know that there is an alternative to the current standard
implementation of midi pitch bend as a message that affects all notes currently in play in
the channel.
>
> It has its disadvantages - but also has the advantage that it can be used to achieve
"pitch bend polyphony " using pitch bends, without the MTS sysexes (which are prob. the
best of all within the current Midi standard, but haven't had much uptake so not much
coded for) and without changing the midi standard at all.
>
> What one can do is to have a pitch bend message that only affects notes played after the
message is sent and doesn't affect notes already in play.
>
> With that way of implementing pitch bends, you can easily get "polyphonic pitch bends"
- as many simultaneous pitch bends as you like in the same channel.
>
> To make it clear - suppose you want to play a justly tuned major chord you would do
the following (translated into the relevant midi messages)
>
> Channel 1: pitch bend 0 cents
> Channel 1: Note On C
> Channel 1: pitch bend -14 cents
> Channel 1: Note on E
> Channel 1: pitch bend +2 cents
> Channel 1: Note on G
>
> All those are sent one after another in rapid succession within a millisecond or so and
the synth responds by playing a justly tuned major chord.
>
> One advantage of this is that it is actually compatible with Midi - correct me if I am
wrong, I believe the midi standard doesn't specify whether or not pitch bends should affect
notes already in play. The usual implementation is that it does, but an alternative
implementation is that it doesn't.
>
> My next release of Fractal Tune Smithy (FTS 3.0) has an in-built waveform player -
which specialises in playing repeating single waves - i.e. theoretical pure harmonic
timbres. Anyway - I've programmed it with an option to treat pitch bends in this
polyphonic fashion and it works.
>
> With this implementation of pitch bends, then you can have every one of those 128
notes with a different pitch bend if you like, and you can do it without adding to the midi
standard at all - just by choosing an alternative implementation of the pitch bend
message.
>
> It has disadvantages. One disadvantage is that you can no longer use the pitch bend
wheel to bend notes already in play.
>
> Ideally one would want to combine the two - which seems to require two pitch bend
messages - one to retune only the notes not yet played, and another to bend all the notes
in the channel, including ones already in play as well as ones not yet played. The first one
would be the one you send to retune a note to the current tuning and the second one
would be the one you use to bend notes already in play - so that all notes in the channel
are simultaneously bent and kept in tune with each other (e.g. to bend an entire chord at
once).
>
> The two have to be cummulative - if you have already applied a pitch bend of -14 cents
to put the E in tune, then when the pitch bend wheel is in its rest position of - 0 cents -
that should give you an E at 14 cents.
>
> So - if you want to introduce a new message, you could have these two types of pitch
bend message. This would require recoding because the synth would have to respond to
both types of message - so would need to keep track of two types of pitch bend. But I
think it may be about the smallest change you could make to midi that would work. You
still have to figure out what bytes to use to send the alternative pitch bend message.
Maybe add a new rpn? The rpns seem to be the easiest mechanism available in Midi to add
new messages to it without the cumbersomeness of sysexes.
>
> Another disadvantage of these "polyphonic pitch bends" is that if you want to play lots
of notes simultaneously that are very close in pitch - you may run out of notes near
enough to be pitch bent to position within the standard + - two semitones pitch bend
range. But you can manage a few notes all within a semitone of each other - and it isn't
that often that one wants to simultaneously play a cluster of more than two or three notes
so close together.
>
> Another is that this "polyphonic pitch bend" still applies to all notes that follow from
then on - if you do -14 cents, then E, then 0 cents then C then play an E then the E is at 0
cents.
>
> If you want to retune all your Es 14 cents flat, then you need to send a -14 cents pitch
bend before every E that you play.
>
> So - to address those as well - you could have another new pitch bend message which
applies to only a particular midi note, as suggested.
>
> That could be implemented using two rpns - one rpn varies the number to apply the
bend to, and the other rpn sets the amount of the bend to use for the currently selected
note to bend.
>
> I'm not particularly suggesting that this particular approach is the best way ahead. It is
just an illustration, maybe it illustrates the sorts of issues one would need to address to
implement this sort of change at a low level.
>
> The proposal to use ints would require more work by way of low level coding in practice,
simple though it is in principle.. The midi file format is based on 7 bit integers and 8 bit
bytes in a very low level way - and if you saved a midi file with ints, then there is no doubt
at all it would be unplayable, and there is no way to make it playable by standard midi
players as they would go through the file incrementing by 8 bits at a time, and if it was
actually 16 bit ints, rather than 8 bit bytes in the file, then the file would be nonsense.
>
> Similarly also - in Windows anyway the way programs communicate midi messages to
each other is also based on 8 bit bytes and the standard message structures of Midi in a
very low level way. So in order to communicate integers via Midi Out or In, then you would
need to get Microsoft to recode the Windows API for midi to accept integers, which would
be a big task, and midi device drivers etc would also need to be recoded.
>
> You could have a midi file format involving ints that is only a file format used for sharing
data between newly coded apps that are able to recognise it - but then the programs
themselves need to be recoded to use ints when parsing the midi file. They would also
need to be recoded to e.g. accept integer ranges for the variables. Also to re-parse the
"new style" midi files using ints instead of bytes. I think maybe some very enthusiastic
programmers might, or if their own internal format they use in their program is already for
some reason very similar for some reason - happens to also use ints instead of bytes
already (and particularly ints, and not floats or doubles say) - but the take up would be
likely to be rather uneven.
>
> Robert
>

Robert, your suggestion does not appeal to me for reasons you already stated as disadvantages. Synchronous playing is sacrificed, or at least latency is introduced. Is it so impossible to implement a humonguous tuning table out of which any number of notes may be mapped to a Midi controller? I am thinking in line with Gene of an equal division of the entire compass so large as to be JI to all intents and purposes. As such, we can reserve pitch-bend its original function of simultaneously sliding chords in a channel. If we had, say a trillion or so equi-distant notes out of which any practical subset could be chosen and where portamenti and glissandi are indistinguishable from the real thing, then our problems would be over.

Oz.

----- Original Message -----
From: Robert walker
To: tuning@yahoogroups.com
Sent: 04 Nisan 2007 Çarşamba 14:52
Subject: [tuning] Re: Why don't we create our own damned midi standard?

Hi There,

You may be interested to know that there is an alternative to the current standard implementation of midi pitch bend as a message that affects all notes currently in play in the channel.

It has its disadvantages - but also has the advantage that it can be used to achieve "pitch bend polyphony " using pitch bends, without the MTS sysexes (which are prob. the best of all within the current Midi standard, but haven't had much uptake so not much coded for) and without changing the midi standard at all.

What one can do is to have a pitch bend message that only affects notes played after the message is sent and doesn't affect notes already in play.

With that way of implementing pitch bends, you can easily get "polyphonic pitch bends" - as many simultaneous pitch bends as you like in the same channel.

To make it clear - suppose you want to play a justly tuned major chord you would do the following (translated into the relevant midi messages)

Channel 1: pitch bend 0 cents
Channel 1: Note On C
Channel 1: pitch bend -14 cents
Channel 1: Note on E
Channel 1: pitch bend +2 cents
Channel 1: Note on G

All those are sent one after another in rapid succession within a millisecond or so and the synth responds by playing a justly tuned major chord.

One advantage of this is that it is actually compatible with Midi - correct me if I am wrong, I believe the midi standard doesn't specify whether or not pitch bends should affect notes already in play. The usual implementation is that it does, but an alternative implementation is that it doesn't.

My next release of Fractal Tune Smithy (FTS 3.0) has an in-built waveform player - which specialises in playing repeating single waves - i.e. theoretical pure harmonic timbres. Anyway - I've programmed it with an option to treat pitch bends in this polyphonic fashion and it works.

With this implementation of pitch bends, then you can have every one of those 128 notes with a different pitch bend if you like, and you can do it without adding to the midi standard at all - just by choosing an alternative implementation of the pitch bend message.

It has disadvantages. One disadvantage is that you can no longer use the pitch bend wheel to bend notes already in play.

Ideally one would want to combine the two - which seems to require two pitch bend messages - one to retune only the notes not yet played, and another to bend all the notes in the channel, including ones already in play as well as ones not yet played. The first one would be the one you send to retune a note to the current tuning and the second one would be the one you use to bend notes already in play - so that all notes in the channel are simultaneously bent and kept in tune with each other (e.g. to bend an entire chord at once).

The two have to be cummulative - if you have already applied a pitch bend of -14 cents to put the E in tune, then when the pitch bend wheel is in its rest position of - 0 cents - that should give you an E at 14 cents.

So - if you want to introduce a new message, you could have these two types of pitch bend message. This would require recoding because the synth would have to respond to both types of message - so would need to keep track of two types of pitch bend. But I think it may be about the smallest change you could make to midi that would work. You still have to figure out what bytes to use to send the alternative pitch bend message. Maybe add a new rpn? The rpns seem to be the easiest mechanism available in Midi to add new messages to it without the cumbersomeness of sysexes.

Another disadvantage of these "polyphonic pitch bends" is that if you want to play lots of notes simultaneously that are very close in pitch - you may run out of notes near enough to be pitch bent to position within the standard + - two semitones pitch bend range. But you can manage a few notes all within a semitone of each other - and it isn't that often that one wants to simultaneously play a cluster of more than two or three notes so close together.

Another is that this "polyphonic pitch bend" still applies to all notes that follow from then on - if you do -14 cents, then E, then 0 cents then C then play an E then the E is at 0 cents.

If you want to retune all your Es 14 cents flat, then you need to send a -14 cents pitch bend before every E that you play.

So - to address those as well - you could have another new pitch bend message which applies to only a particular midi note, as suggested.

That could be implemented using two rpns - one rpn varies the number to apply the bend to, and the other rpn sets the amount of the bend to use for the currently selected note to bend.

I'm not particularly suggesting that this particular approach is the best way ahead. It is just an illustration, maybe it illustrates the sorts of issues one would need to address to implement this sort of change at a low level.

The proposal to use ints would require more work by way of low level coding in practice, simple though it is in principle.. The midi file format is based on 7 bit integers and 8 bit bytes in a very low level way - and if you saved a midi file with ints, then there is no doubt at all it would be unplayable, and there is no way to make it playable by standard midi players as they would go through the file incrementing by 8 bits at a time, and if it was actually 16 bit ints, rather than 8 bit bytes in the file, then the file would be nonsense.

Similarly also - in Windows anyway the way programs communicate midi messages to each other is also based on 8 bit bytes and the standard message structures of Midi in a very low level way. So in order to communicate integers via Midi Out or In, then you would need to get Microsoft to recode the Windows API for midi to accept integers, which would be a big task, and midi device drivers etc would also need to be recoded.

You could have a midi file format involving ints that is only a file format used for sharing data between newly coded apps that are able to recognise it - but then the programs themselves need to be recoded to use ints when parsing the midi file. They would also need to be recoded to e.g. accept integer ranges for the variables. Also to re-parse the "new style" midi files using ints instead of bytes. I think maybe some very enthusiastic programmers might, or if their own internal format they use in their program is already for some reason very similar for some reason - happens to also use ints instead of bytes already (and particularly ints, and not floats or doubles say) - but the take up would be likely to be rather uneven.

Robert

Hi Aaron

Oh it does have advantages over a five byte note on message.

You don't need to change anything in the midi standard or any of the coding to communicate between applications - for instance on Windows anyway you couldn't currently send a five note midi note on message via the Windows api for midi messages as it only permits two data bytes (note number and velocity). Nor could you save it to a backwards compatible midi file, as any player parsing that file would expect a note on message to have two bytes, so after the note on would advance two bytes further through the file, and so take one or both of the extra bytes in the new message as its next time increment, and the one after that as the next status byte, and so get out of sync for parsing the whole of the rest of the file. It wouldn't just ignore the extra bytes, because to do that it would need to know that it has to advance five bytes further through the file rather than just two, and no midi player coded to use the existing standard would do that. Similar to the problem with ints.

Yet you could achieve the same effect with rpns.

Instead of sending on a five note midi note message, you send first an rpn (to add to the spec) to select the note you want to adjust the pitch for - then another one to give the amount of the pitch bend - then you play the note itself.

It sounds more clumsy on paper but it means making changes using a mechanism already available within the midi standard to allow for future expansion of the standard - the rpns. So all existing code will continue to parse it properly, and the messages can be transmitted through all existsing apis and protocols for midi without change.

It means that change only needs to be made at one point - parsing the incoming rpns and obtaining the pitch bends from them, and the note to adjust.

Also - another advantage of applying the bend to a note first then playing the note is that if you apply e.g. -14 cents pitch bend to note 64, then after that all note 64s will have that pitch bend, rather than just the current note.

I.e. in effect it can be the same or better than the note on extra bytes, with probably less work by way of extra coding for the synth programmer and the program that sends the message, and no extra work at all for midi drivers or midi file parsing.

I.e. the advantages are for low level coding reasons, even though it may seem to be inherently simpler in principle. Hope this is clear - the aim is to just show what this all looks like from the point of view of someone like myself who works with midi messages at a fairly low level of code to parse byte by byte, so that you can take account of the way of thinking that such developers would have - who would need to code for the new messages at some point down the line.

The simple pitch bend polyphony without rpns is compatible with the current midi standard, and can be very easy to code for (depending on your existing code base) and could just be added as an option as I did with FTS, so it seems there is nothing to stop any synth coder adding it in if they wish or it were asked for. But is only a partial solution.

The rpns would need a lot of further thought about whether it is the best approach, but may be one way ahead, if ones aim was to achieve the desired result with minimum changes to the midi messages, using the mechanism already existing in the standard for future expansion. It would be as flexible as the extra bytes for note ons with less extra coding required.

In my opinion, the most compatible way ahead is to encourage more use of MTS sysexes - which is already in the standard and only requires more programs to implement them. Perhaps the lack of example source code may be part of the reason why it hasn't been taken up so much?

Hope this helps.

Robert

Ozan, MIDI is serial, so Robert's suggestion does not introduce
latency. Note messages creating a chord are already being received
serially. Sure, there are more bytes according to Robert's suggestion,
but this is not a problem. Anyway, up to 30 milliseconds message
delay is not even noticable.

Aaron Hunt
H-Pi Instruments

--- In tuning@yahoogroups.com, "Ozan Yarman" <ozanyarman@...> wrote:
>
> Robert, your suggestion does not appeal to me for reasons you already stated as
disadvantages. Synchronous playing is sacrificed, or at least latency is introduced. Is it so
impossible to implement a humonguous tuning table out of which any number of notes
may be mapped to a Midi controller? I am thinking in line with Gene of an equal division of
the entire compass so large as to be JI to all intents and purposes. As such, we can reserve
pitch-bend its original function of simultaneously sliding chords in a channel. If we had,
say a trillion or so equi-distant notes out of which any practical subset could be chosen
and where portamenti and glissandi are indistinguishable from the real thing, then our
problems would be over.
>
> Oz.
>
> ----- Original Message -----
> From: Robert walker
> To: tuning@yahoogroups.com
> Sent: 04 Nisan 2007 Çarþamba 14:52
> Subject: [tuning] Re: Why don't we create our own damned midi standard?
>
>
> Hi There,
>
> You may be interested to know that there is an alternative to the current standard
implementation of midi pitch bend as a message that affects all notes currently in play in
the channel.
>
> It has its disadvantages - but also has the advantage that it can be used to achieve
"pitch bend polyphony " using pitch bends, without the MTS sysexes (which are prob. the
best of all within the current Midi standard, but haven't had much uptake so not much
coded for) and without changing the midi standard at all.
>
> What one can do is to have a pitch bend message that only affects notes played after
the message is sent and doesn't affect notes already in play.
>
> With that way of implementing pitch bends, you can easily get "polyphonic pitch
bends" - as many simultaneous pitch bends as you like in the same channel.
>
> To make it clear - suppose you want to play a justly tuned major chord you would do
the following (translated into the relevant midi messages)
>
> Channel 1: pitch bend 0 cents
> Channel 1: Note On C
> Channel 1: pitch bend -14 cents
> Channel 1: Note on E
> Channel 1: pitch bend +2 cents
> Channel 1: Note on G
>
> All those are sent one after another in rapid succession within a millisecond or so and
the synth responds by playing a justly tuned major chord.
>
> One advantage of this is that it is actually compatible with Midi - correct me if I am
wrong, I believe the midi standard doesn't specify whether or not pitch bends should affect
notes already in play. The usual implementation is that it does, but an alternative
implementation is that it doesn't.
>
> My next release of Fractal Tune Smithy (FTS 3.0) has an in-built waveform player -
which specialises in playing repeating single waves - i.e. theoretical pure harmonic
timbres. Anyway - I've programmed it with an option to treat pitch bends in this
polyphonic fashion and it works.
>
> With this implementation of pitch bends, then you can have every one of those 128
notes with a different pitch bend if you like, and you can do it without adding to the midi
standard at all - just by choosing an alternative implementation of the pitch bend
message.
>
> It has disadvantages. One disadvantage is that you can no longer use the pitch bend
wheel to bend notes already in play.
>
> Ideally one would want to combine the two - which seems to require two pitch bend
messages - one to retune only the notes not yet played, and another to bend all the notes
in the channel, including ones already in play as well as ones not yet played. The first one
would be the one you send to retune a note to the current tuning and the second one
would be the one you use to bend notes already in play - so that all notes in the channel
are simultaneously bent and kept in tune with each other (e.g. to bend an entire chord at
once).
>
> The two have to be cummulative - if you have already applied a pitch bend of -14
cents to put the E in tune, then when the pitch bend wheel is in its rest position of - 0
cents - that should give you an E at 14 cents.
>
> So - if you want to introduce a new message, you could have these two types of pitch
bend message. This would require recoding because the synth would have to respond to
both types of message - so would need to keep track of two types of pitch bend. But I
think it may be about the smallest change you could make to midi that would work. You
still have to figure out what bytes to use to send the alternative pitch bend message.
Maybe add a new rpn? The rpns seem to be the easiest mechanism available in Midi to add
new messages to it without the cumbersomeness of sysexes.
>
> Another disadvantage of these "polyphonic pitch bends" is that if you want to play lots
of notes simultaneously that are very close in pitch - you may run out of notes near
enough to be pitch bent to position within the standard + - two semitones pitch bend
range. But you can manage a few notes all within a semitone of each other - and it isn't
that often that one wants to simultaneously play a cluster of more than two or three notes
so close together.
>
> Another is that this "polyphonic pitch bend" still applies to all notes that follow from
then on - if you do -14 cents, then E, then 0 cents then C then play an E then the E is at 0
cents.
>
> If you want to retune all your Es 14 cents flat, then you need to send a -14 cents pitch
bend before every E that you play.
>
> So - to address those as well - you could have another new pitch bend message which
applies to only a particular midi note, as suggested.
>
> That could be implemented using two rpns - one rpn varies the number to apply the
bend to, and the other rpn sets the amount of the bend to use for the currently selected
note to bend.
>
> I'm not particularly suggesting that this particular approach is the best way ahead. It is
just an illustration, maybe it illustrates the sorts of issues one would need to address to
implement this sort of change at a low level.
>
> The proposal to use ints would require more work by way of low level coding in
practice, simple though it is in principle.. The midi file format is based on 7 bit integers
and 8 bit bytes in a very low level way - and if you saved a midi file with ints, then there is
no doubt at all it would be unplayable, and there is no way to make it playable by standard
midi players as they would go through the file incrementing by 8 bits at a time, and if it
was actually 16 bit ints, rather than 8 bit bytes in the file, then the file would be nonsense.
>
> Similarly also - in Windows anyway the way programs communicate midi messages to
each other is also based on 8 bit bytes and the standard message structures of Midi in a
very low level way. So in order to communicate integers via Midi Out or In, then you would
need to get Microsoft to recode the Windows API for midi to accept integers, which would
be a big task, and midi device drivers etc would also need to be recoded.
>
> You could have a midi file format involving ints that is only a file format used for
sharing data between newly coded apps that are able to recognise it - but then the
programs themselves need to be recoded to use ints when parsing the midi file. They
would also need to be recoded to e.g. accept integer ranges for the variables. Also to re-
parse the "new style" midi files using ints instead of bytes. I think maybe some very
enthusiastic programmers might, or if their own internal format they use in their program
is already for some reason very similar for some reason - happens to also use ints instead
of bytes already (and particularly ints, and not floats or doubles say) - but the take up
would be likely to be rather uneven.
>
> Robert
>

Hi Ozan,

Yes it does take just a bit more time to send the messages.

The time to send the messages is already relevant for midi note ons - in a chord of five notes, then you have to send five midi messages to play the chord, so the last message is slightly delayed with respect to the first.

If the notes just have to be relayed internally from one program to another on the same computer - or over a high speed midi connection - then the extra time isn't that important.

Typically it may add a millisecond or so every five or ten messages or so (depending on the speed of the computer). At millisecond timing, then that's the sort of timing where if you view a piano from the player's point of view you hear the relative timing of the notes differently from a listener that hears the piano from the audience, because of the speed of sound as the soundwaves traverse the piano they take a millisecond or so to travel. A chord in time to the nearest millisecond for the player (assuming the player could achieve such a thing) would no longer be in time at the millisecond level from the point of view of the audience because of the change in the geometry (the bass notes take slightly longer to reach the audience than treble notes on the millisecond level, while both take the same time to reach the player)..

(speed of sound = 340 m / second so in one millisecond sound travels about a foot).

I don't think ensembles normally manage to synchronise their notes to quite this level of accuracy - more like hundredths of a second, or maybe slightly better than that, but not quite thousandths of a second. It would be a great surprise if they could becaue they stand feet apart so sound takes milliseconds to get from one player to the other. E.g. if two players are one metre apart, the sound takes 3 ms. to get from the one to the other, so if the notes sound in time for the one player, they will sound 6 ms out of time to the other, just because of the speed of sound and the geometry of the situation.

If the notes have to go through a midi cable then the number of messages to be sent is more relevant as the protocol assumes a very slow rate of transmission of messages - in a very dense chord meant to be synchronous, if you have lots of midi messages it may get ragged just because of the time to transmit them through the cable.

With midi cables again, the size of an MTS sysex is relevant though internally within a computer it isn't so releavant as a single sysex may well be transmitted internally in not much more than the same time it takes to send a single midi message.

Yes, you could have an enormous number of notes - or you could somewhat more easily conceptually have floating point numbers for the note number - so you can send e.g. 67.01955 as your midi note number to play - somewhat similar to what is done in CSound - same effect as having huge numbers of notes but probably easier to code for and for the user to understand too.

Conceptually that approach is much better. The problem is that that involves a fundamental change to the way that midi itself works, won't be backwards compatible, and will require a lot of recoding for someone. Would need recoding of all programs that parse midi files, and of all code used to transmit midi messages from one program to another - and change in the midi standards for sending data through a midi cable. Really you would prob. be better not calling it midi any more and just say it is a new standard with a close affinity to midi.

Again, hope this helps.

Robert

Re: [tuning] Re: Why don't we create our own damned midi standard?

Robert, your suggestion does not appeal to me for reasons you already stated as disadvantages. Synchronous playing is sacrificed, or at least latency is introduced. Is it so impossible to implement a humonguous tuning table out of which any number of notes may be mapped to a Midi controller? I am thinking in line with Gene of an equal division of the entire compass so large as to be JI to all intents and purposes. As such, we can reserve pitch-bend its original function of simultaneously sliding chords in a channel. If we had, say a trillion or so equi-distant notes out of which any practical subset could be chosen and where portamenti and glissandi are indistinguishable from the real thing, then our problems would be over.

Oz.

Thanks Robert, for explaining your idea again here. If the spec
isn't changing, then NRPS or non-registered parameter numbers
would need to be used, since by definition RPNs mean something
in the spec. It could be done, both in hardware and software, as
you say. Since MIDI was created as a hardware interconnect protocol,
in response to a lack thereof, for anything MIDI I tend to think
about hardware first. A problem with this will be accessing the source
for multiple notes in small intervals, especially if it is a sample,
when the note number is the same but the tuning is different,
such as an A + 4 cents and an A - 49 cents at the same time.
In software you can work around it, but hardware?

Re: the problem you point out with the 5-byte message screwing up
existing MIDI apps, APIs, etc. Yes, but this would not happen after the
MIDI spec changes, because when the spec changes it will be
supported. MMA members will not ignore a change to basic MIDI
messages in the official spec. Microsoft and everyone else will have
to update their drivers. That's how the rest of the techno-world functions;
it's about time MIDI started working the same way.

Yours,
Aaron Hunt
H-Pi Instruments

--- In tuning@yahoogroups.com, "Robert walker" <robertwalker@...> wrote:
>
> Hi Aaron
>
> Oh it does have advantages over a five byte note on message.
>
> You don't need to change anything in the midi standard or any of the coding to
communicate between applications - for instance on Windows anyway you couldn't
currently send a five note midi note on message via the Windows api for midi messages as
it only permits two data bytes (note number and velocity). Nor could you save it to a
backwards compatible midi file, as any player parsing that file would expect a note on
message to have two bytes, so after the note on would advance two bytes further through
the file, and so take one or both of the extra bytes in the new message as its next time
increment, and the one after that as the next status byte, and so get out of sync for
parsing the whole of the rest of the file. It wouldn't just ignore the extra bytes, because to
do that it would need to know that it has to advance five bytes further through the file
rather than just two, and no midi player coded to use the existing standard would do that.
Similar to the problem with ints.
>
> Yet you could achieve the same effect with rpns.
>
> Instead of sending on a five note midi note message, you send first an rpn (to add to the
spec) to select the note you want to adjust the pitch for - then another one to give the
amount of the pitch bend - then you play the note itself.
>
> It sounds more clumsy on paper but it means making changes using a mechanism
already available within the midi standard to allow for future expansion of the standard -
the rpns. So all existing code will continue to parse it properly, and the messages can be
transmitted through all existsing apis and protocols for midi without change.
>
> It means that change only needs to be made at one point - parsing the incoming rpns
and obtaining the pitch bends from them, and the note to adjust.
>
> Also - another advantage of applying the bend to a note first then playing the note is
that if you apply e.g. -14 cents pitch bend to note 64, then after that all note 64s will have
that pitch bend, rather than just the current note.
>
> I.e. in effect it can be the same or better than the note on extra bytes, with probably less
work by way of extra coding for the synth programmer and the program that sends the
message, and no extra work at all for midi drivers or midi file parsing.
>
> I.e. the advantages are for low level coding reasons, even though it may seem to be
inherently simpler in principle. Hope this is clear - the aim is to just show what this all
looks like from the point of view of someone like myself who works with midi messages at
a fairly low level of code to parse byte by byte, so that you can take account of the way of
thinking that such developers would have - who would need to code for the new messages
at some point down the line.
>
> The simple pitch bend polyphony without rpns is compatible with the current midi
standard, and can be very easy to code for (depending on your existing code base) and
could just be added as an option as I did with FTS, so it seems there is nothing to stop any
synth coder adding it in if they wish or it were asked for. But is only a partial solution.
>
> The rpns would need a lot of further thought about whether it is the best approach, but
may be one way ahead, if ones aim was to achieve the desired result with minimum
changes to the midi messages, using the mechanism already existing in the standard for
future expansion. It would be as flexible as the extra bytes for note ons with less extra
coding required.
>
> In my opinion, the most compatible way ahead is to encourage more use of MTS sysexes
- which is already in the standard and only requires more programs to implement them.
Perhaps the lack of example source code may be part of the reason why it hasn't been
taken up so much?
>
> Hope this helps.
>
> Robert
>

I c

----- Original Message -----
From: "Aaron Andrew Hunt" <aahunt@h-pi.com>
To: <tuning@yahoogroups.com>
Sent: 04 Nisan 2007 �ar�amba 17:20
Subject: [tuning] Re: Why don't we create our own damned midi standard?

Ozan, MIDI is serial, so Robert's suggestion does not introduce
latency. Note messages creating a chord are already being received
serially. Sure, there are more bytes according to Robert's suggestion,
but this is not a problem. Anyway, up to 30 milliseconds message
delay is not even noticable.

Aaron Hunt
H-Pi Instruments

--- In tuning@yahoogroups.com, "Ozan Yarman" <ozanyarman@...> wrote:
>
> Robert, your suggestion does not appeal to me for reasons you already
stated as
disadvantages. Synchronous playing is sacrificed, or at least latency is
introduced. Is it so
impossible to implement a humonguous tuning table out of which any number of
notes
may be mapped to a Midi controller? I am thinking in line with Gene of an
equal division of
the entire compass so large as to be JI to all intents and purposes. As
such, we can reserve
pitch-bend its original function of simultaneously sliding chords in a
channel. If we had,
say a trillion or so equi-distant notes out of which any practical subset
could be chosen
and where portamenti and glissandi are indistinguishable from the real
thing, then our
problems would be over.
>
> Oz.
>

Robert walker wrote:
> Hi Aaron
> > Oh it does have advantages over a five byte note on message.
> > You don't need to change anything in the midi standard or
> any of the coding to communicate between applications -
> for instance on Windows anyway you couldn't currently send
> a five note midi note on message via the Windows api for
> midi messages as it only permits two data bytes (note
> number and velocity). Nor could you save it to a
> backwards compatible midi file, as any player parsing that
> file would expect a note on message to have two bytes, so
> after the note on would advance two bytes further through
> the file, and so take one or both of the extra bytes in the
> new message as its next time increment, and the one after
> that as the next status byte, and so get out of sync for
> parsing the whole of the rest of the file. It wouldn't just
> ignore the extra bytes, because to do that it would need
> to know that it has to advance five bytes further through
> the file rather than just two, and no midi player coded
> to use the existing standard would do that. Similar to the
> problem with ints.

There are deeper problems with Windows -- at least Win32. It sends the simple MIDI messages as Windows messages. So the MIDI data have to be packed into a 32-bit integer. You can't do that with a 5 byte message. It'd have to use a completely different message -- or throw away a byte.

And spot on for Standard MIDI Files. The length of messages does matter. Neither note ons nor note offs have enough bytes. If you get more data without a new message it assumes another message of the same type. That's *why* note-offs went out.

There are plenty of other contexts where MIDI streams would foul up with this proposal.

> Yet you could achieve the same effect with rpns.
<snip>
> In my opinion, the most compatible way ahead is to encourage
> more use of MTS sysexes - which is already in the standard
> and only requires more programs to implement them. Perhaps
> the lack of example source code may be part of the reason
> why it hasn't been taken up so much?

Yes. I can't really see point of these RPNs. They can be difficult to keep track of because they have to arrive in the right order. Some sequencers index everything by time, so you need to add a delay between the parts of the RPNs, which will slow down the notes. Sysexes can be whatever size you want, and have been around longer, but you need to allocate a buffer for them in Windows. That also means they can be passed around as a chunk whereas RPNs are spread over several messages. The MTS really isn't that complicated -- if you can parse sysexes you should be able to deal with it.

Graham

Aaron Andrew Hunt wrote:

> Re: the problem you point out with the 5-byte message screwing up
> existing MIDI apps, APIs, etc. Yes, but this would not happen after the
> MIDI spec changes, because when the spec changes it will be
> supported. MMA members will not ignore a change to basic MIDI
> messages in the official spec. Microsoft and everyone else will have
> to update their drivers. That's how the rest of the techno-world functions;
> it's about time MIDI started working the same way.

Huh? Wake me up when Microsoft support CSS2. Or the MFC headers parse as standard C++.

MMA members don't respond to the spec. They write the spec. Why should they agree to make such radical changes? If you have that much clout get them to add MTS to the minimum standard for the next General MIDI.

There are also plenty of semi-official or pure home-brew apps out there that work with MIDI. They're going to keep on with the classic spec because your new one's going to be a nightmare. And the users won't care. Until they meet a program that outputs a new-style file and they'll call it broken.

Graham

Yes, this was most helpful. I would like to see how you could program FTS to double pitch-bend notes on a single channel as you said. But is there no other solution that is backwards compatible?
----- Original Message -----
From: Robert walker
To: tuning@yahoogroups.com
Sent: 04 Nisan 2007 Çarşamba 17:32
Subject: [tuning] Re: Why don't we create our own damned midi standard?

Hi Ozan,

Yes it does take just a bit more time to send the messages.

The time to send the messages is already relevant for midi note ons - in a chord of five notes, then you have to send five midi messages to play the chord, so the last message is slightly delayed with respect to the first.

If the notes just have to be relayed internally from one program to another on the same computer - or over a high speed midi connection - then the extra time isn't that important.

Typically it may add a millisecond or so every five or ten messages or so (depending on the speed of the computer). At millisecond timing, then that's the sort of timing where if you view a piano from the player's point of view you hear the relative timing of the notes differently from a listener that hears the piano from the audience, because of the speed of sound as the soundwaves traverse the piano they take a millisecond or so to travel. A chord in time to the nearest millisecond for the player (assuming the player could achieve such a thing) would no longer be in time at the millisecond level from the point of view of the audience because of the change in the geometry (the bass notes take slightly longer to reach the audience than treble notes on the millisecond level, while both take the same time to reach the player)..

(speed of sound = 340 m / second so in one millisecond sound travels about a foot).

I don't think ensembles normally manage to synchronise their notes to quite this level of accuracy - more like hundredths of a second, or maybe slightly better than that, but not quite thousandths of a second. It would be a great surprise if they could becaue they stand feet apart so sound takes milliseconds to get from one player to the other. E.g. if two players are one metre apart, the sound takes 3 ms. to get from the one to the other, so if the notes sound in time for the one player, they will sound 6 ms out of time to the other, just because of the speed of sound and the geometry of the situation.

If the notes have to go through a midi cable then the number of messages to be sent is more relevant as the protocol assumes a very slow rate of transmission of messages - in a very dense chord meant to be synchronous, if you have lots of midi messages it may get ragged just because of the time to transmit them through the cable.

With midi cables again, the size of an MTS sysex is relevant though internally within a computer it isn't so releavant as a single sysex may well be transmitted internally in not much more than the same time it takes to send a single midi message.

Yes, you could have an enormous number of notes - or you could somewhat more easily conceptually have floating point numbers for the note number - so you can send e.g. 67.01955 as your midi note number to play - somewhat similar to what is done in CSound - same effect as having huge numbers of notes but probably easier to code for and for the user to understand too.

Conceptually that approach is much better. The problem is that that involves a fundamental change to the way that midi itself works, won't be backwards compatible, and will require a lot of recoding for someone. Would need recoding of all programs that parse midi files, and of all code used to transmit midi messages from one program to another - and change in the midi standards for sending data through a midi cable. Really you would prob. be better not calling it midi any more and just say it is a new standard with a close affinity to midi.

Again, hope this helps.

Robert

Re: [tuning] Re: Why don't we create our own damned midi standard?

Robert, your suggestion does not appeal to me for reasons you already stated as disadvantages. Synchronous playing is sacrificed, or at least latency is introduced. Is it so impossible to implement a humonguous tuning table out of which any number of notes may be mapped to a Midi controller? I am thinking in line with Gene of an equal division of the entire compass so large as to be JI to all intents and purposes. As such, we can reserve pitch-bend its original function of simultaneously sliding chords in a channel. If we had, say a trillion or so equi-distant notes out of which any practical subset could be chosen and where portamenti and glissandi are indistinguishable from the real thing, then our problems would be over.

Oz.

Graham, MMA members are reps of companies. You think
companies won't respond to a change in the spec agreed upon
by their own reps? Of course, the whole reason the MIDI spec
hasn't changed is that the big companies don't want it to change.

As far as Microsoft not supporting standard specifications, yes,
Microsoft features so many 'broken' protocols it boggles the mind.
I only own a PC because I have to have one for software development.

As far as clout goes, I have none! If I sound like I'm making lots of
pronouncements, I'm coming across completely wrong, as usual. I'm
just throwing out ideas. As I said, I also tend to think for hardware
rather than software, as backward as that may seem; there are still
lots of musicians who want self-contained instruments to play live.

Yours,
Aaron Hunt
H-Pi Instruments

--- In tuning@yahoogroups.com, Graham Breed <gbreed@...> wrote:
>
> Aaron Andrew Hunt wrote:
>
> > Re: the problem you point out with the 5-byte message screwing up
> > existing MIDI apps, APIs, etc. Yes, but this would not happen after the
> > MIDI spec changes, because when the spec changes it will be
> > supported. MMA members will not ignore a change to basic MIDI
> > messages in the official spec. Microsoft and everyone else will have
> > to update their drivers. That's how the rest of the techno-world functions;
> > it's about time MIDI started working the same way.
>
> Huh? Wake me up when Microsoft support CSS2. Or the MFC
> headers parse as standard C++.
>
> MMA members don't respond to the spec. They write the spec.
> Why should they agree to make such radical changes? If
> you have that much clout get them to add MTS to the minimum
> standard for the next General MIDI.
>
> There are also plenty of semi-official or pure home-brew
> apps out there that work with MIDI. They're going to keep
> on with the classic spec because your new one's going to be
> a nightmare. And the users won't care. Until they meet a
> program that outputs a new-style file and they'll call it
> broken.
>
>
> Graham
>

--- In tuning@yahoogroups.com, Charles Lucy <lucy@...> wrote:

> It would be great if someone could actually get it [pitch bend]
> to work for a
> complete band or orchestra of instruments, without all the old
> problems, but I am not holding my breath.

It does work, Charles. 16 channels = 15 monophonic lines with
15 timbres plus percussion. If you need more than that, you can
use multiple synths. There are many examples on the H-Pi website
of working this way using H-Pi gear, which deals with the old
problems for you.

Aaron Hunt
H-Pi Instruments
http://www.h-pi.com

Now to get reactions (and sales) ;-)

http://profile.myspace.com/index.cfm?fuseaction=user.viewprofile&friendid=34603529

Charles Lucy lucy@lucytune.com

----- Promoting global harmony through LucyTuning -----

For information on LucyTuning go to: http://www.lucytune.com

LucyTuned Lullabies (from around the world):
http://www.lullabies.co.uk

Skype user = lucytune

> Ozan, MIDI is serial, so Robert's suggestion does not introduce
> latency. Note messages creating a chord are already being received
> serially. Sure, there are more bytes according to Robert's
> suggestion, but this is not a problem. Anyway, up to 30
> milliseconds message delay is not even noticable.

I don't know what you mean by "message delay", but 30 ms
delays are extremely obvious in musical applications. 5ms
is a widely understood threshold of acceptable latency.

-Carl

Um, no. The JND is often placed as high as 35 ms.
But based on the fact that you are 10 feet tall and have
green skin (if I'm remembering the description published in
Keyboard Magazine in the Haken Continuum review correctly),
your super-human, freak-of-nature ability to find 30 millisecond
serial message delays "extremely obvious" doesn't surprise me.
At least you do concede that 5 ms is not noticable.

Aaron Hunt
H-Pi Instruments

--- In tuning@yahoogroups.com, "Carl Lumma" <clumma@...> wrote:
>
> > Ozan, MIDI is serial, so Robert's suggestion does not introduce
> > latency. Note messages creating a chord are already being received
> > serially. Sure, there are more bytes according to Robert's
> > suggestion, but this is not a problem. Anyway, up to 30
> > milliseconds message delay is not even noticable.
>
> I don't know what you mean by "message delay", but 30 ms
> delays are extremely obvious in musical applications. 5ms
> is a widely understood threshold of acceptable latency.
>
> -Carl
>

--- In tuning@yahoogroups.com, "Ozan Yarman" <ozanyarman@...> wrote:
>
> Robert, your suggestion does not appeal to me for reasons you already
stated as disadvantages. Synchronous playing is sacrificed, or at least
latency is introduced. Is it so impossible to implement a humonguous
tuning table out of which any number of notes may be mapped to a Midi
controller? I am thinking in line with Gene of an equal division of the
entire compass so large as to be JI to all intents and purposes.

Here's a question for Robert: how hard would it be to get FTS
to play a 32-bit standard midi file?

> Tell it to Manuel. I've been trying to claim Scala
> should default to 12 (at present it defaults to nothing)
> but he thinks that is anti-microtonal.

I've been trying to get Gene to type "equal 12" in order to specify
that he's going to assume 12-equal but he finds that so much work it's
driving him nuts.

Manuel

--- In tuning@yahoogroups.com, "Gene Ward Smith" <genewardsmith@...>
wrote:
> > Are you aware of the SINGLE NOTE TUNING CHANGE (REAL-TIME)
> > and SINGLE NOTE TUNING CHANGE (NON REAL-TIME) messages, which
> > are part of the MIDI standard.
>
> Questions:
>
> (1) Do you know of a midi player which supports them?

Timidity supports single note change real-time.

> (2) Do you know of a midi file renderer which supports
> them?

Idem.

> (3) For this question we need Manuel. But I'll ask it:
> can we get Scala to use the tuning information on such
> a file when creating a seq file from a midi file? At
> present Scala does not support using tuning data from
> midi files, which is a major problem.

You could get a bookkeeping program to administer which
scl and kbm files were used to make which midi files. Why would
you want to retrieve quantised raw tuning data from midi
files? I haven't seen you giving a single convincing use case yet.

> (4) Can we get Scala to create such midi files from seq
> files?

Already possible, it uses single note change real-time.

Manuel

Hi Gene,

The main problem is how to advance through the midi file. At present when you find a midi note on message, you know that you have to advance two data bytes after the status byte to find the next time increment.

If you look at a hex dump of a midi file - there are no "punctuation marks" to show where one event ends and the next begins. So if you advance two bytes in the file when it should be four bytes, then you will interpret whatever you see next in the file as a time delta.

So the short answer is there is no such thing as a 32 bit standard midi file because the midi file standard doesn't include the flexibility to have 32 bit ints included in it. The reason for that is that it isn't a tagged format like html - there is no punctuation in it. Nor do any of the messages have any element to say how many bytes there are to expect - if the note on message was in the form Note on, 2, byte 1, byte 2, where the 2 there says to expect two data bytes to follow it, then it would be an easy matter to replace the 2 there by a 4, or 5 or whatever you like. But it is just in the form of <note on + channel as single byte> <data byte> <data byte>.

This comes up if you hand code the parsing of a midi file - if you get something wrong while coding it, e.g. think that a particular message should be 2 bytes when in fact it is 1 byte in the spec - then not only does that particular message get garbled - but the whole of the rest of the midi file is also garbled in your parsing, and no longer makes sense, just a lot of nonsense bytes.

So - the short answer is that when they wrote the midi file spec they didn't write in any flexibility into it to allow future developers to change the length of the messages so therefore we can't do it now. The only way to do it is to change the midi fiile spec to a more flexible format - which then wwould no longer be a standard midi file.

Hope this helps!

Robert

Just use a conditional to parse the Note ON message.
When it is found, either expect this or that; 2 more bytes,
or 4 mour bytes, or whatever, and act accordingly. Of course,
whenever I say something like this to my chief engineer
he tells me that the microcontroller has to be 5 times faster in
order not to slow things down if something like this is to be done
in hardware in realtime. But for parsing a file, I don't see what
the problem could possibly be. You've got buffers and huge
processor power.

Aaron Hunt
H-Pi Instruments

--- In tuning@yahoogroups.com, "Robert walker" <robertwalker@...> wrote:
>
> Hi Gene,
>
> The main problem is how to advance through the midi file. At present when you find a
midi note on message, you know that you have to advance two data bytes after the status
byte to find the next time increment.
>
> If you look at a hex dump of a midi file - there are no "punctuation marks" to show
where one event ends and the next begins. So if you advance two bytes in the file when it
should be four bytes, then you will interpret whatever you see next in the file as a time
delta.
>
> So the short answer is there is no such thing as a 32 bit standard midi file because the
midi file standard doesn't include the flexibility to have 32 bit ints included in it. The
reason for that is that it isn't a tagged format like html - there is no punctuation in it. Nor
do any of the messages have any element to say how many bytes there are to expect - if
the note on message was in the form Note on, 2, byte 1, byte 2, where the 2 there says to
expect two data bytes to follow it, then it would be an easy matter to replace the 2 there
by a 4, or 5 or whatever you like. But it is just in the form of <note on + channel as
single byte> <data byte> <data byte>.
>
> This comes up if you hand code the parsing of a midi file - if you get something wrong
while coding it, e.g. think that a particular message should be 2 bytes when in fact it is 1
byte in the spec - then not only does that particular message get garbled - but the whole
of the rest of the midi file is also garbled in your parsing, and no longer makes sense, just
a lot of nonsense bytes.
>
> So - the short answer is that when they wrote the midi file spec they didn't write in any
flexibility into it to allow future developers to change the length of the messages so
therefore we can't do it now. The only way to do it is to change the midi fiile spec to a
more flexible format - which then wwould no longer be a standard midi file.
>
> Hope this helps!
>
> Robert
>

> Um, no. The JND is often placed as high as 35 ms.

Citation? I've measured it with test equipment by the
way, and with various audio device drivers. You're um,
how you say, wrong.

-Carl

--- In tuning@yahoogroups.com, "Manuel Op de Coul"
<manuel.op.de.coul@...> wrote:

> > (1) Do you know of a midi player which supports them?
>
> Timidity supports single note change real-time.

Does Scala? If so, why doesn't pitch bending work
better than it seems to? What's the biggest problem
now?

> > (3) For this question we need Manuel. But I'll ask it:
> > can we get Scala to use the tuning information on such
> > a file when creating a seq file from a midi file? At
> > present Scala does not support using tuning data from
> > midi files, which is a major problem.
>
> You could get a bookkeeping program to administer which
> scl and kbm files were used to make which midi files.

(1) You know perfectly well that Scala does not assume
a scl and kbm file is used at all. Notes can be entered
as fractions or cents values.

(2) If I had a "bookkeeping program" to tell me that
such and such a seq file used 31 equal (data already
recorded on the seq file) what good would it do me?

> Why would
> you want to retrieve quantised raw tuning data from midi
> files?

Because I'd really like to be able to recover the
tuning people (including but not confined to me)
used in a midi file. Did so and so use 1/4-comma
meantone for this file, etc? I'd actually like
Scala to be able to recover enough information from
a midi file that Scala could recreate a midi file
which, when played, sounded the same. The utility
of that seems obvious.

> I haven't seen you giving a single convincing use case yet.

Oh, please. After all the times I've looked at asciied
midi binary, checked the pitch bend, coverted that to
an interval, and tried to determine what scale was
implied I think I am in a position to say it's a pain.
Of course, maybe a utility exists somewhere to extract
scale information from pitch bends, but if so, I don't
know of it.

> > (4) Can we get Scala to create such midi files from seq
> > files?
>
> Already possible, it uses single note change real-time.

So it should have no difficulty in recovering pitch info
from the files it itself makes, it seems to me. And why
do we still get the track limitations with this system?
I guess I'm not seeing the hangup here.

--- In tuning@yahoogroups.com, "Robert walker" <robertwalker@...>
wrote:

> If you look at a hex dump of a midi file - there are
no "punctuation marks" to show where one event ends and the next
begins. So if you advance two bytes in the file when it should be
four bytes, then you will interpret whatever you see next in the file
as a time delta.

This is why I said there should be header data telling the
program what kind of file it was. Alternatively, as someone
suggested, you could use a different extension.

> So the short answer is there is no such thing as a 32 bit standard
midi file because the midi file standard doesn't include the
flexibility to have 32 bit ints included in it. The reason for that
is that it isn't a tagged format like html - there is no punctuation
in it.

Why isn't that taken care of in my initial suggestion or the
extension change suggestion?

I have better things to do than engage in a silly shouting
match with a tall green man.

Aaron Hunt
H-Pi Instruments

--- In tuning@yahoogroups.com, "Carl Lumma" <clumma@...> wrote:
>
> > Um, no. The JND is often placed as high as 35 ms.
>
> Citation? I've measured it with test equipment by the
> way, and with various audio device drivers. You're um,
> how you say, wrong.
>
> -Carl
>

Hi Aaron,

Yes - what you could do is to put something at the head of the file to say to expect ints all the way through - perhaps that's what you have in mind?

If one is making a new format, then why not make it so that it expects double precision floating point for the note number instead? Personally I'd prefer that to ints in some very high number et, since you don't need a "magic number" to decode the file, so it is a bit more transparent, and also doubles at 64 bits are a little more accurate than ints.

It might also be better to change to a format that uses "punctuation" - or just a format where each status byte is followed immediately by an integer that tells the parser how many bytes to expect next - to allow for future changes if any more things need to be done to it. I expect that is how the midi file format would be done if it was set out now - rather than back then when every byte counted. Or indeed even a plain text format e.g. XML.

But even if it was just a new file format with ints or doubles all the way through - there would be issues for coders, many of them. You are asking for many hours of work to update the code. I could do it in FTS but it would take a fair amount of work just because it assumes byte size messages in the midi file parser, which then sends those messages on internally to the retuning midi player which also expects them to be byte sized - all that would need to be recoded and debugged with ints or (I would prefer) doubles. I might do it because of enthusiasm if there was a lot of demand for it and if I had the time. But do you expect Sibelius, Finale, Microsoft etc to all follow suite? If they did, everyone would also have to update to a newer version of all those programs and of Windows too, and since they are all commercial companies, they would undoubtedly add on an extra cost to the customer to pay for all the extra coding that was required.

It is a fair amount of work - the equivalent for midi coding of the year 2000 bug fixes which was a very similar type of problem at the low level coding level. Depends - some programmers might find not much work is involved, while others might find that a lot of work is involved, so the uptake would be bound to be uneven, and depend on how easy it is to do and how enthusiastic the programmers were.

While on the other hand the extra rpns - though not ideal - do require very little extra coding all round, and also the sort of coding that is unlikely to lead to unrelated bugs - while changing bytes to ints or doubles is just the sort of thing that is fairly likely to introduce mysterious bugs and crashes in a program that need to be debugged - if coded all the way through to use bytes for that thing. Depending on how it is coded of course, so that is why I predict that it would be uneven in the uptake.

Robert

Re: Why don't we create our own damned midi standard?

Just use a conditional to parse the Note ON message.
When it is found, either expect this or that; 2 more bytes,
or 4 mour bytes, or whatever, and act accordingly. Of course,
whenever I say something like this to my chief engineer
he tells me that the microcontroller has to be 5 times faster in
order not to slow things down if something like this is to be done
in hardware in realtime. But for parsing a file, I don't see what
the problem could possibly be. You've got buffers and huge
processor power.

Aaron Hunt
H-Pi Instruments

--- In tuning@yahoogroups.com, "Robert walker" <robertwalker@...>
wrote:

> If one is making a new format, then why not make it so that it
expects double precision floating point for the note number instead?
Personally I'd prefer that to ints in some very high number et, since
you don't need a "magic number" to decode the file, so it is a bit
more transparent, and also doubles at 64 bits are a little more
accurate than ints.

Doubles would be fine. I prefer ints because an int
is what it is. A double leaves you guessing what
precision, and in ascii format, is more of a mess.
Converting the ascii so it can be used by something
else is potentially a problem, since ints have a
single, fixed, absolute ascii representation whereas
floats and doubles do not.

And there seem to be no advantages to outweigh the
the disadvantages. I don't know why you would want
to use 64 bits, but if you thought there was a reason
ints could do that also.

One question with floating point which does not come
up with ints is whether it is logarithmic or not. You
need to specify that, of course, as Csound does.

> It might also be better to change to a format that
uses "punctuation" - or just a format where each status byte is
followed immediately by an integer that tells the parser how many
bytes to expect next - to allow for future changes if any more things
need to be done to it.

My idea was to make a single change, and leave it at that. An
incremental approach. But if you were to write your own player
using a new extension, the sky would be the limit.

> I expect that is how the midi file format would be done if it was
set out now - rather than back then when every byte counted. Or
indeed even a plain text format e.g. XML.

Text seems like a better idea than hex.

> But do you expect Sibelius, Finale, Microsoft etc to all follow
suite?

No. I would hope to get Scala and then Tinidity to follow suit,
and then some synths.

--- In tuning@yahoogroups.com, "Carl Lumma" <clumma@...> wrote:
>
> > Um, no. The JND is often placed as high as 35 ms.
>
> Citation? I've measured it with test equipment by the
> way, and with various audio device drivers. You're um,
> how you say, wrong.

Here's a paper with a literature review:
http://gsd.ime.usp.br/~lago/masters/latency-paper.pdf

I submit that results reported in sections 2 and 2.1 are
significant despite later claims to the contrary. In
particular, the claims about simultaneity have nothing
to do with anything, and their claims about piano haptics
are pretty daft. They finally do seem to come to the
correct conclusion (in a roundabout way), that there is
no latency in a piano action.

-Carl

Thank you, my scaly friend; this confirms what I've already said.

Yours,
Aaron Hunt
H-Pi Instruments

--- In tuning@yahoogroups.com, "Carl Lumma" <clumma@...> wrote:
>
> --- In tuning@yahoogroups.com, "Carl Lumma" <clumma@> wrote:
> >
> > > Um, no. The JND is often placed as high as 35 ms.
> >
> > Citation? I've measured it with test equipment by the
> > way, and with various audio device drivers. You're um,
> > how you say, wrong.
>
> Here's a paper with a literature review:
> http://gsd.ime.usp.br/~lago/masters/latency-paper.pdf
>
> I submit that results reported in sections 2 and 2.1 are
> significant despite later claims to the contrary. In
> particular, the claims about simultaneity have nothing
> to do with anything, and their claims about piano haptics
> are pretty daft. They finally do seem to come to the
> correct conclusion (in a roundabout way), that there is
> no latency in a piano action.
>
> -Carl
>

Hardly.

--- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aahunt@...> wrote:
>
> Thank you, my scaly friend; this confirms what I've already said.
>
> Yours,
> Aaron Hunt
> H-Pi Instruments
>
>
> --- In tuning@yahoogroups.com, "Carl Lumma" <clumma@> wrote:
> >
> > --- In tuning@yahoogroups.com, "Carl Lumma" <clumma@> wrote:
> > >
> > > > Um, no. The JND is often placed as high as 35 ms.
> > >
> > > Citation? I've measured it with test equipment by the
> > > way, and with various audio device drivers. You're um,
> > > how you say, wrong.
> >
> > Here's a paper with a literature review:
> > http://gsd.ime.usp.br/~lago/masters/latency-paper.pdf
> >
> > I submit that results reported in sections 2 and 2.1 are
> > significant despite later claims to the contrary. In
> > particular, the claims about simultaneity have nothing
> > to do with anything, and their claims about piano haptics
> > are pretty daft. They finally do seem to come to the
> > correct conclusion (in a roundabout way), that there is
> > no latency in a piano action.
> >
> > -Carl
> >
>

Hi Aaron,

The problem with the NRPNs is that by their nature they may already be in use to mean something else on particular hardware. But with RPNs, they should not be used for anything else. Yes if you add an extra RPN that _does_ mean a change in the midi spec, but a minimal one using a special mechanism already in place in the midi format to permit expansion.

The problem with the 5 byte midi note ons is the amount of recoding needed which would be expensive - and the lack of backward compatibility, so that you have to have two versions of your code to parse note ons, one version that parses them as 2 byte for backward compatibility - and one as 5 byte - and you need a mechanism by which a program can tell which way to parse the note message as well since one can't expect all programs, device drivers etc to simultaneously update to the new standard, and old hardware never can be updated, so a program must be able to handle both types of note on - and there has to be a message to tell a midi synth which one is currently in use for any particular device - and there must be an option in the user interface for the user to tell any particular midi program to send only the old two byte note ons to a particular synth if the user knows e.g. that it is a hardware synth or has not yet been coded for the newer 5 byte note ons of your proposal.

The amount of recoding you are talking about there is huge, many thousands or more of programmer years I would guess if all existing midi software were updated in this way.

While the rpns only affect the sending and receiving programs and nothing else in between, and is backwards compatible - as the receiving synth if it doesn't receive these extra rpns will just parse the midi stream as usual - it can include MTS sysexes, and standard pitch bends as well as the two new types of pitch bend message - and most programs won't use the new pitch bend messages to start with, but you just need one soft synth and one sending program that does use them and that is enough to start a user base. Then if it is useful enough the new messages could then spread to other programs if enough users demand them to be introduced. So fully backwards compatible and it does introduce a couple of new RPNs - but there are plenty of those not yet taken up. Does need that to be approved in some way, don't know what the process is - or you could just introduce them experimentally in programs flagged clearly as beta software for users, and then use those programs as reasons to update the midi spec to permit them.

Not so elegant, but would work, is backward compatible, and you can continue to use standard pitch bends and MTS sysexes and this just adds another layer on top of them that has no effect if not present.

If you want to get something underway, and spread widely, something that requires a minimum of coding to include it is I think more likely to be widely accepted, not necessarily this idea, but some idea that requires similarly minimal recoding at the low level in midi, and preferably backwards compatible.

For something more elegant than midi while more data redundant, really one needs a new format altogether, midi comes from a time when single bytes were precious and transmission rates were slow, and formats used the minimum number of bytes - it is elegant in that sense of minimising the number of bytes, but not in the sense of transparency or permitting easy future expansion, and if that is ones objective one should really prob. start again and make a new up to date format for modern conditions - though it could be one with strong affinities with midi.

If ones objective is to not change the midi spec at all, ones efforts might perhaps be best put towards trying for more widespread adoption of MTS.

The extra bytes are a nice idea at a high level, it is just that it doesn't work at a low level because of the particular way that midi was implemented at a low level. If it was more of a packet or tagged type format then the change would be trivial - but of course such formats use more bytes so would have been inappropriate to adopt at the time that the midi format was originally devised. Just a matter of particular historical circumstances which we can't do anything about and have to work with because of the widespread popularity of midi - well deserved I think because it is a fine format of its type, just that it has been so successful that it has lived on to times when the limitations in place when it was invented no longer apply.

Robert

..........
Thanks Robert, for explaining your idea again here. If the spec
isn't changing, then NRPS or non-registered parameter numbers
would need to be used, since by definition RPNs mean something
in the spec. It could be done, both in hardware and software, as
you say. Since MIDI was created as a hardware interconnect protocol,
in response to a lack thereof, for anything MIDI I tend to think
about hardware first. A problem with this will be accessing the source
for multiple notes in small intervals, especially if it is a sample,
when the note number is the same but the tuning is different,
such as an A + 4 cents and an A - 49 cents at the same time.
In software you can work around it, but hardware?

Re: the problem you point out with the 5-byte message screwing up
existing MIDI apps, APIs, etc. Yes, but this would not happen after the
MIDI spec changes, because when the spec changes it will be
supported. MMA members will not ignore a change to basic MIDI
messages in the official spec. Microsoft and everyone else will have
to update their drivers. That's how the rest of the techno-world functions;
it's about time MIDI started working the same way.

--- In tuning@yahoogroups.com, "Robert walker" <robertwalker@...> wrote:

> For something more elegant than midi while more data redundant,
really one needs a new format altogether, midi comes from a time when
single bytes were precious and transmission rates were slow, and
formats used the minimum number of bytes - it is elegant in that sense
of minimising the number of bytes, but not in the sense of transparency
or permitting easy future expansion, and if that is ones objective one
should really prob. start again and make a new up to date format for
modern conditions - though it could be one with strong affinities with
midi.

How well would a Scsla seq file serve that purpose? A
program to play one like a midi file would solve some
problems right there, and if they could be rendered
directly, even better.

Hi Gene,

Oh something more modest like that makes more sense.
I also would prefer a text based format because it is user editable

A a new shared file format like this does make sense in that
way if you don't expect that much uptake, and mainly amongst programs
where the programmers are already microtonal enthusiasts.

But it would need a fair amount of work on the file format.

I see the advantage of integers now - and another one - that
it is unambiguous which note you are switching off if you use
integers rather than doubles or floats with rounding errors.
The main advantage of double precision is that it makes it
easier to discover whether two pitches are intended to be at
exact integer ratios to each other - though ideally one needs
a format that permits one to enter ratios of two integers
directly as for the Scala scale format.

If I were to code to parse an integer based midi like file format in FTS
some day - rather than modify my existing byte based code, I would prob.
code it all again from scratch as less likely to introduce new bugs
into the code. If other coders are in a similar position then that
suggests that a better approach might be to make a new
file format from scratch, with affinities to midi of course,
and possibly text based.

I do however have lots on right now - coding and otherwise,
it is a fun project but not sure I have the time in the near
future. But if it took off and some other programs already
adopted it - by then maybe FTS 3.0 will be released
and maybe just maybe I may have less of a coding
workload to get through :-). Don't promise anything.
Have lots to do right now and other things that would
have to be higher priority, and for a good many months to
come prob.

Anyway I now understand your idea and it makes sense, I can
see the point in it, and it does have possibilities I agree
- at least as a shared file format.

Robert

Robert walker wrote:
> Hi Gene,
> > Oh something more modest like that makes more sense.
> I also would prefer a text based format because it is user editable
> > A a new shared file format like this does make sense in that
> way if you don't expect that much uptake, and mainly amongst programs
> where the programmers are already microtonal enthusiasts.
> > But it would need a fair amount of work on the file format.
> > I see the advantage of integers now - and another one - that
> it is unambiguous which note you are switching off if you use
> integers rather than doubles or floats with rounding errors.
> The main advantage of double precision is that it makes it
> easier to discover whether two pitches are intended to be at
> exact integer ratios to each other - though ideally one needs
> a format that permits one to enter ratios of two integers
> directly as for the Scala scale format.

There is already a text-based file format that can be used for microtonal scores ... a Csound score file. At least it would be convenient to be able to take whatever file format we might come up with and make a Csound score from it directly, even if the Csound format itself isn't exactly the most optimal for what we might want to do with it. But there are advantages to using a format that's already widely understood and has ready-made software that works with it.

Aaron Andrew Hunt wrote:
> Just use a conditional to parse the Note ON message. > When it is found, either expect this or that; 2 more bytes, > or 4 mour bytes, or whatever, and act accordingly. Of course,
> whenever I say something like this to my chief engineer > he tells me that the microcontroller has to be 5 times faster in > order not to slow things down if something like this is to be done > in hardware in realtime. But for parsing a file, I don't see what
> the problem could possibly be. You've got buffers and huge > processor power.

The main problem is that you're introducing a new file format that's incompatible with the old format and doesn't have any advantages for most users. The other one is that making low-level changes requires a lot of testing and may break assumptions you made somewhere else.

Graham

Aaron Andrew Hunt wrote:
> Graham, MMA members are reps of companies. You think > companies won't respond to a change in the spec agreed upon > by their own reps? Of course, the whole reason the MIDI spec > hasn't changed is that the big companies don't want it to change.

Well, yes. I used to be a web developer. Those standards are also agreed by companies and not implemented properly. SQL is the best example. They keep having new meetings to define a new standard when nobody -- but nobody -- supported the old one or even a usable subset.

> As far as Microsoft not supporting standard specifications, yes,
> Microsoft features so many 'broken' protocols it boggles the mind. > I only own a PC because I have to have one for software development.
> > As far as clout goes, I have none! If I sound like I'm making lots of
> pronouncements, I'm coming across completely wrong, as usual. I'm
> just throwing out ideas. As I said, I also tend to think for hardware
> rather than software, as backward as that may seem; there are still
> lots of musicians who want self-contained instruments to play live.

So have you studied the MIDI standard to see how it's supposed to behave when it receives surplus data bytes? I can't find anything authoritative online.

I did find a USB-MIDI standard, which I think is the big one. Involves Microsoft, Roland and IBM:

http://www.usb.org/developers/devclass_docs/midi10.pdf

Page 16 shows how MIDI messages are sent. There are 3 MIDI bytes packed into a 32 bit integer which leaves no space for a 5 byte message. You could scavenge one more bit for the note value but break compatibility with the old DIN standard.

Note that there's a also a new 4 bit cable number. So a single USB MIDI device effectively listens on 256 channels. The best backwards compatible way to get more notes is to redefine the MIDI channel number. You could use your multi-channel keyboards to control 16 different voices of a microtonal synth by switching the cable number and you might even find a hardware box already set up to do this. This is all before you start using evil hacks like squeezing more voices from different ranges of MIDI channels or pretending to be a USB hub with multiple devices plugged in.

If you want to nudge the standard, suggest they encourage the MIDI channel to be used for different manuals of an organ, different strings of a guitar, and so on. But assume the cable number is used to address different instruments. I think in this case the trend's going the way we want.

Graham

--- In tuning@yahoogroups.com, Herman Miller <hmiller@...> wrote:

> There is already a text-based file format that can be used for
> microtonal scores ... a Csound score file.

No, because that requires an orc file to go with it,
and there isn't anything like GM. I at least can't
see how to use it for this purpose.

--- In tuning@yahoogroups.com, "Gene Ward Smith" <genewardsmith@...>
wrote:
> > Timidity supports single note change real-time.
>
> Does Scala? If so, why doesn't pitch bending work
> better than it seems to? What's the biggest problem
> now?

If you retune a midi file with Scala using MTS, then pitch bends still
work normally. Unless you have a problem that I'm not aware of.
When you convert a .seq file to a midi file with MTS then you don't
have pitch bends, because they are not in the seq file format (yet).

> > You could get a bookkeeping program to administer which
> > scl and kbm files were used to make which midi files.
>
> (1) You know perfectly well that Scala does not assume
> a scl and kbm file is used at all. Notes can be entered
> as fractions or cents values.

But you _can_ save your scales and mappings and then write down the
filenames, that's the point.

> (2) If I had a "bookkeeping program" to tell me that
> such and such a seq file used 31 equal (data already
> recorded on the seq file) what good would it do me?

No I said midi file, not seq file. Also when you retune a midi file
using pitch bends, the cents are stored as comments in the pitch bend
track.

> > Why would
> > you want to retrieve quantised raw tuning data from midi
> > files?
>
> Because I'd really like to be able to recover the
> tuning people (including but not confined to me)

Including yourself, so then use the solution I suggested and it will
be much easier and you don't lose information. As for other people's
files, there are often other ways to get this information, like asking
them, etc. The remaining cases where there's no alternative are
probably so rare, they don't warrant me to put a lot of effort in.

> Oh, please. After all the times I've looked at asciied
> midi binary, checked the pitch bend, coverted that to
> an interval, and tried to determine what scale was
> implied I think I am in a position to say it's a pain.

"I've done this many times" is not a convincing argument when there
are alternatives.

> Of course, maybe a utility exists somewhere to extract
> scale information from pitch bends, but if so, I don't
> know of it.

No, anyone else cares to help Gene here?

> So it should have no difficulty in recovering pitch info
> from the files it itself makes, it seems to me.

Nor should you have the problem of losing this info, it seems to me.

>And why do we still get the track limitations with this system?

Which track limitations?

Manuel

Thanks Robert; your idea is making more sense to me each time
you explain it. But what about Graham's concern that RPN timing
is an issue?

And what about my concern that hardware won't react
to multiple source requests properly?

Still, I see an advantage of this aproach over sysex messages.

Previously, I said that MTS messages were proprietary Sysex.
Carl said they were not "proprietary", and I quickly recanted.
But thinking about this again, isn't it correct to say that Sysex is
proprietary? I believe all systex messages have to carry a series of
IDs, the manufacturer, the device ID and sub ID, before the data.
This would seem to make them all proprietary, meaning the message
carries the manufacturer ID with it, because different devices do
different things in a proprietary way. That is, unless I'm forgetting
something special about the tuning messages; I admit I don't use
them since I find them too confusing, and I found a way to make
pitch bending work.

Yours,
Aaron Hunt
H-Pi Instruments

--- In tuning@yahoogroups.com, "Robert walker" <robertwalker@...> wrote:
>
> Hi Aaron,
>
> The problem with the NRPNs is that by their nature they may already be in use to mean
something else on particular hardware. But with RPNs, they should not be used for
anything else. Yes if you add an extra RPN that _does_ mean a change in the midi spec,
but a minimal one using a special mechanism already in place in the midi format to permit
expansion.
>
> The problem with the 5 byte midi note ons is the amount of recoding needed which
would be expensive - and the lack of backward compatibility, so that you have to have two
versions of your code to parse note ons, one version that parses them as 2 byte for
backward compatibility - and one as 5 byte - and you need a mechanism by which a
program can tell which way to parse the note message as well since one can't expect all
programs, device drivers etc to simultaneously update to the new standard, and old
hardware never can be updated, so a program must be able to handle both types of note
on - and there has to be a message to tell a midi synth which one is currently in use for
any particular device - and there must be an option in the user interface for the user to tell
any particular midi program to send only the old two byte note ons to a particular synth if
the user knows e.g. that it is a hardware synth or has not yet been coded for the newer 5
byte note ons of your proposal.
>
> The amount of recoding you are talking about there is huge, many thousands or more
of programmer years I would guess if all existing midi software were updated in this way.
>
> While the rpns only affect the sending and receiving programs and nothing else in
between, and is backwards compatible - as the receiving synth if it doesn't receive these
extra rpns will just parse the midi stream as usual - it can include MTS sysexes, and
standard pitch bends as well as the two new types of pitch bend message - and most
programs won't use the new pitch bend messages to start with, but you just need one soft
synth and one sending program that does use them and that is enough to start a user
base. Then if it is useful enough the new messages could then spread to other programs
if enough users demand them to be introduced. So fully backwards compatible and it does
introduce a couple of new RPNs - but there are plenty of those not yet taken up. Does
need that to be approved in some way, don't know what the process is - or you could just
introduce them experimentally in programs flagged clearly as beta software for users, and
then use those programs as reasons to update the midi spec to permit them.
>
> Not so elegant, but would work, is backward compatible, and you can continue to use
standard pitch bends and MTS sysexes and this just adds another layer on top of them
that has no effect if not present.
>
> If you want to get something underway, and spread widely, something that requires a
minimum of coding to include it is I think more likely to be widely accepted, not
necessarily this idea, but some idea that requires similarly minimal recoding at the low
level in midi, and preferably backwards compatible.
>
> For something more elegant than midi while more data redundant, really one needs a
new format altogether, midi comes from a time when single bytes were precious and
transmission rates were slow, and formats used the minimum number of bytes - it is
elegant in that sense of minimising the number of bytes, but not in the sense of
transparency or permitting easy future expansion, and if that is ones objective one should
really prob. start again and make a new up to date format for modern conditions - though
it could be one with strong affinities with midi.
>
> If ones objective is to not change the midi spec at all, ones efforts might perhaps be
best put towards trying for more widespread adoption of MTS.
>
> The extra bytes are a nice idea at a high level, it is just that it doesn't work at a low level
because of the particular way that midi was implemented at a low level. If it was more of a
packet or tagged type format then the change would be trivial - but of course such
formats use more bytes so would have been inappropriate to adopt at the time that the
midi format was originally devised. Just a matter of particular historical circumstances
which we can't do anything about and have to work with because of the widespread
popularity of midi - well deserved I think because it is a fine format of its type, just that it
has been so successful that it has lived on to times when the limitations in place when it
was invented no longer apply.
>
> Robert
>
> ..........
> Thanks Robert, for explaining your idea again here. If the spec
> isn't changing, then NRPS or non-registered parameter numbers
> would need to be used, since by definition RPNs mean something
> in the spec. It could be done, both in hardware and software, as
> you say. Since MIDI was created as a hardware interconnect protocol,
> in response to a lack thereof, for anything MIDI I tend to think
> about hardware first. A problem with this will be accessing the source
> for multiple notes in small intervals, especially if it is a sample,
> when the note number is the same but the tuning is different,
> such as an A + 4 cents and an A - 49 cents at the same time.
> In software you can work around it, but hardware?
>
> Re: the problem you point out with the 5-byte message screwing up
> existing MIDI apps, APIs, etc. Yes, but this would not happen after the
> MIDI spec changes, because when the spec changes it will be
> supported. MMA members will not ignore a change to basic MIDI
> messages in the official spec. Microsoft and everyone else will have
> to update their drivers. That's how the rest of the techno-world functions;
> it's about time MIDI started working the same way.
>

--- In tuning@yahoogroups.com, "Manuel Op de Coul"
<manuel.op.de.coul@...> wrote:

> >And why do we still get the track limitations with this system?
>
> Which track limitations?

Where using pitch bends when there are too many parts
causes Scala to crap out.

I have tended to avoid using .scl and other file formats for microtuning, for many reasons.

One of those reasons is because meantone tunings usually seem to be listed in a very limited way and unable to handle more exotic "scales" using .scl and other file formats.

May I suggest that for all meantone type tunings only two values are needed:

a) the octave ratio - usually exactly two.

b) the size of the Large interval (e.g. between the fourth and the fifth)

Using a) and b) can unambiguously define the parameters of any meantone tuning.

Having defined any meantone tuning, we now need to set a reference pitch to a particular midinote.

(My own preference is A=440Hz, and octave equivalents for ratio 2 meantones)

Now the problem arises;

To provide a reasonable selection of playable scales, in diverse keys there need to be a plethora of files for each meantone tuning.

I have publicly limited my freely available downloads to about 50 for "consonant" LucyTunings.

This could be reduced by examining the sequence of interval patterns which can be viewed as transpositions, yet transposing in this way shifts the reference pitch to midinote relationship.

If we could agree on the definition parameters for all meantones, it should also be possible to agree a number of standard patterns which could be applied to all and every meantone tuning.

This would result in 50 + files for each meantone, but at least we could all understand exactly what tuning each meantone tuning file should produce.

This same system could be applied to the edo scales which are also obviously "circular meantones". e.g. 19, 31, 53, 88 etc. which are presently also often confusingly mapped or non-existent.

I appreciate that this approach will result in thousands of different tuning files, yet with the ubiquity of broadband, cheap hard drives/storage, and multimegabyte applications and programmes, the

present technology can easily handle the traffic and storage volumes necessary to transmit and host them.

As things stand at present, I accept responsibility for tuning files downloadable from the lucytune.com site only;

and zero blame for the multiple supposedly Lucy tuning files, which others may have misguidedly and erroneously produced and published on the net or bundled with various applications and programmes.

Comments, flames, etc. welcomed;-)

Charles Lucy lucy@lucytune.com

----- Promoting global harmony through LucyTuning -----

For information on LucyTuning go to: http://www.lucytune.com

LucyTuned Lullabies (from around the world):
http://www.lullabies.co.uk

Skype user = lucytune

On 5 Apr 2007, at 22:34, Gene Ward Smith wrote:

> --- In tuning@yahoogroups.com, "Manuel Op de Coul"
> <manuel.op.de.coul@...> wrote:
>
> > >And why do we still get the track limitations with this system?
> >
> > Which track limitations?
>
> Where using pitch bends when there are too many parts
> causes Scala to crap out.
>

--- In tuning@yahoogroups.com, Charles Lucy <lucy@...> wrote:

> May I suggest that for all meantone type tunings only two values
are
> needed:
>
> a) the octave ratio - usually exactly two.
>
> b) the size of the Large interval (e.g. between the fourth and the
> fifth)

A Scala seq file can use LT notation. For that, you
could for instance include a line

0 lt_gens 695.492965855 1200.0

Now a line saying

480 note 2.-1 240

would say to play a note at time 480 with length
240, and tuning 2*695.492965855 - 1200.0 =
190.985931710 cents above your middle C value.

If you didn't like fifth and octave as generators,
other pairs would work also; for instance you could
use 122.535170724 and 68.450760986 and express
everything in terms of them.

> To provide a reasonable selection of playable scales, in diverse
keys
> there need to be a plethora of files for each meantone tuning.

You don't need any files at all if you are working
with just seq and midi. This is how I prefer to
work most of the time.

> If we could agree on the definition parameters for all meantones,
it
> should also be possible to agree a number of standard patterns
which
> could be applied to all and every meantone tuning.

The tuning of the octave and the fifth determines it
if we assume regularity.

> This would result in 50 + files for each meantone, but at least we
> could all understand exactly what tuning each meantone tuning file
> should produce.

That's 50 more files than we need.

> This same system could be applied to the edo scales which are also
> obviously "circular meantones". e.g. 19, 31, 53, 88 etc. which are
> presently also often confusingly mapped or non-existent.

Again, if you simply work with seq files and midi, the
seq file only needs to say

0 equal 88

and you are in 88 equal.

Thanks Gene "Wizard";

Fifth and generator are fine by me.

Where can I find the specs etc. for Scala seq files?

What do we need to do and how can it be practically implemented, so that everyone (including me;-) can understand and use it universally?

Charles Lucy lucy@lucytune.com

----- Promoting global harmony through LucyTuning -----

For information on LucyTuning go to: http://www.lucytune.com

LucyTuned Lullabies (from around the world):
http://www.lullabies.co.uk

Skype user = lucytune

On 6 Apr 2007, at 01:08, Gene Ward Smith wrote:

> --- In tuning@yahoogroups.com, Charles Lucy <lucy@...> wrote:
>
> > May I suggest that for all meantone type tunings only two values
> are
> > needed:
> >
> > a) the octave ratio - usually exactly two.
> >
> > b) the size of the Large interval (e.g. between the fourth and the
> > fifth)
>
> A Scala seq file can use LT notation. For that, you
> could for instance include a line
>
> 0 lt_gens 695.492965855 1200.0
>
> Now a line saying
>
> 480 note 2.-1 240
>
> would say to play a note at time 480 with length
> 240, and tuning 2*695.492965855 - 1200.0 =
> 190.985931710 cents above your middle C value.
>
> If you didn't like fifth and octave as generators,
> other pairs would work also; for instance you could
> use 122.535170724 and 68.450760986 and express
> everything in terms of them.
>
> > To provide a reasonable selection of playable scales, in diverse
> keys
> > there need to be a plethora of files for each meantone tuning.
>
> You don't need any files at all if you are working
> with just seq and midi. This is how I prefer to
> work most of the time.
>
> > If we could agree on the definition parameters for all meantones,
> it
> > should also be possible to agree a number of standard patterns
> which
> > could be applied to all and every meantone tuning.
>
> The tuning of the octave and the fifth determines it
> if we assume regularity.
>
> > This would result in 50 + files for each meantone, but at least we
> > could all understand exactly what tuning each meantone tuning file
> > should produce.
>
> That's 50 more files than we need.
>
> > This same system could be applied to the edo scales which are also
> > obviously "circular meantones". e.g. 19, 31, 53, 88 etc. which are
> > presently also often confusingly mapped or non-existent.
>
> Again, if you simply work with seq files and midi, the
> seq file only needs to say
>
> 0 equal 88
>
> and you are in 88 equal.
>
>
>

Gene Ward Smith wrote:
> --- In tuning@yahoogroups.com, Herman Miller <hmiller@...> wrote:
> >> There is already a text-based file format that can be used for >> microtonal scores ... a Csound score file. > > No, because that requires an orc file to go with it,
> and there isn't anything like GM. I at least can't
> see how to use it for this purpose.

You can put the orchestra in the same file as the score with the new unified files, so that's not a problem.

As far as having anything like GM, I don't recall that being one of the criteria. Not that GM is all that great in the first place, but if you're thinking of an editable text file, you'd have to convert that to a MIDI format to use GM sounds no matter how you define it. Or write a MIDI player that can read text files, but in that case, why not make the text file format something that can be used with Csound?

Charles Lucy wrote:
> Thanks Gene "Wizard";
> > Fifth and generator are fine by me.
> > Where can I find the specs etc. for Scala seq files?
> > What do we need to do and how can it be practically implemented, so > that everyone (including me;-) can understand and use it universally?

http://www.xs4all.nl/~huygensf/scala/seq_format.html

Graham

Hi Aaron,

On the RPN timing - yes indeed, that's an issue, also with the polyphonic
pitch bends. They are only appropriate if the synth playing them is
able to keep the RPNs synchronised with the note ons,
also any editor used to edit the files ditto. Some can't so
they just can't play these, unless the programming can be
updated to keep the RPNs and pitch bends synchronised
with the note ons - or unless you insert extra ms delays
which I agree is a cludge to be avoided.

Basically, a requirement of a player of polyphonic pitch bends
used for instant note retuning is that it has to respond to the
change of pitch instantly and must respect the serial order
of the pitch bends and note ons.

BTW I have programmed CSound instruments to respond to
pitch bends in a polyphonic fashion. All you do is make them
respond to pitch bends, then make that response due to an
instruction rate variable instead of a control rate variable so that
it only responds at the start of the note.

Perhaps one could test the whole thing using CSound
instruments? So long as one could program them to detect
"out of range" RPNs, and treat those as non polyphonic
pitch bends. It is a while since I last did CSound midi
instruments so don't know if that is poss.

Ditto with my single wave player in FTS - making it pitch bend
polyphonic was a matter of just disabling the code that
goes through all the currently playing notes to update their
pitches as new pitch bend messages arrive.

Yes most of the ids are for manufacturers in various countries.

The thing is the sysex id field can also be set to
0x7E for Universal Non Real time
or
0x7F for Universal Real time
which are used for the tuning sysexes.

For beta testing there are also ids
0x70 - 0x7d for Non-Commercial (not for public release)

Robert

.......................

Thanks Robert; your idea is making more sense to me each time
you explain it. But what about Graham's concern that RPN timing
is an issue?

And what about my concern that hardware won't react
to multiple source requests properly?

Still, I see an advantage of this aproach over sysex messages.

Previously, I said that MTS messages were proprietary Sysex.
Carl said they were not "proprietary", and I quickly recanted.
But thinking about this again, isn't it correct to say that Sysex is
proprietary? I believe all systex messages have to carry a series of
IDs, the manufacturer, the device ID and sub ID, before the data.
This would seem to make them all proprietary, meaning the message
carries the manufacturer ID with it, because different devices do
different things in a proprietary way. That is, unless I'm forgetting
something special about the tuning messages; I admit I don't use
them since I find them too confusing, and I found a way to make
pitch bending work.

Yours,
Aaron Hunt
H-Pi Instruments

Hi There,

With the .seq format the problem is that there are so many different options and notations. Yes one could program some of them and add more as time goes on - but only enthusiasts will do that and to try and include all the SCala notations would be a big job so it would prob. never get finished (If I attempted it myself for FTS I would prob. never finish anyway with all the other programming commitments) - and Manuel is likely to continue to add new options to it as time goes on.

One could play a .seq file, but the ideal way to do that is to let Scala itself somehow convert it into a simpler common format

Best is if you could call Scala with a command line argument to convert a .seq file into the common format before playing it- then if Manuel updates Scala to handle more options in a .seq file, then all the .seq file players automatically are updated too.

Then there are all the midi controllers and other types of midi events, if you want it to be as close as poss. to midi then you have to decide what to do about those, and couldn't record them to a CSound score and perhaps not to a .seq file either??

So that still leaves the q. of what the common format is.
.................................
In the spirit of the discussion one would think - something that transcribes the midi but with decimal values for the note numbers, prob. also able to show additional pitch bends on top of the tuning (perhaps as decimal cents), otherwise identical to midi.

One idea: show status in square brackets and channel as first number after it.

So e.g.:

[instr] 2, 32
[pitchbend] 2, 30.0
[noteon] 2, 67.01955, 120

You have to think about how to transcribe any sysexes and any other binary data in the file (show the binary data as hex?).

It would need care and take some thought and time to get it right. I ha ven't really got the time to work on it in a sufficiently thorough way to do it justice right now.
.................................
Another option might be to just convert to a midi file but with the extra RPNs used to give appropriate "pitch bends" before each note - i.e. work out the extra rpns format, and use those in a regular type of midi file but just with the extra rpns inserted as they would be to get it played correctly tuned on a midi player able to respond to them.

The midi file then wouldn't be particularly user friendly to read, but it would be very easy to modify ones programming for playing midi files to detect the rpns in it and use those as extra pitch bends for the appropriate notes. So would minimise the amount of coding needed all round.

.................................
Maybe use .seq as a user readable text format. To play it, Scala would convert that via command line args into the rpn midi format, and the player then plays that by using the rpns as extra pitch bends for notes that follow them, or for just a particular note number following, as appr.

Programs that want to save to a user readable text format could use a simplified version of the Scala .seq. format as a common format, using any of the .seq options as convenient. So long as the program only saves to .seq instead of reading from it then it doesn't need to keep up to date with latest developments for .seq, and doesn't need to program all the notations and various other options that make the .seq. files more user friendly for editing.

If it were nec. to read a .seq. file not for playing (not sure what for but if it is a common format, may be needed in some way), if there were some Scala command line option to convert a .seq. file to a "simplified .seq." of some sort then it would then be poss. for programs to input .seq. files by calling Scala on a more complex user edited .seq. file.

Just a few thoughts. It would need more careful thought I'm sure before actually setting down to do anything about it.

Robert

Gene Ward Smith wrote:
> --- In tuning@yahoogroups.com, Herman Miller <hmiller@...> wrote:
>
>> There is already a text-based file format that can be used for
>> microtonal scores ... a Csound score file.
>
> No, because that requires an orc file to go with it,
> and there isn't anything like GM. I at least can't
> see how to use it for this purpose.

You can put the orchestra in the same file as the score with the new
unified files, so that's not a problem.

As far as having anything like GM, I don't recall that being one of the
criteria. Not that GM is all that great in the first place, but if
you're thinking of an editable text file, you'd have to convert that to
a MIDI format to use GM sounds no matter how you define it. Or write a
MIDI player that can read text files, but in that case, why not make the
text file format something that can be used with Csound?

--- In tuning@yahoogroups.com, "Robert walker" <robertwalker@...>
wrote:

> With the .seq format the problem is that there are so many
different options and notations. Yes one could program some of them
and add more as time goes on - but only enthusiasts will do that and
to try and include all the SCala notations would be a big job so it
would prob. never get finished (If I attempted it myself for FTS I
would prob. never finish anyway with all the other programming
commitments) - and Manuel is likely to continue to add new options to
it as time goes on.

I suggest what I called the four easy methods are
plenty. That's general rank one (since "equal" has
an option for including octave size), general rank
two (LT notation), floating point, and ratios. That
covers a hell of a lot of ground and is all you
really need.

> So that still leaves the q. of what the common format is.

I really don't understand what the objection to a subset of seq
files is. It's the best system I know of, at any rate.

> If it were nec. to read a .seq. file not for playing (not sure what
for but if it is a common format, may be needed in some way), if
there were some Scala command line option to convert a .seq. file to
a "simplified .seq." of some sort then it would then be poss. for
programs to input .seq. files by calling Scala on a more complex user
edited .seq. file.

Why the added layer of complexity?

> > No, because that requires an orc file to go with it,
> > and there isn't anything like GM. I at least can't
> > see how to use it for this purpose.
>
> You can put the orchestra in the same file as the score with the
new
> unified files, so that's not a problem.

It is, because there isn't a decent library of orc files.

> As far as having anything like GM, I don't recall that being one of
the
> criteria.

It needs to be, because you can't very well have a score without
indication of what kinds of timbres/instruments are being used.

> Not that GM is all that great in the first place, but if
> you're thinking of an editable text file, you'd have to convert
that to
> a MIDI format to use GM sounds no matter how you define it.

GM is not that great, but what else is there? Csound is useless.

--- In tuning@yahoogroups.com, "Gene Ward Smith" <genewardsmith@...>
wrote:
> GM is not that great, but what else is there? Csound is useless.

ChucK? It's free and one microtonal composer is already trying it
out. It can do synthesis, microtonal implementation is apparently
easy, etc.

http://chuck.cs.princeton.edu/

Hi Gene,

> I really don't understand what the objection to a subset of seq
> files is. It's the best system I know of, at any rate.

This is to do with the programming side of things rather than the user's point of view. So long as there is a converter available to convert .seq files to something more like midi in the background then there would be no problem and one could use the full .seq format too, not just a subset of it.

The thing is that you can only say that your program is able to play a format if it will play any file of that format that you throw at it.

Otherwise your player is "broken" - and your job is never quite done until you can play all the formats that a user may ask your program to be able to play. Right now you feel only four formats are needed - well four very flexible formats is still a fair amount to code for! Especially for parsing, which is harder than saving. Then - some time in the future maybe you will find some other format essential for some particular project in some not foreseen way, and may then press for it to be added too (very natural and nothing wrong about that too - I would in such a position anyway).

But have an automatic pre-processor of .seq files to something else much closer to midi or even to valid midi with MTS sysexes embedded in it for the tunings - and then it is no longer a problem at all.

From the point of view of the user then it is the same more or less - they can write .seq files by hand and play them immediately in the player (don't need to concern themselves that it is automatically converted to an intermediate file in the background as it can all be done invisibly). They can also record to .seq files as well, and give them the choice of those four formats to save their playing in prob.

But require that the player can play .seq files directly and the coding immediately becomes far more involved, and you are less likely I think to get much take up. From the user's point of view, there is hardly any difference, maybe a slight extra delay when they press the play button for SCALA to launch invisibly and the file to get converted.

Recording to .seq format is different. It is easier to save in a format than to parse it for input anyway - and it would be reasonable to start with e.g. just the ratios and cents - then add the other two later on if there was enough user demand and one had the time to do it - and then gradually add more .seq options as required and depending on the time available, ones own enthusiasm for the project, and feedback from users who find the .seq save useful to them. The difference is that unlike the player, your recorder isn't broken in any way, just a bit less versatile, and this is also far less likely to lead to complaints and requests to fix it. With a player there is a natural reluctance to embark on a project which you know will cause frustration for the user from time to time when they maybe come across a .seq file somewhere which they want to play and find that your player won't play it, or make such a file themselves and find it won't play it.

I agree with you on CSound BTW that it is just too different from midi to be useful in this particular context where the music is to be played on a slightly modified microtonal midi player with as few coding changes as possible.

Best is prob. the MTS sysexes which may require no work at all for the player if it is already coded to recognise them - and I expect SCALA could convert a .seq file to a midi file with MTS sysexes in it?

Or the rpns idea (or just polyphonic pitch bends for the situation where no pitch bending of notes is needed while they are held on). Advantage of those is that the player doesn't need to parse sysexes. The MTS sysexes are straightforward to parse but there are a few "gotchas" just making sure one keeps track of the position in the sysex in the correct fashion as you go through it - there is enough involved in it to require some debugging and testing rather than to just write it out and expect it to work straight off with hardly any testing at all. It's a fair amount of work for a coder if they haven't already got the code to parse MTS sysexes - well it took me long enough with FTS, can't remember now how long exactly, but long enough. Adding code to parse the extra RPNs to polyphonic pitch bends would be far easier from the programming point of view if one doesn't have the MTS sysexes already coded for, but of course isn't standard midi.

Robert

Hi Gene,

Perhaps it isn't clear how the automatic conversion would work.

The way I've done it in other similar situations - from the user's point of view - the playing program (e.g. the retuning midi player for FTS) would just show the user a list of .seq files in the current folder. User selects one of them and clicks the Play button. The player then plays the file.

What is happening in the background is that when the user clicks Play, the player calls SCALA with the file on the command line in some way - and SCALA converts it to a temporary .mid file with MTS sysexes (or whatever is appr.). Once the .mid file has been completed, then the player plays that. When it is finished playing, then the .mid file is deleted (though there could also be a user selectable option to keep the .mid file, and only remake it if the .seq file is newer).

But user sees none of this - just sees the .seq file listed, and click the Play button to hear it.

So long as SCALA can convert a .seq file passed on the command line to a .midi file, and also can be started invisibly (some programs don't let themselves be started invisibly - you start them hidden but they show themselves a moment or two later anyway) - then all is fine. It might be nec. to use the non GUI version of SCALA for command line conversions, if so, requires the user to install it before they can play .seq files - well you would need to consult with Manuel if one wants to take the whole thing further in this part. direction, but this gives an idea of the sort of thing that may be poss.

Robert

--- In tuning@yahoogroups.com, "paolovalladolid" <phv40@...> wrote:
>
> --- In tuning@yahoogroups.com, "Gene Ward Smith" <genewardsmith@>
> wrote:
> > GM is not that great, but what else is there? Csound is useless.
>
> ChucK? It's free and one microtonal composer is already trying it
> out.

Prent Rodgers uses it, with sample files he has
laboriously accumulated and edited himself. That's
not the same, at all, as the off-the-shelf samples
available elsewhere.

It can do synthesis, microtonal implementation is apparently
> easy, etc.

It can do a lot of things, but what you would really
need is a catalog of decent Csound instruments. This
does not exist. Some effort has been put into
replicating known instrument sounds, but not nearly
enough, and people are often do not share the results.

The main problem, as I've remarked before to the horror
of Jon, is that most people involved with Csound don't
really care about music.

--- In tuning@yahoogroups.com, "Gene Ward Smith" <genewardsmith@...>
wrote:
>
> --- In tuning@yahoogroups.com, "paolovalladolid" <phv40@> wrote:
> >
> > --- In tuning@yahoogroups.com, "Gene Ward Smith" <genewardsmith@>
> > wrote:
> > > GM is not that great, but what else is there? Csound is useless.
> >
> > ChucK? It's free and one microtonal composer is already trying it
> > out.
>
> Prent Rodgers uses it, with sample files he has
> laboriously accumulated and edited himself. That's
> not the same, at all, as the off-the-shelf samples
> available elsewhere.

Ok, make that 2 known microtonal composers playing with ChucK. The
other is Jeff Harrington.

I would not play with ChucK the way Prent is doing it - I'd rather go
with ChucK's physical modeling capabilities. Then again, I've been
biased in favor of physical modeling vs. sample-playback ever since I
was blown away by an in-person demo of the Yamaha VL-1.
>
> It can do synthesis, microtonal implementation is apparently
> > easy, etc.
>
> It can do a lot of things, but what you would really
> need is a catalog of decent Csound instruments. This

Not sure how that would work, as ChucK is not CSound. The ChucK
people do appear to have ported at least part of the STK instrument
library, though:

http://chuck.cs.princeton.edu/doc/examples/ (scroll down to Unit
Generators)

> does not exist. Some effort has been put into
> replicating known instrument sounds, but not nearly
> enough, and people are often do not share the results.

The folks at the ChucK forum on electro-music.com seem to be friendly
and open enough. That's where I found Jeff Harrington's posts. If
you treat them with respect, I'm sure they'll tweak the physical
models to your taste free of charge.

--- In tuning@yahoogroups.com, "paolovalladolid" <phv40@...> wrote:

> Ok, make that 2 known microtonal composers playing with ChucK. The
> other is Jeff Harrington.

Sorry, I thought you were talking about Csound and
the microtonal composer Chuckk, who actually exists.
I'll checK it out.

The Wizard strikes again!
(see his posting below for context)

If you've got any decent Csound samples, (regardless of exact pitch) with say three or four notes in each octave,
it is trivial nowadays to convert them into a set of ESX24 samples to use with Logic Pro 7 as virtual instruments automatically tuned to the nearest cent for any 12 notes per octave tuning.

There is a great new application called Keymap from Redmatica which will calculate the pitch of the samples, loop them, for you and export
the .exs mapping of the pitch adjustments, and note assignments, and ready to be used automatically with any group choices you may select.

You also edit the gain, envelope, and other pertinent parameters for each sample from within Keymap.

http://www.redmatica.com/Redmatica/Welcome%20to%20Redmatica.html

If you really "like" the CSound sample you could less samples per octave and re-constitute them to build a complete range using Keymap,

CamelAudio

http://www.camelaudio.com/cameleon5000.php

or MetaSynth.

http://uisoftware.com/MetaSynth/

Unfortunately you'll have to use a pre-Intel Mac for Metasynth until they get around to universalising it.

So if anyone has a great set of Csound samples, there is prolly a market for them, regardless of what precisely what pitch they are.

So send me a link to where I can download them, and we'll experiment and see if we can use them in a million-selling pop production;-)

This page partially tells you how to do it, and to LucyTune the results

Charles Lucy lucy@lucytune.com

----- Promoting global harmony through LucyTuning -----

For information on LucyTuning go to: http://www.lucytune.com

LucyTuned Lullabies (from around the world):
http://www.lullabies.co.uk

Skype user = lucytune

On 7 Apr 2007, at 01:29, Gene Ward Smith wrote:

> --- In tuning@yahoogroups.com, "paolovalladolid" <phv40@...> wrote:
> >
> > --- In tuning@yahoogroups.com, "Gene Ward Smith" <genewardsmith@>
> > wrote:
> > > GM is not that great, but what else is there? Csound is useless.
> >
> > ChucK? It's free and one microtonal composer is already trying it
> > out.
>
> Prent Rodgers uses it, with sample files he has
> laboriously accumulated and edited himself. That's
> not the same, at all, as the off-the-shelf samples
> available elsewhere.
>
> It can do synthesis, microtonal implementation is apparently
> > easy, etc.
>
> It can do a lot of things, but what you would really
> need is a catalog of decent Csound instruments. This
> does not exist. Some effort has been put into
> replicating known instrument sounds, but not nearly
> enough, and people are often do not share the results.
>
> The main problem, as I've remarked before to the horror
> of Jon, is that most people involved with Csound don't
> really care about music.
>
>
>
>

Hi Aaron,

Just a correction, not really adding much to the discussion.

Sorry - I just realised now, that what I said to you and Gene earlier this week about the midi file parser is muddled - I was forgetting that it is in fact poss. for a midi file parser to detect the end of the data bytes of an unknown length of message, because all the data bytes have most significant bit set to 0 - while the first byte(s) of time deltas, and the status bytes all have it set to 1 (which is why all the data numbers have ranges 0 to 127 instead of 0 to 255).

So - you could indeed have 5 byte midi note on messages in a midi file.

An existing midi file parser can validly expect a midi note on to be two data bytes since the spec says that it is, so could treat a midi file as broken if the note on has more than two bytes. But if the spec were updated to allow for five byte note on messages, it would be poss. to update one's parser to detect both types of note on just by counting how many data bytes follow the note on, and behave accordingly when they are detected.

So you were right there. Sorry for my mistake.

It is however true that you still couldn't send them via the low level API in windows as it only allows for two extra bytes in the routine to send a midi message ( the routine is called MidiOutShortMsg(...) http://msdn2.microsoft.com/en-us/library/ms711640.aspx, and actually has space for a third byte, but the byte is marked as "not used" so prob. anything you put there is just ignored )

Robert

Robert walker wrote:
> Hi Aaron,
> > Just a correction, not really adding much to the discussion.
> > Sorry - I just realised now, that what I said to you and Gene > earlier this week about the midi file parser is muddled - I was
> forgetting that it is in fact poss. for a midi file parser to
> detect the end of the data bytes of an unknown length of message,
> because all the data bytes have most significant bit set to 0 -
> while the first byte(s) of time deltas, and the status bytes all
> have it set to 1 (which is why all the data numbers have ranges
> 0 to 127 instead of 0 to 255).

I thought you were right first time. A time delta with the MSB set means it isn't the end of the time deltas. A delta of less than 128 ticks would have the MSB clear. Do you have a reference for the file standard?

Graham

Hi Graham,

The midi file format is:
<1 time delta> <1 time delta>... <0 time delta> <1 status channel> <0 data> <0 data>
<1 time delta> <1 time delta>... <0 time delta> <1 status channel> <0 data> <0 data>
...

So the midi file parser can go through the file like this:

Read <1 time delta> then read the rest of the time delta until you hit <0 time delta>
Read <1 status channel> then read the data for as long as you continue to encounter <0 data>
repeat

So - it does permit variable lengths of all the messages after all, but more efficiently coded for short chunks than the method that requires a separate byte to give the length of the chunk.

Typically you have three bytes for the message, and only use 3 bits to keep track of the length of it, and the shorter the message, the less bytes used to keep track of its length.

I've checked my own parser and as it is now, it uses a mixed approach - works out how many bytes to expect from the type of message - but if it encounters a highest bit set to 1 in any of the expected data bytes that follow, then it stops looking for data, and treats that as the start of the next time delta. So as it is now, it would be able to recover from an invalid midi file and just ignore unrecognised data in it.

However, it would be quite reasonable to write a midi file parser that just works out how many data bytes to expect from the status byte and doesn't do any additional checks to make sure they are valid. It would work fine so long as the midi file isn't corrupted, just is less able to recover data from a corrupted midi file. My parser was originally written like that, but I must have updated it later on to take account of possibly corrupted midi files.

Robert

Robert walker wrote:
> Hi Graham,
> > The midi file format is:
> <1 time delta> <1 time delta>... <0 time delta> <1 status channel> <0 data> <0 data>
> <1 time delta> <1 time delta>... <0 time delta> <1 status channel> <0 data> <0 data>
> ...
> > So the midi file parser can go through the file like this:
> > Read <1 time delta> then read the rest of the time delta until you hit <0 time delta>
> Read <1 status channel> then read the data for as long as you continue to encounter <0 data>
> repeat

I found one MIDI file on my hard drive. It says it's retuned by Scala. It doesn't look like that -- lots of the time deltas are 00. That means all the <1 time delta> bytes are optional.

> So - it does permit variable lengths of all the messages after all,
> but more efficiently coded for short chunks than the method that
> requires a separate byte to give the length of the chunk.

Every message type has to have a fixed length. Otherwise you can't tell if you're reading a <0 data> or <0 time delta>.

> Typically you have three bytes for the message, and only use 3
> bits to keep track of the length of it, and the shorter the
> message, the less bytes used to keep track of its length.

?

> I've checked my own parser and as it is now, it uses a mixed
> approach - works out how many bytes to expect from the type
> of message - but if it encounters a highest bit set to 1 in
> any of the expected data bytes that follow, then it stops
> looking for data, and treats that as the start of the next
> time delta. So as it is now, it would be able to recover
> from an invalid midi file and just ignore unrecognised data in it. That'll work because you should never find the parity bit set when you expect data bytes. But ignoring the expected message lengths and waiting for the parity bit to be set won't work as you'll encounter single byte deltas. Try it!

> However, it would be quite reasonable to write a midi file
> parser that just works out how many data bytes to expect
> from the status byte and doesn't do any additional checks
> to make sure they are valid. It would work fine so long
> as the midi file isn't corrupted, just is less able to
> recover data from a corrupted midi file. My parser was
> originally written like that, but I must have updated it
> later on to take account of possibly corrupted midi files.

In many cases it's an advantage to recognize a corrupt file.

Graham

Hi Graham,

> I found one MIDI file on my hard drive. It says it's
retuned by Scala. It doesn't look like that -- lots of the
time deltas are 00. That means all the <1 time delta> bytes
are optional.

Oh yes of course, I was forgetting that possibility, which is the most common case too as you say. Yes you are right!
If the time delta is small enough then the 1 isn't needed and it could be confused with a data byte if one didn't know the length of the preceding message. Then the next status byte would be taken as time delta, its first data byte as the second byte of a time delta and you only know that you have a corrupted midi file by the time you get to the second data byte (if present).

Yes you are correct, and so was I originally as you said. Thanks for the clarification.

Robert

--- In tuning@yahoogroups.com, "Gene Ward Smith" <genewardsmith@...>
wrote:
>
> --- In tuning@yahoogroups.com, "paolovalladolid" <phv40@> wrote:
>
> > Ok, make that 2 known microtonal composers playing with ChucK. The
> > other is Jeff Harrington.
>
> Sorry, I thought you were talking about Csound and
> the microtonal composer Chuckk, who actually exists.
> I'll checK it out.

Here's the electro-music forum discussion thread on microtuning in
ChucK, with some suggestions. Yes, I too thought Chuckk was somehow
involved. ;)

http://electro-music.com/forum/viewtopic.php?t=17327