[sdiy] CV to Expo in a processor

[Tom Wiltshire]

On 14 Jul 2012, at 00:52, Tim Ressel wrote:

> I figured out if I use a table with 2 entries per semitone the error drops to about 0.055 cents. This sounds good to me. The table will be about 1K bytes, which is a manageable size.
> 
> --TimR
> 

I recently did something similar for a VCDO project ( http://www.muffwiggler.com/forum/viewtopic.php?t=51177 ).

I used the approach Magnus suggested, with a table for one octave, which is then shifted to get values for other octaves. For twelve tones, I had 16 values per semitone, which gives a table of just 192 bytes and much better accuracy. The downside is having to work out the octave and do the shifts, but that isn't too onerous. As often happens, you can trade off program memory against time (bigger table needs no shifts so is faster, smaller table saves memory but needs octave calculation and shifting). You know best for your situation whether time is more valuable than memory.

Incidentally, people differ as to whether the one octave should be the top octave or the bottom octave. Those who argue it should be the top point out that it gives you the most accurate increment for higher notes. Downshifting might push some lower bits off the bottom for lower octaves, but you have the maximum accuracy at the top. Those who argue for storing the bottom octave say that upshifting zeros into the lower bits ensures that every octave *is exactly* an octave with the increment twice the octave below it. That's not strictly true for the downshifting method, though the difference is usually tiny. Secondly, the increments are smaller in the lowest octave, so less bits of storage are required.

I usually use the top octave, but sometimes I've shifted the increments to limit the amount of storage required - e.g. storing only the top 16 bits of what may be a 20-bit increment value to be added to a 24 bit phase variable. This is a compromise between the two in some ways.

HTH,
Tom