Juno 106 style analog synth possible?

[msi]

I've been doing a lot of research recently on analog synths with the purpose of actually building one. While looking at the technology of the Juno 106 I noticed that the juno sends timing information from the CPU to an intel chip that outputs a square wave which is then modified to other waveforms using a waveshaper. Likewise the CV is generated by using square waves and smoothed to produce the voltage required. How plausible is a setup like this using a midibox core and external timing chips to produce the DCO signal?

Some information on the Juno's DCO's can be found at Roland Juno Series DCOs

[nILS]

It's actually even easier when using a microcontroller. You can use a simple phase accumulator and directly output the square wave (or PWM square) at the correct frequency w/o having to worry about external dividers etc.

Rough pseudo-code sketch (replace sampling rate of 44100 Hz at will, same goes for the precision (16bit in the example)):

16_bit_unsigned_integer: phase

integer: frequency = 65536/44100*frequencyInHz


functionThatGetsCalled44100timesPerSecond {

  phase = phase + frequency


  if phase > 32767

    then output_pin = 0

    else output_pin = 1 

}

[/code]

[TK.]

Nils: the pure software approach isn't optimal, as it will introduce some jitter, especially when this routine is interrupted.

The better approach would be the usage of an integrated timer + capture/compare unit which outputs the waveform directly on an output pin.

Than faster it is running, and than higher the resolution, than better (see also the comments on the frequency accuracy of Juno DCOs at Tom Wiltshire's website)

E.g. on a PIC you could use MIOS_TIMER_Init to initialize the frequency (assigned to TIMER3), and use the CCP1 unit to output 0 or 1 on pin #17 based on the compare value.

More details about these units can be found in the PIC18F452 datasheet (and in the user manuals)

The signal will be available at pin 17 (J7:SO of the core module). There will be a 0->1 transition when the compare value is reached, and it will go back to 0 when the timer period is reached.

This means in other words: you are not only able to output a pulse waveform, but also to generate PWM with a few register writes.

I remember that somebody implemented a very simple synthesizer based on this approach, the code is buried somewhere in this forum.

Best Regards, Thorsten.

[lucem]

I second that, TK.

That's part of what the timer's and capture/compare units are made for (and in many cases today, they can directly drive a pin for PWM on their own).

[jojjelito]

Ahh, here we go with that project again... the elusive DCO synth. I've been wanting to make something using the CEM3396 wave-shapers but other projects are keeping me busy. The CEMs use a square wave at the right frequency in order to come up with a whole bunch of wave-shapes generated by analogue means. The idea here is the same. The easiest way to get a square wave of the right frequency would be to use the PWM output with a pulse-width of 50%.

The issue here is that you don't exactly have a plethora of these outputs using the extant microcontrollers of Core8 or Core32 if you want polyphony. Suppose you want 6 voice polyphony ala Cheetah MS6, Oberheim Matrix6/6r/1000. This calls for 12PWMs at different frequencies for a 2-oscillator per voice synth.

The way it was solved in the olden days was to program a PIT (Programmable Interval Timer) that is an old standard 8bit CPU peripheral. See 8253 or the enhanced 82C54. This way you get 3 square-waves/IC. Unfortunately those chips are using parallel I/O (no modern SPI alternatives exist) so you need to stick a 74HC595 chip somewhere close to the timer and program it in the same fashion as the SID.

Also, if you go for something polyphonic it might be a good idea to feed the timer chips 1 or 2MHz base frequencies from different clock sources such as high-speed RC oscillators to make the sound less stiff than using a single crystal-derived source.

But before you get there it might be a good idea to start with just one PWM from the Core in order to check and debug your DCO...

You might want to thoroughly check Tom Wilthire's pages on DCOs if you want to see how Roland made their more digital DCOs and what makes them tick :sorcerer: There's plenty of good educational reading there that needs to sink in.

Edited April 14, 2011 by olga42

[msi]

Nils: the pure software approach isn't optimal, as it will introduce some jitter, especially when this routine is interrupted.

The better approach would be the usage of an integrated timer + capture/compare unit which outputs the waveform directly on an output pin.

Than faster it is running, and than higher the resolution, than better (see also the comments on the frequency accuracy of Juno DCOs at Tom Wiltshire's website)

E.g. on a PIC you could use MIOS_TIMER_Init to initialize the frequency (assigned to TIMER3), and use the CCP1 unit to output 0 or 1 on pin #17 based on the compare value.

More details about these units can be found in the PIC18F452 datasheet (and in the user manuals)

The signal will be available at pin 17 (J7:SO of the core module) whenever the timer reaches the compare value.

This means in other words: you are not only able to output a pulse waveform, but also to generate PWM with a few register writes.

I remember that somebody implemented a very simple synthesizer based on this approach, the code is buried somewhere in this forum.

Best Regards, Thorsten.

Yes, I am aware of the tuning issues with the Juno as the notes get higher. My main thought on using external timing IC's was to free up processor cycles in the PIC and allow for the polyphony to be changed by the builder. At a minimum I'd hope to achieve something similar in ability like a juno, meaning six voices and an LFO. Also it'd be nice if it could support the abilities of a SID with three voices with independent wave forms and VCA's with a shared VFC. Not saying I would want it to sound like a clone, but have similar abilities.

So by using external timing IC's all the PIC would have to do is send the square wave cycle to the Timing IC until the pitch had to change. I was thinking that managing the timing on a minimum of six square waves plus the CV's for the VCA and VCF might be asking a bit much of the PIC, but honestly I'm not sure.

I've been mulling this over for about a month now and have been looking into how older synths managed to accomplish this. I've begun to look into what options were available but until a few days ago I didn't find much. Also I've been looking into how the Juno used 4051 IC's to generate the CV but that part is still a mystery to me. I understand how those chips are selecting which ports to have open, and understand the idea that the square wave gets smoothed to create the voltage control but the exact process is above my current understanding.

[jojjelito]

Yes, I am aware of the tuning issues with the Juno as the notes get higher. My main thought on using external timing IC's was to free up processor cycles in the PIC and allow for the polyphony to be changed by the builder. At a minimum I'd hope to achieve something similar in ability like a juno, meaning six voices and an LFO. Also it'd be nice if it could support the abilities of a SID with three voices with independent wave forms and VCA's with a shared VFC. Not saying I would want it to sound like a clone, but have similar abilities.

So by using external timing IC's all the PIC would have to do is send the square wave cycle to the Timing IC until the pitch had to change. I was thinking that managing the timing on a minimum of six square waves plus the CV's for the VCA and VCF might be asking a bit much of the PIC, but honestly I'm not sure.

I've been mulling this over for about a month now and have been looking into how older synths managed to accomplish this. I've begun to look into what options were available but until a few days ago I didn't find much. Also I've been looking into how the Juno used 4051 IC's to generate the CV but that part is still a mystery to me. I understand how those chips are selecting which ports to have open, and understand the idea that the square wave gets smoothed to create the voltage control but the exact process is above my current understanding.

Ahh, you're beginning to grok this :). The base frequency sent to the timer chip doesn't change! You only change the divider value for the timer resulting in different output frequencies. So, new note->fetch the new pre-computed value in a table. Send it to the right timer control register and you're done, unless you do some fancy detune or pitch-bend stuff.

The 4051 IC use is just a ghetto (read low-cost) method of multiplexing the DAC output by making a primitive sample-and-hold. I.e, output CV1 from the DAC. Set address one on the 4051 to charge the capacitor connected to output 1 of the 4051. Do the same for all the channels so that the poor DAC has to output new voltages each cycle. If you do this quick enough you won't have too much droop (voltage loss) on each CV between update periods. Normally you use FET-style inputs connected to this SH output in order not to drain the capacitors. See the CEM 3396 PDF or the schematics of say, an Alpha Juno and you'll see it.

Edit: This method applied more in the past where DACs were expensive single-channel beasts and lots of CVs were needed to control VCAs, VCFs etc in polyphonic systems. See how the Prophet VS made by Sequential Circuits did it for instance. Its' DAC multiplexing system is a sight to behold! It uses in excess of 68 channels of CV generated by one single DAC.

Edited April 13, 2011 by olga42

[msi]

Ahh, you're beginning to grok this :). The base frequency sent to the timer chip doesn't change! You only change the divider value for the timer resulting in different output frequencies. So, new note->fetch the new pre-computed value in a table. Send it to the right timer control register and you're done, unless you do some fancy detune or pitch-bend stuff.

The 4051 IC use is just a ghetto (read low-cost) method of multiplexing the DAC output by making a primitive sample-and-hold. I.e, output CV1 from the DAC. Set address one on the 4051 to charge the capacitor connected to output 1 of the 4051. Do the same for all the channels so that the poor DAC has to output new voltages each cycle. If you do this quick enough you won't have too much droop (voltage loss) on each CV between update periods. Normally you use FET-style inputs connected to this SH output in order not to drain the capacitors. See the CEM 3396 PDF or the schematics of say, an Alpha Juno and you'll see it.

Edit: This method applied more in the past where DACs were expensive single-channel beasts and lots of CVs were needed to control VCAs, VCFs etc in polyphonic systems. See how the Prophet VS made by Sequential Circuits did it for instance. Its' DAC multiplexing system is a sight to behold! It uses in excess of 68 channels of CV generated by one single DAC.

Right, the base 8Mhz of the base Oscillator is divided by the range switch, then goes to the 82C54. I was thinking it might be more efficient to maintain that method because once the timers are set the main CPU doesn't have to worry about the timing until a new pitch is needed. I had considered the possibility of using master clocks to avoid the oscillators being in exact sync. Also I had considered using a higher frequency base frequency to avoid pitch errors at higher notes.

My main concern is my lack of knowledge concerning the digital side of things. I can program C++ badly and understand analog theories poorly. But it seems like a worthwhile project that hasn't been done yet and a good place to firm up on these subjects.

The design goals I'd like to achieve for the digital domain are,

-Multiple polyphony (I'd like ten.....ten fingers=ten notes)

-Stable tuning

-Midi control

-Low part count (already moving away from this unfortunately)

-Low overhead on the CPU (MBHP Core)

-Avoid feature creep

Worth attempting

-Save patches

-MBHP Sid type control surface

Unknown hurdles

-Exact needs hardware wise

-Best methods

Edited April 14, 2011 by msi

[jojjelito]

Right, the base 8Mhz of the base Oscillator is divided by the range switch, then goes to the 82C54. I was thinking it might be more efficient to maintain that method because once the timers are set the main CPU doesn't have to worry about the timing until a new pitch is needed. I had considered the possibility of using master clocks to avoid the oscillators being in exact sync. Also I had considered using a higher frequency base frequency to avoid pitch errors at higher notes.

My main concern is my lack of knowledge concerning the digital side of things. I can program C++ badly and understand analog theories poorly. But it seems like a worthwhile project that hasn't been done yet and a good place to firm up on these subjects.

The design goals I'd like to achieve for the digital domain are,

-Multiple polyphony (I'd like ten.....ten fingers=ten notes)

-Stable tuning

-Midi control

-Low part count (already moving away from this unfortunately)

-Low overhead on the CPU (MBHP Core)

-Avoid feature creep

Worth attempting

-Save patches

Unknown hurdles

-Exact needs hardware wise

-Best methods

There you go! It starts to sound like a project! At any rate I think it might be worthwhile to design a 82C54 sub-module with one Dout (74HC595) per timer IC. The thing is that I don't know beforehand how many voices can be driven off one core if things like envelopes, LFOs and mod-matrices are run there as well. The soft-synth things can be lifted from the current SID-synth engine and/or MB-FM. Then add one AOUT_NG per core for 8 channels of CV. This will drive the basis of a synth regardless of DCO method chosen.

CV multiplexing will eat CPU resources like crazy (think small, but uninterruptible parts of code - jitter is somewhat a concern). If tons of CVs are needed then one can look at MB_NET and several cores a la MB6582, or design an SPI-slave core that contains soft registers for all CVs, takes care of LFOs etc which is updated via CAN or SPI by the main core only when needed. This slave updates all CVs, multiplexers etc. Core offloading achieved. However, one better start small before aiming for the stars.

Low part count poly. LOL :laugh: Take a peek at the schematics of analog polys when you have the chance :sweat: The only one that is low-part count (per voice) is the Korg PS-family. There you had full voicing and a complex control scheme (in case of the PS3200) instead.

Edits due to somewhat iffy spelling etc at this late hour...

Edited April 14, 2011 by olga42

[msi]

There you go! It starts to sound like a project! At any rate I think it might be worthwhile to design a 82C54 sub-module with one Dout (74HC595) per timer IC. The thing is that I don't know beforehand how many voices can be driven off one core if things like envelopes, LFOs and mod-matrices are run there as well. The soft-synth things can be lifted from the current SID-synth engine and/or MB-FM. Then add one AOUT_NG per core for 8 channels of CV. This will drive the basis of a synth regardless of DCO method chosen.

CV multiplexing will eat CPU resources like crazy (think small, but uninterruptible parts of code - jitter is somewhat a concern). If tons of CVs are needed then one can look at MB_NET and several cores a la MB6582, or design an SPI-slave core that contains soft registers for all CVs, takes care of LFOs etc which is updated via CAN or SPI by the main core only when needed. This slave updates all CVs, multiplexers etc. Core offloading achieved. However, one better start small before aiming for the stars.

Low part count poly. LOL :laugh: Take a peek at the schematics of analog polys when you have the chance :sweat: The only one that is low-part count (per voice) is the Korg PS-family. There you had full voicing and a complex control scheme (in case of the PS3200) instead.

Edits due to somewhat iffy spelling etc at this late hour...

Yea, Starting simple is always a good idea when starting a project. I guess the minimum would be to get a tuned raw square wave out of a pic. Care should be taken so that it can be expanded and will not load the PIC down. I do think the idea of using a DOUT to control something like a 82C54 is a decent design choice. The issue I see with that is there is still the problem of higher pitched notes being inaccurate due to timing issues and the only supplier I've found is Jameco and they cost 5 dollars a pop.

[jojjelito]

Yea, Starting simple is always a good idea when starting a project. I guess the minimum would be to get a tuned raw square wave out of a pic. Care should be taken so that it can be expanded and will not load the PIC down. I do think the idea of using a DOUT to control something like a 82C54 is a decent design choice. The issue I see with that is there is still the problem of higher pitched notes being inaccurate due to timing issues and the only supplier I've found is Jameco and they cost 5 dollars a pop.

If you think that's much then take a look at the AMD/CTS9513 5-output timer at Jameco... You can get the C54 chip at Farnell or Digi-key but you'll end up paying the same. Or spend 3EUR at Reichelt in the EU.

[Antix]

Why dont use a simply CD4059 instead of computer peripherals like 82c54?

As it is necessarily anyway the use of an external chip for note generation

may be interesing the 4059 whith PIC a generated clock ( like for MBSID )and

stick many chips to increase the polyphony.

The 4059 is cheaper than 82c54 and comes in SMD to save space on board.

Logically it is only an idea but years ago I used it for my firsts synth experiment and

as it is thrue it generate only square wave we can obtain other WF with some

external parts.

regards

Antix

[jojjelito]

Why dont use a simply CD4059 instead of computer peripherals like 82c54?

As it is necessarily anyway the use of an external chip for note generation

may be interesing the 4059 whith PIC a generated clock ( like for MBSID )and

stick many chips to increase the polyphony.

The 4059 is cheaper than 82c54 and comes in SMD to save space on board.

Logically it is only an idea but years ago I used it for my firsts synth experiment and

as it is thrue it generate only square wave we can obtain other WF with some

external parts.

regards

Antix

Interesting idea, it's certainly another option.

However, you can only get one output divided by N (from 3 to 15999) so it's not full 16-bit division accuracy we're getting. But, it's cheaper. And the package contains the same friendly number of pins.

You can get the 82c54 as SOP from Toshiba. If that's hard it can be had from Intel, NEC and Samsung as well, possibly in several package variants.

There's lots of ICs out there to explore for sure, the old 4541 contains a full 16-bit divide by N counter, but that IC only works up to 100kHz. These days it seems that the development seems to trend towards low-cost - thus people will have to stick with what's internal in the MCU. The issue then is that we can abandon polyphony unless we have heaps of PWM outputs or use lots of MCUs which may well be cheaper at some point.

Take care,

J

[Antix]

The issue then is that we can abandon polyphony unless we have heaps of PWM outputs or use lots of MCUs which may well be cheaper at some point.

Ok you are right

but with only one clock generator ( so not PWM output from MCU ) clocking many dividers and one MCU to drive them?

Regards

[jojjelito]

The CPU can be one of several possibilities for the base clock generator. At least it's programmable so it's easy to redefine in software should the need arise. But this way we get three different pitches (in phase wrt to each other when the timer starts) per PWM.

There are those who argue that the Matrix 1000 sounds less good than the Matrix 6r due to the latter not using a crystal-derived (or MCU-based) clock but rather gets its base frequency from a high-speed RC oscillator. If we want polyphony with a more lush sound of oscillators beating against each other we want to use several base clocks, up to one per timer chip so that they are out of phase with respect to each other. This comes with the added bonus that it ought to shut up some sceptics who are analog purists. Maybe. I've even heard people complaining that the Juno 60 sounds somewhat thin (wait, what were the smoking?) due to a shared root clock scheme.

More schemes to look at than the usual 3396 and Roland suspects would be nice. Maybe something from Crumar or Elka? The Bit 99/Bit 01 are underrated faves from the past for instance.

Cheers!

[nILS]

Nils: the pure software approach isn't optimal, as it will introduce some jitter, especially when this routine is interrupted.

I am well aware of that ;) It's pretty much the simplest and most insta-reward approach though, which is why I mentioned it.

[Imp]

Just one thought: If you use several clocks at 1 or 2 Mhz, wouldn't the resulting Phase-offset between them be very small(max one period)?

Or did i get that wrong and it's about some frequency inaccuracies?

[jojjelito]

Just one thought: If you use several clocks at 1 or 2 Mhz, wouldn't the resulting Phase-offset between them be very small(max one period)?

Or did i get that wrong and it's about some frequency inaccuracies?

As you observed the phase offset can be anywhere between infinitesimally close to 0 and 100 percent regardless of frequency :sorcerer: BUT you won't exactly have much time to register the phase offset at those high frequencies. The thing is that the offset remains the same (percentage-wise) when we divide down the base frequencies unless we have different signal propagation delays in different dividers. Thus it too becomes audible.

The issue is that we may *want* some frequency drift and that comes from using several timing sources, each with their own drift that's independent of the others. Think of it as a subtle chorus effect. Once you try it you won't look back. Or something :ike: Think "super-saw" and you'll get it at its most extreme.

[Imp]

I understood, that this is a wanted effect. I just don't understand why it's audible in the end.

At 1MHz the period is 1 microsecond, so we have a delay of 0.5 mS or less between clocks. If we divide those clocks by N, isn't the delay still 0.5 mS?

[jojjelito]

Waves hand: These are not the droids you're looking for...

The delay is the same, but therein lies not the magic! The thing is that the phase offset is there and will be continously variable over time as we can safely assume that the different clocks will behave differently. Hence, the sound will be less static. We will have all sorts of errors (although small) in both frequency and phase. A little dose of chaos is good.

It's not going to be more fun than the fully static condition (where everything is in phase to begin with) if we have just one phase offset that is unchanging.

Clear as mud? Otherwise I hafta resort to scope shots or samples :thumbsup:

Cheers!

[msi]

Here's the thing that is not making sense as far as using multiple master clocks, if the timing source is the same between the multiple clocks, say a crystal on a pic, and the pic is outputting multiple master clocks can't we just vary the output of the pic how ever we decide. If we decide to have an 8Mhz frequency on one master clock and 7.98 on a second, we can do that can we not? Maybe not to that drastic a degree but it's still an option? Or am I still running behind the curve?

[jojjelito]

Here's the thing that is not making sense as far as using multiple master clocks, if the timing source is the same between the multiple clocks, say a crystal on a pic, and the pic is outputting multiple master clocks can't we just vary the output of the pic how ever we decide. If we decide to have an 8Mhz frequency on one master clock and 7.98 on a second, we can do that can we not? Maybe not to that drastic a degree but it's still an option? Or am I still running behind the curve?

Sounds nice in theory. But sadly it's not easy to use a the divide by n counter (n=1,2,3...) and prescaler in order to get a still very large frequency that is close to what we had from the beginning.

Assume f_Xtal=40MHz. Then divide by 5 and we get 8MHz. Obvious. How do we divide with something that gives us 7.98MHz? The possible frequency steps become too big for small values of n. Obviously we end up with much more subtle differences if we divide the base clock frequency with 15879 in one case and 15878 in another. We can get base clock differences of 100kHz if we want 2MHz (40/20 40/21 40/19 etc).

If we want to be hardcore with this we can either use a crystal with some very high frequency which is not very practical, or resort to inherently unstable (compared to crystals) LRC-networks where temperature differences and component tolerances will do the work of introducing some jiggly bits. Or resort to more exotic spread-spectum techniques or frequency shifting or use PLLs. However, any responsible parent or teacher ought to teach that it's generally a bad idea to open a can with a stick of dynamite.

However, before anyone gets to clocking there's still the main task of generating square waves with the desired frequencies plus controlling waveshapers, filters and other bits. Be that with timers, PWMs which we sadly lack, or other means such as the garden variety V/oct VCO, direct synthesis etc.

The base clock design is a (nice to have) diversion later down the line.

Toodles!

Edited April 15, 2011 by olga42

[msi]

If the design uses the Aout_NG we could use a sample and hold circuit for each CV needed. That is basically what the older synths did as well. It would require once CV per voice for the VCA envelope, and two per voice for Cutoff frequency and resonance at a minimum I believe. Again, I'm not sure what the latency would running multiple voices off one CV would be as the voices started increasing.

[jojjelito]

If the design uses the Aout_NG we could use a sample and hold circuit for each CV needed. That is basically what the older synths did as well. It would require once CV per voice for the VCA envelope, and two per voice for Cutoff frequency and resonance at a minimum I believe. Again, I'm not sure what the latency would running multiple voices off one CV would be as the voices started increasing.

Ahh, this way we can get 8x8 CVs for sure. There was a S/H module in olden days of MBHP, the SHX8 but it came with latency. Also it used EOL chips from JRC (NJU7304). Those can be substituted with the usual 4051 and 8 external caps we see in other schematics. Still, as you said: it would take some research in order to performance test for latency as well as droop rate which would then yield the size of caps needed etc.

Next is the voice architecture: Your example above is the bare minimum. It's then possible to add things like a mixer with a few VCAs for different waveforms going into the VCF, PWM for the pulse-wave, CV for FM, cross-mod, output panner using a cross-fader, digital control for sub-oscillator octave selection, digital control for applying oscillator sync, external signals or noise as needed. The issue there is to lab what *you* deem useful assuming it's possible to use for instance 8CVs plus 8 bits of control signals per VCO. The good thing is that there's lots of classic and modern analog synths to look at for inspiration.

Edited April 28, 2011 by olga42

[msi]

Ahh, this way we can get 8x8 CVs for sure. There was a S/H module in olden days of MBHP, the SHX8 but it came with latency. Also it used EOL chips from JRC (NJU7304). Those can be substituted with the usual 4051 and 8 external caps we see in other schematics. Still, as you said: it would take some research in order to performance test for latency as well as droop rate which would then yield the size of caps needed etc.

Next is the voice architecture: Your example abobe is the bare minimum. It's then possible to add things like a mixer with a few VCAs for different waveforms going into the VCF, PWM for the pulse-wave, CV for FM, cross-mod, output panner using a cross-fader, digital control for sub-oscillator octave selection, digital control for applying oscillator sync, external signals or noise as needed. The issue there is to lab what *you* deem useful assuming it's possible to use for instance 8CVs plus 8 bits of control signals per VCO. The good thing is that there's lots of classic and modern analog synths to look at for inspiration.

I think going with the juno's basic design is a safe bet. Adding multiple timers to avoid the timing sync of the juno is an improvement that can be made. Also we should look at consolidating as much logic and timing functions into the PIC as possible. The juno is nearly 30 years old and computer technology has advanced since then. We should be able to do more with the pic than Roland could do with the CPU's it had available at the time. Also we should figure out a way to avoid pitch issues as notes get higher.