Archiving and Music Roll Duplicating
By John Rhodes, forwarded by Robbie Rhodes
John asked me to edit his submission and add comments {mine appear in curly brackets like this}. [Jody is also invited to comment, in square brackets like these!] -- Robbie Rhodes
[ In the interest of getting this out tonight, I'm going to refrain
[ from commenting at this time. I hope to read it for content
[ tomorrow. Perhaps some of our other readers will have some ideas
[ to add by the time I put in my 2 cents worth...
[ Jody
===== John's letter follows: =====
from: jrhodes@teleport.com (John Rhodes)
via: rrhodes@foxtail.com (Robbie Rhodes)
date: 28 December 1995
Here are some thoughts of mine about duplicating music rolls.
TO ARCHIVE - where the objective is to save all relevant information content from the roll (most likely in electronic form). {If you can exactly duplicate the original music roll - make a "counterfeit copy" - then you have proven that _all_ relevant data was saved.}
The deteriorated physical condition of the rolls impact the system design, e.g., torn edges must be physically repaired, or else the data file must be edited before a replica can be produced.
TO REPLICATE - where the desired result is an exact replica (content and media) of the input roll:
High accuracy reproduction of the original rolls is a frequent request. I assume many owners of antique machines don't want them converted to operate from MIDI; they want to restore the players and play high- quality working copies of the original rolls.
TO TRANSLATE - where roll music from one machine (e.g., Ampico) is translated into roll music for another machine (e.g., Duo-Art). And, of course, translation into MIDI would permit some of us less well-situated aficionados to enjoy songs which were originally arranged for player pianos, organs, band organs, music boxes, etc.
TO EMULATE - where the music is performed on other than the original target machine (for example, playing band organ music on a MIDI- controlled synthesizer). Implies Translation.
TO EDIT - where the archived music information is examined for various defects (time skew, dropped beats, quantizing errors), and corrected.
---- The Need for Realtime and Portable:
Some collectors have over 5000 rolls which need to be archived. At 12 rolls per hour, over 50 eight-hour days will be needed to effect the conversion. Transporting those rolls to a conversion site would require more than 100 household-moving boxes. Modern technology should be capable of delivering an archiving mechanism (spool box & reader) supporting electronics, digital (laptop?) computer, and archive media (magneto-optical disk) which would fit in a medium-size suitcase.
---- MIDI as an archive format:
MIDI data format provides all that is needed for archiving. {It won't save images of the artwork of the leader.} Accuracy and time resolution are adequate -- MIDI file format can specify a simultaneous 88-note keydown event. Even something as demanding as subtle loud-pedal manipulation could be handled by a dedicated track (with >100 possible positions for the pedal!). Editing programs such as Cakewalk and Master Tracks provide extended MIDI formats which can archive lyrics. There is a huge advantage in using existing formats and commercially available editors! {Amen!}
For performance, MIDI file format can be distributed and buffered for acceptable time coherence. {This capability isn't available in typical sequencers using the Midi wireline for output data.} Further, MIDI format processors could be developed which partially compensate for skew, much as pipe organists anticipate the slow bass notes on their pedal manual, or as was done on Ampico rolls to pick out the melody from the accompaniment. And who 's to say that the next generation of MIDI instruments won't operate over a 10 Mhz bus where time skew is no longer an issue. The MIDI format will endure. {Are you speaking of the Midi File Format or the wireline protocol?}
---- The Reader:
I like an optical reader, specifically, a pair (side-by-side) of 200-dpi FAX scanner heads. There is adequate bandwidth and sensitivity. The price is right because they are a component of a consumer product. The electrical interface is already TTL. (As of 3-4 years ago, cost-effective FAX technology crossed over from page-width arrays to optics (lens, mirrors) and a CCD linear array on a small chip at 200 dpi; lower resolution used the page-width arrays.)
The FAX approach utilizes the imaging component as it was designed to be used! Video cameras with a frame grabbers are 2-dimensional imagers, whereas we are dealing with a single axis (data versus time/distance). Video devices waste bandwidth and resolution on unnecessary data, and data conversion is time consuming. FAX optics enable a non-contacting reader (but I think it would be better to pass the paper web over a stabilizing bar at or near the reading point).
I think we should explore oblique lighting of the paper, and utilize the translucence of the paper (which is common to all paper, oil-soaked or not) to signal the photodetector. The scanner sees black until paper covers the target area. (Think about the image on your office Xerox machine when you leave the cover open.)
---- Paper Transport:
This is the difficult task. I remember the edges of rolls which were horribly damaged by the Ampico B tracking system. {The B piano has tracking "ears" which protrude from the tracker bar. If the pneumatic servo is malfunctioning the music roll is forced into, or over, those ears. }
When a roll-edge had been mangled by a poorly-tracking spoolbox, the resulting feathered edges would not support the tracking ears on the tracker bar, so things got worse with each playing. The small tears folded over, locally thickening the roll diameter. And those which we patched with cellophane tape also doubled the paper thickness wherever it was applied. With those memories in mind, here 's a proposed system:
The music roll feeds out from its own original spool. The spool is not allowed to move from side to side.
The paper web passes under a spring-loaded tension idler. This acts very much like the vacuum column on the older (mainframe) magnetic tape readers. The idler's position is used to adjust the source-spool holdback friction.
The web then passes over the optical reader bar.
The web is pulled through the system by a 3-inch diameter metal drum (capstan drive). The drum is rotated by stepper motor and gear train. If more accuracy is needed, the drum can have an opto-encoder on its shaft (we have the technology). {Shaft encoders are available with 2400 pulse per revolution.}
The web is pressed against the drum by two rubber pressure rollers. These strategically-placed idlers are set in about 1 inch from the roll edges to avoid folds, tears and cellophane tape. The rollers provide three functions: 1) create the normal force between the paper and the drum so the web does not slip. 2) provide a small bias across the web (transverse) to keep the web in full contact with the drum. 3) nudge the paper so that it tracks on the center of the drum. (The idlers can be swiveled slightly under program control).
The web cascades freely off the drum into a box. This should avoid several problems associated with thickened or feathered edges.
I remember seeing nickleodeons at Knotts Berry Farm with an endless web of many songs -- one song for 5 cents. {Gosh, we were _real young_ then, John! You'll be lucky if 50 cents makes it play now!} The paper-roll loop fed into one end of a "stuffing box' where it formed many serpentine "meanders" until it was pulled out the other end to be played. At Hewlett-Packard we used a similar design on our reusable impact- printer ribbons.
Note that fine tracking can be accomplished with algorithms after the data is recorded by the optical reader. And coarse (mechanical) tracking information can be derived in real-time from the optical tracker (reader) bar.
-- John Rhodes
|
(Message sent Fri 29 Dec 1995, 05:56:45 GMT, from time zone GMT-0800.) |
|
|
Mechanical
Music Digest™ Archives
