[sdiy] How DCOs work

[Tom Wiltshire]

On 10 Oct 2016, at 18:05, Colin f <colin at colinfraser.com> wrote:
> 
> It'd be a lot easier just to generate the waveform in DSP and output through
> an audio DAC.
> If you're going to change the ramp current during the cycle, you'd need
> band-limiting etc. to avoid artefacts there, so it would make more sense
> just to go DSP and be done with it.

Why do you need band-limiting to avoid artefacts? We can have sharp corners with no problems! This is an analog output, remember?
We've got no sample rate for the output waveform to worry about.

But yeah, DSP and DAC is always going to be simpler and more flexible. I'm not suggesting this as a practical/economical course of action particularly, more that I'm interested in exploring if it's actually possible now or not.

> Unless you were trying to convince people your design was more "analogue"
> than it really was.

Isn't that what everyone tries to do?! Anyway, in this case, it'd be more true - an oscillator with an analog output waveform and sub-period-length modulation, allowing bending of the waveform during each cycle.

>> Still, it can't be impossible to update the charging CV and the counter value
>> during a cycle these days. You'd have to work out what the required count
>> should be given the new final count, but modern processors can do that
>> quickly enough. So maybe the problem isn't insoluble.
> 
> A free running hardware timer will have a very precise period, but as soon
> as you start programmatically changing the registers mid-cycle, you're going
> to run into the possibility of making the change at a time that will
> introduce jitter or other instability.
> We'll see...

I don't understand why hanging registers mid-cycle needs to introduce jitter or instability. In my head, the most likely result would be a slight over- or under-compensation of the charging CV, which would give a slight change in output amplitude. Call that character - we would if it was a VCO, after all.
Many of the hardware counter implementations I've seen do indeed limit register changes to the end of the period using double-buffering (example: dsPIC 32-bit counters as used in the Prophet 08), but there's no need for that to be the case. Obviously if you change the registers in the middle of a cycle, it's not enough to just set the new static charging CV and new counter (division) value. You have to compensate for the part-cycle you've already done, and when that's over, then you can move to the "normal" new values at the end of the cycle. If you're doing constant modulation of pitch (something really unusual like..uhh..an LFO to osc pitch, for example!) then this is going to require a lot of recalculation at the modulation update rate. But we have powerful processors these days and we have modulation update rates of many KHz and we can easily recalculate the required values many times during a cycle and produce a piecewise-linear (but analog) approximation to a proper VCO-with-FM curved ramp waveform.

Dunno. It just seems to me like it must be possible now. It definitely wasn't with the old 16-bit counters. They simply wouldn't let you. But we have many more options or we could design our own multi-bit counter DCO hardware in a FPGA if we wanted, and then it's just a software problem.

Tom