[sdiy] How DCOs work

[Richie Burnett]

In a DCO there are two control variables:

1. The period count that gets sent to the digital counter that periodically 
resets the integrator,
2. The integrator CV that sets how quickly the integrator output ramps up 
(or down.)

One of these is inversely proportional to the other, which means you need to 
have a micro to do the reciprocal calculation.  Or at least use two lookup 
tables to get the required values from a MIDI note number, if you're using a 
1980's micro that chugs at divisions.  But one is still the reciprocal of 
the other.  If you play an octave higher, the integrator CV is doubled, and 
the period count (or "terminal count") for the timer gets halved.

However, things aren't as simple as this if you make a pitch change mid-way 
through an audio cycle.  For instance if you go up an octave in pitch 75% of 
the way through a cycle... It's fair enough to double the integrator CV, and 
the integrator output will ramp with twice the gradient, but you can't just 
halve the period match count (or "terminal count") that you load into the 
digital counter, because it's already counted past half way!  So what do you 
do?

The total period needs to be the inverse of the average frequency over the 
full cycle, which means the micro would have to keep track of the progress 
of the integrator ramp at all times, in order to decide exactly when to call 
an end to the present cycle and reset the integrator.  Or at least it would 
have to have prior knowledge of what modulation was going to be applied over 
the duration of each cycle so that it could perform the integration and 
reciprocal calculation to set the period count at the start of the cycle. 
All of this is way more hassle than just synthesising the waveform you want 
with BLIT, BLEP, minBLEP, or whatever, and dealing with modulations as they 
come at you.

-Richie,


-----Original Message----- 
From: Tom Wiltshire
Sent: Monday, October 10, 2016 7:21 PM
To: Colin f
Cc: 'synth-diy DIY'
Subject: Re: [sdiy] How DCOs work


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



_______________________________________________
Synth-diy mailing list
Synth-diy at dropmix.xs4all.nl
http://dropmix.xs4all.nl/mailman/listinfo/synth-diy


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7797 / Virus Database: 4656/13184 - Release Date: 10/10/16