[music-dsp] Math programs
earlevel at earlevel.com
Mon Feb 28 17:46:57 EST 2005
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
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
> 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,
> 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
More information about the music-dsp