DIYAPASON-L Digest #583 - Tuesday, June 4, 2002
Re: [Residence Organs]  sampling rates
  by "Tom Dimock" <>
Re: sampling rates
  by "Larry Chace" <>

(back) Subject: Re: [Residence Organs] sampling rates From: "Tom Dimock" <> Date: Tue, 04 Jun 2002 08:29:50 -0400   At 08:01 PM 6/1/2002 -0500, Robert Taylor wrote: >At tempo "90", the roll travels 1.8 inches per second. The perforator >advances the roll 28 steps per inch. This computes to about 50 possible >starting events per second. Most rolls are much slower, with tempo 50 >being quite common.   However, it is important to note that this can start ALL of the notes at once with that resolution, as the pneumatic system is completely parallel. Thus a full 10 finger chord can be played in 1/50 of a second. Most electronic systems such as MIDI are serial, so a 10 finger chord will take ten times the minimum time for a single note..... ---------------------------------------------------------------------------= - Tom Dimock ---- Cornell University ---- "There go my people. I must follow them, for I am their leader." M. = Gandhi    
(back) Subject: Re: sampling rates From: "Larry Chace" <> Date: Tue, 4 Jun 2002 23:25:12 -0400   Christopher Sabatowich raised the questions of sampling rates (for a multiplex system for pipe organs), and several folks have made interesting contributions on that topic. I'd like to join in, even at the risk of it becoming un-interesting!   The original question ("how fast can an organist play") was addressed at least once, in a letter to the editor of "Theatre Organ" magazine (March/April 1984), in which Judd Walton reported on some tests of Wurlitzer chest actions and some of the variables that go into determining the action speed. In that article, he also said that organist Gordon Kibbie was able to achieve 20 keystrokes per second, using one finger of each hand, or 16.5 keystroks per second, using just one finger. (The Wurlitzer chests couldn't quite keep up -- their maximum repetition rate was about 19 per second, or 17.5 when the usual note relay was included.)   The web articles by Mr. Pykett seem to have moved; I found them here: and . (I had some difficulty reading them on my narrow screen, but they were nevertheless quite interesting.) His tests of a slider chest with (large) pull-down magnets referenced a repetition rate of 8 per second.   Mr. Pykett also discusses some of the timing problems that can arise in multiplex systems, including a smearing of notes in a chord, as well as several MIDI "traffic congestion" problems.   I found the description of the Aeolian player rolls interesting, and I = drew a parallel with at least one of the commercial multiplex relay systems (Z-tronics) with which I have a bit of experience. In that system, all of the inputs are captured (sampled!) and latched every 10 milliseconds. The system then clocks through the data, note by note, and processes all of = the coupling and unification, sending the results to the output drivers, which latch and output the results at the end of each scan cycle. This, in effect, "quantizes" the performance in units of 10 milliseconds. (The individual note processing time, if anyone is interested, is about 90 microseconds.) The analogy to the player roll is quite strong, if you imagine the paper perforator moving to the next step and then the = necessary notes are punched out. At about 5 times the speed that an organist can play or a pipe can speak, this seems like a reasonable scanning speed, and real-life experience has shown that none of the professional theatre organists have complained about "relay lag" on such a system. (Note tha the system always runs at the same speed, no matter how many notes or = stops are being used. Since each rank has its own output datastream, it also doesn't matter how many ranks are being played.)   Back in 1988 (yikes!), Tom Dimock and I designed and built a MIDI-based organ relay similar perhaps to what Peter Schmuckal described. This = system had a microprocessor for each rank, and that processor implemented a 16-manual 1-rank unit organ (a "rank-slice" processor, if you like). The MIDI datastream, produced by keyboard and stop scanners, ran to all of the rank processors in parallel (via MIDI splitters). The organ's specification wasn't even defined in the rank drivers; instead, they were told, for example, to play at 8' pitch on channel 1, 4' on channel 2, and 16'+1' on channel 3 (individually, for each rank as required). That was done via Sysex messages, and I can certainly see that such a scheme purchases its flexibility at the cost of MIDI traffic jams if lots of = stops change at once! (We used Concertware, an early Mac-based MIDI composition program, and the stops were encoded as "macros" in the score.)   I also designed and built a multiplex system *without* the input latching feature. That one ran at 700 scans per second, which is to say that it completely scanned and processed the entire organ 700 times per second. The internal clock speed was 8.4Khz, since each clock cycle handled one of the 12 notes; all C notes were processed in parallel, then all C# notes, and so on. This was probably fast enough to "cover" the smearing of notes in a chord, and it saved having to have input latch registers.   Back for a moment to the Z-tronics world, and looking at its MIDI = facility, stops are encoded here as Control Change sequences, thereby consuming 2 or 3 bytes per stop that is changed. While some folks have worried that such a scheme would result in MIDI traffic jams, in reality that doesn't seem = to have been a problem, at least in the theatre organ world, where some CDs have been produced using the MIDI system to re-perform the pieces for the benefit of the microphones. Note that some organ MIDI implementations use Sysex or multiple Control Change sequences for stops, and so they *might* end up sending quite a bit more data per stop change. Sysex, in particular, looks attractive since you can send a "whole mess" of bites, 7 bits of each might be used to encode particular stops. You are gambling, though, since you'll be sending bits for stops that might not have = changed.   Happy, designing, everyone (at least those who are still awake)!   Larry Chace