Poly Keyboard Interfaces

gstopp at fibermux.com gstopp at fibermux.com
Wed May 1 19:00:08 CEST 1996


     Good idea, Bob. This is an example of "centralized logic", versus the 
     "distributed logic" in my previous description. This is a totally 
     different approach and now you got me thinking.
     
     Many times I get the feeling that some solution to a given problem 
     will work because it makes sense, but that there is a much simpler 
     solution out there that I just don't see (yet). For example in 
     software a bubble sort routine makes sense at first but gets totally 
     blown away by a more clever sort algorithm. Who knows? There may be 
     some state-machine solution to this poly keyboard voice assignment 
     problem that only requires a couple chips!
     
     It's fun to think about, though.
     
     - Gene
     gstopp at fibermux.com


______________________________ Reply Separator _________________________________
Subject: Re: Poly Keyboard Interfaces
Author:  Bob.Schrum at harpercollins.com at ccrelayout
Date:    5/1/96 6:30 AM


     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
     




More information about the Synth-diy mailing list