[chuck-dev] EXTERNAL: Re: SinOsc calculations

Napoletano, Nathaniel nathaniel.napoletano at lmco.com
Fri Sep 18 10:22:46 EDT 2015


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 at lists.cs.princeton.edu [mailto:chuck-dev-bounces at lists.cs.princeton.edu] On Behalf Of Joel Matthys
Sent: Friday, September 18, 2015 8:35 AM
To: chuck-dev at 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 <jwmatthys at gmail.com<mailto:jwmatthys at gmail.com>> wrote:
Hello! I was looking through the source recently, and I was a little surprised to find that the SinOsc UGen performs a trig function every sample. I was under the impression that most osc implementations use a lookup table with interpolation because it's considerably more efficient.

Was this a specific design decision? Would there be support for revising SinOsc for efficiency if the audible result was indistinguishable?

Thanks,
Joel
_______________________________________________
chuck-dev mailing list
chuck-dev at lists.cs.princeton.edu<mailto:chuck-dev at lists.cs.princeton.edu>
https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev




--
Spencer Salazar
Doctoral Candidate
Center for Computer Research in Music and Acoustics
Stanford University

spencer at ccrma.stanford.edu<mailto:spencer at ccrma.stanford.edu>
+1 831.277.4654
https://ccrma.stanford.edu/~spencer/<https://ccrma.stanford.edu/%7Espencer/>





_______________________________________________

chuck-dev mailing list

chuck-dev at lists.cs.princeton.edu<mailto:chuck-dev at lists.cs.princeton.edu>

https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-dev/attachments/20150918/d8b5b71e/attachment.html>


More information about the chuck-dev mailing list