Quick question-

I'm using tabread4~ for wavetable oscillators.

When I write the table itself, am I fine with a simple 256 (+3) steps like in the obiwannabe tutorial, or should I use a crazy size like the 2048 (+3) steps in the floss manuals tutorials? or something in-between?

I figure with the interpolation of tabread4~, I shouldn't need to go crazy?

Thanks again

-Lars

i guess it depends on how convoluted your wavetable is. if it's just a simple geometric shape, then a small table would be fine. but if it's something more complicated (like a human voice sample), then a larger table will give you better resolution.

alright.
That makes sense.

thanks

also, I'm gonna spend some time with this, but is there a good way to antialias the values in a table for better wavetable quality? like the internal message "normalize" table?

actually a list of all internal messages is something I haven't been able to track down yet

you could interpolate them by hand: table(n-1)/4+table(n+1)/4+table(n)/2

Using less points is kind of like killing off some upper partials, similar to using lower sampling rates. The 4-point interpolation then acts similar to the lowpass filter at the dac. And with geometric shapes, such as squares and saws that have sudden leaps, it does matter. It's those upper harmonics that make the leaps. Geometric shapes theoretically have harmonics that go on to infinity; otherwise, they wouldn't have such perfect edges. Of course, those are also the ones that get aliased . Anyhow, take a look at the attached patch. It graphs a 32-point square wave and a 512-point one onto 1024-point graphs using interpolation. 32 is obviously low, but it's meant to illustrate the point.

Personally, I don't use below 1024 points for audible oscillators. For LFOs, I would go considerably higher or just generate them on the fly.

http://www.pdpatchrepo.info/hurleur/lookuprestest.mmb.pd

ok. that patch is really helpful.

Clears up one or two things concerning table writing as well. Thanks for drafting it up