Poly Keyboard Interfaces

[Bob.Schrum at harpercollins.com]

     Gene wrote...
       >I think that the idea of a CPU-less polyphonic CV interface is 
       >fascinating,...[edited]...My brain hurts.
     
     
     Of course an MPU would be the easy way, but definitely not as fun! :) 
     I can see, as this hardware solution grows in feature, the closer it 
     resembles a microprocessor.  So, I will assume a CPU-less design, by 
     definition, contains neither a standard processor chip or ROM.
     
     Voice assignment nonwithstanding, it seems that triggering would be a 
     nightmare.  I hate to blaspheme by suggesting anything that resembled 
     M**I, but the essential things both assignment and triggering logic 
     needs to know are:
     
       1.) What keys were just pressed down? 
       2.) What keys were just released?
     
     In order to do this, you would have to know what keys were down the last 
     time the keyboard was scanned.  The difference between then and now would 
     represent the above two events.  My idea is a keyboard scanner with static 
     RAM as its centerpiece. Only the first 61 addresses would be used for a 5 
     octave keyboard.  The RAM would be 5 bits wide, with Bit 0 containing the 
     last known state of the keyboard (0=up 1=down), Bit 1 representing the 
     current state, and Bits 2 through 5 representing the voice currently 
     playing that note.  Scanning would be done in four "passes" using a clock 
     rate 4 times higher than would be needed to produce the same effective 
     rate. 
     
     The first pass would scan the keyboard, writing the state of each key in 
     Bit 1 of the key's address in RAM
     
     The second pass finds any key addresses where Bit 0 (previous state) is on 
     and Bit 1 (current state) is off.  Any addresses found in that condition 
     would cause the voice addressed by the contents of 2 thru 5 to drop its 
     trigger level.
     
     The third pass would look for key addresses where Bit 0 is off and Bit 1 is 
     on.  These are new key presses and would trigger the voice allocation 
     logic, with the selected voice's address written into Bits 2 thru 5.  There 
     would need to be some logic disabling the remainder of pass 3 in the event 
     that no voices could be allocated.  
     
     The fourth pass copies Bit 1 (current state) into Bit 0 (previous state).
     
     This is a very software-like solution, but seems possible to implement in 
     hardware.  Of course, there will need to be a power-on initialization of 
     all the RAM locations to Zero. 
     
     Some random scraps of thought about voice allocation... Unconditional 
     rotation would be musically useful, especially if the number of voices in 
     rotation were variable.  With differing patches per voice, this would 
     produce a hocketing effect (a'la Carlos).  ...use the same voice if the 
     same note is struck in succession.  ...choose an unallocated voice that has 
     the lowest amplitude envelope.  I hear the CMOS-head gears turning!  
     Now my brain hurts! :-)
     
     -- Bob