[PD] better tabread4~
cyrille.henry at la-kitchen.fr
Sat Jun 28 13:43:07 CEST 2008
Matt Barber a écrit :
> The following bit of code might work to that end as a test, borrowing
> Cyrille's general notation:
> cminusb = c-b;
> aminusd = a-d;
> a0 = aminusd + 3.0 * cminusb;
> a1 = -2.5f * aminusd - 7.5f * cminusb;
> a2 = 1.5f * aminusd + 4.5f * cminusb;
> a3 = 0.5f * (c + a) - b;
> a4 = 0.5f * (c - a);
> a5 = b;
> *out++ = ((((a0*frac+a1)*frac+a2)*frac+a3)*frac+a4)*frac+a5;
ok, i'll try that.
but i don't think adjusting the 2nd derivative is the best thing to do.
for me, having a 6 point interpolation would be more important.
well, we will see...
> The variables would have to be declared further up, obviously. Also,
> the compiler should optimize the a5 definition out and just use b
> (right?), so the above might be clearer and more explicit from a
> formal standpoint. I'm very prone to algebraic mistakes (especially
> on friday nights), so if someone else is interested you can check my
> work and see if you arrive at the same result (x''[n] = x[n-1] -2*x[n]
> + x[n+1] , x'[n] = 0.5*(x[n+1] - x[n-1]) for both x and x )
> -- the result may be able to be further optimized as well due to some
> redundancies in the coefficients. Following the naming scheme of the
> other tests, this might be [tabread4fi~] or some such (fi for
> As this line of experimentation proceeds, it might make sense to
> develop a set of benchmarks both for quality and performance. One
> place to start might be to test the residual error between all of the
> new and old [tabosc~] objects running through a cosine table and an
> [osc~] with the same frequency and phase, trying out different
> respective table sizes, and then further test with various cosinesum
yes, a benchmarking tool would be good to make.
but i would not use osc~ as a reference, as it's output come from a table interpolation.
(if i did understand pd code, osc~ comes from a linear interpolation of a 512 points table).
(btw, if the interpolation lib is extended to a "better audio synthesis lib", then a better osc~ can be add there to)
the more i digg in pd audio code, the more i think it's important to make this kind of lib. But it would need lot's more work that i can do. and i also don't know much on this subject...
> Of course the "ear" test will probably determine things more,
> especially with sampled data, but it's still a little unclear to me
> exactly what these interpolations are "supposed" to do when the
> waveform has transients and discontinuities among the samples -- e.g.
> what bandwidth should result from moving through a table that's filled
> with white noise, or what should happen when moving slowly through a
> table that's filled with alternating 1 -1, or what should a snare-drum
> or bongo hit sound like at a fifth the speed? These seem to me to be
> more a matter of taste and interpretation than the cosine tests.
i personally consider that the interpolation should not add harmonics, and should remove non audible harmonics.
i.e : a noise with freq from 20Hz to 20kHz shift 2 octave lower should result in a noise with freq from 20Hz to 5KHz.
but it's ok for me if the result is from 5Hz to 5KHz.
shifting it 2 octave higher should result in a 80Hz->20KHz frequency on the signal. (freq from 20KHz to 80Kz should be removed to kill alliasing effect.
a table filled with alternate -1 and 1 can be seen as a 22KHz sinus (@ 44100 Hz sampling rate). shifting it higher should result in a null signal with an anti aliased interpolation. shifting it lower should result in a pure sinus wave.
this is my opinion.
i test this, and tabread4c~ is very close to the sinus wave, while tabread4~ is closer to a triangle wave.
More information about the Pd-list