AW: Poly Keyboard Interfaces

[Haible_Juergen#Tel2743]

Here's what I have found out so far (or at least think so) about the
Oberheim n-voice locic:

There are two maine control cycles. The first one I'd call
"keyboard cycle" - it works just like Gene explained it several
times, and like it was suggested in some EN issues.
With every new step (i.e. every new note!) of the keyboard
cycle, a second and much faster cycle is started that scans
thru the voices. I'd call this "voice cycle". So at any moment, we
have some "note adress" (in the keyboard cycle) and some
"voice adress" (from the voice cycle).

Intelligence is distributed. There is some "overhead logic"
that does the scanning, adressing and switching between different
modes, and there is a remarkable amount of logic in each voice.
Each voice remembers by itself what note it was assigned to,
if its gate is on or off, and so on. So each voice has the two
adress busses as input, and some status signals as output.
It's just like you would do it with object oriented programming,
if you would do it in software, nowadays (;->).
Reall, it all comes down to a kind of conversation: The overhead logic
finds that a key is depressed, asks the first voice in line if it is
busy, if by chance it holds the same key adress that is valid
at the moment, and if the voice refuses, it goes on and asks the next
one. The order in which the voices are scanned is fixed; but the
counter for the voice adress can be reset to no 1 for different conditions,
depending on the continue/reset switch. (In reset mode, the voice
counter is reset with every new keyboard cycle, for example - but
not in continuus mode.)
There are some very, very clever things implemented. Every
voice compares its own stored key adress with the momentary one
by itself, and if they are identical (i.e. if the keyboard scanner just
crosses the right note), the S&H of this voice fetches un update
of the CV from the DAC, regardless if the voice is assigned or not!
This way voltage drop by leakage is avoided.

The more I look at it, the more I love it. Though it *is* mind-boggling,
the implementation semms to be far more straight-forward
than it would be in a CPU, where you have to concentrate all intelligence
at one spot. Maybe if you programm it in C++, you get a similar
feeling as with the hardware design - maybe.

>      There are a couple of ways for the voice to check that the scan
>     counter address matches the latched word. One would be to use a 6-bit
>     address comparator in each voice (made out of 2 cascaded 4-bit
>     comparators).

Hey, in the n-voice it's even worse (;->). It uses 6 latches as a
memory, and 6 exor gates plus an and gate for comparing ...
but I would do this with a comparator chip for sure (and even
EN suggested this back then)

>     Now there must be a way to determine which voice gets chosen to pick a 

>     note to play. If each voice is enabled for decision-making one at a
>     time, from a 3-bit count driven by the scan counter's MSB, then every
>     eight scans of the keyboard a voice will get it's chance to either get 

>     a new note, keep the same note, or drop a note. This would result in
>     sequential assignment, in a rotary fashion, like on the OB-8 for
>     example.

This is one possibillity (Continue Mode). But remember that each
unassigned voice still holds its last adress (and even updates its
S&H regularly!). So in the voice loop, you can ask the comparator
output of the voice which is next in line, if it has by chance been
asigned to this note before - and only if you have gone thru the whole
voice cycle and haven't found a fitting one, you can use the
next (in terms of voice number) voice. That's the famous "continue/
reset" mode !!

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

Asuming you had the original schematics - how long would it take to
put it all in several small PLD's, one for the overhead logic, and
one for each voice ???


>  Now, tell us again how you're going to add
> MIDI and an Arpeggiator? ;-}

Who needs MIDI (;->) (no, this was not meant seriously !!)

But I was thinking about an arpeggiator the last days. Not only
would it be easy to implement an arpeggiator in a discrete
keyboard scanner, but I think I have found some idea how
to retrofit an arpeggiator on any existing polysynth that
adresses its voices by Gate and CV signals. Just think
of an analogue sequencer core that has the capability
to skip voices that are not assigned ... but this will be the topic
of another message, maybe next week (:->).
But as far as I have thought about it, you could easily implement
everything: up, down, random - just as in an ordinary sequencer.


JH.