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 > > _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
