sine-wave oscillator abstractions
hi all.
i made a collection of sine-wave oscillator abstractions with phase distortion and customizable sample tables size.
i'd like to know what you all think...
----
here's what's inside:
cycler~, cycler_a~
sine-wave generator with customizable buffer table size.
i use 4096 samples in help files, which is 4 times bigger than the one on supercollider which uses 1024 samples.
http://ondomusic.com/mesa.elech.tele/cycler~.jpg
http://ondomusic.com/mesa.elech.tele/cycler~inside.jpg
cycler-s~, cycler-s_a~
sine-wave generator with saw-wave phase distortion.
a slight distortion sometimes gives you a bit analog feel and sounds pleasant especially on lower frequencies.
http://ondomusic.com/mesa.elech.tele/cycler-s~.jpg
http://ondomusic.com/mesa.elech.tele/cycler-s~inside.jpg
cycler-p~, cyclerp_a~
the same concept as cycler-s~ but with pulse-wave phase distortion.
http://ondomusic.com/mesa.elech.tele/cycler-p~.jpg
http://ondomusic.com/mesa.elech.tele/cycler-p~inside.jpg
cycler~_audiotest.help
you can compare the sound qualities of different max/msp oscillators, such as cycle~, sinx~, oscbank, with cycler~.
cycler~_audiotest_fm.help
you can compare the sound qualities of fm synthesis using cycler~.
----
whatever abstractions with [_a] have an fft anti-alias filter,
but it doesn't seem to be working correctly.
if someone could tell me why, that would be great.
also, i'd like to know if any of this make any difference.
in cycler~_audiotest.help, honestly, i don't really hear the differences. maybe it's because i'm using a fairly cheap sound card. i don't know...
please let me know what you hear and think. thanks.
thanks for feedback.
> I am pretty sure your concept of antialiasing doesn't work. Its coming
> in when its too late already...
i see.
so as soon as the signal goes to the yellow cable,
it must be too late. thanks for the point.
is there anyway to do antialiasing in max other than going deep into object programming in C?
and the reason i use .txt is i'd like to avoid win<>mac issue as much as possible.
.txt hasn't failed me so far while .mxb and .pat has a few times before.
(and .txt works anyways...)
> is there anyway to do antialiasing in max other than going deep into object programming in C?
I'm not sure I entirely understand - you mean in addition to
the antialiasing oscillators that already are included with
MSP? [tri~ saw~ rect~]
Quote: Gregory Taylor wrote on Thu, 11 December 2008 05:04
----------------------------------------------------
> > is there anyway to do antialiasing in max other than going deep into object programming in C?
>
> I'm not sure I entirely understand - you mean in addition to
> the antialiasing oscillators that already are included with
> MSP? [tri~ saw~ rect~]
----------------------------------------------------
so you aren't going to get aliasing when you phase modulate a cycle with a pulse wave?
I think this is about audio rate modulation without aliasing. not a single aa'ed oscillator
hmm, i'm not sure what you mean by anti-aliased buffer~...
i thought anti-alias was a brick-wall filter.
at what stage would you apply to the signal?
would it be like anti-aliased sine wave function algorithm into peek~?
how would you make one?
(am i asking too many questions?)
and thanks for .mxt tip. i didn't know this.
hmm..., that sounds very complicated.
so ideally, you would want to calculate the wave function for each frequency to have a wave function overtones just right...
i wonder how they do it in [tri~] and such.
>A bigger wavetable doesn't mean too
>much in the real world.
the reason i did this was the whole "sound quality" issues with other DSP softwares like supercollider and RTCmix.
i've seen a lot of people saying Max/MSP doesn't have the "highest audio quality."
i wasn't quite sure what it meant,
so i thought increasing the samples in wavetable might do something and i was kinda hoping those sound quality experts could weight in.
[cycle~] doesn't handle more than 512 samples so using [cycle~] negates this whole goal so that's why i used [wave~].
i guess i can use sine-wave oscillator in [rtcmix~],
but, hey, max can do better, can't it?
How about this?
save as cosine~
save as something else.....
I know it's not particularly cpu-friendly, but it generates a "cleaner" cosine waveform than cycle, as it's not scanning a wavetable and interpolating.
Try making another version of the FM or AM tutorial patches using [cosine~] instead of [cycle~] and compare the spectra of the two.
A problem with it is that modulating the frequency of [cosine~] at higher than about 100 Hz causes it to "explode". I'm guessing this is because the cpu can't calculate a sinx~/cosx~ function at that rate.
But it does work if you restrict the frequency of the modulating oscillator in the fm tutorial.
I just did this about an hour ago, and have not listened to the result on anything but laptop speakers, so I can't say with certainty that it sounds "better" or even noticeably different.
The amplified spectra of [cycle~] is alarming though.........
Thoughts?
very interesting oli, i'd love to see your take on anti aliased classic waveforms
@ mesa.elech/tele
Other people have already made the comments about anti-aliasing - which will not work here. Also the pfft~ is very expensive for a single oscillator and adds a delay to the signal.
Also, it should be noted that wave~ performs linear interpolation on the buffer, whereas cycle~ is almost certainly doing cubic interpolation. In my experience that will create a big difference - probably more so than using a bigger sample buffer.
@timlloyd
That's pretty interesting.
However, your theory about modulation speed and cosx~ doesn't really hold up - it should calculate whatever is going into it - it has no awareness of whether it is being modulated or not.
Also - when doing modulation here (at whatever speed) I don't experience a problem.
To put some rough figure on what you're showing. From my calculations you have a cycle~ at 0dB - you then multiply by 1000 (+60dB) - you then have artifacts at what looks like just under 0.5dB giving you a signal to noise ratio of > 59.5 dB. It's not brilliant, but I wouldn't expect it to immediately be audible. You also have artifacts on the cosx~ version, just not as many, and at a (slightly) lower level). You'll note that if pick a different frequency (or sweep the frequency slowly) the level of these artifacts changes and you seem to have picked a worst case scenario (or near as damn it).
Also, I'd be a bit wary about trying to determine exactly what the spectroscope~ is telling us, as it's hard to tell *exactly* how it's calibrated, or the effects of any windowing function etc. etc.....
Still - interesting to see all this.
Alex
His cb.oscil~ external uses the same equation as my experiment, but produces a completely clean waveform (Maybe because the decimal value resolution of 2*pi is limited in max/msp? I'm not sure).
I'm not expecting it to sound different when listening to a single oscillator, but my understanding is that when combining multiple oscillators (in FM or AM for example) any artifacts such as those on the output of cycle~ will eventually manifest. I could be wrong, but the interpolation artifacts of cycle~ seem to me to be a potential factor in all the past and current max/msp vs supercollider/csound etc.... sound quality debates.
Regarding the FM "exploding" cosine~, I can't test it out again yet because my 9 month student license just expired
When I was testing it, high frequency modulation of the frequency resulted in cosine~ outputting mostly noise.
It's interesting and useful to hear what people think though, because I'm hardly well-informed on this!
timlloyd wrote on Mon, 02 November 2009 11:03http://music.calarts.edu/~cbaker/Home/Code/MaxMSP/
His cb.oscil~ external uses the same equation as my experiment, but produces a completely clean waveform (Maybe because the decimal value resolution of 2*pi is limited in max/msp? I'm not sure).
Almost certainly beacuse he does a double precision phasor calulation, multiplies by a double precision 2PI constant - calls a double precision cosine math library function, and only then rounds it into 32 bits.
There's no such thing as completely clean in a digital domain - the resolution is not infinite - it's just at what level the error is.
timlloyd wrote on Mon, 02 November 2009 11:03
I could be wrong, but the interpolation artifacts of cycle~ seem to me to be a potential factor in all the past and current max/msp vs supercollider/csound etc.... sound quality debates.
In my experience these debates are mostly based on myth rather than hard evidence or perception. SC also does a table lookup for a (co)sine oscillator - it's just that the table is I believe twice the size as in max (which I don't believe is that big of a deal but I haven't done the maths). Most of these arguments also treat the dsp like it is some kind of voodoo. I believe that the issues surrounding these so-called differences are actually more to do with the ease with which things are done in a particular language, other things that the language may or may not "do for you" (like control interpolation in SC, the balance of user base between novices and experts, and a lot of made up nonsense. There's a thread about this kind of thing in which some tests were done - which were actually fairly inconclusive:
Not meaning to argue one thing or another here - just think it's easy to get hung up on DSP sound arguments, when they aren't the key issue in why something may sound better than something else.
timlloyd wrote on Mon, 02 November 2009 11:03
When I was testing it, high frequency modulation of the frequency resulted in cosine~ outputting mostly noise.
Not my experience here.
Regards.
Alex
timlloyd wrote on Mon, 02 November 2009 11:03http://music.calarts.edu/~cbaker/Home/Code/MaxMSP/
His cb.oscil~ external uses the same equation as my experiment, but produces a completely clean waveform (Maybe because the decimal value resolution of 2*pi is limited in max/msp? I'm not sure).
OK. Now I've just checked his help patch, and according to the info here (which is set up in a way that is much easier to understand and calibrate - I misread the values in your previously posted patch for the amplitude range of spectroscope~ as being in dB) cycle~ is producing artifacts which peak at about -120dB. I don't think we need lose any sleep over that....
I certainly won't be wasting my CPU cycles on a non-table based cosine~ oscillator any time soon...
A.
[/quote]
There's no such thing as completely clean in a digital domain - the resolution is not infinite - it's just at what level the error is.
[/quote]
--- good point
Here is what sparked my experiment, I'm not too sure what to think about the whole "You can hear this difference if you compare a simple oscilator in supercollider or csound with one in max" debate. There seem to be very respectable people on both sides of the discussion.
I guess I should leave it up to the devs and get back to making music!
timlloyd wrote on Mon, 02 November 2009 15:32
There seem to be very respectable people on both sides of the discussion.
This isn't really like for like:
the post states that the oscillator is modulated - "at signal rate in MSP and kr in SC"
Which is not the same thing - there's not a lot of detail on what the values were etc. etc.
I can't really tell the difference here on a medium level pair of headphones for low modulation speeds and on my built in Mac soundcard. I can tell the difference for FM type stuff (with a higher modulation speed), because SC sounds very different (one might say worse, but that's subjective) - and that's clearly because the modulation is at uninterpolated control rate. I can make max sound the same if I use sah~ to sample the modulating oscillator once per vector.
That said - if I route SC to max using soundflower I can see the difference in the output of SinOsc against cycle~ (clearly a lower noise level).
I think if you want to really know whether one sounds better than the other (for a given task) - do the tests yourself in good listening conditions with like-for-like code. I'm still to be convinced about this by any listening test though - as you say these are respectable people, but the blog post is uninformative on many relevant aspects of the test.
Alex