On Sat, Jun 28, 2008 at 7:43 AM, cyrille henry cyrille.henry@la-kitchen.fr wrote:
Matt Barber a écrit :
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...
I did not know that about [osc~] -- I'm still going through the code, but [osc~] has often felt kind of "rough around the edges." I suppose that the error in various interpolation schemes from the tabosc objects would begin to converge with larger tables, so it's possible something like that could be used for the benchmark instead. With appropriate frequencies there could probably be some interesting fft tests as well.
I've always liked the sound of SC3's SinOsc ugen... it might be worth looking through that code to see how it differs from [osc~]'s.
Thanks,
Matt