Discussion about the Korg PolySix synthesizer

Hi All,

I've started my project to add aftertouch and velocity functions to my Polysix. After studying the schematics and planning out the circuitry needed to implement these functions, I went ahead and ordered the new keybed.

To implement the velocity portion, I need to know which Polysix voice goes with each key press. So, I'm pretty sure that I need to replace the built-in key assigner with my own key assigner...this will allow me to have total control over which key press goes with which voice. Since many of the MIDI kits for the polysix already do this, I'm thinking that I'm up to the task.

I've started to probe all the signals generated by the Key Assigner microprocessor. I've documented my results on my blog (link below) to show graphs and timing values. I have some questions that you might know...

http://synthhacker.blogspot.com/

My questions for you all are:

1) What does the "MC" line do? I can't find where it links to anywhere.

2) Why are the voice periods so long (676 usec). If they just wanted to latch in the pitch CV into the S-H circuit, couldn't they have used a much shorter period? If they used a shorter period, wouldn't they be able to greatly increase the update rate?

Thanks for your thoughts!

Chip

Hi Chip,

1) Probably it should be "NC" for "no connection". If you look at the
schematics of the "New Production" you can find this.

Maybe it has a meaning in another keyboard of this era. The same
key assigner (8049C-217) was used in the MONO/POLY and the first
generation Poly-61 ("old production").

2) I think things were not much faster those days. The MCU runs off a
6MHz resonator. Due to internal timing this is divided by 15 giving
a core frequency of 400kHz / 2.5usec. The timer is set to 640usec,
which matches your measurements (676usec). All the recurring stuff
(KBD/button scanning, voice CV output, etc.) is done within the
timer interrupt service routine. Due to different code in different
phases:
- slot 0..5 (voices)
- slot 6..7 (calibrating the antilog amplifier)
- slot 8 (kbd/button scanning plus other housekeeping)
slightly different times occur. The timer ISR itself does not take
that much time but the 4051 muxes are only updated at this rate.
There is a lot other code outside the timer running - it is pretty
much stuffed up to the last byte...

Have fun with your project!

Johannes

On 2013-02-08 19:06, chipaudette wrote:
> Hi All,
>
> I've started my project to add aftertouch and velocity functions to my Polysix. After studying the schematics and planning out the circuitry needed to implement these functions, I went ahead and ordered the new keybed.
>
> To implement the velocity portion, I need to know which Polysix voice goes with each key press. So, I'm pretty sure that I need to replace the built-in key assigner with my own key assigner...this will allow me to have total control over which key press goes with which voice. Since many of the MIDI kits for the polysix already do this, I'm thinking that I'm up to the task.
>
> I've started to probe all the signals generated by the Key Assigner microprocessor. I've documented my results on my blog (link below) to show graphs and timing values. I have some questions that you might know...
>
> http://synthhacker.blogspot.com/
>
> My questions for you all are:
>
> 1) What does the "MC" line do? I can't find where it links to anywhere.
>
> 2) Why are the voice periods so long (676 usec). If they just wanted to latch in the pitch CV into the S-H circuit, couldn't they have used a much shorter period? If they used a shorter period, wouldn't they be able to greatly increase the update rate?
>
> Thanks for your thoughts!
>
> Chip
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

Hi Johannes,

Thank you for the reply. If I wanted to run the whole loop faster (by shortening the period during each voice), do you see any reason why it wouldn't work? For example, will the antilog filter setting quickly enough? Will the pitch compensation circuits keep up?

My goal for speeding up would be to increase the immediacy of the "press a key, get a note". At the current loop rate, it could take up 6 ms for that note to come out.

Since I'm now adding a MIDI chain between my keybed and the key assigner, I'm adding even more latency. If I could compensate for the addition of the MIDI latency by pulling latency out somewhere else (by shortening the Polysix's internal loop by a few milliseconds), that would please me.

Thoughts?

Chip

--- In PolySix@yahoogroups.com, Johannes Hausensteiner wrote:
>
> Hi Chip,
>
> 1) Probably it should be "NC" for "no connection". If you look at the
> schematics of the "New Production" you can find this.
>
> Maybe it has a meaning in another keyboard of this era. The same
> key assigner (8049C-217) was used in the MONO/POLY and the first
> generation Poly-61 ("old production").
>
> 2) I think things were not much faster those days. The MCU runs off a
> 6MHz resonator. Due to internal timing this is divided by 15 giving
> a core frequency of 400kHz / 2.5usec. The timer is set to 640usec,
> which matches your measurements (676usec). All the recurring stuff
> (KBD/button scanning, voice CV output, etc.) is done within the
> timer interrupt service routine. Due to different code in different
> phases:
> - slot 0..5 (voices)
> - slot 6..7 (calibrating the antilog amplifier)
> - slot 8 (kbd/button scanning plus other housekeeping)
> slightly different times occur. The timer ISR itself does not take
> that much time but the 4051 muxes are only updated at this rate.
> There is a lot other code outside the timer running - it is pretty
> much stuffed up to the last byte...
>
> Have fun with your project!
>
> Johannes
>
>
> On 2013-02-08 19:06, chipaudette wrote:
> > Hi All,
> >
> > I've started my project to add aftertouch and velocity functions to my Polysix. After studying the schematics and planning out the circuitry needed to implement these functions, I went ahead and ordered the new keybed.
> >
> > To implement the velocity portion, I need to know which Polysix voice goes with each key press. So, I'm pretty sure that I need to replace the built-in key assigner with my own key assigner...this will allow me to have total control over which key press goes with which voice. Since many of the MIDI kits for the polysix already do this, I'm thinking that I'm up to the task.
> >
> > I've started to probe all the signals generated by the Key Assigner microprocessor. I've documented my results on my blog (link below) to show graphs and timing values. I have some questions that you might know...
> >
> > http://synthhacker.blogspot.com/
> >
> > My questions for you all are:
> >
> > 1) What does the "MC" line do? I can't find where it links to anywhere.
> >
> > 2) Why are the voice periods so long (676 usec). If they just wanted to latch in the pitch CV into the S-H circuit, couldn't they have used a much shorter period? If they used a shorter period, wouldn't they be able to greatly increase the update rate?
> >
> > Thanks for your thoughts!
> >
> > Chip
> >
> >
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>

Whatever you do you should ensure that the gate signal that drives any
particular envelope does not arrive before the new pitch CV is presented
to the VCO. The stock Polysix exhibits an annoying trait in that the
first three voices are actually triggered before the pitch CV is updated
to the new note. Hence, with patches that use a fast attack, the first
three voices click slightly if the difference between the previous note
played on that voice is significantly different in pitch to the new note.

The difference in time varies per voice but voice two has the worst
delay with gate being applied 2mS *before* the CV. Voices 4, 5 and 6
have their gates applied a good 2mS *after* the CV is updated so do not
click. 2mS might not sound that much but it's enough to produce an
audible click particularly if the patch is one with low harmonics.

I had thought this was an offset error or bleedthrough problem within
the voice VCA. But the randomness of the clicking led me to look
elsewhere. All the polysix units I have seen exhibit this problem and,
indeed, it's even audible on the many Youtube demos.

A quick way to test this is play is choose a patch with a fast attack
and fast release, no EG sweep to the filter and set the filter to a
dullish sound. Press the top C note six times to load the highest note
into each voice. Then press the lowest note on the keyboard six times.
You should hear three of the voices produce a noticeable click while
three of them don't. Continuing to press the same note again will not
produce the same clicking because now the voices don't have to change
pitch. If you can hear an appreciable click still you need to adjust the
VCF offset but that is a different problem.

If one is designing the key assigner from scratch one should able to
avoid this problem by writing the pitch information before any new gates
are sent out from the latches.

If you have a stock Polysix you can do what I have done and that is
build a triple gang gate delay circuit from a handful of components.
This delays the gate signal for around 3mS and completely silences the
pre-note glitching. I'll pop up a schematic at some point if any one is
interested in doing it themselves.

Tony

http://takla-makan.bandcamp.com/
http://www.oakleysound.com

Dear Tony,
 
YES!  Please count me in as one who would LOVE to implement that 3ms gate delay.
 
And as long as I have your kind attention, if you have any other suggestions for improving the Polysix (or Mono/Poly), I'd love to know about them as well.
 
Thank you so much.
 
Dave Garfield - Colorado, USA

From: Oakley Sound <oakleylist@btinternet.com>
To: PolySix@yahoogroups.com
Sent: Saturday, February 9, 2013 3:38 AM
Subject: Re: [PolySix] Key Assigner Logic and Timing

 
Whatever you do you should ensure that the gate signal that drives any
particular envelope does not arrive before the new pitch CV is presented
to the VCO. The stock Polysix exhibits an annoying trait in that the
first three voices are actually triggered before the pitch CV is updated
to the new note. Hence, with patches that use a fast attack, the first
three voices click slightly if the difference between the previous note
played on that voice is significantly different in pitch to the new note.

The difference in time varies per voice but voice two has the worst
delay with gate being applied 2mS *before* the CV. Voices 4, 5 and 6
have their gates applied a good 2mS *after* the CV is updated so do not
click. 2mS might not sound that much but it's enough to produce an
audible click particularly if the patch is one with low harmonics.

I had thought this was an offset error or bleedthrough problem within
the voice VCA. But the randomness of the clicking led me to look
elsewhere. All the polysix units I have seen exhibit this problem and,
indeed, it's even audible on the many Youtube demos.

A quick way to test this is play is choose a patch with a fast attack
and fast release, no EG sweep to the filter and set the filter to a
dullish sound. Press the top C note six times to load the highest note
into each voice. Then press the lowest note on the keyboard six times.
You should hear three of the voices produce a noticeable click while
three of them don't. Continuing to press the same note again will not
produce the same clicking because now the voices don't have to change
pitch. If you can hear an appreciable click still you need to adjust the
VCF offset but that is a different problem.

If one is designing the key assigner from scratch one should able to
avoid this problem by writing the pitch information before any new gates
are sent out from the latches.

If you have a stock Polysix you can do what I have done and that is
build a triple gang gate delay circuit from a handful of components.
This delays the gate signal for around 3mS and completely silences the
pre-note glitching. I'll pop up a schematic at some point if any one is
interested in doing it themselves.

Tony

http://takla-makan.bandcamp.com/
http://www.oakleysound.com



[Non-text portions of this message have been removed]