As said in the original text, you have to make a difference between
MIDI stored/played and MIDI transportation through a wire.

One of the differences is that in the stored form, each MIDI-event has
extra information called DELTA-TIME.  This represents the time before
the following event is to be played.  But this is not in real-time,
like for example seconds, but in coordinates that describes the
position of the note on the piano roll.  The final real-time that the
note will be actually played depends on the tempo (and eventual tempo
changes).

This relates to another difference in the way MIDI is designed compared
to a piano roll.  All the music on the MIDI-piano roll is in absolute
terms.  One quarter-note is always the same length on the paper.  If
you want a song to play slower, you must slow the feed of the paper
down.  It's a little like a real piece of written music.  If the music
slows down, you do not write the notes further apart, but the musician
starts reading slower.  Where the exact time lays in terms of seconds,
depends on the speed (tempo) of the performance.  It's thanks to this
approach that you can change the tempo at any time after the MIDI file
has been finalized.

I'm not sure how Cakewalk stores it's WRK files, but this has basically
nothing to do with the event-list.  If you load a MIDI file, you find
the length of the notes by looking for the note-off that relates to
a previous found note-on.  Then a little fiddling with the DELTA-TIMES
gives you the length, which is then easily displayed in a list.

In the DELTA-TIME MIDI uses we find one of the problems when converting
between piano roll and MIDI.  As you slow the paper feed down, you start
messing with mechanical properties.  For example, a drum-beater must
play a little ahead.  If you start changing the feed, these times get
messed up, resulting in poor timing.  The solution lays in the software
that must try to calculate and correct this.  But in order to do that,
the software must "know" the properties of the mechanical instrument.

About displaying a real-time piano roll, I have made different attempts
at it, and it works great.  But the only problem is that you need some
heavy computer hardware.  It is very demanding for a PC to redraw about
20 frames every second.  If the PC is not up to it, then you get a
shaky or flickering picture and/or worse, the MIDI playback starts to
lose its good timing.  I'm currently playing with the tools used to
make games (called DirectX), but I lack the time for the moment to get
deeper into it.  If anyone has some tips for me how to get better
results with this issue, it's always appreciated.

The effort I make (which are the MIDI players supplied with our organs)
is also for a project that's in my mind for years.  The idea is simple:
make a software that holds all the tools to create virtual mechanical
instruments, new ones or re-create existing ones.  Add visual
possibilities so that you can see the instrument play (animate the
instruments), including the piano roll.  This software would include
issues like the DELTA-TIME problem mentioned above.

The uses are many: Anybody who owns an instrument could re-create it
in software so that he for example could arrange new music and hear it
play (on the included sampler with all needed samples) real-time on
his "virtual" instrument.  Or he could think about adding or changing
things which he could first try out in his PC.  Or he could build his
dream-instrument and get it build after he decided which scale and how
many ranks of pipes and so on.

This software would work with our new line of stand-alone instruments
like accordion, drums, percussion and pipe-chests.  These pipe-chests
are very small (about 125 x 125 x 600 or 1200 mm) and stand-alone
chests containing any pipe-register.  It only needs unregulated air
(straight from a blower or bellows), power and MIDI.  You can set it
to one of the 16 MIDI-Channels.  Air-effects like tremulant/vibrato
are built-in.

The big advantage is that you can put it, for example, on your desk or
any shelf.  If you create an organ with the software, you then could
slowly realize the organ rank by rank, add an accordion, drums,
xylophone.  And you would always have a full sound as all missing
ranks/parts would be played by the PC.

But people do not want to pay money for things they do not get.  If
they buy a chest with pipes, they understandably want a reasonable
price.  So disguising the design-costs of the software in our products
is not completely fair.

The problem with the software is of coarse the monumental effort it
takes.  And we all know that so much illegal software copying is going
on, that it is very unlikely that you would ever get the effort
translated in to break-even -- forget profit -- if you try to sell it
(unprotected) at a reasonable price.

The other angle could be that we as a company could give the software
for free, and hope that when a customer put his dream-instrument
together, he will order it at our factory.  But why would he, as in the
end we may be more expensive due to our investment in tools like this
virtual software.

Another possibility would be to copy-protect all our efforts.  But this
is a big effort in it's own right, and nobody is happy with all these
keys and registration.  So for me no real solution here.

But we will continue the work, and we will see how this develops.
And our work is our hobby, so who cares if we lose some hours spent
searching for that great application.

Tony Decap
Herentals, Belgium