It's good to hear more about Peter Phillip's new roll reader.  However,
I was struck by the assertion that "a roll scanner is not suited to
producing a performance file" because "a single perforation will
produce a MIDI signal with a duration equal to one perforation".  This
is only true if the software's author hasn't bothered to code for it!
In general, if a behaviour such as this can be described it can be
allowed for in the software model.

I've long said that if you start with a file that accurately represents
a roll (ideally a reconstructed roll master, however that is created),
then you can accurately model the way a player piano converts this into
sound -- as long as you bother to capture all the aspects of what this
entails!  You have in the computer exactly what the player-piano receives
when the roll's played on it, nothing missing, so there's nothing in
the playback that can't be replicated.

Peter is spot-on about how MIDI versions of rolls are becoming an ever
more important means of presenting this historical musical material to
the wider public, and even within the hobby.  Sadly, a lot of the
software to make MIDI files from piano rolls is fairly rudimentary,
omitting a lot of the subtlety of how a physical player interacts with
a piano roll.  Creating playable MIDI files from roll scans, and
particularly recreated-master files, requires quite a lot of processing
to deal with the way that the player converts the roll into sound.
I've been doing quite a lot of work on this in my roll-processing
software.

The most obvious thing is that you have to strip out the bridges
('eroll' MIDI files omit these anyway).  You should also allow for the
acceleration of the paper as the roll progresses, but this isn't quite
as simple as it sounds because virtually all dance rolls are strict
tempo, and accelerate when played on a player piano even though they
shouldn't, so a conversion could achieve a more precise, although less
authentic, musical effect by omitting acceleration-compensation on
strict-tempo rolls.  This requires the software to be told what type
of construction the roll is.  I'm not aware of anybody bothering about
this.

Once you've been through all of this, allowing for the way that a player
extends notes is really not a lot more to add!  The smart way is to add
a fixed amount to the 'off' event associated with each slot.  If you do
this, you automatically remove any bridging as well -- this is exactly
how the real player piano works, anyway.  You do, though, have to be
careful about how you do it.  If you simply delay the MIDI 'off' events
then you need to sort everything back into time order again afterwards;
MIDI works a list of events and times between events, so shifting one
event affects all those that follow it.

Shuffling notes around requires the software to keep track of the
proper order, typically by tagging the events with absolute rather than
relative times, which allows you to sort the absolute times into order
and re-calculate the relative times afterwards.  You also have to
remove any 'on' event that the 'off' event overtakes (that's how you
get rid of bridges).  Not hard to do, but fiddly.  However, it's this
attention to detail that makes a good playable MIDI file.

Now, if you're going to use these MIDI files to operate a pneumatic
player piano that's fine, but if you want to operate a MIDI instrument
you need to do more.  This is because there's a fundamental difference
between a MIDI and a piano roll -- a roll codes for the point when the
piano action starts to move, but MIDI codes for the time when the note
actually sounds.  In the case of a piano there's a significant
difference between these times.

Instruments such as the Yamaha Disklavier and the Boesendorfer SE allow
for this by having calibration logic that knows how long each note
takes to operate as differing velocities, and adjusting the start time
in order to sound at the correct time.  That's why they operate with
a half-second delay.  So far all I've done is ponder about this.  Logic
suggests you need to shift the 'on' events by a time related to their
velocity, but to date I've not attempted it.

In rolls made from MIDI files you see exactly the same thing in
reverse.  When I started to make rolls one of my first custom-cuts was
a set of boogie woogie piano rolls created to sound precisely correct
in the MIDI.  When the first rolls were cut the notes were just too
long to get the desired effect.

This is the note-extension effect in reverse: to make a roll from MIDI
you need to subtract a bit from the slot length in order to allow for
the way the player extends notes by some fraction of the height of the
tracker-bar hole.  You also need to allow for the size of the punch and
the way that punches overlap, because 'note-on' is the start of the
first punch but 'note-off' is the end of the last punch.  Both of these
effects require the slot to be shortened a bit, and are additive.

In all of the above, if MIDI is to become a major way of sharing roll
performances, it seems to me that those in the hobby need to put more
work into creating the best-possible musical results from these files
(whether or not we agree with the trend).  I'm not aware of a great
deal of work going on in this area.  I think that most of the software
being used to convert scans is the first-generation material created by
those in the 'rollscanners' group.

The production of simple scanners has been a triumph, and with growing
volumes of scanned material perhaps it's time to do more work on the
software to polish up all the nuances described here, and the many I've
no doubt missed.  If this is all too clinical, you could even add a bit
of random or controlled error to allow for ill-adjusted instruments!

Julian Dyer
Wokingham, Berkshire, UK

 [ I think the moral of the story here is to make the most accurate
 [ scans you can of the roll and preserve the scans after they have
 [ been processed into MIDI files.  That way if a better software model
 [ is written the scans can be reprocessed without having to re-scan the
 [ rolls.  --Jody