[sdiy] CV to Expo in a processor

[Magnus Danielson]

On 07/14/2012 11:31 AM, Tom Wiltshire wrote:
>
> 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.

It really depends on your frequency generation principle, but if we 
assume phase-accumulator principles, then the top octave will have 
highest accuracy and you shift out bits with 0s as you move down the 
octaves. The end result will be that the frequency error is that of the 
LSB frequency resolution.

16 notes per seminote is around what I should try out as well. It should 
give enough non-linearity such that interpolation seems smooth enough. 
The number of bytes per phase accumulator constant is what will dominate 
the behaviour. A single byte doesn't seem good enough. Possibly one 
could compress it by removing the linear trend, which is simple enough 
to implement and it's really just a interpolation of corrections then.

> 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.

There are many ways to compromise it, but once a bunch of ideas is on 
the table, then one can try them out and find out which one best fits 
the need for the particular application. Another thing is what is the 
good-enough factor for the particular design. If you do christmas-cards 
you might not bother as much as if you do semi-pro or pro-level of 
equipment.

Cheers,
Magnus