In the first place, it is simply rhetoric to say that MIDI doesn't have
semantics. You may not like its semantics, but they are there.

My motivation for this suggestion is to make it easier to inter-operate with
existing protocols such as MIDI. I would not be the first developer to
extend or change MIDI; its commercial developers have been doing this since
the beginning. Just recently, for example, Cubase supplemented MIDI by
including a cent field in the MIDI channel message structure in their new
VST 2 plugin protocol. Adding a duration field would be a similar move.

Another example of an extended MIDI protocol is Perry Cook's SKINI.

Again, the purpose of these adaptations is to make it easy to, for example,
open a MIDI port and then fill in fields of one's adapted protocol, or to
take a score written in one's extended protocol and pump it out a MIDI port
or save it as a MIDI file. It is not to develop a new representation of
music from the ground up. There is an enormous body of music, and an
emormous body of working hardware and software, that uses MIDI in musically
significant ways. Adding floating point precision and duration to MIDI would
provide a very large increment in functionality, and be easily adapted to
existing systems, at a very slight cost in programming.


-----Original Message-----
From: Tobias Kunze 
To: Michael Gogins 
Cc: Richard Dobson ; csound csound

Date: Monday, July 26, 1999 9:50 AM
Subject: Re: sequencer


>
>> The simplest thing would be to use MIDI semantics but with float values.
>> Thus key 60.5 would be 1/4 tone sharper than C.
>
>Please don't.
>For the most part, pitch included, MIDI doesn't have semantics.
>It would be wrong, therefore, to equate "60" with "middle-C" or
>a unit increase in keynumbers with one tempered half-step.
>
>Also, as others have pointed out, there is no notion of duration
>in MIDI, hence no such pfield to set.
>
>If you want a sequencer for csound, look at cm.  It doesn't care
>about pfields, as long as you (the programmer) defines their
>semantics.   I dont' see how a different approach is possible for
>csound.