[PD] better tabread4~

Matt Barber brbrofsvl at gmail.com
Sat Jun 28 19:31:43 CEST 2008

On Sat, Jun 28, 2008 at 7:43 AM, cyrille henry
<cyrille.henry at 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.



More information about the Pd-list mailing list