In re-reading my post in the 95.11.26 digest I realize that I
was not quite as precise as I should have been on a couple of points
which I hope the following will clarify.  The insomniacs among you may
wish to view this as therapy.

        IF the purpose in "electronically" reading a music roll is to
manufacture new paper copies of the roll, THEN optically scanning the
roll with an essentially zero width sensing line will produce
perfectly acceptable results.  It will not be necessary to account for
differences in specific tracker bar hole sizes and patterns, i.e., the
(usual) spatial differences between expression holes and note holes.
HOWEVER, two things DO need to be considered and accounted for:

        1) The optically sensed length of the hole will be different
from the pneumatically sensed length of the hole.  The degree of this
difference will be somewhat dependent on the transport "speed" of the
paper (as subtly differentiated from "tempo").  Since the goal is to
produce a roll that has the same pneumatic performance as the
original, this difference must be compensated for.  A properly
designed post-scanning data manipulation algorithm should be able to
do this.

        2) The mechanism by which the paper is moved past the sensing
line is critical as transports which use the "bulk drawn" method will
produce differing, gradual tempo errors depending on such variables as
the take-up spool diameter and the driving motor torque
characteristics.  The safest method would be to use the capstan/pinch
roller method found in the roll perforators themselves such that the
paper is moved at a constant, predictable rate (distance per time
division), past the sensing line, end-to-end.  This is a more
complicated method/mechanism.  My experimental bulk-drawn pneumatic
reader has a component to allow this compensation, a shaft encoder.
For anyone unfamiliar with these, a short tutorial is offered.  A
typical shaft encoder looks like a small DC motor as might be found in
a toy car.  Mine is about an inch in diameter and has a 1/8" shaft.
Attached to the shaft is a rubber tire wheel of such a diameter that
when the assembly is held against the moving paper, the wheel makes
exactly 2 1/2 revolutions per foot length of paper travel.  The
encoder is provided with a 5 VDC power input and outputs, on a
separate line, a logic level square wave pulse train of 100 pulses per
360 degree revolution of the shaft.  The pulse train is fed to the
MIDI circuitry and each pulse is recorded as a separate MIDI event.
This allows the other true note events to be correlated with a precise
position on the length of the paper.  Most importantly, these
relationships are INDEPENDENT of the transport speed so the method by
which the paper is moved is irrelevant.  In fact, I can even vary the
tempo during reading, speeding up for good sections and slowing down
for damaged sections.  Of course, depending on the sequence recording
software being used, a data manipulation algorithm will still be
needed to convert this into a file which can actually be used to drive
a perforator accurately.  This is something I have not pursued as of
yet.  Now, it would seem with the above setup I would only be able to
resolve hole events with a precision of 1/250th of a foot or about
48/1000ths  of an inch.  Many music rolls seem to be perforated at
about 40 steps per inch so that each step is about 25/1000ths of an
inch.  The engineer's rule-of-thumb is that your measuring method
should be about one tenth as "fine" as the data you are trying to
measure.  Fortunately, the shaft encoder is precise enough that events
which occur between encoder pulses can be interpolated by means of the
system clock to a much finer resolution, how much finer I have not
empirically determined.  The ultimate resolution will still be
determined by the capabilities of the sequencing program being used
for recording, usually specified as a "pulses per quarter note" value
which itself is tempo dependent, although its absolute time resolution
should be constant.  A different method of increasing the apparent
resolving ability of the shaft encoder would be to decrease the
diameter of the wheel, thereby increasing the pulses per foot output
value.  This likewise increases the density of the MIDI data, which,
if allowed to become too high, will negatively affect the timing of
other MIDI events within the file.  I have not determined an optimum
relationship among these variables.  I have found that using this
reader with the Cakewalk program for recording yields files of
approximately 100K bytes for an average length Ampico classical roll,
BEFORE COMPRESSION.  Since MIDI data compresses quite efficiently,
these should be able to be stored as approximately 50K byte files.  If
I am doing the math correctly, this should allow EVERY Duo-Art AND
Ampico roll ever issued (10,000 to 12,000 rolls?) to be transcribed
onto ONE CD-ROM!!  Now, what would you pay for that?!

        Now, IF the purpose in reading the roll is to convert the
performance into a format which reproduces correctly on electronic
synthesizers, my original concerns about the spatial/size differences
among various tracker bar hole formats once again become important and
must be accounted for if read by a zero width sensing line.  Richard
Brandle, please step in here and educate us on this!  Likewise,
converting MIDI intensity (velocity) data into appropriate tracker bar
hole openings to achieve an equivalent performance on a reproducing
piano (has anybody done this?) is a capability which I would be VERY
interested in.

        That's all for now.  Sleep well!

-John Grant