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?
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]
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.
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.
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.
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.
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)
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 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…
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 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.
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.
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.
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.
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.
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?
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