[PD] ipoke~ ?

[katja]

On Sat, Jun 9, 2012 at 5:18 PM, Matt Barber <brbrofsvl at gmail.com> wrote:

> Csound has a variable write delay opcode that would be worth looking
> at - the csound website has just been flagged by google for having
> malicious content so I can't link to the manual page, but the opcode
> is called "vdelayxw."

Unfortunately I can not understand the c code of vdelayxw. There's
comments for the obvious things but not for the magic numbers and
other tricks. But it may be a method for sinc-interpolated resampling.

James Fenn pointed to Julius O. Smith's pages on resampling and
sinc-interpolation:

https://ccrma.stanford.edu/~jos/resample/

After reading the pages and experimenting with the proposed sinc
tables, I noticed that proper sinc-interpolation would be fairly
cpu-intensive. It is much less effective than [tabread4~], because 4
point sinc-interpolation would not even work for the simplest
resampling job. Compare with a FIR filter, which should be up to a few
dozen points per octave resampling.

In addition to that, an object like [ipoke~] or [tabwrite4~] implies a
continuously variable resampling factor, which depends on the
distances between consecutive float indexes received at the index
inlet. Should the interpolation order grow according to distance? If
so, what would be the limit?

On the other hand, think of [tabread4~]: it's interpolation scheme is
fixed, no matter what resampling factor. With extreme resampling,
aliases may be noticeable. But what the hell, it doesn't sound like
the original music anyway, when sped up or down to extremes. That is
the difference with an offline resampling job, when the original sound
must be preserved insofar the new frequency range allows. In that
sense, an interpolation scheme like in [tabread4~] could be used for
realtime variable speed writing, leaving the consequences for the
user. For example, if you make large jumps through the table, many old
samples would simply not be rewritten.

But even with interpolation quality requirements so relaxed, it is not
by itself clear how the samples should be written. Using
sinc-interpolation, each input sample could be written as many samples
of a (eventually phase-shifted) sinc function, with amplitude
compensation for the overlap. The interpolation scheme of [tabread4~]
however can not calculate four output samples based on one input
sample, it could only calculate one output sample based on four input
samples.

Imagine how one would do this with a fixed resampling factor. For
example with resampling factor 0.75 (downsampling) you would write 64
* 0.75 = 48 samples into the array for every block of 64 input
samples, while incrementing the read index by 1 / 0.75 = 1.3333333.
Another example, with resampling factor 1.5 (upsampling) you would
write 64 * 1.5 = 96 samples into the array for each block of 64 input
samples, while incrementing the read index with 1 / 1.5 = 0.6666666.
The perform loop would not iterate over an integer n (= blocksize),
but it would just break when the float read index exceeds n. To
accommodate for interpolation, and for index increments larger than
one, a few samples of fixed delay 'headroom' must be introduced.

In a [tabwrite4~], resampling factor would follow from index
increments calculated from float index values received at the inlet.
But what to do with large increments, exceeding the delay 'headroom'
at the end of the input buffer? And another question: what to do with
very small increments, leading to massive amounts of written samples
and possibly to cpu overload? When starting on [tabwrite4~] a few
months ago, I stumbled upon these problems. I then considered a
version where you don't enter a float index at signal rate, but a
resampling factor at message rate which can be checked for bad values,
and set the delay 'headroom' as needed. But such a write object would
need another method to optionally synchronize with a read object, and
I have not worked that out either. Suggestions or comments are
appreciated.

Katja