Now listen up, MIDIots!
     This group of  .MID files is designed to test the new MIDI file
standard format.  It contains a number of simple sequences created
with Dr.T's KCS 2.0 for the Atari ST, and converted to .MID files
by the CONVERT.PRG supplied with KCS 2.0 by Dr.T's.

     It seems to work fine changing from KCS format to .MID format
and back again (at least on those rare occasions when I remember to
set steps/beat correctly at every stage of the conversions!)

  The burning question is of course: will it work with your favorite
sequencer? (Atari, Mac, IBM, whatever.) And I want to know if I can
convert files from another sequencer to the Dr.T format. (Is we
compatible?)

      I have no documentation as to the format of the .MID file. I
guess it was invented and first supported by Opcode last year. If
anyone has the MIDI file standard specification and feels like typing
it up & uploading it, we would certainly appreciate it!  It would
clarify some of these confusing points.
      But I looked at the .MID files created by the Dr.T program
and found the following:

     [1]  Midi events are stored with a varying number of bytes,
depending on the type of event and the number of data bytes it uses.
     [2]  The normal format is:
            - one byte for number of time-steps (ticks) since
              the last event, as long as this is 127 steps or less.
              (Longer times-between-events use another byte;
                see below.)
            - the status byte for the MIDI event, if necessary,
               typically $90 for a note-on, channel 1.
            - one or 2 data bytes, as required.
     [3] If the time between events is greater than 127 steps,
           a second timing byte is included, before the other one.
           It may be identified by the fact that its high bit is on,
            in other words, it is &80 (128) or greater. The remaining
            7 bits give the number of 128-step increments to be added.
           For example, if the first byte in the event is (decimal) 24,
            then this means 24 steps, normally a quarter note.
            If the first 2 bytes are 179 and 99, then the time between
            events is 6627 steps, normally about 69 measures.
             179-128=51, so 51 * 128 = 6528 steps come from the "179";
             and the 99 (since it is < 128) means 99 steps.
             And 6528 + 99 = 6627.
       [4] Running status is used, even if your sequencer's native
            data storage format does not use it. So an event like
            channel pressure may use only 2 bytes, one for time-since,
            and one for data.
               Note offs are sent as note-on, velocity zero to use
            running status, provided they were originally sent that
            way from your synth (most synths do this, instead of
            actually sending release velocity.)  
            The Dr.T method of storing a note-on
            -off pair as one event with an associated duration
            is of course not used in the .MID format.
      [5]  A status byte of $FF (255) is used to indicate the end- 
            of sequence. All Dr.T's "DE" events seem to be converted
            into $FF. Not sure if this will confuse the conversion
            from .MID to .SEQ files if your Dr.T tracks or sequences
            contain DE events besides the normal one at the end.
            I certainly hope that no conversion program actually sends
            $FF from your sequencer, since this is the "system reset"
            command, which could cause big trouble!
                Apparently one or 2 more bytes follow this $FF;
             I don't know what they mean.
      [6] Usually, the track or sequence data begins at byte # 65.
            The first 26 bytes contain some ASCII characters like
            "MThd" and "MTrk", and other info which I presume relates
            to the length of the file, and such things as
            steps per beat, and tempo.
                Bytes 25 and 26 appear to contain the length of the
            data (number of bytes).....I'm not sure
      [7] Bytes # 27 thru #64 appear to be used for the track or
            sequence name, in ASCII of course.  Since Dr.T's file
            storage format includes an 8-character track- or sequence-
            name, this name appears in the first 8 spots (bytes # 27
            thru #34.)
                Although the Dr.T conversion program puts the 
            sequence or track name into the .MID file, it does
            not extract it and name the Dr.T track or sequence
            as it should when converting from .MID to Dr.T's
            .SEQ format.   (Bug, or "feature", #1)
      [8] I just looked at some more .MID files, and while the 
            above info is sometimes true, sometimes it's not.
      [9] When I create .MID files, my conversion program asks
            how many steps/beat I used.  I tried some files at 24,
            48, and 96 steps/beat.  The program seems to know which
            one I used, since when I convert from .MID to Dr.T's
            format, this value comes out right. Therefore it must be
            encoded somehow in the first few bytes of the .MID file.
            The Dr.T conversion program will also create Dr.T files
            from .MID files that use a different steps/beat value,
            and will adjust all times accordingly.
                 Steps/beat can be tricky. You have 4 chances to
            screw up, and I usually do.  My coversion program allows
            me to tell it how many steps/beat to use at 4 times:
               when loading a .SEQ file, when saving a .MID file
            when loading a .MID file, and when saving a .SEQ file.
                 I'm not sure that all the .MID files I've included
           here were created correctly.

    I'm interested in hearing how they look on your sequencers.


THE FILES:   


DSCALE1.MID is a simple D scale, MIDI channel 1, in quarter note 
     separation, with eighth note durations.  24 steps/beat.

DSCALE2.MID is the same scale at 48 steps/beat. 
        Still quarter notes, but this time the note-ons are
         separated by 48 steps.


DSCALE3.MID is the same scale but uses 48 steps/beat, and 24 
         steps between note-ons  (eighth notes.) 
         Also includes a tempo event (122.7 beats/minute) so
         we can see if the tempo is somehow encoded in those first
         26 bytes.  The Dr.T program correctly extracts this tempo
         from the .MID file.  Look for it in your sequencer!

DSCALE4.MID  is the same scale, 48 steps/beat.  But the note-ons
        are separated by LONG rests of 148 steps, 248 steps, 348
        steps, etc....  See if your conversion program gets these
        values (848 steps before the last event.)


TRASH.MID is the scale with lots of other controllers added (channel 
    pressure, mod wheel, contr. #4, sustain pedal, and pitch
    bend)   .....Check and see if your conversion program gets all
    these MIDI events as it should.  If it works correctly, it should
    sound even worse than Willie Nelson.

TIGHT.MID is a chromatic scale at 96 steps/beat, with only one
      time step between notes (VERY fast) It is one bar long,
      so it has 384 notes (OK, 385.)

WALTZ_96.MID is recorded at 96 steps/beat, and 288 steps/measure.
        A tempo of 181 (?) beats/minute is included. The Dr.T
        program did not correctly get the 3/4 time signature
        from the .MID file, but it might be my mistake. 

JINGLE1.MID is 24 steps/beat, MIDI channel 1; a television jingle which
    should sound quite familiar to anyone who has watched late movies
    in L.A. (It's public domain!)

JINGLE2.MID is similar, but done at 48 steps per beat, and features
    even sloppier playing.  If your conversion program gets this one,
    you should see notes happening on all sorts of odd steps, not
    just those divisible by 4. (as you would get if your resolution
     were only 24 steps/beat)

JINGLE3.MID is the same as JINGLE2 but the melody is on channel 2.
       The accompaniment is auto-corrected (quantized) but the 
         melody is not.

That's it!  I'm interested in some feedback to see if this Midi File
standard is working, and if the conversion programs that our software
companies provide can handle all the garbage we put in.

       I'm sorry, but I'm sure that I made some mistakes in
the steps/beat area, and some of these files may not be as
advertised.  Still, we can learn something from them.

Let me know if you want to see some more types of files. I'll be 
looking for .MID files from other sequencers so I can try them with
Dr. T's conversion program.

        The Dr.T conversion program supports only file standard 1.0,
for single (multi-channel) sequences or tracks.  I don't know if there
is another standard which supports chaining, looping, or whatever the
various structuring  options may be called on your sequencer.  I doubt
it, since each sequencer seems to have a completely different way of
making a whole piece of music out of smaller pieces.  Dr.T's KCS has
more structuring options than other sequencers I've seen, so I'm sure
there is no way to make another sequencer understand the KCS structure
commands.

    The easiest solution to this problem appears to be either:

      [1] Let a .MID file contain a whole piece, and let the
            receiver unmerge by channel or whatever.   OR,
      [2] Include lots of .MID files for people whose sequencers
            can't unmerge, along with a text file explaining how
            to put it all back together again.  OR,
      [3]  Some insane combination of the above...OR,
      [4]  Keep your music to yourself. Everybody's heard all those
            notes before, anyway.


I'm leaving this on MIDIUM (818-764-4538).  Maybe our SYSOP will
create a new file directory for .MID files.

Let's try this out!

                            Doug Livingston....