On Sat, Jun 28, 2008 at 7:43 AM, cyrille henry <[EMAIL PROTECTED]> 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 _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list