Poly Keyboard Interfaces

[J.D. McEachin]

On 30 Apr 96 at 11:00, Gene wrote:

>      I think that the idea of a CPU-less polyphonic CV interface is 
>      fascinating, especially now that I will have many voice cards to play
>      with. I have been thinking about it....

I think it's lunacy, but since you're so dead set on it, I'll try to lend my 
experience w/ the software-based polyphonic interface to your cause.  

On 30 Apr 96 at 18:03, Bob.Schrum at harpercollins.com wrote:

>      Of course an MPU would be the easy way, but definitely not as fun! :) 

This depends on how you get your jollys.  %-)  Actually, a software solution
isn't as easy as you think, if you go for multiple assignment schemes w/
sophisticated handling of held notes.  The case that's been driving me nuts is
when you have multiple note ons of the same note# (possible w/ MIDI), and
there are more notes held than there are voices to assign.  I could go on for 
hours about how to deal w/ this...

>      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.

This is a fuzzy area.  I've recently been studying the vector generator circuit
in the Atari Asteroids video game.  It's a very complex state machine that has
its "program counter" loaded by the CPU, which puts it in its initial state of
reading and executing one of 16 commands out of ROM.  All the commands are
geared towards drawing vectors on a CRT by feeding 12bit position data to the X
and Y DACs.  It can even do scaling and intensity.  When it hits a "HALT"
command it stops executing.

Now, when does a state machine stop being a state machine and become a CPU?
Even primitive state machines tend to have memory, in the form of flip flops,
so the presence of memory isn't a good indicator.  Really, a CPU is just a
honkin' huge state machine.  I'd say a CPU is a chip you buy to execute a
predefined set of instructions, but I don't think this is the place to go into
it.  I think Gene is just trying to avoid using chips that say "Intel" or
"Motorola".  %-)

But I digress.  Back to the state machine, and defining its states...
 
>      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?

Here's how I would do it: 8 bytes of memory for the prior state of the
keyboard  (1 bit for each key).  A counter would cycle thru the bits, XORing
the keyboard buffer w/ the memory.  A 1 is a change to be acted on, advancing
to the next state.  If the key is a 1, it would go into Voice On state, if 0,
it would go to Voice Off state.  

Another counter would cycle thru the voices. Each voice would have a 7 bit
memory indicating what note it's playing, with the high bit indicating whether
the voice is in use or not.  In the Voice On state, the first voice w/ the high
bit clear would be used.  The 6 bits of the key strobe counter would be copied
into the voice memory, into the DAC, and the high bit set.  The high bit would
also serve as a gate output.

>      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! :-)

Now, here's a little subtlety:  To use an ordered assignment, reset the
voice counter to 0 every time.  To use a rotating assignment, stop the
counter & leave it where it is, so that the next search will begin at the
next voice. 

The Voice Off state would cycle thru the voices, comparing the keyboard strobe 
counter w/ the low 6 bits.  A match would result in the high bit being cleared 
and the low 6 bits being set.

The weakness in the scheme is that when all the voices are assigned, any keys
which are being held and are unassigned would be ignored when the voices do
become available, because the hardware would have already seen the off to on
transition, found all the voices used, and ignored it.  Designing a state that
figures out which keys are held and unassigned would be frightening.

Now, just for fun, let's add some Solo states.  Low or high note priority would 
be easiest to implement - just strobe the keyboard from low to high or high to 
low, and assign the first key On you encounter to the first voice, ignoring the 
state of the high bit.  Last note assign is easy, until someone tries a trill.  
Then you have the same nightmare situation that you have w/ poly when there are 
N voices, N+1 keys held.  I don't know how to handle this w/o some sort of 
memory to remember the order of key depression.

>      As for the CV outputs, either each latch could have its own 6-bit DAC, or
>      the voice latch outputs could be bussed together and enabled sequentially
>      to a single DAC, whose output goes into a 1-of-n analox mux to holding
>      caps with buffers.

Just re-multiplex them, dude.  DACs are cheap, but not as cheap as muxes, 
demuxes, & sample & holds.

>      Now that I've gone this far I realize that I have no idea on how to
>      implement keyboard split. 


How do you want to implement the split?  Fixed split point?  Fixed number of
voices on each side of the split?

>      My brain hurts.

Welcome to the frightening world of voice assignment! 
 
Assignable split could be implemented by having a Split button, which
would store the count of the next key-on in a comparator, one that has a
less than/greater than output (they DO make those, don't they?  I don't
have my TTL Data Book...).  This would be the most significant bit of the
voice selection count - 1/2 the voices would be used for one patch, 1/2
for another. 

>      So - will this work? Any thoughts? Maybe someday I'll draw this up on our
>      Altera station. I could do all of this on one chip. After hours, of
>      course.

I could do it all on one chip too - an 8751!

Good luck Gene, if you decide to accept the challenge.  You'll earn my respect 
for being even crazier than me.  Now, tell us again how you're going to add 
MIDI and an Arpeggiator? ;-}

JDM