Hi all, I want to thank Tony Decap for making a clear statement about
the coding process used in MIDI. And I certainly agree that the
ability to both see and hear the music when using MIDI is a loss worth
addressing.
You are correct that it was not intended. That is because the folks
who devised MIDI had no input or requirements from anyone involved in
mechanical music.
I think it would be a very worthwhile effort to make a program that
would display both the notes and the music graphically on something
like a laptop screen. (By the way, if I were doing it, I would have
the notes scroll from bottom to top so that the words read top to
bottom instead of the awkward up-reading text used on a piano roll.
I would _not_ have the words scroll across the bottom of a vertical
moving roll either.)
I'd like to add a note and a question to Tony's description. We all
hear about compression used to reduce the data stored for various
processes. The most common use mentioned today is in graphic images;
see the manual for a digital camera. But there are many others like
zip files and fax compression algorithms.
When you encode music into MIDI, you actually use compression too
because MIDI only records a change in state (a MIDI event = note on vs.
note off). The piano roll uses 88 (parallel) columns to represent the
88 notes on a piano; at any instant, each column has either a hole or
a non-hole. As time passes (and the roll moves forward), holes and
non-holes reach the tracker bar and cause notes to play or be silent.
Thus a piano roll containing one note near the beginning and one note
near the end (2 minutes later) is the same size as a roll containing
thousands of notes but lasting the same length of time (2 minutes).
MIDI would be a tiny file which shows just the 2 notes.
So, here is a question. I understand how a live MIDI performance
(from a keyboard) sends a note-on or a note-off command because it
happens in real time. But, how does a _recorded_ MIDI file represent
the time when the notes are on and off? I would think that there is
another part to the data for each event which tells the device _when_
to play each note/event. In this case the 'clock' would be in the
program the receives or processes the file -- right?
While I'm at it, I notice that a Cakewalk event file lists the on-time
for each event and (if it is a note) then the duration of the event.
Is there another 'level' of code in a Cakewalk MIDI file that actually
contains the on and off events?
With all this in the back of my mind (where there is usually a _lot_
of room), I wonder if one could make a MIDI file where notes were notes
and where events would represent each word as it 'plays' by the tracker
bar.
Regards
Craig Smith in snowy upstate New York - USA
[ Editor's comments;
[
[ You're correct, the MIDI data file contains time information,
[ actually stored as measures and beats along with metronome
[ information. The program that plays the MIDI file reads the
[ metronome setting and the meter (3/4 or 4/4, etc.) to determine
[ how fast to play the music. The MIDI file is analogous to sheet
[ music in many ways, and it's this adherence to traditional sheet
[ music convention that makes MIDI editing programs frustrating
[ when editing music roll performances.
[
[ A MIDI file does not store music like a audio recording does.
[ MIDI data is commands to push the keys of a real instrument,
[ whereas MPEG or JPEG files store fuzzy representations of the
[ sound or image.
[
[ The native Cakewalk "WRK" file stores the on-time and the duration
[ of the event, whereas standard MIDI files (SMF) store the on-time
[ and off-time (or equivalent) as separate events. The Cakewalk WRK
[ file is much larger than a MID file but editing the data is quicker.
[
[ MIDI files can store all the words and syllables that you see on
[ the piano roll, but typical MIDI editing and playing programs don't
[ display a piano roll image like you wish. Maybe a karaoke player
[ program could do the job; I've heard they can also display images.
[
[ -- Robbie
|
