Yes, and it would make sense to use interpolating oscillators (e.g.
oscili, oscil3, tablei, table3) to smooth out the signal in all cases
where the table is not read at original speed.
best
Oeyvind

2009/3/31 Arda Eden <ardaeden@gmail.com>:

> In the Csound Book it was said:
> With a sampling rate of 44100 Hz a 512 sized table's every value has to be
> scanned twice for a frequency of 43 Hz.
> So,
> 44100 / 43 = 1025 samples for one cycle, this is twice the size of the table
> and the table's every value has to be scanned twice.
>
> If the table size was 16384 in the same example, would some table values be
> skiped while table scanning ?
>
>
>
>
> --
> Arda EDEN
> Cumhuriyet University
> Faculty of Fine Arts
> Department of Music Technology
> Sivas/TURKEY
>

Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

If you are referring to p66 (J.C. Nelson) paper, that is a slight but crucial mis-quotation.  He says: "...periodically scanning a 512-point f-table with a 43 Hz oscil opcode at a 44.1 kHz sampling rate reaps approximately two copies of each point...".

So the table is not being scanned twice as such; it is being scanned once per cycle, but with a smaller or larger step along the table. When the demanded position reaches the end of the table it "wraps" round to the beginning again (thus emulating an infinitely long table with an infinite number of cycles). These steps are almost invariably fractions, e.g. one wants a value at position 1.3 followed by a value at position 1.85, then at 2.4 and so on. With oscil (which uses "truncated lookup"), the value obtained is the "nearest lower", e.g. we get table values at position 1 ~twice~, followed by the value at position 2. Clearly, this will result is very audible distortion (the output waveform is a series of hard steps). With oscili, the required value is interpolated from the nearest lower and higher values, reducing the distortion very possibly to an acceptable level (output waveform a much smoother curve, though still with corners), at the cost of a little more computation.

How bad the distortion is is determined primarily by the length of the table. With a long table (such as the 16384 size you suggest), the table is so precise that a truncated lookup is probably more than good enough. In effect, the chances of hitting an exact table position are very much greater. Conversely, cleverer  interpolation methods can get pretty good results from a very small table. And yes, with a large table,  the step size through the table will indeed be much larger for the same frequency. At the extreme (attempting to generate a frequency at the Nyquist limit), just the samples at the start and the middle will be used, over and over. With a sinewave in the table, the result is silence!

Such things are unfortunately far more difficult to explain in words than to illustrate with pictures. It is a good idea both to look at the figures  in that paper, and also to experiment with Csound directly , inspecting the output waveform (as well as listening to it), to see the effect of various combinations of small v large tables, and using oscil v oscili.

Richard Dobson

Arda Eden wrote:

In the Csound Book it was said:
With a sampling rate of 44100 Hz a 512 sized table's every value has to be scanned twice for a frequency of 43 Hz.
So,
44100 / 43 = 1025 samples for one cycle, this is twice the size of the table and the table's every value has to be scanned twice.

If the table size was 16384 in the same example, would some table values be skiped while table scanning ?

Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"