Polysix OTA Overdrive

I still chase my dream -- to get a decent electric piano feeling from my Korg Polysix.  Adding velocity sensitivity got me a long way there, but the sound itself needs to be dirtier, with more compression, more grit.  I tried adding diodes to the signal path to generate some distortion, but it sounded bad.  Too fizzy.  Now, I've modified my Polysix to overdrive one of its OTA circuits.  Having a soft onset that eventually leads to a deep, warm saturation, I think that it worked out pretty well!

OTA Overdrive:  After the failure of my experiment with diodes, I looked for other places in the Polysix circuit where I could generate distortion in other ways.  I noticed that the Polysix has a number of LM13600 chips, which are operational transconductance amplifiers, or OTAs.  Seeing them there reminded that a number of newer synths (e.g. Moog Sub Phatty) say that they offer "OTA Overdrive" as a means of user-controllable distortion.   I don't know how these synths overdrive their OTAs, but I was certainly game to figure out how to overdrive mine.

Pre-OTA Attenuation:  A key requirement of the LM13600 is that the input signals have to be very small.  If the inputs are too strong, the out signal will become distorted.  Since I want distortion, this looks like a good place to make my modifications.  Looking at the Polysix schematic, I see voltage dividers in front of every LM13600 to cut the signal down.  One example is shown below, which shows the elements around IC20.  The signal comes in on the right and exits on the left.  The voltage divider in front of IC20 is formed by R155 (10 kOhm) and R163 (100 ohm).  This cuts the input signal voltage by a factor of 100.  That's 40 dB of pre-OTA attenuation!

Adding a resistor in parallel to R155 reduces the attenuation prior to IC20 enabling the LM13600 OTA to be overdriven

Reducting the Pre-OTA Attenuation:  If I modify the circuit to have less pre-OTA attenuation (ie, to allow the signal to be stronger), I will likely overdrive this OTA.  I can easily reduce the attenuation by adding a resistor in parallel with R155, which will reduce the effect of the voltage divider.  For example, putting a 1 kOhm resistor in parallel to R155 will result in the signal being cut down by only a factor of 10, instead of the factor of 100.  This means that the signal is attenuated by only 20 dB instead of the 40 dB.  In effect, I'm slamming the OTA with a 20 dB stronger signal.  This seems like an easy path to overdriving IC20.  That's what I want.

Connecting the Resistor:  Looking inside the synth, I first looked for IC20 on the KLM-368 PCB.  I found R155 nearby.  To easily try different resistors in parallel to R155, I attached clip leads on either side of R155.  See the pics below.  I also attached my oscilloscope to C75 so that I could visualize the output as well as hear it.

Clipping in on either side of R155.

Adding a resistor, via the clip leads, to be in parallel with R155.

Trying a Range of Resistors:  As you saw in the video at the top of the post, I tried a range of different resistor values.  For gritty electric piano sounds, I liked the 3.3K and 1.1K values the best because the effect was subtle...it simply warmed up the signal and only added some grit when I played hard.  At the other end of the spectrum of resistor values (ie, when I shorted across R155), I unexpectedly enjoyed the unpredictable chaos of the heavily saturated distortion.  It was really fun!

Seeing the Effect:  The video demonstrated what this modification sounds like.  The figure below shows what it *looked* like.  The figure shows the output of IC20 for different resistor values across R155.  As you can see, with no resistor (which is the same as a very large resistor), the output signal is a nice sawtooth, but it is relatively small.  Then, as I add a large resistor (3.3 kOhm) the signal gets quite a bit stronger due to the extra gain.  As I make the resistor smaller (1.1 kOhm), the signal gets stronger.  Continuing to make the resistor stronger (500 ohm and on), the shape of the waveform starts to deviate from a sawtooth -- the top and bottom are becoming rounded.  This is signature of the OTA being overdriven.  It's a softer, more rounded, distortion than seen in my diode mod from my last post.  Finally, when I short across R155, the distortion becomes so heavy that the signal is a square wave.  Under certain contditions, as seen in the video, that can be cool in its own way.

Output of IC20 recorded for different resistors placed in parallel with R155. Note that decreasing resistance results in increased gain, which eventually leads to overdriving IC20, causing the sawtooth to become distorted.  Note that, for these images, I played two notes at the same pitch and waited for the two voices to naturally phase into alignment.

More Than Just Gain:  Clearly, the main effect of changing the resistor is to boost the level of the signal going into the OTA, which then overloads the OTA and causes the output signal to be distorted,  But, gain and distortion is not the resistor's only effect.  Looking back at the Polysix schematic, I see that R156 and C80 are also in parallel with R155.  This resistor and capacitor act to boost the treble frequencies.  By adding my own resistor around R155, I will also be reducing the effect of this treble boost.  So, maybe the "warmth" that I felt was actually a result of changing the frequency response, and not necessarily due to overdriving the OTA.  To confirm this theory, let's analyze the circuit for different resistor values and see what happens.

Circuit Simulation:  To simulate this part of the circuit, I used 5Spice Analysis, which is a SPICE-based circuit simulation program with a nice graphical interface for Windows.  Like most graphical versions of SPICE, you start by drawing the schematic of the circuit that you want to simulate.  The screenshot below shows the schematic that I made to represent the elements leading into the IC20 OTA.  For this simulation, the input signal is generated by "SigIn" on the right.  "TPv1" on the left represents the output signal, which would normally go to IC20.  In between the elements of the Polysix's voltage divider, the R-C treble boost, and my added overdrive-inducing resistor.  Now I can run the simulation and see the expected frequency response.

Using "5Spice Analysis" to model the frequency response of the pre-OTA voltage divider network.

Expected Response, Unmodified Polysix:  The graph below shows the modeled response of the circuit.  On the bottom (in blue) is the the circuit response with no added resistor around R155.  As expected, the signal is 40 dB down, which is what we expect based on the 10 kOhm / 100 Ohm voltage divider.  Also note, however, that the treble frequencies are boosted due to the effect of R156 and C80.  At 5 kHz, the signal is boosted by about 5 dB.  While not a huge boost, this would definitely sharpen the sound.

Expected Response of the pre-OTA voltage divider network.  The different lines show the effect of different values for the resistor that I placed in parallel to R155.

Expected Response, Modified Polysix:  When the parallel resistor is added, I get the black traces shown in the figure above.  The primary effect is that the signal level goes up.  The 1.1 kOhm case, for example, shows that the signal is at -20 dB instead of at -40 dB.  This is the 20 dB gain that I mentioned earlier.  A secondary effect of adding the parallel resistor, however, is that the boost to treble frequencies becomes much less.  Perhaps this is the increased "warmth" that I perceived.  Hmm.  I think that this requires a little more exploration.  Maybe there are additional modifications that I can make to shape the frequency response to make the OTA overdrive sound even better!

Next Step:  I liked the sound and feel of this OTA overdrive much more than the diode distortion.  I think that, if I can figure out how to make this OTA overdrive controllable from the Polysix's front panel, I'll enjoy having this modification.  So, that's my next step: figure out how to have a controllable amount of overdrive for IC20.  Stay tuned!

Follow-Up:  How to make this mod controllable without clipping in new resistors?  In this follow-up post, I start designing this mod to use an Arduino and a digipot.  

Polysix Drive - Diode Distortion

I recently modified my Korg Polysix to have velocity sensitivity.  Now that it is responsive to the dynamics in my playing, my Polysix makes much more convincing electric piano and clav sounds.  The problem, however, is that those classic EP and clav riffs from the classic records from the 70s were often played through a guitar amp, which means that we're used to hearing them with the warm compression and light overdrive of tube guitar amps.  By comparison, the EP and clav sounds from my Polysix are too clean and too dynamic.  In this post, I start the process of finding the right "drive" mod to bring some of that compression and overdrive to my Polysix.  I'm going to start with some simple diode-based distortion.

A simple distortion generator: an LED, or a diode, or both!

Classic Diode Distortion:  Being a guitarist, I know that it is very difficult to simulate the sound and feel of a tube amp.  So, instead of heading down that challenging path, I'll look to the well-known overdrive and distortion tricks used in guitar pedals.  A very common technique used for guitar distortion is to use a pair of opposite-facing diodes in parallel.  This is how distortion pedals such as the Ibanez Tubescreamer and the ProCo Rat achieve their classic sounds.  Maybe it'll work well in my Polysix, too!

Putting Diodes in the Polysix:  Below is an excerpt from the Polysix schematic.  It shows the last VCA and the last amplifier prior to the audio signal being sent to the output jack.  In the blue region, it shows that the make-up gain after the VCA is simply an op-amp configured as an inverting amplifier.  Since the Tubescreamer also uses an inverting op-amp, I chose to follow the Tubescreamer's distortion approach of adding a pair of diodes into the op-amp's feedback loop.  I just need to clip in a pair of diodes?  That's it?  Easy.

Schematic of the last VCA and last amplifier in the Polysix.  I've chosen this location to add my "Diode Distortion Mod", which is simply a pair of clipping diodes in the feedback loop of the last amplifier.

In Parallel with R196:  In the modified schematic above, you can see that the pair of diodes are added in parallel with the other elements in the feedback loop.  To enable a quick test, I simply attached the diodes using clip leads on either end of R196.  The other ends of the clip leads (not shown) are clipped onto the diodes.  The only tricky part is to make sure that the diodes face in opposite direction.  I used my handheld multi-meter to determine which direction was "forward" for each diode, and then I swapped one of them around backwards.

Using small clip leads to attach my diodes (not shown) in parallel with R196.

Looking at the Output:  With the diodes hooked up, I used my oscilloscope to look at how the diodes affected the audio signal from the op-amp.  The pictures below show some screenshots from the oscilloscope.  To make a strong signal, I set the Polysix to play two voices at the same pitch.  Then, I set the Polysix's "Attenuator" dial to maximum volume (ie, "+10dB").  Now the signal is strong enough to really show the effect of the diodes.

Screenshots of my oscilloscope when recording the output of the op-amp.
I tried different combinations of diodes in the op-amp's feedback loop.

Clipping of the Waveform:  As can be seen in the top-left screenshot ("No Mods"), I've got a normal-looking sawtooth waveform.  When I add just the LED, I see that the top of each sawtooth has been clipped to a maximum voltage of 1.6V (ie, the LED's forward voltage drop).  When I swap out the LED for a backwards silicon diode, it's the bottom of the sawtooth that has been limited (clipped at 0.6V, which is the diode's forward voltage drop).  Finally, when I have both the red LED with the backwards silicon diode in circuit, both the top and bottom of the waveform is clipped.  So, the diodes act to distort the signal by limiting its dynamic range.  Pretty sensible.

Demo:  OK, these oscilloscope views are interesting and all...but how does it SOUND?!?  That's a good question.  Below is a short demo that I pulled together.  It shows the baseline Polysix with no distortion mod, the Polysix with LED distortion only, and the Polysix with the LED + diode.

Not What I Wanted:  By the end, my conclusion was that I didn't like the results.  My first reaction was that the distortion was too fizzy/fuzzy.  But, beyond just the fizzy sound, the diode distortion didn't have the right feel when playing it.  I had been hoping that the distortion would provide a sense of dynamic compression, like a guitar amp feels.  But, instead of feeling that kind of compression, I actually felt like the signal was being hard limited...which, of course, is exactly what diodes do.  I should not have been surprised at this disappointment.

Moving Forward:  Yes, I could have spent more time refining this diode distortion modification to try to address my criticisms.  For example, to reduce the fizzy/fuzzy sound, the Tubescreamer includes additional capacitors to reduce the high frequency sizzle.  I could have tried that.  But, in truth, this experiment reminded me of why I don't use diode-based distortion pedals with my guitar...I never end up liking the sound.  So, for my Polysix, I'm going to leave behind the diodes and try some other approaches.  Let the synth hacking continue!

Update: I've removed the diode distortion and, instead, modded the Polysix to overdrive one of its OTAs.  I like that sound much better!

Korg Polysix with Velocity Sensitivity

In truth, a Korg Polysix has rather limited features.  But, because it is an analog synth, it is open to modifications.  And so I've dived in head first.  I've already added aftertouch and portamento, controllable detuning, sustain pedal, and Moog-style legato triggering.  My most recent modifications began a few weeks ago, when I decided that I wanted my Polysix be velocity sensitive.  After a bunch of explorations and trials, I've finally pulled together all of the pieces.  That's today's story.  But first, here's a demo!  (Note, the bass distorts my laptop speakers, too.  Go for headphones.)

The Pieces:  The addition of velocity sensitivity to my Polysix builds upon many of the previous mods that I've done.  The core enabler of this mod was the fact that I had already replaced the stock Polysix keybed (which does not transmit velocity information) with a new Fatar keybed that is both velocity and aftertouch sensitive.  It's sweet.  As shown below, in my modified Polysix, the data from the new keybed is fed to an Arduino Mega, which assigns each new note to one of the six voices in the Polysix.  To modulate that voice in response to the note's velocity, I also feed the velocity information to my new "Velocity Processor", which then does the actual velocity-based modulation.

My highly-modified Polysix.  The newly-added "Velocity Processor" is highlighted in yellow.

Velocity-Based Modulation:  So what kind of velocity sensitivity did I implement?  I chose to modulate the intensity of the filter envelope.  As you heard in the demo, the intensity of the filter opening and closing gives a strong sense of articulation and dynamics.  In a stock Polysix, the intensity is the same for all voices (as set by the "EG Int" knob).  My goal was to dynamically change the envelope intensity based on how hard I hit the key.  As shown below, I chose to attenuate the filter envelope based on the note velocity.  At maximum velocity (MIDI 127), the envelope would be at its full intensity (as set by the "EG Int" knob, as before).  At lower velocity values, the intensity would be progressively smaller.  As a result, notes that I press hard should have a strong intensity and notes that I press lightly will soft intensity.

Scaling the VCF Envelope Based on the Note Velocity

Hardware Approach: After studying the Polysix schematic, and after figuring out how the VCF envelope multiplexing and how its associated addressing and synchronization works, I settled on the plan that I would manipulate the VCF envelopes in the multiplexed portion of its circuit.  Being multiplexed, I only have one signal line to manipulate, instead of six individual signals (one for each voice).  Sure, the signal on that one multiplexed line is changing very quickly (all six envelopes are time-sliced onto a single line), but I've already proved that a Teensy 3.1 plus a digital potentiometer can keep up just fine.  So, my hardware plan was settled -- I'd insert my Velcoity Processor right after the VCF Multiplexer (IC24) on the Polysix's KLM-366 PCB.

Building It:  In the Polysix, I was happy to see that IC24 is socketed, which means that you can pull out the chip and insert all sorts of fun new circuitry via the now-empty socket.  And so that's exactly what I did.  I took a piece of protoboard, soldered on the Teensy 3.1, the digipot, and IC24 itself.  More details on the build are here.  I then inserted the assembled protoboard into the empty IC24 socket.  As you can see below, it's not too pretty.  It's not complicated, it's just messy.  Someone with more experience would certainly do this more cleanly.

My "Velocity Processor" Installed in my Polysix.  Lots of wires.  Someone smarter than me could surely do it more cleanly.

Arduino and Teensy Software:  Hardware alone does not make this modification work.  I also needed to write some software.  For example, I needed to program the Teensy (my "Velocity Processor") to keep up with the multiplexing circuitry and to drive the digipot to properly attenuate the envelope signal.  I also needed to expand the programming on the Arduino Mega (my replacement for the Polysix's "Key Assigner CPU") to properly route the velocity data from the keybed to the Velocity Processor.  While this routing of the velocity data sounds straight-forward, the need to support the Arpeggitor modes made it more challenging (note that the velocity-sensitive arpeggiator leads to fun effects, like being able to make some notes feel accented...definitely a cool effect).  In the end, the software writing went pretty smoothly.  My latest code for both the Arduino and the Teensy are on my GitHub here.

First Trials and Tweaking:  Once I got it all wired up and programmed, I started to play it.  The velocity sensitivity really makes it more expressive.  Velocity sensitivity also quickly exposes bad keyboard technique!  I need practice!  But, even with my poor technique, I felt that the velocity response wasn't quite right.  So, I spent some time remapping the velocity values to create a custom response curve.  Furthermore, to get a good electric piano/clav sound, I felt that I needed a little grit and compression in the sound.  So, I added a drive circuit, which will be the subject of another post.

Playing It:  Once I got it adjusted to my liking, I've had a lot of fun adjusting all of my traditional Polysix patches to best include the velocity capability.  I started with the piano and clav sounds (as seen at the top of this post) because they our ears most expect velocity dynamics with these kinds of sound.  Interestingly, though, even organ sounds (which are traditionally not velocity sensitive) can benefit from velocity dynamics.  Hitting the keys a little harder, gives the organ more "pop!".  You can here it this little carnie organ vamp:

Moving Forward:  My next step is to continue to refine the interaction of the velocity with the other synth's features.  For example, I'd like a way to turn off the velocity sensitivity so that the EG Int will work as it does in a stock Polysix.  To do this, I simply need to wire up a switch, or re-purpose one of the switches already on the back of the synth.  Also, I need to further tweak (and then write-up!) my drive circuit.  It is critical for the velocity-sensitive piano/clav sounds, but I've found fun uses with other sounds, too.  Finally, I also want to improve how the velocity interacts with the Unison and Chord Mem modes of the synth.  It doesn't feel quite right yet.  So there's lot's to do!  But first, I've got some playing to do.  :)

Update: I tried adding diode-based distortion to add some grit to my EP/clav sounds...but I didn't like it very mcuh.

Update: I tried overdriving one of the Polysix's OTAs to add some grit and I liked it a lot!

Building my Polysix Velocity Processor

Today it starts.  We've talked enough about my dreamy dreams of velocity sensitivity for my Korg Polysix.  It's time to get down to business.  It's time to apply what I've learned about its multiplexing and about its synchronization.  It's time to build something.  Let's smell the solder!

First Generation "Velocity Processor" Installed in my Polysix

Where to Insert My Circuity:  Before I solder anything, I need to figure out where I am going to insert my "Velocity Processor" into the Polysix circuit.  As discussed in my previous post, I want to put it after the multiplexer (IC24) but before any of the other envelope and VCF processing.  The figure below shows, notionally, how I'll use several of the signals associated with IC24.  What is the easiest way to get physically access to these signals?

Use the IC24's Socket!  When I opened up my Polysix and too a look at IC24 to see what connection points might be available, I was immediately struck by the fact that IC24 is socketed!  By pulling IC24 out of its socket, I now have instant, easy, and easily-reversible access to most of the signals that I need!

Here is the socket for IC24.  The perfect place for inserting my Velocity Processor.

Which Holes for Which Signals:  Looking at the Polysix schematic, I see that I can get almost all of my signals from this one socket: +5V power and ground, the three addressing lines (A,B,C), the inhibit line (INH) as well as a place to inject my velocity-modified, multiplexed envelope signal.

The signals that I will use for my Velocity Processor -- all available from the socket for IC24.

How to Connect to the Socket:  While the socket is a very convenient way to get signals without modifying the Polysix PCB, I still had to find the right hardware that would mate into the socket.  After trying a few options, I found that the legs on the Arduino-style "stackable" headers fit very nicely into the socket.  My plan, therefore, would be to mount the stackable headers to a protoboard, solder them in place, and have their legs reach down and mate to the socket.  Since these stackable headers have really long legs, they'll let the protoboard (with all of my other components) stand above the other components on the Polysix PCB.  It'll be great!

Arduino-style "stackable" headers fit into the Polysix IC sockets.

Why Not Use Regular 0.1" Pins?  Arduino fans may immediately wonder why I'm using these stackable headers when it appears that 0.1" male pins (also popular with Arduino projects) would be cheaper and less bulky.  In fact, I did try to use these pins.  But they don't fit in the socket.  After looking at the detailed geometry of these pins versus the legs on the stackable header (shown below), I found that the pins are indeed thicker than the legs on the stackable header (0.64 mm vs 0.40 mm).  That's the reason that the pins don't fit.  That's the reason I'm using these stackable headers.  [Note: If you really want to use pins, perhaps the 0.45 mm pins of the Samtech TS-108-T-A will work.]

The common 0.1" male pins are too thick to fit. But pins the stackable female headers are thin enough to work.

General Configuration:  After looking at the space inside the Polysix, and after looking at the size of the protoboard that I had on-hand, I decided to configure the basic elements of my Velocity Processor as shown below.  The stackable headers are shown on the bottom right.  The digipot is on the left.  The Teensy 3.1 microcontroller is on the top.  Now we just need to figure out the wiring.

Here is my high-level plan: a Teensy 3.1 plus a digipot plus a pair of stackable headers.

Connections to the Teensy:  Below is a picture of the Teensy with the pins labeled.  It shows which pins I'm going to use for the various connections.  Remember that the Teensy is only a 3.3V device whereas the Polysix's digital signals (the A,B,C addressing lines and the inhibit line) and the Serial connection from my Arduino key Assigner are all 5V signals.  Luckily the pins on the Teensy 3.1 are 5V tolerant, so I can attach those lines to the Teensy without damaging it.  Another side-effect of the Teensy being 3.3V is that its SPI connections to the digipot will also be 3.3V signals.  Therefore, the digipot will have to be provided with a 3.3V reference, which will come from the wire that I show attached to the Teensy's 3.3V supply.

Connections to my Teensy 3.1

Connections to the Digipot:  Below is a figure showing connections that I'm making to the pins of my digipot.  As mentioned above, the SPI logic signals are at 3.3V, so I connect the "VL" logic reference (pin 12) as well as to the other logic pins.  The multiplexed envelope signal (my "input" to the digipot), however, can span 0V to 5V.  Therefore I set VDD to +5V and VSS to ground.

Connections for the Digipot to handle the 0V-5V Multiplexed Envelope Signal

The Wiring Plan:  The figure below shows my wiring plan for the Teensy, digipot, and IC24 socket.  Of course, I still need IC24 itself to function within the circuit.  Therefore, I had the brilliant idea to insert another IC socket into the stackable headers!  Isn't that brilliant!?!  I happened to have a spare IC socket whose legs seemed just long enough to fit in the big holes of the stackable header.  So, I can build my velocity processor as shown below, insert the board into the vacated socket for IC24, and then stick IC24 into my board.  That's the plan, at least.

The First Wiring Diagram for my Velocity Processor.  Note IC24 sitting on top of the stackable headers in the bottom right.

The Wiring Reality:  Below, you can see the protoboard after I wired and soldered everything in place.  You can even see how I inserted IC24 in place.  On the underside of the board, you can see the pins sticking out that will fit into the Polysix's socket for IC24.

The first version of my Velocity Processor

Testing It:  At the top of this blog post is a picture of this first version of my Velocity Processor mounted within my Polysix.  While it did do something, I quickly discovered that my plan of sticking IC24 on top of the stackable headers wasn't working.  The pins of my add-on IC socket did not mate securely nor reliably to the stackable header.  Sad.

The New Wiring Plan:  The solution to this problem was to move IC24 off the stackable headers and down onto the protoboard.  I had resisted doing this because it mean adding 16 wires (one for each leg of IC24) between the stackable headers and the new spot for IC24.  It was going to be an annoying task, but I needed to do it.  <Sigh>

The Second Wiring Diagram for my Velocity Processor.  Note that IC24 has been moved and 16 additional wires have been added to connect it to the circuit.

The Completed Wiring:  Below is a picture of my Velocity Processor after moving IC24.  You can see it on the top right.  You can also see the rainbow of wires that I had to add to connect IC24 back to the stackable headers.  All those extra wires sure made it ugly.  But, the task is done.

By moving IC24 to its own spot on the top right, the extra wiring really made it ugly.

Plugging It In:  Below is a picture of my revised Velocity Processor mounted within my Polysix.  All of the signals that it needs come up through the IC24 socket into which it has been mounted.  The only exception is the serial communication signal that comes from my Arduino Key Assigner.  That simplicity is pretty nice.

My revised "Velocity Processor" installed in my Polysix. 

Next Steps:   I need to finish the software on the Velocity Processor and I need to write the companion software for the Arduino Key Assigner so that it conveys the velocity data from the keybed to the Teensy.  Then I can test it and make sweet, sweet music.  Stay tuned!

Update:  It lives!  Check out the demo here.

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!

Velocity Sensitivity - Understanding the Multiplexing

As discussed in my previous post, I have a dream of adding velocity sensitivity to my Korg Polysix.  My replacement keybed already generates the velocity data, I just have to figure out how to use the data.  My plan is to have the velocity affect the intensity of the envelope applied to the filter (VCF).  The harder I hit the key, the more of the envelope signal is applied to the VCF.  Should be easy, right?  Well, it turns out that the Polysix uses a lot of multiplexing to handle its polyphony, including its VCF control.  This post is about understanding the multiplexing so that I can adjust the envelopes based on note velocity.  Let's go!

The Simplified View:  To figure out how the VCF envelope is applied to the VCF, I looked at the Polysix schematic.  Being a six-voice synth, one might expect that six individual circuits are used to apply six individual envelopes to six individual filters.  But this is not the case.  To save money, the designers used multiplexing so that a single circuit could be used to service all six voices.  When I look at the schematic, I do see that there are six circuits used to create the six envelopes.  But then, at IC24, I see that these six envelope signals are multiplexed into a single time-sliced signal.  The single multiplexed signal is then passed through a circuit that combines the envelopes with the VCF cutoff, the VCF key tracking, and the VCF LFO modulation.  At the end of the circuit, IC23 demultiplexes the time-sliced signal back into six individual control voltages that go off to the filter circuit for each voice.

The Detailed View:  With that overview, I have excerpted the real schematic below and highlighted the signal path specific to the VCF envelope.  As can be seen, the six envelope signals enter at the bottom left.  At IC24, they are multiplexed, at which point the time-sliced envelope signal follows the thin red line through the modulation circuit.  Finally, it ends up back at IC23, were it is demultiplexed back into six control signals for each voice's VCF.  Somewhere in this signal path,  we will make a modification to allow us to modify the VCF envelope based on the note velocity.  To decide where and how to make that modification, I need to better understand how the multiplexing works.

Korg Polysix VCF Envelope Processing Circuit, with Annotations

What Does the Multiplexed Signal Look Like?  I hooked up my oscilloscope to the multiplexed signal line shown in the schematic above.  I hit two keys on the keybed and saw what the multiplexed envelope signal looks like.  In the screenshot below, you can clearly see that two envelopes were triggered.  You can also see that the two envelope signals have been sliced up and interleaved.  This is what multiplexing does, it slices up multiple signals and interleaves them onto a single line.  Looks pretty straight-forward, eh?  Let's zoom in, just to be sure of the details.

Voltage at R58.  Two envelopes are multiplexed onto one line.  The second envelope was triggered 6 msec after the first.

Zoomed View:  The picture below is a zoomed in view of the multiplexed envelopes.  As can be seen, there is a repeating signal that contains two two non-zero voltages.  The first voltage value corresponds to the envelope for Voice #1 at a that specific moment in time.  The second voltage corresponds to the envelope for Voice #4 at its moment in time.  In the time between those two voltages, the voltage is zero because none of the other voices are active.  If the other voices were active (as shown later), there would be signal here.  Since the notes are off, there is no envelope, so there is no signal in that time slot.  Easy.  [As a side note, we see that the mutiplexed signal appears to have a cycle of ~310 microseconds, which means that each voice's envelope gets updated at a rate of 3.2 kHz.  I'm actually a bit surprised that it is that slow.  I expected faster.]

Zoomed in view.  Two envelopes on one line.  The second envelope is the Polysix's voice #4 (out of 6).  Note that the pattern repeats every 310 ms, which means that the envelope for each voice is only updated at 3.2 kHz.

All Six Voices Active:  To further illustrate how the envelopes are multiplexed, the screenshot below shows the multiplexed signal when all six voices are active.  In this case, all of the envelopes were triggered at the same time (Unison mode!) so all of the envelopes are showing approximately the same (non-zero) value.  The critical detail here is that we see six period's worth of non-zero signal.  Those are the six voices.  Curiously, we also see two periods of zero signal.  These extra two slots ("slot 7-8") are, in my opinion, purely an artifact of how the addressing is done to keep the multiplexing and demultiplexing in sync with each other.

View at R58 with all six voices active.  Note the empty space, which implies a voice #7 and #8 (which don't exist).

The Vision for Velocity Sensitivity:  Now that I see how the multiplexing works, I can also see how I can modify the envelope signal based on the velocity of each key press.  I think that I can work directly with the multiplexed signal.  In my illustration below, the left portion of the figure is the multiplexed envelope signal as created by the Polysix.  Each color represents the time slice that is associated with each of the six voices.  My idea is that I can introduce a new circuit -- my "Velocity Processor" -- which can attenuate the envelope signal for each voice, depending upon the velocity of the note assigned to that voice.  As long as my Velocity Processor responds fast enough to keep up with the multiplexing, it can affect each voice independently of the others.

Hardware Configuration:  I like this plan -- to simply modify the multiplexed envelope signal based on each notes velocity.  Looking back at the Polysix's hardware, it looks like the right place to introduce my Velocity Processor would be right after the IC24 Multiplexer, as illustrated in the simplified view below.  This location gives me access to the multiplexed envelope signal, but it is before the signal gets too complicated by the rest of the VCF CV processing, where the cutoff, key tracking, and LFO modulations are applied.

Next Step:  The key to this approach is that I want to independently modify each voice in the multiplexed signal stream.  This means that I need to know which voice is on the multiplexed line at each moment in time.  As a result, I really need to dig in and learn about the synchronization and addressing scheme used by the multiplexer.  Figuring this out will be the topic of my next post.

Update:  I figured out the addressing and timing of the multiplexing.  Check it out here.

Update:  I finished the mod.  Behold: Velocity Sensitive Polysix!

Velocity Sensitive Polysix - The Dream

As regular readers know, I've done many modifications to my Korg Polysix.  Probably the biggest change was when I swapped out the original keybed for a new one (Fatar, FTW!).  My goal with the new keybed was to add aftertouch to my Polysix, but a side-benefit was that the new keybed was also velocity sensitive.  Unfortunately, the velocity capability has gone unused because the Polysix had no obvious way of including its effect.  Today, though, that begins to change.  Today, I plan out how to add velocity sensitivity to the Polysix.  Behold, the VelocitySix!

Dreaming a Dream of a Dreamy, Velocity-Sensitive, Korg Polysix.  (Fake Graphic)

What Do I Want Velocity to Do?  This is the first question that I asked myself.  What do I want the velocity to affect?  In other synthesizers, the two most traditional answers would be to affect the intensity of the filter (VCF) envelope or of the amplitude (VCA) envelope.  Personally, I've always been a bigger fan of velocity-sensitive VCF, so that's what I decided to target (first, at least).  My idea, therefore, is to add circuitry that will scale the envelope based on the velocity of the keypress.

Scaling the VCF Envelope Based on the Note Velocity

Adding More Hardware:  As can be seen in the figure above, what I need is some hardware that can scale (attenuate) the existing envelope signals.  As discussed in my recent posts, my plan is to do this velocity-dependent attenuation using a digital potentiometer that is driven by a Teensy microcontroller.  I'll simply send the MIDI velocity value for each voice to the Teensy and it will drive the digital potentiometer to adjust the overall amplitude of that voice's VCF envelope.  I'll call the Teensy + digipot my "Velocity Processor".

Piecing it All Together:  The figure below shows all of the components that I've added to my Polysix.  For the addition of velocity sensitivity, I've added my new "Velocity Processor" and highlighted it in yellow.  It is important to realize that I can add this velocity sensitivity only because of my previous modifications.  Without having replaced the built-in keybed with my own keybed and keyscanner, I wouldn't have the velocity values in the first place.  And, without having replaced the built-in "Key Assigner" CPU with my Arduino Mega, I wouldn't know which velocity value to associate with which voice.  It is only through my prior work that this new modification is possible.  [Note: the DAC on the right side of the figure is irrelevant to the velocity sensitivity, but it is crucial for my portamento and detuning modifications.]

My Highly-Modified Polysix.

Building and Testing:  My upcoming posts will discuss the details of how I will manipulate the envelop signals, how I built and tested the new electronics, and how it all sounded when I was done.  This is gonna be fun!

Update:  I've worked out how the Polysix multiplexes its VCF envelopes.

Update:  I've worked out how the Polysix multiplexing handles addressing and synchronization.

Update:  I've wired up the Velocity Processor.

Update:  It works.  It's sweet.  Here are the demos!