On 11/23/14, 7:21 AM, Magnus Danielson wrote:
Jim,
Find myself providing guidance in both the 2010 and 2013 threads, and
they are still valid starting-points.
For music synthesizer applications, flicker noise have been done, such
as on this schematic:
https://rubidium.dyndns.org/~magnus/synths/friends/stopp/asm1ns.pdf
The work is traceable back to the Barnes-Jarvis work. Might be fun to
know. :)
There's a bunch of schemes described at
http://www.firstpr.com.au/dsp/pink-noise/
Some of which look remarkably like the Barnes, Jarvis, Greenhall approaches.
Anyway, yes, it would be reasonable that you would need that many
sections if you really intend to cover the full range, but on the other
hand, usually you have a corner from which white noise dominates, and
you really don't need to do much more than an octave or two beyond that
corner. Doing 16-17 sections is cheap today.
computationally, but any time I start down the path of implementing
something where the literature has half a dozen stages and I'm going to
be doubling or tripling that, you start to wonder about whether there's
some numerical issue that will bite you. After all, that difference
equation for the lowest frequency cutoff, with the high sample rate, has
coefficients that are very close to 1 (The Barnes & Greenhall paper
appendix A shows a lot of zero values in the tabulated area, but they
were using double precision and not printing all the digits)
The other approach is to read Chuck Greenhalls more recent papers and
see if none of those methods is applicable to your needs.
Also, remember that in the Barnes-Jarvis approach, the distance between
upper and lower corners is separated from how tight variation is
allowed, which is controlling how many sections you need. Plotting with
a scale normalized with sqrt(f) helps in analysis.
yes.. the examples in the paper make that pretty clear.. 4 sections
spread over 6 decades gets you a fair amount of variation.
There's also, of course, all those notes about "selecting an appropriate
starting point by trial and error".. Which is probably why they wrote
the analysis part of their code: make a run with one value, look at the
plot, hmm, change a value, make a run, etc.
Well.. I'm grinding through the implementation now.. in Python, as it
happens, so I'm trying to figure out how to do it a Python-esque way, as
opposed to my usual Fortran/Matlab in Python style. Seems one should be
able to have nice abstracted filter sections that you can iterate
through, etc.
BTW, if anyone is going to implement the algorithm in the PTTI paper,
you really need the Greenhall JPL report also, because a lot of the
terminology and variables carry forward.
http://ipnpr.jpl.nasa.gov/progress_report/42-77/77M.PDF
(of course, as I think about it, if I need 60 seconds worth of samples
at 1 kHz, that's only 60,000 samples, so I could just do it by
generating 64k of white noise, FFTing, applying a -3dB/octave slope, and
then inverse transforming.. And, since the FFT of white noise is white
noise, it's really just taking N samples of white noise, applying the
filter, and doing the transform to the time domain.)
(yes, the FFT method was discussed in the earlier threads)
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
