AW: crap Synth idea-DIY

Thu Feb 29 21:43:09 CET 1996

     I have exactly the same thoughts as Juergen - I always have been 
     thinking about building a poly analog interface without using a CPU. 
     One reason that I have never tried to actually do something about this 
     urge is that it is way too fun to try to figure it out in my head. If 
     I built it finally, I would miss the mental exercise. Also I am 
     waiting to stumble across some solution that would be so easy to 
     implement that it would be a shame not to do it. Oh yeah - I would 
     also need to figure out what I would use for all the synth voices, but 
     that's another issue.

     Yeah I know it's that hobby thing again.... hey JDM I understand where 
     you're coming from - if you actually make music then you're one step 
     ahead of me, and more power to you. I'm totally guilty of messing with 
     the stuff so much that I never get around to making music with it. 
     Most people who first meet me look at my stuff and say "You must make 
     a fortune with this stuff" and get totally blown away when I reply 
     "No, not a cent in my life, in fact it's quite an expensive hobby". 
     Hey people tell me I'm smart but if I were really smart I'd be rich, 
     right? :-) Oh well I plan to make music some day, maybe after the kid 
     arrives (like I'll have the time, yuk yuk).

     Anyway back to the topic at hand - 

     In my experience there is a basic keyboard scanner block that would 
     make the heart of any digital keyboard interface, based on the digital 
     keyboard interface option of the Electronotes ENS-76 synthesizer. This 
     scanner consists of a clock, a 6-bit counter, and the key scanning 
     mux. This block provides a 6-bit counting word plus a synchronized 
     serial data stream of select pulses that represent key depressions. 
     The scanning mux can be either a N-to-1 mux to individual j-wires, or 
     an 8 X 8 diode matrix. The former is usually used with old analog 
     keyboards that don't have the diode boards, the latter can be used on 
     the newer Panasonic units etc. BTW I've never had the dreaded dirty 
     rubber pad syndrome show up with this interface.

     The basic monophonic analog interface consists of a set-reset 
     flip-flop controlling a latch on the 6-bit bus. The flip-flop is set 
     by the select line and reset by the overflow of the counter. The 
     flip-flop, when set, latches the 6-bit word at that instant and then 
     blocks any further select pulses. When the end of the count is 
     reached, the flip-flop is reset and un-blocks the select line.

     This means that after the scan starts, the binary value of the first 
     key down encounterd by the mux will be loaded into the latch, and any 
     other key-downs will be ignored. If the counter is counting up, then 
     the keyboard will exhibit lowest-note priority. If the counter is 
     counting down, then it will be high-note priority. If all keys are let 
     up, the latch holds its last value. The 6 bits out of the latch go into 
     a D/A and provide the keyboard CV. A one-shot on the select line 
     provides the gate.

     This interface is so simple that there is absolutely no reason to do 
     anything other than build one of these if you need a new monophonic CV 
     controller. It works flawlessly and I've built at least a half-dozen 
     of them over the years (my Minimoog has one to replace the old 
     problem-ridden analog S/H).

     It seems to me that in order to extend the design to an N-voice poly 
     design, the following needs to be done:

     For each voice there would be a word latch with a D/A, a word compare 
     circuit between the 6-bit bus and the latch output, and a "busy" 
     flip-flop. The voice word comparator has two functions: first, to reset 
     the "busy" flip-flop if a busy voice sees the lack of a select pulse 
     when its note address comes up, and second, to contribute to a "taken" 
     bus that is common to all voices.

     For the whole system there would be one voice assignment circuit that 
     collects all of the busy signals and monitors the "taken" bus line. 
     This circuit has the job of "pointing" to any voice that is not busy, 
     and checking the "taken" bus whenever a select pulse occurs on the 
     select line (this would prevent unwanted stacking of voices onto the 
     same note). When this circuit assigns a note to a voice, the voice's 
     "busy" flip-flop gets set.

     The way that the voice assignment circuit "points" to an available 
     voice determines the assignment rules. If a priority encoder function 
     is used, then you will have lowest-note or highest-note assign rules. 
     If you use a counter, then you will have rotary assignment rules. Note 
     that if you kill the "taken" bus, then all voices will be stacked on 
     the first note encountered, to create a "Unison" mode. This circuit 
     would also be responsible for keyboard splits, I think (right?).

     Wow I've never written all this stuff down before. I hope it makes 
     sense. There's probably some holes in the logic that need some minor 
     patching. This method has been written up in Electonotes before, both 
     in theory and in schematic form. I think however that the schematic 
     can be improved upon in this more modern age, especially with the 
     advent of gate arrays.

     Anybody got some more thoughts on this?

     - Gene
     gstopp at fibermux.com

______________________________ Reply Separator _________________________________
Subject: AW: crap Synth idea-DIY
Author:  Haible_Juergen#Tel2743 <HJ2743 at denbgm3xm.scnn1.msmgate.m30x.nbg.scn.de>
at ccrelayout
Date:    2/29/96 4:00 PM

>circuitry, doesn't mean that *you* can't go ahead and build one if you

I'd love to hear more about these things - the logic behind different 
key scanning algorithms !

>Detecting which keys are depressed are the easiest part of the >problem. 
>Then you have to decide how to assign notes to a (presumably) limited 
>number of voices.  Unison, rotating, nonrotating assignments - how are 
>you going to do this in hardware?  These are difficult enough to 
>implement in software.

Unfortunately, my schematics of the n-voice scanning logic are barely 
readable, so I haven't figured everything out. So once again, every 
information about the logic behind different assign modes (regardless 
of a CPU/non-CPU implementation!) is highly welcome! I encourage
you to share all you know about this topic!

(And yes, I have considered building a discrete (i.e. MSI CMOS) 
polyphonic keyboard scanner myself, now and then. But I still 
lack the information I need for this!)

JH.