[music-dsp] Math programs

Nigel Redmon earlevel at earlevel.com
Mon Feb 28 17:46:57 EST 2005

Hi Jim,

I started with a student version matlab years ago (not as a student, 
but was doing some work at Stanford); it had a limited array size, but 
was dirt cheap--just good enough fro trying some things out while 
learning. They bailed on Mac in the 90's, so that's as far as I took 
it. I used MathCad for a while, again dirt cheap, but they bailed on 
Mac (was buggy unless you had a lot of memory anyway--obvious syndrome 
of handles not being locked down as you scroll and garbage appears). I 
did develop a lot of filter builders and analyzers on it, and it was 
good for q&d things--and formulas look right on the screen, and 
everything recalculates like a spreadsheet on any change, so I still 
pull the darn thing out when I need to look at something I've already 
been through (runs OK under OS X via Classic). Not so good for complex 
systems though--best for looking at one thing at a time.

Then I got my employer to shell out the big bucks for Mathematica. I 
like it a lot--not blazingly fast, but does some pretty amazing things. 
But, when I went back to being a consultant, I wasn't willing to pony 
up the $ for the upgrade to OS X.

For new things lately, it's been Octave. I scouted a bit, and it looked 
like that was a better choice over SciLab for OS X. Matlab and clones 
have certain very annoying features (1-based indices and stuff), but 
the clones are free and it work. I think you're running on PC, but for 
OS X folk, installing octave via Fink is pretty painless.

The good thing about matlab clones is that you can fine some files on 
the web that help in calculating and plotting certain common DSP 
things. I pretty much had to roll everything in Mathcad--sometimes 
that's a good thing because you have to understand how everything 
works, but sometimes it's just time wasted.

Sometimes there's no substitute for doing as you say--using your own 
audio classes and generating a file to look at. but certain things are 
very handy for math programs. Some that you are unlikely to have in 
your own audio app--things like generating a polynomial approximation 
to a response curve to a specified accuracy. Others that you could do 
in your program, but are better suited for tweaking in a math program. 
For instance, I wrote one that generates and plots FIRs from 
Kaiser-windowed sinc based on FC, number of taps, and stop-band 
rejection. It also allows some custom tweaks, such as setting the 
endpoints to zero (if your coefficient endpoints are very small, 
setting them to zero does little to the response and saves you two 
taps), and I have a version that does multiple FIRs and plots for 
multistage conversion.

Also, a math program is extremely helpful for analyzing things like 
quantization effects. If you're going to code a filter in fixed point, 
especially, it's pretty important to know if it's going to be stable, 
and listening won't always tell you (a lot of times it shows up as a DC 
instability, so it might not show up until your users get annoyed about 
why their meters are always hopping about when nothing is going 
through--I always add the ability to set the quantization in my IIR 


On Feb 28, 2005, at 1:10 PM, James Chandler Jr wrote:
> ----- Original Message ----- From: "Nigel Redmon" 
> <earlevel at earlevel.com>
>> I think it's a good idea to fiddle with filters in a math program and 
>> plot the output. I plot just about everything before I code.
> Thanks for the graphic example Nigel. Yer png graph showed up fine in 
> Winders IE 6.
> I should learn a math program. From brief inspection, Octave looks 
> labor-intensive. SciLab looks more promising.
> To minimize the learning/setup curve-- If money were no object, is 
> matlab the way to go?
> Reckon learning a math program is roughly equivalent to learning a new 
> programming language AND learning a new IDE? Would free programs like 
> scilab entail more work, having to search out tools or roll yer own?
> How much time does it take a dummy to become moderately proficient in 
> matlab?
> =====
> I have a long-ago-written audio helper program that reads a command 
> text file and processes the list of audio files.
> The command text file specifies input/output files (and other 
> conditions). I can repeatedly tweak an algorithm, hit run, and quickly 
> see/hear the results in CoolEdit. Since the utility program 
> encapsulates the audio in/out, the buffer processing function is the 
> only thing I have to write.
> The utility program has common audio classes. If I want an RBJ filter 
> in the block processing function, something like--
> RBJNotchFilt.FilterMonoBuf(InFloatPtr, InFloatPtr, InputNumBytes);
> //filter the buffer in-place
> Having added a class for Dave's polyphase halfband, it is easy to 
> one-line test in the same fashion--
> HalfBandFilt.ProcessMonoBuf(InFloatPtr, ResampleDirection, 
> InputNumBytes);
> There is a tradeoff between slower development using known tools, 
> against possibly faster development after spending some unknown time 
> learning a math program.
> --
> dupswapdrop -- the music-dsp mailing list and website: subscription 
> info, FAQ, source code archive, list archive, book reviews, dsp links 
> http://shoko.calarts.edu/musicdsp 
> http://ceait.calarts.edu/mailman/listinfo/music-dsp

More information about the music-dsp mailing list