Second Thoughts (verbose AND wordy)
By John Grant
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
|
(Message sent Tue 28 Nov 1995, 19:40:11 GMT, from time zone GMT-0500.) |
|
|