Velocity Sensitivity - Addressing and Synchronization

In my previous post, I explored how the Polysix multiplexes the VCF envelopes so that one circuit could affect the envelopes for all six different voices.  My goal is to modify each voice' VCF envelope intensity based on the velocity of the note's keypress.  If I am to modify the multiplexed VCF envelope signal based on each voice's velocity, I need to know which voice is on the multiplexed line at each moment in time so that I can apply the correct velocity adjustment for that voice.  The Polysix keeps track of this information via the addressing and synchronization lines used in the multiplexing circuit.  It is these elements that I'm going to explore in today's post.

My plan is to insert my "Velocity Processor" circuitry right after the envelope signals have all been multiplexed by IC24 onto a single line.  The trick is to know which voice is on the multiplexed line at any given moment in time.  This is handled by the synchronization and addressing lines generated by IC12.

Always Look at the Schematic:  When trying to understand the circuit, I always start with the schematic.  Below is an excerpt from the Polysix schematics that show the elements that process the envelopes for the VCF.  The multiplexer is down on the bottom right (IC24) which time-slices all six voices' envelopes to put them onto a single line.  The dark red line is the multiplexed envelope signal.  At the end of the dark red line is the demultiplexer (IC23), which breaks up the multiplexed signal back into the six individual VCF control signals that are sent off ot the six individual voices.  This multiplexing and demultiplexing system only works if the two elements (the multiplexer and demultiplexer) stay in sync.  Synchronization is effected through the addressing line (in blue) and the inhibit lines (in green). It is these signals that I will be looking at.

Korg Polysix VCF Envelope Processing Circuits.  Red line is multiplexed VCF envelope, which then becomes the general VCF CV.  To keep the multiplexer and demultiplexer in sync, the blue lines are the addressing lines and the green lines are the inhibit lines.

Addressing:  If I am to manipulate the multiplexed signal based on the velocity of each note, I need to know which note (which voice) is on the multiplexing line at every moment in time.  The Polysix maintains this information on the blue address lines (A,B,C) that you can see originating from IC12 and that connect to both the multiplexer (IC24) and the demultiplexer (IC25).  The signal on each address line can be either HIGH (5V) or LOW (0V).  Between these three address lines, there are eight different combinations of HIGH and LOW, which means that there are enough combinations to each of the six voices to be associated with one of the eight possible HIGH/LOW combinations.  A particular combination of HIGH/LOW signals, therefore, is an "address" that defines which voice is currently being serviced.

Which Voice For Which Address?  The address signals themselves are generated by IC12, which is a simple binary counter (datasheet).  As a result, you can think of the (A,B,C) address as a 3-bit binary number, where a HIGH voltage corresponds to one for that bit and a LOW voltage corresponds to zero for that bit.  IC12 keeps incrementing that 3-bit number from 1 to 8, over and over, in a never-ending loop.  [Well, actually, it loops over 0 to 7, not 1 to 8, but you get the idea].  As might be expected, the first address points to the first voice, the second address to the second voice, and so on.  Note that the last two addresses are unused -- they exist simply because the dumb binary-counting IC12 is not smart enough to skip address codes that might be unused.

Responding to the Address Lines:  To correctly modulate the multiplexed envelope signal, my Velocity Processor needs to know which voice is being serviced at each moment in time.  Therefore, my Velocity Processor will have to tap into the addressing lines in order to stay synchronized with the mulitplexing.  To interpret those addressing lines, my Velocity Processor must have some sort of "smarts" in order to generate the correct response based on the current address (ie, voice) being indicated.    In other words, my Velocity Processor will have to include a microcontroller that listens to the address lines.

Velocity Processor Configuration:  My Velocity Processor will have two parts -- a microcontroller to respond to the address lines and a digital potentiometer to actually apply the adjustment to the multiplexed envelope signal.  This combination of microcontroller and digipot will be my "Velocity Processor".  As shown in the figure below, I am going to insert my Velocity Processor right after the multiplexer (IC24).  It is a convenient location to get access to both the multiplexed envelope signal and to all of the addressing lines.

Conceptual Design for Attenuating the VCF Envelope Based on a Note's Velocity

How to Change the Multiplexed Signal:  As discussed in the previous post, my plan is to attenuate each voice's VCF envelope based on the voice's note velocity.  The slower the note's velocity, the more attenuation that I am to apply to that voice's envelope.  The digipot is a perfect component to do this function because attenuation is what potentiometers do, and because it is digitally controllable from a microcontroller.  The challenge is for the microcontroller and digipot to keep up with the rapidly-changing multiplexed envelope signal.

How Fast Must The Microcontroller Respond?   If my Velocity Processor is to manipulate the multiplexed signal, it has to to keep up with the multiplexing rate.  More specifically, the multiplexing circuitry includes a "deadband" window of time where it switches between voices -- it is within this deadband that the Velocity Processor must start and finish its task of applying the correct per-voice envelope manipulation.  In the Polysix circuit, this window for action is defined by the INH ("inhibit") signals sent to the multiplexer and demultiplexer.  When the multiplexer and demultiplexer are inhibited, it is our time to act.

Analyzing the INH Signals:  A close look at the schematic shows that there are two INH signals -- one that goes to the multiplexer (IC24), and a different one that goes to the demultiplexer (IC23).  The screenshot below shows these two INH signals over several multiplexing periods.  Whenever the INH signal is HIGH, that's when the output signal is blocked, and that is our time to act.  As can be seen, the multiplexer is inhibited for a short period of time (6-7 microseconds), while the demultiplexer is inhibited for a longer period of time (20 microseconds).  Somewhere in between is the right requirement for my Velocity Processor.

The "Inhibit" Signals Driving the Multiplexer (IC24) and De-Multiplexer (IC23).  These signals define how quickly my new velocity processor circuit must respsond.  It must respond in at most 20 usec, and preferably within 6-7 usec.

It Can Respond Feast Enough:  Lucikly, in a recent post, I showed that my Teensy 3.1 could update my digipot in under 2 microseconds.  Therefore, my Velocity Processor is definitely fast enough.  That's great.

Pulling it All Together:  My plan is to implement a velocity sensitive VCF envelope by manipulating the multiplexed envelope signal.  I found that a set of address and inhibit lines are used by the Polysix to keep the multiplex process synchronized.  If my Velocity Processor is to also be synchronized, it must include a microcontroller that listens to those address lines and responds based on the specific voice being indicated.  I then looked at the timing of the multplex-demultiplex "deadband" window and found that my microcontroller is indeed fast enough to make its changes within that constrained period of time.  As a result, I'm feeling really confident in my approach.

My "Velocity Processor" will be a new element added to my highly-modified Polysix

Building It:  I've already prototyped the digipot + Teensy, so I know that it works and that it is fast enough.  Now I have to figure out how to physically insert it into the Polysix's signal path.  Then, I have to wire it all up, write some software, and start testing.  I'm wicked excited!

Update:  I've built it.  Check it out here!