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[0] and x[1] )
-- 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 "fifth"-order-polynomial).
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 combinations.
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.
best cyrille
Thanks,
Matt