Hi Joel, I love your idea about a general waveform ugen. Of course there is SndBuf which has rate control and could be looped arbitrarily short.
The benefit of a dedicated waveform player is that smoothing algorithms could be applied. But after smoothing and filtering the algorithm could be less efficient than the trig function. I'm more of an audio engineer than a programmer, but I would speculate that the reason that a trig function is currently performed on every sample is because the SinOsc is intended to sound good over a wide frequency range. And the current chuck SinOsc implementation sounds great from 20Hz to 20Khz. If you were to implement a table look up with a simple interpolation, it will degrade in fidelity if you stray too far from the original sample rate. Complex waveforms are even more critical.
I don't know where the optimal playback smoothing occurs but from experience, the Creative Labs Audigy board used a hardware 8 point interpolation (4 points to the left and 4 points to the right) and after buying one some 20 years ago, that was the first time that I thought some of my looped samples with sharp edges played back without that annoying swooshing sound. Some modern software samplers sound good too, but I don't know what they have internally.
Nat
From: chuck-dev-bounces@lists.cs.princeton.edu [mailto:chuck-dev-bounces@lists.cs.princeton.edu] On Behalf Of Joel Matthys
Sent: Friday, September 18, 2015 8:35 AM
To: chuck-dev@lists.cs.princeton.edu
Subject: EXTERNAL: Re: [chuck-dev] SinOsc calculations
Hi Spencer.
I think I would like to work on making a wavetable sine.
Actually, I think a general wavetable instrument which takes an array might be very useful. Chuck ought to be able to read a user array just as quickly as an internal one, right? So it could be something like:
Wavetable w => dac;
w.table("sine", 1027); // shape, number of points in array
440 => w.freq;
week => now; // sit back and enjoy
[-1,0,1] @=> float[] mytable;
w.set(mytable);
2::weeks => now; //even better
I'll see what I can glean from the RTcmix code (which I think does it really well, and IIRC is pretty close to MusicN wavetable code) and make a Chugin, and then do some tests to compare for efficiency.
Joel
On 09/18/2015 01:20 AM, Spencer Salazar wrote:
Hi Joel,
Thats correct- SinOsc is just a naive implementation of a sine wave. I don't know that there is a reason for this other than simplicity.
In performance-sensitive situations I have recommended using either MagicSine (if it is not necessary to change the freq/phase rapidly) or Gen9/Gen10, which are sinusoid wavetables.
I have been interested in developing a chugin that is just a really fast/mathematically accurate wavetable sine. If you'd be interested in making something like that, or collaborating on it, that'd be very cool. If we got that in good shape we could replace the default sine, if there is no other reason to keep it the way it is.
spencer
On Thu, Sep 17, 2015 at 6:52 PM, Joel Matthys