From douglas at music.columbia.edu Wed Apr 1 07:00:00 2009 From: douglas at music.columbia.edu (douglas repetto) Date: Wed Apr 1 07:00:09 2009 Subject: [music-dsp] [admin] music-dsp FAQ Message-ID: <20090401110000.7371E54BA41@music.columbia.edu> Hi, Just a reminder that if you are new to the list you should read the music-dsp FAQ. It contains answers to both technical _and_ adminstrative questions that often come up on the list. If your question appears in the FAQ it is safe to assume that it has been discussed on the list many times in the past, and you should probably have a look through the list archives before posting your question to the list. http://music.columbia.edu/cmc/music-dsp/musicdspFAQ.html Also of interest to new and not-so-new list members: The music-dsp list archives http://music.columbia.edu/cmc/music-dsp/musicdsparchives.html The music-dsp source code archive http://www.musicdsp.org music-dsp books and reviews http://music.columbia.edu/cmc/music-dsp/dspbooks.html All this and more at: http://music.columbia.edu/cmc/music-dsp Hasta la pasta, douglas (this is an automated message sent out on the 1st and 15th of each month) From developer at netcologne.de Wed Apr 1 17:08:36 2009 From: developer at netcologne.de (Thomas Rehaag) Date: Wed Apr 1 17:08:53 2009 Subject: [music-dsp] Bandpass IIR Gain Factor References: <20090315110001.4E7704442CC@music.columbia.edu> <49D20C9E.EC366F3B@netcologne.de> <49D2165B.8090907@saunalahti.fi> <49D216AF.20900@saunalahti.fi> <49D21A4B.F61FF310@netcologne.de> <49D21B4E.7060601@saunalahti.fi> <49D2241F.DEAB2EA@netcologne.de> <49D229AB.7080209@saunalahti.fi> Message-ID: <49D3D7D4.A206355D@netcologne.de> Hi Vesa, after spending some hours on recalculating the gain factor with your hint, watching the formulas growing I suddenly knew, this can't be the right way - can't be, that a filter formula has a frequency dependent gain! Went back to bilinear transformation theory and found the mistake. There's been one erroneous line in my code: m_fA1 = 4 * fDQ * fDiv;// from my first posting should be: m_fA1 = fDQ *fFd * fDiv; now erverything works fine. :) Thomas Vesa Norilo schrieb: > > Thomas Rehaag wrote: > > Hi Vesa, > > > > so the equiation is: > > > > H(Z) = (a1 + a3 z^-2) / ( 1 + b2 z^-1 + b3 z^-2 ) > > = (a1 - a1 z^-2) / ( 1 + b2 z^-1 + b3 z^-2 ) > > = (a1 z^2 - a1) / ( z^2 + b2 z^1 + b3) > > > > > > and I substitute Z = e^(i fRel Pi) > > > > ? > > > Yes, that's correct. > > The magnitude response of the filter is the absolute value of H(Z), and > to get the point of Z-plane that corresponds to a real world frequency > f/samplerate, you query H(e^i f pi). Absolute value is the magnitude and > the argument is the phase response. > > A helpful identity with the absolute value of complex numbers is: > > |Z| = Sqrt(Z * Conjugate(Z)) > > Vesa > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From developer at netcologne.de Wed Apr 1 17:34:35 2009 From: developer at netcologne.de (Thomas Rehaag) Date: Wed Apr 1 17:34:49 2009 Subject: [music-dsp] bandpass cutoff frequencies References: <20090315110001.4E7704442CC@music.columbia.edu> <49D20C9E.EC366F3B@netcologne.de> Message-ID: <49D3DDEB.8C880805@netcologne.de> Hi, I want to calculate the center frequency (f0) and the quality (q) of a bandpass from the user input cutoff frequencies fmin and fmax. For analog filters this would be quite cheap as far as I understand: f0 = sqrt(fmin*fmax); q = f0/(fmax - fmin); The question is: can I transfer these calculations to digital filters? Are they exact enough for an audio equaliser? Or is the transfer even totally exact? Thanks, Thomas From martin.eisenberg at udo.edu Sat Apr 4 12:03:20 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Sat Apr 4 12:01:29 2009 Subject: [music-dsp] bandpass cutoff frequencies References: <20090315110001.4E7704442CC@music.columbia.edu><49D20C9E.EC366F3B@netcologne.de> <49D3DDEB.8C880805@netcologne.de> Message-ID: <000701c9b53e$e3aaef40$0201a8c0@mooncode> From: "Thomas Rehaag" > I want to calculate the center frequency (f0) and the quality > (q) of a bandpass from the user input cutoff frequencies fmin > and fmax. > > For analog filters this would be quite cheap as far as I > understand: > f0 = sqrt(fmin*fmax); > q = f0/(fmax - fmin); > > The question is: can I transfer these calculations to digital > filters? > Are they exact enough for an audio equaliser? I assume you're talking about the biquad bandpass from your previous messages. First of all, what is your purpose? Do you want values that make musical sense to display, or do you just want them in order to generate the filter coefficients with the usual formulas? Martin From developer at netcologne.de Sun Apr 5 05:28:28 2009 From: developer at netcologne.de (Thomas Rehaag) Date: Sun Apr 5 05:28:38 2009 Subject: [music-dsp] bandpass cutoff frequencies References: <20090315110001.4E7704442CC@music.columbia.edu><49D20C9E.EC366F3B@netcologne.de> <49D3DDEB.8C880805@netcologne.de> <000701c9b53e$e3aaef40$0201a8c0@mooncode> Message-ID: <49D879BC.C4B0781@netcologne.de> > > I want to calculate the center frequency (f0) and the quality > > (q) of a bandpass from the user input cutoff frequencies fmin > > and fmax. > > > > For analog filters this would be quite cheap as far as I > > understand: > > f0 = sqrt(fmin*fmax); > > q = f0/(fmax - fmin); > > > > The question is: can I transfer these calculations to digital > > filters? > > Are they exact enough for an audio equaliser? > > I assume you're talking about the biquad bandpass from your > previous messages. First of all, what is your purpose? I'm trying to build a parametric EQ (2/4 pole) with subsequent bands where the user sets the band limits. Thanks, Thomas From rbj at audioimagination.com Sun Apr 5 08:14:51 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sun Apr 5 08:15:08 2009 Subject: [music-dsp] bandpass cutoff frequencies Message-ID: <20090405121451.6C8A94F3D0@ws6-5.us4.outblaze.com> > ----- Original Message ----- > From: "Thomas Rehaag" > To: "A discussion list for music-related DSP" > Subject: Re: [music-dsp] bandpass cutoff frequencies > Date: Sun, 05 Apr 2009 11:28:28 +0200 > > > > > > I want to calculate the center frequency (f0) and the quality > > > (q) of a bandpass from the user input cutoff frequencies fmin > > > and fmax. > > > > > > For analog filters this would be quite cheap as far as I > > > understand: > > > f0 = sqrt(fmin*fmax); > > > q = f0/(fmax - fmin); > > > > > > The question is: can I transfer these calculations to digital > > > filters? you can get very close with the bilinear transform. this has been done by a variety of authors (Zoelzer, Moorer, Stanley, myself, and Orfanidis sorta). > > > Are they exact enough for an audio equaliser? the adjacent bands do *not* add to be a wire, if that is what you mean be "exact enough". > > I assume you're talking about the biquad bandpass from your > > previous messages. First of all, what is your purpose? > > I'm trying to build a parametric EQ (2/4 pole) with subsequent bands > where the user sets the band limits. i am not sure, but i think the peaking EQ in Audio EQ Cookbook should be able to do that. there *is* an approximation made when dealing with bandwidth (the difference between bandedges) and the bilinear transform (due to frequency warping of the bilinear transform), but if you use the two equations above to map fmin, fmax to f0 and Q, you should be okay. maybe a little bit off. if you're using the Cookbook "Q" maps from analog to digital with no adjustment due to warping. in the analog filter: 1) f0 = sqrt(fmin*fmax) (as you have specified) and normally the bandwidth in octaves is 2) BW = log2(fmax) - log2(fmin) = log2(fmax/fmin) = log(fmax/fmin)/log(2) and, in the analog filter 1/Q = 2*sinh(log(2)/2*BW) but that gets fudged a little in the Cookbook because of frequency warping 3) 1/Q = 2*sinh(log(2)*BW*pi*f0/sin(2*pi*f0)) anyway, you should be able to map fmin and fmax to f0 and Q, using the equations 1), 2), and 3) and use the Cookbook peaking EQ (in cascade). if it's not precise enough for you, all's i can say is "rots o' ruck". -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From martin.eisenberg at udo.edu Sun Apr 5 08:42:09 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Sun Apr 5 08:40:10 2009 Subject: [music-dsp] bandpass cutoff frequencies References: <20090315110001.4E7704442CC@music.columbia.edu><49D20C9E.EC366F3B@netcologne.de><49D3DDEB.8C880805@netcologne.de><000701c9b53e$e3aaef40$0201a8c0@mooncode> <49D879BC.C4B0781@netcologne.de> Message-ID: <001501c9b5eb$f32fade0$0201a8c0@mooncode> From: "Thomas Rehaag" > I'm trying to build a parametric EQ (2/4 pole) with > subsequent bands where the user sets the band limits. (It's "consecutive bands".) Then it's probably best to calculate the filter coefficients directly from the band edges. Regarding the 2-pole bandpass, observe that the phase response phi(w) takes special values at the interesting points: phi(w_peak) = 0 and for 0 < wl < wh < pi, phi(wl) = pi/4, phi(wh) = -pi/4. So we can use the last two conditions to solve for the pole location, then find wp from the first condition and normalize the filter gain at wp. Expressing the filter as H(z) = b*(z^2-1)/(z-r*exp(I*p))/(z-r*exp(-I*p)) and armed with some trig identities, the transformation psi(v) = tan(phi(2*arctan(v))) gives a rational function in v, r, and cp := cos(p). The equations to solve then become {psi(vl) = 1, psi(vh) = -1} for (r, cp), psi(vp) = 0 for vp, and finally H(exp(j*wp)) = 1 for b, where wp = 2*arctan(vp). The derivation is feasible by hand if you like that sort of thing, although I let a CAS do the work ;) The resulting coefficient generator is as follows: makeBP:= proc(wl,wh) local tmp, vl,vh, r2, r, cp, b; vl,vh := tan(wl/2), tan(wh/2); tmp := vh*vl+vh-vl+1; r2 := abs((-vh*vl+vh-vl-1)/tmp); r := sqrt(r2); cp := -(vh*vl-1)/r/tmp; b := (1-r2)/2; return unapply(b*(z^2-1)/(z^2 - 2*r*cp*z + r2), z); end: Note that tmp can never be zero if 0 < wl < wh < pi. For your interest, the peak frequency is wp = 2*arctan(sqrt((r^2+1-2*r*cp) / (r^2+1+2*r*cp))) and is at most 10% below the ideal center frequency w0 = sqrt(wl*wh) for wh <= 1.45+wl-0.11*wl^2, pretty tightly. Martin From jchandjr at bellsouth.net Mon Apr 6 11:36:33 2009 From: jchandjr at bellsouth.net (James Chandler Jr) Date: Mon Apr 6 11:37:24 2009 Subject: [music-dsp] bandpass cutoff frequencies In-Reply-To: <20090405121451.6C8A94F3D0@ws6-5.us4.outblaze.com> References: <20090405121451.6C8A94F3D0@ws6-5.us4.outblaze.com> Message-ID: <2DEFE53B-1CD4-42DA-9F8C-9B39865CA769@bellsouth.net> Hi Thomas I have used RBJ's cookbook filters a lot, for many things, for many years. They perform very close to equivalent analog filters at lower Fc, and have some deviation from analog filter performance at higher Fc. The deviation from 'perfection' at higher Fc's does not make them useless, and it is just the way IIR filters seem to behave when Fc approaches Nyquist. Am thankful RBJ made them available. Have read that there are alternate mappings of coefficients that can get 'closer to analog' at high frequencies, but dunno if there really is a good way to cheat mother nature with high-Fc IIR's. Maybe. As a rough rule-of-thumb (from my experience), for instance with a sample rate of 44.1 KHz-- You get pretty close to analog filter expected curves (Fc versus Q) up to about 1 or 2 KHz Fc. They work fine all the way up to Nyquist, but get looser up there. One obvious way to get 'more ideal' filter response at high Fc would be to run the filters at a higher samplerate. If you use high-quality samplerate conversion on the front end to bump up the samplerate to 176.4 KHz (or whatever), run your equalizer, and then high-quality convert back down to the original samplerate-- I think all the bands in your equalizer (including the high frequency bands) would operate very close to their analog equivalents. At the cost of extra CPU time. Dunno if it is worth the work. A fellow might typically listen to audio and guestimate that he needs a 4 dB boost at 1.6 KHz with a fifth-octave width, or whatever. But if that doesn't sound right-- He will just twiddle the knobs until the sow's ear has been polished as close as possible to silk texture. So if an equalizer is not exactly scientifically accurate, then this does not often prevent the equalizer from being useful . Of course it is desirable that an EQ's knob settings would have some semblance to reality, but even original analog equipment is not typically super-precise in the real world. The typical mass-produced analog parametric EQ from yesteryear is not likely to give you the EXACT frequency, Q and gain that the knobs indicate . What can one expect when many important components have tolerances of +/- 5% or worse? Many analog equalizer designs arrange filter banks in parallel, within a global feedback loop. That is a good lowest-noise design for an analog equalizer. IMO parallel is not a good configuration for a digital equalizer. If attempting to mimic the analog parallel design with IIR filters, in my experience it will not perform as good as the equivalent analog circuit. Noise build-up is not a big problem with digital filters (but noise is a constant enemy in analog). You can get much better results by putting digital filters in series. If you build a parametric EQ out of some RBJ peaking filters wired in series-- Except for a bit of 'looseness' at high frequencies, the knob settings will more-closely resemble reality than do most analog parametric equalizers. James Chandler Jr. From developer at netcologne.de Mon Apr 6 16:17:04 2009 From: developer at netcologne.de (Thomas Rehaag) Date: Mon Apr 6 16:17:24 2009 Subject: [music-dsp] bandpass cutoff frequencies References: <20090315110001.4E7704442CC@music.columbia.edu><49D20C9E.EC366F3B@netcologne.de><49D3DDEB.8C880805@netcologne.de><000701c9b53e$e3aaef40$0201a8c0@mooncode> <49D879BC.C4B0781@netcologne.de> <001501c9b5eb$f32fade0$0201a8c0@mooncode> Message-ID: <49DA6340.AF7184C6@netcologne.de> Hi Martin, thanks a lot for your help. > > I'm trying to build a parametric EQ (2/4 pole) with > > subsequent bands where the user sets the band limits. > > (It's "consecutive bands".) My bad english! But I fear that my knowledge about filter theory is even worse, so that I could hardly follow some steps of your explanation :( But I took the resulting formula for wp, and it seems to work fine! ... and shows that the 'analog equations' ain't too bad. One (maybe dumb) question: Which programming language is your function makeBP? As a simple c++ programmer I couldn't even imagine what it returns ;) Best Regards, Thomas From developer at netcologne.de Mon Apr 6 16:40:30 2009 From: developer at netcologne.de (Thomas Rehaag) Date: Mon Apr 6 16:40:40 2009 Subject: [music-dsp] bandpass cutoff frequencies References: <20090405121451.6C8A94F3D0@ws6-5.us4.outblaze.com> <2DEFE53B-1CD4-42DA-9F8C-9B39865CA769@bellsouth.net> Message-ID: <49DA68BE.F9344DC3@netcologne.de> Hi James, my problem was that I didn't know enough about the frequency warping of digital filters. That's why I feared big errors in my 'analog calculation'. I don't need a perfect EQ. Your words about "RBJ peaking filters" sound very interesting. Don't know them. I'll have a look at them tomorow. My first plan was to add or subtract LP/BP/HP filtered sound to/from the original sound in order to keep the untreated parts clean. Especialy clean of phase distortion. Thanks, Thomas James Chandler Jr schrieb: > > Hi Thomas > > I have used RBJ's cookbook filters a lot, for many things, for many > years. > > They perform very close to equivalent analog filters at lower Fc, and > have some deviation from analog filter performance at higher Fc. The > deviation from 'perfection' at higher Fc's does not make them useless, > and it is just the way IIR filters seem to behave when Fc approaches > Nyquist. Am thankful RBJ made them available. > > Have read that there are alternate mappings of coefficients that can > get 'closer to analog' at high frequencies, but dunno if there really > is a good way to cheat mother nature with high-Fc IIR's. Maybe. > > As a rough rule-of-thumb (from my experience), for instance with a > sample rate of 44.1 KHz-- You get pretty close to analog filter > expected curves (Fc versus Q) up to about 1 or 2 KHz Fc. They work > fine all the way up to Nyquist, but get looser up there. > > One obvious way to get 'more ideal' filter response at high Fc would > be to run the filters at a higher samplerate. If you use high-quality > samplerate conversion on the front end to bump up the samplerate to > 176.4 KHz (or whatever), run your equalizer, and then high-quality > convert back down to the original samplerate-- I think all the bands > in your equalizer (including the high frequency bands) would operate > very close to their analog equivalents. At the cost of extra CPU time. > > Dunno if it is worth the work. A fellow might typically listen to > audio and guestimate that he needs a 4 dB boost at 1.6 KHz with a > fifth-octave width, or whatever. But if that doesn't sound right-- He > will just twiddle the knobs until the sow's ear has been polished as > close as possible to silk texture. So if an equalizer is not exactly > scientifically accurate, then this does not often prevent the > equalizer from being useful . > > Of course it is desirable that an EQ's knob settings would have some > semblance to reality, but even original analog equipment is not > typically super-precise in the real world. The typical mass-produced > analog parametric EQ from yesteryear is not likely to give you the > EXACT frequency, Q and gain that the knobs indicate . What can one > expect when many important components have tolerances of +/- 5% or > worse? > > Many analog equalizer designs arrange filter banks in parallel, within > a global feedback loop. That is a good lowest-noise design for an > analog equalizer. > > IMO parallel is not a good configuration for a digital equalizer. If > attempting to mimic the analog parallel design with IIR filters, in my > experience it will not perform as good as the equivalent analog circuit. > > Noise build-up is not a big problem with digital filters (but noise is > a constant enemy in analog). You can get much better results by > putting digital filters in series. If you build a parametric EQ out of > some RBJ peaking filters wired in series-- Except for a bit of > 'looseness' at high frequencies, the knob settings will more-closely > resemble reality than do most analog parametric equalizers. > > James Chandler Jr. > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From jchandjr at bellsouth.net Mon Apr 6 18:03:28 2009 From: jchandjr at bellsouth.net (James Chandler Jr) Date: Mon Apr 6 18:04:13 2009 Subject: [music-dsp] bandpass cutoff frequencies In-Reply-To: <49DA68BE.F9344DC3@netcologne.de> References: <20090405121451.6C8A94F3D0@ws6-5.us4.outblaze.com> <2DEFE53B-1CD4-42DA-9F8C-9B39865CA769@bellsouth.net> <49DA68BE.F9344DC3@netcologne.de> Message-ID: <47DD79BA-CCE4-402C-A13A-89C85C95A14F@bellsouth.net> Hi Thomas Robert's cookbook is very well-behaved. Regardless of your chosen filtering and coefficient selection method, it is advisable to do all coefficients and filter processing math in double or Int64 fixed point math if possible. I usually use double math because all my programming is done on desktop puters. Strangely enough, if you are forced by hardware limitations to use 32 bit float or small-sized-int fixed point math, it is said that long term math error accumulation is most likely to affect low-FC filters. The strategy of adding or subtracting filtered output to the original sound, is similar to the parallel-bank design in analog equalizers. What makes this 'tricky' in digital, is that analog equalizers usually incorporate a global feedback loop to enforce boost/cut. In analog, once you set the Q of a filter, that boost/cut feedback loop 'magically' allows the width of the boost to be the same as the width of an equivalent cut. IE, a 6 dB boost hump is the mirror image of a 6 dB cut dip. The 'constant Q design'. The different filters in the analog bank will fight each other at band boundaries somewhat, because of reverse-direction phase shifting where the bands overlap, but the global feedback can hide some of the unpredictable inter-band ugliness in a good analog EQ design. In digital you typically cannot do successful global feedback (ala opamps), except at outlandish high sample rates. Digitally adding or subtracting a filter output against the 'straight wire' doesn't have exactly the same effect as an analog filter bank with boost/cut global feedback. In digital without the feedback to 'linearize' the boost/cut bandwidth, if you select a certain Filter Q and add it to the 'straight wire', then the more gain you add, the wider is the boost. But if you keep the same selected Filter Q and subtract it from the 'straight wire', then the more cut you impose, the cut band gets narrower. So you don't get the expected analog 'constant Q' behavior. Given a certain Filter Q, a 6 dB boost would have a much wider 'hump' than a 6 dB cut's 'dip'. That is because of how the phase shift cancellations interact with the original signal with simple addition or subtraction. You could do an add/subtract parallel filter bank in digital (without feedback), but to accomplish constant Q output behavior, you would need to calculate a different Q for a filter, every time the user changes that band's gain. Robert worked out most of those nasty details in his Peaking Filter. He incorporates the 'constant Q' feature into his coefficient calculations. Every time the user twists a gain knob in the GUI and you recalc an RBJ peaking filter for a different gain (but same Q)-- Robert's coefficient calculations adapt the 'actual' width of the filtering so that cuts have the same bandwidth as equivalent boosts. If a digital EQ is implemented as peaking filters in series, it also eliminates adjacent bands fighting each other with phase cancellations. This does not eliminate the phase shifts, but it eliminates unexpected inter-band amplitude wiggles from phase cancellation or reinforcement. The output of filter 1 is 'carved in stone' amplitude-wise and phase- wise when it arrives at filter 2. And so filter 2 can mess with the amplitude and phase, but filter 2 can't do anything to the phase that would unexpectedly cancel or reinforce amplitude with whatever filter 1 did to the phase. So if filter 2 is wider than filter 1, then filter 2 might affect what filter 1 did to the amplitude response, but the phase shifts of the two filters cannot unpredictably cancel or reinforce and cause unexpected inter-band behavior. If you use high-resolution calculations and high-resolution intermediate data in-between the filters, to minimize accumulated math errors, a series filter EQ is generally well-behaved. For top and bottom bands, you might want shelving filters rather than peaking filters, but a bass shelving filter given a lot of boost can occasionally be 'sonically' problematic. I don't know much about this field compared to the experts here, but believe the above to be 'generally accurate'. James Chandler Jr. On Apr 6, 2009, at 4:40 PM, Thomas Rehaag wrote: > Hi James, > > my problem was that I didn't know enough about the frequency warping > of > digital filters. That's why I feared big errors in my 'analog > calculation'. I don't need a perfect EQ. > Your words about "RBJ peaking filters" sound very interesting. Don't > know them. I'll have a look at them tomorow. > My first plan was to add or subtract LP/BP/HP filtered sound to/from > the > original sound in order to keep the untreated parts clean. Especialy > clean of phase distortion. > > Thanks, > > Thomas From didid at skynet.be Mon Apr 6 18:27:52 2009 From: didid at skynet.be (Didier Dambrin) Date: Mon Apr 6 18:28:17 2009 Subject: [music-dsp] bandpass cutoff frequencies In-Reply-To: <47DD79BA-CCE4-402C-A13A-89C85C95A14F@bellsouth.net> References: <20090405121451.6C8A94F3D0@ws6-5.us4.outblaze.com><2DEFE53B-1CD4-42DA-9F8C-9B39865CA769@bellsouth.net><49DA68BE.F9344DC3@netcologne.de> <47DD79BA-CCE4-402C-A13A-89C85C95A14F@bellsouth.net> Message-ID: <0AD10DFB797B4EDEB7BEDB395B3F72F2@GOLAMD> While I too wouldn't say it's a good idea to build an EQ out of filters in parallel, I've done one using RBJ's bandpasses, and its flat output is not too far from the dry, better than I expected - but I still consider it as a "fancy EQ-like effect" rather than a proper EQ tool. I'm now evaluating possibilities for something that really does need a parallel filterbank: a vocoder. One option is to use bandpasses, like RBJ's. Problem here, I'd like the freedom of moving bands around, not necessarily having the same distance between them. So another option would be to build bandpasses out of low/highpasses. This would cost a lot of CPU, especially because the bands should be narrow, for a minimum of 24dB/oct it would already require 2x2 filters per band. And the slopes not being controllable, hard to play with the # of bands if they're all too wide. This (old?) article also seem to say that bessel filters would be better for vocoders, and maybe EQ in parallel too? http://scitation.aip.org/getabs/servlet/GetabsServlet?prog=normal&id=JASMAN000043000004000803000001&idtype=cvips&gifs=yes > Hi Thomas > > Robert's cookbook is very well-behaved. > > Regardless of your chosen filtering and coefficient selection method, > it is advisable to do all coefficients and filter processing math in > double or Int64 fixed point math if possible. > > I usually use double math because all my programming is done on > desktop puters. Strangely enough, if you are forced by hardware > limitations to use 32 bit float or small-sized-int fixed point math, > it is said that long term math error accumulation is most likely to > affect low-FC filters. > > The strategy of adding or subtracting filtered output to the original > sound, is similar to the parallel-bank design in analog equalizers. > What makes this 'tricky' in digital, is that analog equalizers usually > incorporate a global feedback loop to enforce boost/cut. > > In analog, once you set the Q of a filter, that boost/cut feedback > loop 'magically' allows the width of the boost to be the same as the > width of an equivalent cut. IE, a 6 dB boost hump is the mirror image > of a 6 dB cut dip. The 'constant Q design'. > > The different filters in the analog bank will fight each other at band > boundaries somewhat, because of reverse-direction phase shifting where > the bands overlap, but the global feedback can hide some of the > unpredictable inter-band ugliness in a good analog EQ design. > > In digital you typically cannot do successful global feedback (ala > opamps), except at outlandish high sample rates. Digitally adding or > subtracting a filter output against the 'straight wire' doesn't have > exactly the same effect as an analog filter bank with boost/cut global > feedback. > > In digital without the feedback to 'linearize' the boost/cut > bandwidth, if you select a certain Filter Q and add it to the > 'straight wire', then the more gain you add, the wider is the boost. > But if you keep the same selected Filter Q and subtract it from the > 'straight wire', then the more cut you impose, the cut band gets > narrower. So you don't get the expected analog 'constant Q' behavior. > Given a certain Filter Q, a 6 dB boost would have a much wider 'hump' > than a 6 dB cut's 'dip'. That is because of how the phase shift > cancellations interact with the original signal with simple addition > or subtraction. > > You could do an add/subtract parallel filter bank in digital (without > feedback), but to accomplish constant Q output behavior, you would > need to calculate a different Q for a filter, every time the user > changes that band's gain. > > Robert worked out most of those nasty details in his Peaking Filter. > He incorporates the 'constant Q' feature into his coefficient > calculations. Every time the user twists a gain knob in the GUI and > you recalc an RBJ peaking filter for a different gain (but same Q)-- > Robert's coefficient calculations adapt the 'actual' width of the > filtering so that cuts have the same bandwidth as equivalent boosts. > > If a digital EQ is implemented as peaking filters in series, it also > eliminates adjacent bands fighting each other with phase > cancellations. This does not eliminate the phase shifts, but it > eliminates unexpected inter-band amplitude wiggles from phase > cancellation or reinforcement. > > The output of filter 1 is 'carved in stone' amplitude-wise and phase- > wise when it arrives at filter 2. And so filter 2 can mess with the > amplitude and phase, but filter 2 can't do anything to the phase that > would unexpectedly cancel or reinforce amplitude with whatever filter > 1 did to the phase. > > So if filter 2 is wider than filter 1, then filter 2 might affect what > filter 1 did to the amplitude response, but the phase shifts of the > two filters cannot unpredictably cancel or reinforce and cause > unexpected inter-band behavior. > > If you use high-resolution calculations and high-resolution > intermediate data in-between the filters, to minimize accumulated math > errors, a series filter EQ is generally well-behaved. For top and > bottom bands, you might want shelving filters rather than peaking > filters, but a bass shelving filter given a lot of boost can > occasionally be 'sonically' problematic. > > I don't know much about this field compared to the experts here, but > believe the above to be 'generally accurate'. > > James Chandler Jr. > > > On Apr 6, 2009, at 4:40 PM, Thomas Rehaag wrote: > >> Hi James, >> >> my problem was that I didn't know enough about the frequency warping >> of >> digital filters. That's why I feared big errors in my 'analog >> calculation'. I don't need a perfect EQ. >> Your words about "RBJ peaking filters" sound very interesting. Don't >> know them. I'll have a look at them tomorow. >> My first plan was to add or subtract LP/BP/HP filtered sound to/from >> the >> original sound in order to keep the untreated parts clean. Especialy >> clean of phase distortion. >> >> Thanks, >> >> Thomas > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database: 270.11.43/2043 - Release Date: 04/06/09 06:22:00 From neolit123 at gmail.com Mon Apr 6 20:12:40 2009 From: neolit123 at gmail.com (Lubomir Ivanov) Date: Mon Apr 6 20:13:18 2009 Subject: [music-dsp] bandpass cutoff frequencies References: <20090405121451.6C8A94F3D0@ws6-5.us4.outblaze.com><2DEFE53B-1CD4-42DA-9F8C-9B39865CA769@bellsouth.net> <49DA68BE.F9344DC3@netcologne.de> Message-ID: <003601c9b715$97025b00$0201a8c0@LuboPC> Hello, As Didier suggested, chaining bandpasses wouldn't exactly give you an equalizer like FX. It would closer to the principle used in crossover systems in my opinion (multiband). The user in this case will be manipulation the gain of separate bands. The main issue here would be the resulted phase-shifts at crossover points and your design would require a linear/close-to-linear phase filters if sound quality is of concern. The best way to deal with this, cpu cycles wise would be with Bessel crossovers. http://www.rane.com/note147.html The approach of modifying a peak filter on the other hand, seems much more reasonable and will be more efficient too. Lubomir I. Ivanov http://www.tu-varna.bg ----- Original Message ----- From: "Thomas Rehaag" To: "A discussion list for music-related DSP" Sent: Monday, April 06, 2009 11:40 PM Subject: Re: [music-dsp] bandpass cutoff frequencies > Hi James, > > my problem was that I didn't know enough about the frequency warping of > digital filters. That's why I feared big errors in my 'analog > calculation'. I don't need a perfect EQ. > Your words about "RBJ peaking filters" sound very interesting. Don't > know them. I'll have a look at them tomorow. > My first plan was to add or subtract LP/BP/HP filtered sound to/from the > original sound in order to keep the untreated parts clean. Especialy > clean of phase distortion. > > Thanks, > > Thomas > > > > > James Chandler Jr schrieb: >> >> Hi Thomas >> >> I have used RBJ's cookbook filters a lot, for many things, for many >> years. >> >> They perform very close to equivalent analog filters at lower Fc, and >> have some deviation from analog filter performance at higher Fc. The >> deviation from 'perfection' at higher Fc's does not make them useless, >> and it is just the way IIR filters seem to behave when Fc approaches >> Nyquist. Am thankful RBJ made them available. >> >> Have read that there are alternate mappings of coefficients that can >> get 'closer to analog' at high frequencies, but dunno if there really >> is a good way to cheat mother nature with high-Fc IIR's. Maybe. >> >> As a rough rule-of-thumb (from my experience), for instance with a >> sample rate of 44.1 KHz-- You get pretty close to analog filter >> expected curves (Fc versus Q) up to about 1 or 2 KHz Fc. They work >> fine all the way up to Nyquist, but get looser up there. >> >> One obvious way to get 'more ideal' filter response at high Fc would >> be to run the filters at a higher samplerate. If you use high-quality >> samplerate conversion on the front end to bump up the samplerate to >> 176.4 KHz (or whatever), run your equalizer, and then high-quality >> convert back down to the original samplerate-- I think all the bands >> in your equalizer (including the high frequency bands) would operate >> very close to their analog equivalents. At the cost of extra CPU time. >> >> Dunno if it is worth the work. A fellow might typically listen to >> audio and guestimate that he needs a 4 dB boost at 1.6 KHz with a >> fifth-octave width, or whatever. But if that doesn't sound right-- He >> will just twiddle the knobs until the sow's ear has been polished as >> close as possible to silk texture. So if an equalizer is not exactly >> scientifically accurate, then this does not often prevent the >> equalizer from being useful . >> >> Of course it is desirable that an EQ's knob settings would have some >> semblance to reality, but even original analog equipment is not >> typically super-precise in the real world. The typical mass-produced >> analog parametric EQ from yesteryear is not likely to give you the >> EXACT frequency, Q and gain that the knobs indicate . What can one >> expect when many important components have tolerances of +/- 5% or >> worse? >> >> Many analog equalizer designs arrange filter banks in parallel, within >> a global feedback loop. That is a good lowest-noise design for an >> analog equalizer. >> >> IMO parallel is not a good configuration for a digital equalizer. If >> attempting to mimic the analog parallel design with IIR filters, in my >> experience it will not perform as good as the equivalent analog circuit. >> >> Noise build-up is not a big problem with digital filters (but noise is >> a constant enemy in analog). You can get much better results by >> putting digital filters in series. If you build a parametric EQ out of >> some RBJ peaking filters wired in series-- Except for a bit of >> 'looseness' at high frequencies, the knob settings will more-closely >> resemble reality than do most analog parametric equalizers. >> >> James Chandler Jr. >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, source code archive, list archive, book reviews, >> dsp links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From jchandjr at bellsouth.net Mon Apr 6 21:41:59 2009 From: jchandjr at bellsouth.net (James Chandler Jr) Date: Mon Apr 6 21:42:53 2009 Subject: [music-dsp] bandpass cutoff frequencies In-Reply-To: <003601c9b715$97025b00$0201a8c0@LuboPC> References: <20090405121451.6C8A94F3D0@ws6-5.us4.outblaze.com><2DEFE53B-1CD4-42DA-9F8C-9B39865CA769@bellsouth.net> <49DA68BE.F9344DC3@netcologne.de> <003601c9b715$97025b00$0201a8c0@LuboPC> Message-ID: <5D81AE32-5294-4076-8CB0-B77E7D570614@bellsouth.net> Hi Lubomir Yes, chaining bandpass filters would not be useful at all. ===== A summed-parallel bank of bandpass filters (with a mixer amplitude knob for each bandpass) would be a very inferior equalizer: EQ_Output = Bandpass1_FilterOut + Bandpass2_FilterOut + ... + BandpassN_FilterOut ===== Adding-subtracting bandpass filters (against the original signal) for boost/cut-- That works fine BUT unless you recalculate the bandpass filter Q for each boost/cut adjustment, it does not give conventional constant-Q behavior. 6 dB band boost would make a wide hill: EQ_Output = Input + Bandpass1_FilterOut -6 dB band cut (given the same filter Q) would make a narrower valley: EQ_Output = Input + (Bandpass1_FilterOut * -0.5) 12 dB band boost (same Q) would make an even wider hill: EQ_Output = Input + (Bandpass1_FilterOut * 3) 12 dB band cut (same Q) would make an even narrower valley: EQ_Output = Input + (Bandpass1_FilterOut * -0.75) ===== RBJ's Peaking filter works like a one-band parametric EQ. If dBGain = 0 dB, the Peaking filter is a straight wire. If dBGain > 0 dB, the Peaking filter is a straight wire with a hump at Fc. If dBGain < 0 dB, the Peaking filter is a straight wire with a dip at Fc. The coefficients are adjusted so that the dB frequency-response plot at +X dBGain is the mirror-image of the dB plot of -X dBGain-- Constant Q behavior. Wiring multiple peaking filters in series-- If all of the dBGains are set to zero, you get a straight wire. If some or all dBGains are non- zero, the frequency-response of each filter contributes to the cumulative output response, but the phase shift of one stage cannot cause accidental phase cancellation or phase reinforcement (in amplitude) against any other stage. ===== One could duplicate the behavior of a Peaking Filter by adding- subtracting a bandpass filter output against its input. BUT you would have to pre-compensate the bandpass filter Q according to the dBGain, to get symmetrical-shaped boost-cut behavior. There is nothing wrong with doing it 'the hard way', except it would take more CPU instructions to get the same behavior as RBJ's Peaking Filter-- You would have to run the bandpass filter, and then multiply the filter output by a gain factor, and then add the scaled output to the input signal. Robert setup his coefficient calculations so you can get this same peaking behavior just by running the filter-- Avoiding the necessity of extra manipulation. Impressive design (as best I can tell). With a series array of Peaking Filters, the biggest brain sweat would be to choose appropriate band-skirt amplitudes to 'dovetail' the bands together in a musically-useful manner, and write a few lines to calculate the optimum Q to get the desired behavior. An optional final tiny bit of brain sweat would be experimentally hand- tuning the final EQ-setting algorithm so that slightly modified Q's are selected at higher frequencies. This might be necessary (from my experience) because IIR filters do not act IDENTICAL to analog filters at higher frequencies, and so if you have certain performance expectations, higher-frequency Q values would need a little bit of algorithmic fudging in the final product. Most IIR's seem to behave somewhat "odd" nearing Nyquist, and this behavior is not a fault of Robert's design as best I can tell. Am not pushy-demanding this solution and am not an expert. Some other approach may be much much better. James Chandler Jr. On Apr 6, 2009, at 8:12 PM, Lubomir Ivanov wrote: > Hello, > > As Didier suggested, chaining bandpasses wouldn't exactly give you > an equalizer like FX. It would closer to the principle used in > crossover systems in my opinion (multiband). The user in this case > will be manipulation the gain of separate bands. > > The main issue here would be the resulted phase-shifts at crossover > points and your design would require a linear/close-to-linear phase > filters if sound quality is of concern. The best way to deal with > this, cpu cycles wise would be with Bessel crossovers. > http://www.rane.com/note147.html > > The approach of modifying a peak filter on the other hand, seems > much more reasonable and will be more efficient too. > > Lubomir I. Ivanov > http://www.tu-varna.bg > > ----- Original Message ----- From: "Thomas Rehaag" > > To: "A discussion list for music-related DSP" > > Sent: Monday, April 06, 2009 11:40 PM > Subject: Re: [music-dsp] bandpass cutoff frequencies > > >> Hi James, >> >> my problem was that I didn't know enough about the frequency >> warping of >> digital filters. That's why I feared big errors in my 'analog >> calculation'. I don't need a perfect EQ. >> Your words about "RBJ peaking filters" sound very interesting. Don't >> know them. I'll have a look at them tomorow. >> My first plan was to add or subtract LP/BP/HP filtered sound to/ >> from the >> original sound in order to keep the untreated parts clean. Especialy >> clean of phase distortion. >> >> Thanks, >> >> Thomas >> >> >> >> >> James Chandler Jr schrieb: >>> >>> Hi Thomas >>> >>> I have used RBJ's cookbook filters a lot, for many things, for many >>> years. >>> >>> They perform very close to equivalent analog filters at lower Fc, >>> and >>> have some deviation from analog filter performance at higher Fc. The >>> deviation from 'perfection' at higher Fc's does not make them >>> useless, >>> and it is just the way IIR filters seem to behave when Fc approaches >>> Nyquist. Am thankful RBJ made them available. >>> >>> Have read that there are alternate mappings of coefficients that can >>> get 'closer to analog' at high frequencies, but dunno if there >>> really >>> is a good way to cheat mother nature with high-Fc IIR's. Maybe. >>> >>> As a rough rule-of-thumb (from my experience), for instance with a >>> sample rate of 44.1 KHz-- You get pretty close to analog filter >>> expected curves (Fc versus Q) up to about 1 or 2 KHz Fc. They work >>> fine all the way up to Nyquist, but get looser up there. >>> >>> One obvious way to get 'more ideal' filter response at high Fc would >>> be to run the filters at a higher samplerate. If you use high- >>> quality >>> samplerate conversion on the front end to bump up the samplerate to >>> 176.4 KHz (or whatever), run your equalizer, and then high-quality >>> convert back down to the original samplerate-- I think all the bands >>> in your equalizer (including the high frequency bands) would operate >>> very close to their analog equivalents. At the cost of extra CPU >>> time. >>> >>> Dunno if it is worth the work. A fellow might typically listen to >>> audio and guestimate that he needs a 4 dB boost at 1.6 KHz with a >>> fifth-octave width, or whatever. But if that doesn't sound right-- >>> He >>> will just twiddle the knobs until the sow's ear has been polished as >>> close as possible to silk texture. So if an equalizer is not exactly >>> scientifically accurate, then this does not often prevent the >>> equalizer from being useful . >>> >>> Of course it is desirable that an EQ's knob settings would have some >>> semblance to reality, but even original analog equipment is not >>> typically super-precise in the real world. The typical mass-produced >>> analog parametric EQ from yesteryear is not likely to give you the >>> EXACT frequency, Q and gain that the knobs indicate . What can >>> one >>> expect when many important components have tolerances of +/- 5% or >>> worse? >>> >>> Many analog equalizer designs arrange filter banks in parallel, >>> within >>> a global feedback loop. That is a good lowest-noise design for an >>> analog equalizer. >>> >>> IMO parallel is not a good configuration for a digital equalizer. If >>> attempting to mimic the analog parallel design with IIR filters, >>> in my >>> experience it will not perform as good as the equivalent analog >>> circuit. >>> >>> Noise build-up is not a big problem with digital filters (but >>> noise is >>> a constant enemy in analog). You can get much better results by >>> putting digital filters in series. If you build a parametric EQ >>> out of >>> some RBJ peaking filters wired in series-- Except for a bit of >>> 'looseness' at high frequencies, the knob settings will more-closely >>> resemble reality than do most analog parametric equalizers. >>> >>> James Chandler Jr. >>> -- >>> dupswapdrop -- the music-dsp mailing list and website: >>> subscription info, FAQ, source code archive, list archive, book >>> reviews, dsp links >>> http://music.columbia.edu/cmc/music-dsp >>> http://music.columbia.edu/mailman/listinfo/music-dsp >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, source code archive, list archive, book >> reviews, dsp links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription > info, FAQ, source code archive, list archive, book reviews, dsp > links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp From martin.eisenberg at udo.edu Tue Apr 7 07:48:35 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Tue Apr 7 09:00:56 2009 Subject: [music-dsp] bandpass cutoff frequencies References: <20090315110001.4E7704442CC@music.columbia.edu><49D20C9E.EC366F3B@netcologne.de><49D3DDEB.8C880805@netcologne.de><000701c9b53e$e3aaef40$0201a8c0@mooncode><49D879BC.C4B0781@netcologne.de><001501c9b5eb$f32fade0$0201a8c0@mooncode> <49DA6340.AF7184C6@netcologne.de> Message-ID: <001d01c9b776$cbae6e00$0201a8c0@mooncode> From: "Thomas Rehaag" > My bad english! Actually you're doing fine, but the potential for confusion grows the closer a word substitution gets to superficially making sense ;) > But I fear that my knowledge about filter theory is even > worse, so that I could hardly follow some steps of your > explanation :( Sorry for overloading you; that should teach me to put the important result before any fancy talk in the future! Then you might even have recognized that makeBP returns the transfer function (from which you can read off the coefs) despite me forgetting to clarify. Anything else unclear, quote it right back to me. The language is that of Maple, a computer algebra system. I can't imagine designing computations without something like it -- at least interactive numerics but much preferably symbolics as well. Check out http://maxima.sourceforge.net/, http://yacas.sourceforge.net/, http://www.scipy.org/, http://www.scilab.org/, http://octave.sourceforge.net/. Martin From martin.eisenberg at udo.edu Tue Apr 7 07:29:02 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Tue Apr 7 09:28:21 2009 Subject: [music-dsp] bandpass cutoff frequencies References: <20090405121451.6C8A94F3D0@ws6-5.us4.outblaze.com><2DEFE53B-1CD4-42DA-9F8C-9B39865CA769@bellsouth.net> <49DA68BE.F9344DC3@netcologne.de> Message-ID: <001801c9b774$10fbda40$0201a8c0@mooncode> From: "Thomas Rehaag" > My first plan was to add or subtract LP/BP/HP filtered > sound to/from the original sound in order to keep the > untreated parts clean. Especialy clean of phase distortion. It wouldn't give you that because the bandpass response is nowhere zero (except at the spectrum endpoints), so no region of the original can stay unaffected by the subtraction. Martin From developer at netcologne.de Tue Apr 7 11:52:36 2009 From: developer at netcologne.de (Thomas Rehaag) Date: Tue Apr 7 12:00:44 2009 Subject: [music-dsp] bandpass cutoff frequencies References: <20090315110001.4E7704442CC@music.columbia.edu><49D20C9E.EC366F3B@netcologne.de><49D3DDEB.8C880805@netcologne.de><000701c9b53e$e3aaef40$0201a8c0@mooncode><49D879BC.C4B0781@netcologne.de><001501c9b5eb$f32fade0$0201a8c0@mooncode> <49DA6340.AF7184C6@netcologne.de> <001d01c9b776$cbae6e00$0201a8c0@mooncode> Message-ID: <49DB76C4.24790D03@netcologne.de> Big thanks to you all for all the helpful responses. I'll try to create a simple test VST plugin with the peak/shelf filters. Best Regards, Thomas From jchandjr at bellsouth.net Tue Apr 7 13:12:35 2009 From: jchandjr at bellsouth.net (James Chandler Jr) Date: Tue Apr 7 14:04:02 2009 Subject: [music-dsp] Vocoder Filter Banks Message-ID: Hi Didier Have never made a vocoder. Perhaps one decision could be whether you want the vocoder 'obvious electronica' versus 'as natural-sounding as such an artificial thing might be designed'? In some 'color organ' spectral-response color lighting controllers, fairly wide dead-bands were intentionally added. To assure that if a certain sound turns on the red light, then hopefully that sound will have minimal effect on the adjacent-band blue or green lights. The dead bands were to hopefully exaggerate the visual effect of the light show. Similarly, PERHAPS if you want a dramatic obvious intelligible artificial vocoder effect, then some fairly discrete (but narrow) dead bands between vocoder bands could be an advantage? Perhaps if you take great care to avoid phase-interference between bands and to smoothly merge the band boundaries, you might get a more- realistic 'hi-fi' effect which is less intelligible? Dunno. Just guessing. There is an old analog bandpass filter strategy of pairing series bandpass filters with slightly-spread Fc, to improve selectivity, flatten the band-top, and steepen band skirts. Fancier steeper designs can use more than 2 series staggered bandpass filters. Some simple math on designing these things was in Don Lancaster's old Active Filter Cookbook but there must be better academic articles somewhere. Regurgitating from memory the basic idea-- Given the desired target Fc, set one bandpass filter to (Fc * X), and set the other bandpass filter to (Fc / X). This symmetrically spreads the pair on each side of the center frequency. For any Q, there is some perfect spread factor X which will give the flattest-widest band top, and the pair will have skirts at least twice as steep as a single bandpass filter (of the same Q). Or you could try a smaller spread to get a slightly-humped Fc. Or a wider spread to get a wider band which may have a slight dip in the center-- A wider steep band with a slight camel-back double-hump response at the top. Mixing a bank of the bandpass pairs would likely sound very artificial, but for a vocoder perhaps that would not be a disadvantage? I've experimented with staggered-pair bandpass RBJ filters several times, and found at least one application where it appears useful. Made a program which has middlin success in picking enough harmonic info out of a mix to guess at the chord progression. It uses a chromatic-tuned filter bank covering about 2 octaves in the midrange and 2 octaves in the bass. About 48 12th octave bands. Would need to load up the source code to recall the exact number or the exact params. Attempting to make each detection band as flat and steep as possible over 1/12 octave, with minimal ringing, the first filter stage is a staggered bandpass pair with Q and spread selected to be as steep/flat as possible over the 1/12 octave. I can't recall how that was calculated. Am weak on math and I forget it instantly. The output of the bandpass pair is fed into a Goertzel algorithm tuned to the frequency of interest. The Goertzel by itself could be fooled by strong harmonics from other pitch centers, and that is why I wanted to attenuate out-of-band audio as much as possible before feeding the Goertzel. It seems to be a pretty selective chromatic filter bank, but of course strong harmonics also register in the filter bank, and there is ugly post-processing code to crudely attempt ignoring obvious harmonics and look for likely fundamentals in the bass/midrange, for the chord detection. On some songs it is surprisingly accurate, and on a few songs it is laughably innacurate. Anyway, that is one instance where the paired-staggered-bandpass seems to be worth its pay . James Chandler Jr. On Apr 6, 2009, at 6:27 PM, Didier Dambrin wrote: > While I too wouldn't say it's a good idea to build an EQ out of > filters in parallel, I've done one using RBJ's bandpasses, and its > flat output is not too far from the dry, better than I expected - > but I still consider it as a "fancy EQ-like effect" rather than a > proper EQ tool. > > I'm now evaluating possibilities for something that really does need > a parallel filterbank: a vocoder. > > One option is to use bandpasses, like RBJ's. Problem here, I'd like > the freedom of moving bands around, not necessarily having the same > distance between them. > So another option would be to build bandpasses out of low/ > highpasses. This would cost a lot of CPU, especially because the > bands should be narrow, for a minimum of 24dB/oct it would already > require 2x2 filters per band. And the slopes not being controllable, > hard to play with the # of bands if they're all too wide. > > > This (old?) article also seem to say that bessel filters would be > better for vocoders, and maybe EQ in parallel too? > http://scitation.aip.org/getabs/servlet/GetabsServlet?prog=normal&id=JASMAN000043000004000803000001&idtype=cvips&gifs=yes From didid at skynet.be Tue Apr 7 14:43:33 2009 From: didid at skynet.be (Didier Dambrin) Date: Tue Apr 7 15:01:39 2009 Subject: [music-dsp] Vocoder Filter Banks In-Reply-To: References: Message-ID: <764C8F382AF54CFABAF01A8FF7797AEF@GOLAMD> I'm trying what you say about 2 bandpasses in a param EQ right now, it does seem to work (produces a nice bell shape), nice trick. I've made a vocoder 6 years ago (FL (& also CM) vocoder), it uses RBJ's bandpasses, and sounded ok enough. I'm pretty sure I can do it better now. I didn't know much about filters and I remember I had to stack 2 bandpasses for each band. I don't know if it's because it produced less dephasing when stacking bands (should have tried inverting each even band), and/or if it's because the shapes were more bell-like, but it sounded much clearer. I'd also think that the modulator's envelope analysis must also play a big role in the clarity. > Hi Didier > > Have never made a vocoder. Perhaps one decision could be whether you > want the vocoder 'obvious electronica' versus 'as natural-sounding as > such an artificial thing might be designed'? > > In some 'color organ' spectral-response color lighting controllers, > fairly wide dead-bands were intentionally added. To assure that if a > certain sound turns on the red light, then hopefully that sound will > have minimal effect on the adjacent-band blue or green lights. The > dead bands were to hopefully exaggerate the visual effect of the light > show. > > Similarly, PERHAPS if you want a dramatic obvious intelligible > artificial vocoder effect, then some fairly discrete (but narrow) dead > bands between vocoder bands could be an advantage? > > Perhaps if you take great care to avoid phase-interference between > bands and to smoothly merge the band boundaries, you might get a more- > realistic 'hi-fi' effect which is less intelligible? Dunno. Just > guessing. > > There is an old analog bandpass filter strategy of pairing series > bandpass filters with slightly-spread Fc, to improve selectivity, > flatten the band-top, and steepen band skirts. Fancier steeper designs > can use more than 2 series staggered bandpass filters. > > Some simple math on designing these things was in Don Lancaster's old > Active Filter Cookbook but there must be better academic articles > somewhere. Regurgitating from memory the basic idea-- Given the > desired target Fc, set one bandpass filter to (Fc * X), and set the > other bandpass filter to (Fc / X). This symmetrically spreads the pair > on each side of the center frequency. > > For any Q, there is some perfect spread factor X which will give the > flattest-widest band top, and the pair will have skirts at least twice > as steep as a single bandpass filter (of the same Q). Or you could try > a smaller spread to get a slightly-humped Fc. Or a wider spread to get > a wider band which may have a slight dip in the center-- A wider steep > band with a slight camel-back double-hump response at the top. > > Mixing a bank of the bandpass pairs would likely sound very > artificial, but for a vocoder perhaps that would not be a disadvantage? > > I've experimented with staggered-pair bandpass RBJ filters several > times, and found at least one application where it appears useful. > > Made a program which has middlin success in picking enough harmonic > info out of a mix to guess at the chord progression. It uses a > chromatic-tuned filter bank covering about 2 octaves in the midrange > and 2 octaves in the bass. About 48 12th octave bands. Would need to > load up the source code to recall the exact number or the exact params. > > Attempting to make each detection band as flat and steep as possible > over 1/12 octave, with minimal ringing, the first filter stage is a > staggered bandpass pair with Q and spread selected to be as steep/flat > as possible over the 1/12 octave. I can't recall how that was > calculated. Am weak on math and I forget it instantly. > > The output of the bandpass pair is fed into a Goertzel algorithm tuned > to the frequency of interest. The Goertzel by itself could be fooled > by strong harmonics from other pitch centers, and that is why I wanted > to attenuate out-of-band audio as much as possible before feeding the > Goertzel. > > It seems to be a pretty selective chromatic filter bank, but of course > strong harmonics also register in the filter bank, and there is ugly > post-processing code to crudely attempt ignoring obvious harmonics and > look for likely fundamentals in the bass/midrange, for the chord > detection. On some songs it is surprisingly accurate, and on a few > songs it is laughably innacurate. > > Anyway, that is one instance where the paired-staggered-bandpass seems > to be worth its pay . > > James Chandler Jr. > > On Apr 6, 2009, at 6:27 PM, Didier Dambrin wrote: > >> While I too wouldn't say it's a good idea to build an EQ out of >> filters in parallel, I've done one using RBJ's bandpasses, and its >> flat output is not too far from the dry, better than I expected - >> but I still consider it as a "fancy EQ-like effect" rather than a >> proper EQ tool. >> >> I'm now evaluating possibilities for something that really does need >> a parallel filterbank: a vocoder. >> >> One option is to use bandpasses, like RBJ's. Problem here, I'd like >> the freedom of moving bands around, not necessarily having the same >> distance between them. >> So another option would be to build bandpasses out of low/ >> highpasses. This would cost a lot of CPU, especially because the >> bands should be narrow, for a minimum of 24dB/oct it would already >> require 2x2 filters per band. And the slopes not being controllable, >> hard to play with the # of bands if they're all too wide. >> >> >> This (old?) article also seem to say that bessel filters would be >> better for vocoders, and maybe EQ in parallel too? >> http://scitation.aip.org/getabs/servlet/GetabsServlet?prog=normal&id=JASMAN000043000004000803000001&idtype=cvips&gifs=yes > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database: 270.11.45/2045 - Release Date: 04/07/09 06:41:00 From stephen.blinkhorn at audiospillage.com Wed Apr 8 20:01:44 2009 From: stephen.blinkhorn at audiospillage.com (Stephen Blinkhorn) Date: Wed Apr 8 20:02:15 2009 Subject: [music-dsp] Survey: How much may your music player know about your listening habits? In-Reply-To: <09d101c9b11c$1c66a760$6501a8c0@DaveUpstairs> References: <49D082C2.3050404@cs.uni-magdeburg.de> <09d101c9b11c$1c66a760$6501a8c0@DaveUpstairs> Message-ID: On 30 Mar 2009, at 03:44, contact wrote: > "GPS position" & "Mouse and keyboard events per minute" - This > appears to > have less to do with whether I have Dark Side of the Moon, or Vampire > Weekend, than it does a yet another tracker. > So it knows where you are AND all your passwords, I don't think so. > Also > proposed are audio recordings of your surroundings, and videos of your > face!! So if I look sad or happy then, er, what exactly? Eventually someone comes to the conclusion that not all music is the same and some people like different music to others. Or perhaps we just find out that 99% of the world is listening to the same old shit as everyone else. Who knows. Stephen From contact at quikquak.com Wed Apr 8 22:02:51 2009 From: contact at quikquak.com (contact) Date: Wed Apr 8 22:03:12 2009 Subject: [music-dsp] Survey: How much may your music player know aboutyour listening habits? References: <49D082C2.3050404@cs.uni-magdeburg.de><09d101c9b11c$1c66a760$6501a8c0@DaveUpstairs> Message-ID: <00ce01c9b8b7$4a2e3d00$6501a8c0@DaveUpstairs> > > On 30 Mar 2009, at 03:44, contact wrote: > >> "GPS position" & "Mouse and keyboard events per minute" - This appears >> to >> have less to do with whether I have Dark Side of the Moon, or Vampire >> Weekend, than it does a yet another tracker. >> So it knows where you are AND all your passwords, I don't think so. Also >> proposed are audio recordings of your surroundings, and videos of your >> face!! So if I look sad or happy then, er, what exactly? > > Eventually someone comes to the conclusion that not all music is the same > and some people like different music to others. Or perhaps we just find > out that 99% of the world is listening to the same old shit as everyone > else. Who knows. > > Stephen 99%? No - your world, maybe. hmmmm. Profit margins and marketing - a circular thing. Did they make people like the stuff so they'll buy more of it? ..."Here, this fusion of Jazz and Drum & Bass is really cool, do you want to know more?"... "Here, buy a phase *blah blah* equaliser" - you can convince your boss, it'll make the music shine through the ages..." But this kind of intrusion (back on topic) is clearly the internet coming of aged. (yes aged). : ) From rossb-lists at audiomulch.com Thu Apr 9 09:42:39 2009 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Thu Apr 9 09:43:02 2009 Subject: [music-dsp] [OT] PortAudio mailing list back on the air Message-ID: <00bb01c9b919$0d701520$0400a8c0@rossmacbook> Hi Peoples Just a quick note to let you know that the PortAudio mailing list has found a new home and is back on the air. We've tried to re-invite everyone from the old list, but knowing how spam filters are these days I thought I'd post a quick message here. You can sign up here: http://music.columbia.edu/mailman/listinfo/portaudio Please spread the news if you know anyone who was missing it. And if you've never heard of PortAudio, you can visit http://www.portaudio.com to get the lowdown. Many thanks go to our old host Radio Free Asia, and our new host Columbia University, and especially to Douglas Repetto for his support. Best wishes Ross. =================================== AudioMulch 2.0 coming soon! http://www.audiomulch.com From music-dsp at zenprobe.com Thu Apr 9 11:05:50 2009 From: music-dsp at zenprobe.com (Dylan Menzies) Date: Thu Apr 9 11:06:22 2009 Subject: [music-dsp] [OT] Extension : IEEE Game Inoovation Conference Message-ID: Please note, the deadline for abstracts and papers has been extended to the 30 April. http://ice-gic.ieee-cesoc.org/ Best regards, Dylan Menzies Audio Technology Chair ICE-GIC09 From bastian.schnuerle at silberstein.de Tue Apr 14 13:08:57 2009 From: bastian.schnuerle at silberstein.de (bastian.schnuerle) Date: Tue Apr 14 13:09:14 2009 Subject: [music-dsp] fft in assmbler (htdm) Message-ID: <50B2AB19-8533-47DD-87FF-9490DAF3B865@silberstein.de> hi, i need to write a fft for assembler (htdm). and i am not sure where to start first, i know what a fft is and i also know the maths behind. what i dont know is what i have to keep in mind to get a nice and useful fft for analysing, running in such a system/environment. i would appreciate any help, hints, links to read or everything else massively .. nice regards, bastian From radarsat1 at gmail.com Tue Apr 14 13:23:12 2009 From: radarsat1 at gmail.com (Stephen Sinclair) Date: Tue Apr 14 13:23:22 2009 Subject: [music-dsp] fft in assmbler (htdm) In-Reply-To: <50B2AB19-8533-47DD-87FF-9490DAF3B865@silberstein.de> References: <50B2AB19-8533-47DD-87FF-9490DAF3B865@silberstein.de> Message-ID: <9b3e2dc20904141023i6aa974c0k9b4a11b5f503b5d3@mail.gmail.com> On Tue, Apr 14, 2009 at 1:08 PM, bastian.schnuerle wrote: > hi, > > i need to write a fft for assembler (htdm). and i am not sure where to start > first, i know what a fft is and i also know the maths behind. what i dont > know is what i have to keep in mind to get a nice and useful fft for > analysing, running in such a system/environment. i would appreciate any > help, hints, links to read or everything else massively .. I would start with the FFTW code and translate it into assembler. (Or use... a compiler. :) http://www.fftw.org/ There is also some quite straight-forward C code in Numerical Recipes in C: http://www.fizyka.umk.pl/nrbook/c12-2.pdf Steve From bogac at bteaudio.com Tue Apr 14 16:50:10 2009 From: bogac at bteaudio.com (Bogac Topaktas) Date: Tue Apr 14 16:51:06 2009 Subject: [music-dsp] fft in assmbler (htdm) Message-ID: <44338030$6f947fd4$51cbcade$@com> Hi Bastian, If you only need advice for hand writing an assembly language implementation for an FFT Algorithm which is already implemented in a high level language then the best way (as indicated in dspGuru's FFT FAQ: http://www.dspguru.com/info/faqs/fftfaq.htm ) is to consult the software/documentation/application notes of the manufacturer of your target processor. In most cases, the most demanding decisions regarding the most efficient FFT implementation on your target processor have already been made by the processor vendor's application engineers. Bogac. -------- Original Message -------- > From: "bastian.schnuerle" > Sent: Tuesday, April 14, 2009 8:09 PM > To: "A music-related DSP discussion list for" > Subject: [music-dsp] fft in assmbler (htdm) > > hi, > > i need to write a fft for assembler (htdm). and i am not sure where > to start first, i know what a fft is and i also know the maths > behind. what i dont know is what i have to keep in mind to get a nice > and useful fft for analysing, running in such a system/environment. i > would appreciate any help, hints, links to read or everything else > massively .. > > nice regards, > > bastian > > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From crueger at informatik.uni-bonn.de Wed Apr 15 05:32:13 2009 From: crueger at informatik.uni-bonn.de (Till Crueger) Date: Wed Apr 15 05:32:30 2009 Subject: [music-dsp] fft in assmbler (htdm) In-Reply-To: <50B2AB19-8533-47DD-87FF-9490DAF3B865@silberstein.de> References: <50B2AB19-8533-47DD-87FF-9490DAF3B865@silberstein.de> Message-ID: On Tue, 14 Apr 2009 19:08:57 +0200, bastian.schnuerle wrote: > hi, > > i need to write a fft for assembler (htdm). and i am not sure where to > start first, i know what a fft is and i also know the maths behind. what > i dont know is what i have to keep in mind to get a nice and useful fft > for analysing, running in such a system/environment. i would appreciate > any help, hints, links to read or everything else massively .. A friend of mine once published a FFT in Assembler in his E-Zine. He uses it for Big-Int arithmetics though. Maybe you can use some of the Ideas from that publication and translate them to your dialect. Here is the link: http://www.awarenetwork.org/etc/beta/ (The FFT is under Big Integer Artithmetics) Hope this helps, Till From douglas at music.columbia.edu Wed Apr 15 07:00:00 2009 From: douglas at music.columbia.edu (douglas repetto) Date: Wed Apr 15 07:00:04 2009 Subject: [music-dsp] [admin] music-dsp FAQ Message-ID: <20090415110000.0D3FF62C3A5@music.columbia.edu> Hi, Just a reminder that if you are new to the list you should read the music-dsp FAQ. It contains answers to both technical _and_ adminstrative questions that often come up on the list. If your question appears in the FAQ it is safe to assume that it has been discussed on the list many times in the past, and you should probably have a look through the list archives before posting your question to the list. http://music.columbia.edu/cmc/music-dsp/musicdspFAQ.html Also of interest to new and not-so-new list members: The music-dsp list archives http://music.columbia.edu/cmc/music-dsp/musicdsparchives.html The music-dsp source code archive http://www.musicdsp.org music-dsp books and reviews http://music.columbia.edu/cmc/music-dsp/dspbooks.html All this and more at: http://music.columbia.edu/cmc/music-dsp Hasta la pasta, douglas (this is an automated message sent out on the 1st and 15th of each month) From developer at netcologne.de Fri Apr 17 07:12:01 2009 From: developer at netcologne.de (Thomas Rehaag) Date: Fri Apr 17 07:12:15 2009 Subject: [music-dsp] 4th order EQ filters References: <50B2AB19-8533-47DD-87FF-9490DAF3B865@silberstein.de> Message-ID: <49E86401.30E9E9ED@netcologne.de> Hi, I just built my first EQ using RBJ's shelf & peak filters. Now I'd like to flatten the peaks. So can anybody please point me to the parameter (Q, w0) calculation for cascading shelf & peak filters to get 4th order butterworth filters? Using the Q params of a low/highpass cascade for the shelf filters seems to work fine, but my naive attempt to use the bandpass params for a peak filter cascade didn't work at all. Best Regards, Thomas From volker.duemke at gmx.de Fri Apr 17 07:35:54 2009 From: volker.duemke at gmx.de (Volker Duemke) Date: Fri Apr 17 07:36:23 2009 Subject: [music-dsp] Detection of unwanted Sounds in Speech Message-ID: <933EBEF3-2706-42B9-9FBF-A206826E7216@gmx.de> Hi everyone, i am looking for a tool, which allows me to detect unwanted sounds in natural spontaneous speech automatically. By unwanted sounds i mean hesitations and disfluencies. These are unfluent utterances like repetitions or false starts and nonverbal productions like `uh' and `uhm' or breathing sounds. In principle all that sounds that occur in normal conversations, but dont exist in read speech. Anyone ever heard of a software like this? Ok, its not music-related. Sorry for that. Perhaps anyone know a speech-related discussion list. Best Regards Volker From martin.eisenberg at udo.edu Fri Apr 17 08:57:30 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Fri Apr 17 08:55:36 2009 Subject: [music-dsp] 4th order EQ filters References: <50B2AB19-8533-47DD-87FF-9490DAF3B865@silberstein.de> <49E86401.30E9E9ED@netcologne.de> Message-ID: <001901c9bf5c$14d57640$0201a8c0@mooncode> From: "Thomas Rehaag" > I just built my first EQ using RBJ's shelf & peak filters. > Now I'd like to flatten the peaks. So can anybody please > point me to the parameter (Q, w0) calculation for cascading > shelf & peak filters to get 4th order butterworth filters? http://www.claysturner.com/dsp/Butterworth%20Filter%20Formulae.pd f Holters and Z?lzer, Graphic Equalizer Design Using Higher-Order Recursive Filters, DAFx '06 http://www.dafx.ca/proceedings/papers/p_037.pdf Martin From dgm at baykitty.com Fri Apr 17 13:38:20 2009 From: dgm at baykitty.com (Don Morgan (E-mail)) Date: Fri Apr 17 13:38:30 2009 Subject: [music-dsp] [phase discontinuities in wave files] Message-ID: <31F0A659-2CE1-4D39-A987-2B6DEF677E6A@baykitty.com> I need to process wave files that have numerous phase discontinuities in each channel. The files are really splices of audio streams. How can I get rid of the pops and snaps? I was going to apply a brick wall filter but I was reminded that these will only keep the discontinuity artifacts in band. I need to remove them entirely. Can someone point me to a link or reference on this? Thank you, Don Morgan From rbj at audioimagination.com Fri Apr 17 14:16:36 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Fri Apr 17 14:21:11 2009 Subject: [music-dsp] [phase discontinuities in wave files] Message-ID: <20090417181636.DA37454813E@ws6-6.us4.outblaze.com> > ----- Original Message ----- > From: "Don Morgan (E-mail)" > To: "A discussion list for music-related DSP" > Subject: [music-dsp] [phase discontinuities in wave files] > Date: Fri, 17 Apr 2009 10:38:20 -0700 > > > I need to process wave files that have numerous phase discontinuities in > each channel. The files are really splices of audio streams. > How can I get rid of the pops and snaps? crossfade? you also might be able to "nudge" the audio on the right hand (the audio that you are fading *to*) to the left or right a little to make the splice better. you would cross-correlate the audio on the left (in the region of the splice) to an equal sized segment of the audio on the right. the lag or shift that maximizes the cross-correlation would be the relative lag you would use for crossfading. > I was going to apply a brick wall filter but I was reminded that these will > only keep the discontinuity artifacts in band. I need to remove them > entirely. Can someone point me to a link or reference on this? dunno a reference, but this is what audio guys do with editing software all the time. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From dgm at baykitty.com Fri Apr 17 14:34:32 2009 From: dgm at baykitty.com (Don Morgan (E-mail)) Date: Fri Apr 17 14:34:52 2009 Subject: [music-dsp] [phase discontinuities in wave files] In-Reply-To: <20090417181636.DA37454813E@ws6-6.us4.outblaze.com> References: <20090417181636.DA37454813E@ws6-6.us4.outblaze.com> Message-ID: <6FD005F2-CD6D-4669-B626-5E4BCBDFCA2C@baykitty.com> What if I set a 'big step' increment that will detect the presence of a phase discontinuity by testing for changes between samples that violate a predetermined value (a variable I could manipulate) then replacing the difference with that same incremental value all the while filtering the streams to 22K (brickwall). The phase is the thing that changes. If you imagine an oscillator whose output is WAV'd and spliced at random intervals you would see what I meant. Thanks for what you have given me so far, I will look into that. Don On 2009, Apr, 17, at 11:16 AM, robert bristow-johnson wrote: > >> ----- Original Message ----- >> From: "Don Morgan (E-mail)" >> To: "A discussion list for music-related DSP" > > >> Subject: [music-dsp] [phase discontinuities in wave files] >> Date: Fri, 17 Apr 2009 10:38:20 -0700 >> >> >> I need to process wave files that have numerous phase >> discontinuities in >> each channel. The files are really splices of audio streams. >> How can I get rid of the pops and snaps? > > crossfade? you also might be able to "nudge" the audio on the right > hand (the audio that you are fading *to*) to the left or right a > little to make the splice better. you would cross-correlate the > audio on the left (in the region of the splice) to an equal sized > segment of the audio on the right. the lag or shift that maximizes > the cross-correlation would be the relative lag you would use for > crossfading. > >> I was going to apply a brick wall filter but I was reminded that >> these will >> only keep the discontinuity artifacts in band. I need to remove them >> entirely. Can someone point me to a link or reference on this? > > dunno a reference, but this is what audio guys do with editing > software all the time. > > > -- > > r b-j rbj@audioimagination.com > > "Imagination is more important than knowledge." > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book > reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From czhenry at gmail.com Fri Apr 17 14:48:26 2009 From: czhenry at gmail.com (Charles Henry) Date: Fri Apr 17 14:48:38 2009 Subject: [music-dsp] [phase discontinuities in wave files] In-Reply-To: <6FD005F2-CD6D-4669-B626-5E4BCBDFCA2C@baykitty.com> References: <20090417181636.DA37454813E@ws6-6.us4.outblaze.com> <6FD005F2-CD6D-4669-B626-5E4BCBDFCA2C@baykitty.com> Message-ID: <518fe7b20904171148q292cfa29kdb20a38ae73566a6@mail.gmail.com> I had an idea for approaching this kind of problem. You could perhaps detect the phase discontinuities in the complex signal a(t)+i*b(t) where b(t) is the Hilbert transform of a(t) phase(t)=atan( b(t)/a(t) ) Once the detection is complete, the overall difference in phase can be distributed over a longer period of time, making it impossible to detect. As long as the amplitudes are the same, before and after the discontinuity, it should be possible to just smooth out the phase. Chuck On Fri, Apr 17, 2009 at 1:34 PM, Don Morgan (E-mail) wrote: > What if I set a 'big step' increment that will detect the presence of a > phase discontinuity by testing for changes between samples that violate a > predetermined value (a variable I could manipulate) then replacing the > difference with that same incremental value all the while filtering the > streams to 22K (brickwall). > The phase is the thing that changes. If you imagine an oscillator whose > output is WAV'd and spliced at random intervals you would see what I meant. > > Thanks for what you have given me so far, I will look into that. > Don > > On 2009, Apr, 17, at 11:16 AM, robert bristow-johnson wrote: > >> >>> ----- Original Message ----- >>> From: "Don Morgan (E-mail)" >>> To: "A discussion list for music-related DSP" >>> >>> Subject: [music-dsp] [phase discontinuities in wave files] >>> Date: Fri, 17 Apr 2009 10:38:20 -0700 >>> >>> >>> I need to process wave files that have numerous phase discontinuities in >>> each channel. The files are really splices of audio streams. >>> How can I get rid of the pops and snaps? >> >> crossfade? ?you also might be able to "nudge" the audio on the right hand >> (the audio that you are fading *to*) to the left or right a little to make >> the splice better. ?you would cross-correlate the audio on the left (in the >> region of the splice) to an equal sized segment of the audio on the right. >> ?the lag or shift that maximizes the cross-correlation would be the relative >> lag you would use for crossfading. >> >>> I was going to apply a brick wall filter but I was reminded that these >>> will >>> only keep the discontinuity artifacts in band. I need to remove them >>> entirely. Can someone point me to a link or reference on this? >> >> dunno a reference, but this is what audio guys do with editing software >> all the time. >> >> >> -- >> >> r b-j ? ? ? ? ? ? ? ? ?rbj@audioimagination.com >> >> "Imagination is more important than knowledge." >> >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, source code archive, list archive, book reviews, >> dsp links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp >> > > -- > dupswapdrop -- the music-dsp mailing list and website:subscription info, > FAQ, source code archive, list archive, book reviews, dsp > linkshttp://music.columbia.edu/cmc/music-dsphttp://music.columbia.edu/mailman/listinfo/music-dsp > From dgm at baykitty.com Fri Apr 17 14:51:26 2009 From: dgm at baykitty.com (Don Morgan (E-mail)) Date: Fri Apr 17 14:53:35 2009 Subject: [music-dsp] [phase discontinuities in wave files] In-Reply-To: <518fe7b20904171148q292cfa29kdb20a38ae73566a6@mail.gmail.com> References: <20090417181636.DA37454813E@ws6-6.us4.outblaze.com> <6FD005F2-CD6D-4669-B626-5E4BCBDFCA2C@baykitty.com> <518fe7b20904171148q292cfa29kdb20a38ae73566a6@mail.gmail.com> Message-ID: <12C380F0-31B9-46BF-B0D0-6D37F31FF38E@baykitty.com> That is an interesting idea. Thanks, Don =B7=A2=D7=D4=CE=D2=B5=C4 iPhone =D4=DA 2009-4-17=A3=AC=C9=CF=CE=E711:48=A3=ACCharles Henry = =D0=B4=B5=BD=A3=BA > I had an idea for approaching this kind of problem. > > You could perhaps detect the phase discontinuities in the complex > signal a(t)+i*b(t) where b(t) is the Hilbert transform of a(t) > > phase(t)=3Datan( b(t)/a(t) ) > > Once the detection is complete, the overall difference in phase can be > distributed over a longer period of time, making it impossible to > detect. As long as the amplitudes are the same, before and after the > discontinuity, it should be possible to just smooth out the phase. > > Chuck > > On Fri, Apr 17, 2009 at 1:34 PM, Don Morgan (E-mail) =20 > wrote: >> What if I set a 'big step' increment that will detect the presence =20= >> of a >> phase discontinuity by testing for changes between samples that =20 >> violate a >> predetermined value (a variable I could manipulate) then replacing =20= >> the >> difference with that same incremental value all the while filtering =20= >> the >> streams to 22K (brickwall). >> The phase is the thing that changes. If you imagine an oscillator =20 >> whose >> output is WAV'd and spliced at random intervals you would see what =20= >> I meant. >> >> Thanks for what you have given me so far, I will look into that. >> Don >> >> On 2009, Apr, 17, at 11:16 AM, robert bristow-johnson wrote: >> >>> >>>> ----- Original Message ----- >>>> From: "Don Morgan (E-mail)" >>>> To: "A discussion list for music-related DSP" >>>> >>>> Subject: [music-dsp] [phase discontinuities in wave files] >>>> Date: Fri, 17 Apr 2009 10:38:20 -0700 >>>> >>>> >>>> I need to process wave files that have numerous phase =20 >>>> discontinuities in >>>> each channel. The files are really splices of audio streams. >>>> How can I get rid of the pops and snaps? >>> >>> crossfade? you also might be able to "nudge" the audio on the =20 >>> right hand >>> (the audio that you are fading *to*) to the left or right a little =20= >>> to make >>> the splice better. you would cross-correlate the audio on the =20 >>> left (in the >>> region of the splice) to an equal sized segment of the audio on =20 >>> the right. >>> the lag or shift that maximizes the cross-correlation would be =20 >>> the relative >>> lag you would use for crossfading. >>> >>>> I was going to apply a brick wall filter but I was reminded that =20= >>>> these >>>> will >>>> only keep the discontinuity artifacts in band. I need to remove =20 >>>> them >>>> entirely. Can someone point me to a link or reference on this? >>> >>> dunno a reference, but this is what audio guys do with editing =20 >>> software >>> all the time. >>> >>> >>> -- >>> >>> r b-j rbj@audioimagination.com >>> >>> "Imagination is more important than knowledge." >>> >>> -- >>> dupswapdrop -- the music-dsp mailing list and website: >>> subscription info, FAQ, source code archive, list archive, book =20 >>> reviews, >>> dsp links >>> http://music.columbia.edu/cmc/music-dsp >>> http://music.columbia.edu/mailman/listinfo/music-dsp >>> >> >> -- >> dupswapdrop -- the music-dsp mailing list and website:subscription =20= >> info, >> FAQ, source code archive, list archive, book reviews, dsp >> linkshttp://music.columbia.edu/cmc/music-dsphttp://=20 >> music.columbia.edu/mailman/listinfo/music-dsp >> > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book =20 > reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From dgm at baykitty.com Fri Apr 17 15:25:28 2009 From: dgm at baykitty.com (Don Morgan (E-mail)) Date: Fri Apr 17 15:25:43 2009 Subject: [music-dsp] [phase discontinuities in wave files] In-Reply-To: <6FD005F2-CD6D-4669-B626-5E4BCBDFCA2C@baykitty.com> References: <20090417181636.DA37454813E@ws6-6.us4.outblaze.com> <6FD005F2-CD6D-4669-B626-5E4BCBDFCA2C@baykitty.com> Message-ID: <84DA99B7-C924-432E-9035-1E12A0113B80@baykitty.com> I have been corrected, It audio is not an oscillator- it could be music or dialogue or whatever. The splices will not change between sources however, that is if it is a song playing, the splice will occur within the same song, the same applies to the dialogue or whatever. Don So perhaps teh On 2009, Apr, 17, at 11:34 AM, Don Morgan (E-mail) wrote: > What if I set a 'big step' increment that will detect the presence > of a phase discontinuity by testing for changes between samples that > violate a predetermined value (a variable I could manipulate) then > replacing the difference with that same incremental value all the > while filtering the streams to 22K (brickwall). > The phase is the thing that changes. If you imagine an oscillator > whose output is WAV'd and spliced at random intervals you would see > what I meant. > > Thanks for what you have given me so far, I will look into that. > Don > > On 2009, Apr, 17, at 11:16 AM, robert bristow-johnson wrote: > >> >>> ----- Original Message ----- >>> From: "Don Morgan (E-mail)" >>> To: "A discussion list for music-related DSP" >> > >>> Subject: [music-dsp] [phase discontinuities in wave files] >>> Date: Fri, 17 Apr 2009 10:38:20 -0700 >>> >>> >>> I need to process wave files that have numerous phase >>> discontinuities in >>> each channel. The files are really splices of audio streams. >>> How can I get rid of the pops and snaps? >> >> crossfade? you also might be able to "nudge" the audio on the >> right hand (the audio that you are fading *to*) to the left or >> right a little to make the splice better. you would cross- >> correlate the audio on the left (in the region of the splice) to an >> equal sized segment of the audio on the right. the lag or shift >> that maximizes the cross-correlation would be the relative lag you >> would use for crossfading. >> >>> I was going to apply a brick wall filter but I was reminded that >>> these will >>> only keep the discontinuity artifacts in band. I need to remove them >>> entirely. Can someone point me to a link or reference on this? >> >> dunno a reference, but this is what audio guys do with editing >> software all the time. >> >> >> -- >> >> r b-j rbj@audioimagination.com >> >> "Imagination is more important than knowledge." >> >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, source code archive, list archive, book >> reviews, dsp links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp >> > > -- > dupswapdrop -- the music-dsp mailing list and website:subscription > info, FAQ, source code archive, list archive, book reviews, dsp linkshttp://music.columbia.edu/cmc/music-dsphttp://music.columbia.edu/mailman/listinfo/music-dsp > From martin.eisenberg at udo.edu Fri Apr 17 18:24:44 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Fri Apr 17 18:22:48 2009 Subject: [music-dsp] [phase discontinuities in wave files] References: <31F0A659-2CE1-4D39-A987-2B6DEF677E6A@baykitty.com> Message-ID: <001801c9bfab$53202c20$0201a8c0@mooncode> From: "Don Morgan (E-mail)" > I need to process wave files that have numerous phase > discontinuities in each channel. The files are really splices > of audio streams.How can I get rid of the pops and snaps? You might extrapolate each signal part across the splice (forward and backward, resp.), then fade out the extrapolations and mix in with the source material. Unlike a simple crossfade this would preserve stream length. An extrapolation method that comes to mind is to fit an LPC model to a block with one end on the splice and let the LP filter ring out after priming it with the error signal. Regarding literature, look for AR vinyl click removal. Or start with this ebook, which also has other methods: http://www-sigproc.eng.cam.ac.uk/~sjg/springer/index.html Martin From dgm at baykitty.com Fri Apr 17 18:28:54 2009 From: dgm at baykitty.com (Don Morgan (E-mail)) Date: Fri Apr 17 18:29:04 2009 Subject: [music-dsp] [phase discontinuities in wave files] In-Reply-To: <001801c9bfab$53202c20$0201a8c0@mooncode> References: <31F0A659-2CE1-4D39-A987-2B6DEF677E6A@baykitty.com> <001801c9bfab$53202c20$0201a8c0@mooncode> Message-ID: <614F0CC0-59A8-4F41-87CB-3DCD4FB45564@baykitty.com> Thank you, sir. Don On 2009, Apr, 17, at 3:24 PM, Martin Eisenberg wrote: > From: "Don Morgan (E-mail)" > >> I need to process wave files that have numerous phase >> discontinuities in each channel. The files are really splices >> of audio streams.How can I get rid of the pops and snaps? > > You might extrapolate each signal part across the splice (forward > and backward, resp.), then fade out the extrapolations and mix in > with the source material. Unlike a simple crossfade this would > preserve stream length. An extrapolation method that comes to > mind is to fit an LPC model to a block with one end on the splice > and let the LP filter ring out after priming it with the error > signal. > > Regarding literature, look for AR vinyl click removal. Or start > with this ebook, which also has other methods: > http://www-sigproc.eng.cam.ac.uk/~sjg/springer/index.html > > > Martin > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book > reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From vesa.norilo at saunalahti.fi Sat Apr 18 07:29:12 2009 From: vesa.norilo at saunalahti.fi (Vesa Norilo) Date: Sat Apr 18 07:28:58 2009 Subject: [music-dsp] fft in assmbler (htdm) In-Reply-To: <50B2AB19-8533-47DD-87FF-9490DAF3B865@silberstein.de> References: <50B2AB19-8533-47DD-87FF-9490DAF3B865@silberstein.de> Message-ID: <49E9B988.1050103@saunalahti.fi> Hi Bastian, The most concise and clear FFT algorithm I've seen online is on the discussion page for the wikipedia article on Cooley Tukey FFT. http://en.wikipedia.org/wiki?title=Talk:Cooley-Tukey_FFT_algorithm Scroll down for "example". It's written in Python, and of course optimized for clarity rather than speed. It is, however, a very good starting point for understanding a radix-2 FFT. Be sure to optimize away any symmetry there is in the math (transforming a real signal makes half of the transform redunant, also there's a lot of zeroes initially for the imaginary parts). Tuning it all to your architecture is a different matter altogether. While FFTW is very fast on the platforms it's implemented on, I'm not sure if a naive port to a DSP chip without extensive hand tuning is worth the effort. With regard to FFTW, I suggest looking into their methodology of transform code generation instead of porting the results. Vesa > hi, > > i need to write a fft for assembler (htdm). and i am not sure where to > start first, i know what a fft is and i also know the maths behind. > what i dont know is what i have to keep in mind to get a nice and > useful fft for analysing, running in such a system/environment. i > would appreciate any help, hints, links to read or everything else > massively .. > > nice regards, > > bastian > > > -- > dupswapdrop -- the music-dsp mailing list and website:subscription > info, FAQ, source code archive, list archive, book reviews, dsp > linkshttp://music.columbia.edu/cmc/music-dsphttp://music.columbia.edu/mailman/listinfo/music-dsp > From rbj at audioimagination.com Sat Apr 18 13:59:39 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sat Apr 18 13:59:52 2009 Subject: [music-dsp] fft in assmbler (htdm) Message-ID: <20090418175939.64EBD9ECC8@ws6-2.us4.outblaze.com> well, it's neither assembly nor C++, but a quarter century ago i wrote this little Radix-2 FFT and iFFT program in C (below) that i think is transparent. it isn't highly optimized but doesn't do recursive calls and i tried to identify when multiplication by 1 or j was happening so to avoid that chore (nowadays it doesn't make much difference, you can multiply numbers as quickly as moving them). anyway, if you can unwrap the lines of C code, this should spell out what you might need to do to write a radix-2 FFT in the asm language you are stuck with. if you want, i can look up a corresponding piece of code for the old 68K assembly, but i wouldn't expect it to translate any better. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." /* A set of utility programs to compute the Fast Fourier Transform (FFT): N-1 X[k] = SUM { x[n] exp(-j 2pi nk/N) } n=0 and inverse Fast Fourier Transform (iFFT): N-1 x[n] = 1/N SUM { X[k] exp(+j 2pi nk/N) } k=0 To speed things up, multiplication by 1 and j are avoided. The input, x[], is an array of complex numbers (pairs of doubles) of length N = 2^p. The calling program supplies p = log2(N) not the array length, N. The output is placed in BIT REVERSED order in x[]. Call bitreverse(x, p) to swap back to normal order, if needed. However, iFFT(X, p, stbl) requires its input, X[], to be in bit reversed order making bit reversing unnecessary in some cases, such as convolution. stbl is an array of doubles of length N/4 containing the sine function from 0 to pi/2 used to compute the FFT. Call sintable(stbl, p) ONLY ONCE before either FFT(x, p, stbl) or iFFT(X, p, stbl) to set up a sin table for FFT computation. Written in THINK C by Robert Bristow-Johnson. copyright (c) 1985 Robert Bristow-Johnson. */ #if 0 #include "complex.h" #else #include #define PI 3.141592653589793 typedef struct { double real; double imag; } complex; #define Re(z) (z).real #define Im(z) (z).imag #endif void FFT(complex *x, int p, double *stbl); void iFFT(complex *X, int p, double *stbl); void sin_table(double *stbl, int p); void bit_reverse(register complex *x, int p); void FFT(complex *x, int p, double *stbl) { long size; register long length, step, stepsize, end; register complex *top, *bottom; /* top & bottom of FFT butterfly */ complex temp; size = 1L<<(p-2); end = (long)x + 4*sizeof(temp)*size; length = size; stepsize = 1; while (length >= 1) { top = x; while ((long)top < end) { bottom = top + 2*length; Re(temp) = Re(*top) - Re(*bottom); /* butterfly: twiddle = 1 */ Im(temp) = Im(*top) - Im(*bottom); Re(*top) += Re(*bottom); Im(*top) += Im(*bottom); *bottom = temp; top++; bottom++; for (step=stepsize; step>= 1; stepsize <<= 1; } top = x; bottom = x + 1; while ((long)top < end) { Re(temp) = Re(*top) - Re(*bottom); /* butterfly: twiddle = 1 */ Im(temp) = Im(*top) - Im(*bottom); Re(*top) += Re(*bottom); Im(*top) += Im(*bottom); *bottom = temp; top += 2; bottom += 2; } } void iFFT(complex *X, int p, double *stbl) { long size; register long length, step, stepsize, end; double scale; register complex *top, *bottom; /* top & bottom of FFT butterfly */ complex temp; size = 1L<<(p-2); end = (long)X + 4*sizeof(temp)*size; scale = 0.25/(double)size; top = X; bottom = X + 1; while ((long)top < end) { Re(temp) = (Re(*top) - Re(*bottom))*scale; /* butterfly: twiddle = 1/N */ Im(temp) = (Im(*top) - Im(*bottom))*scale; Re(*top) = (Re(*top) + Re(*bottom))*scale; Im(*top) = (Im(*top) + Im(*bottom))*scale; *bottom = temp; top += 2; bottom += 2; } length = 1; stepsize = size; while (stepsize >= 1) { top = X; while ((long)top < end) { bottom = top + 2*length; temp = *bottom; /* butterfly: twiddle = 1 */ Re(*bottom) = Re(*top) - Re(temp); Im(*bottom) = Im(*top) - Im(temp); Re(*top) += Re(temp); Im(*top) += Im(temp); top++; bottom++; for (step=stepsize; step>= 1; } } void sin_table(double *stbl, int p) { register long size, i; double theta; size = 1L<<(p-2); theta = PI/(2.0*(double)size); for (i=0; i0; count--) { r <<= 1; r += (i & 0x00000001L); i >>= 1; } if (r > k) { temp = x[r]; x[r] = x[k]; x[k] = temp; } } } From bastian.schnuerle at silberstein.de Sat Apr 18 14:38:07 2009 From: bastian.schnuerle at silberstein.de (bastian.schnuerle) Date: Sat Apr 18 14:38:36 2009 Subject: [music-dsp] fft in assmbler (htdm) In-Reply-To: <20090418175939.64EBD9ECC8@ws6-2.us4.outblaze.com> References: <20090418175939.64EBD9ECC8@ws6-2.us4.outblaze.com> Message-ID: <1E4AFBD3-19C4-4659-93BD-52D5DE3286C7@silberstein.de> thanks robert, thanks vesa, thank you very much. from your two posts i am getting really excited to check this on the hardware. i was wrong to write htdm, this is their old architecture. it is tdm and their processor is an motorola 56k dsp. so i am a bit confused, because i thought the XXk is signing some kind of memory amount available and now you robert are writing you got some code for the old 64k architecture. ?? or does this mean less memory available, faster processing ? have a great day all, bastian Am 18.04.2009 um 19:59 schrieb robert bristow-johnson: > > > > well, it's neither assembly nor C++, but a quarter century ago i > wrote this little Radix-2 FFT and iFFT program in C (below) that i > think is transparent. it isn't highly optimized but doesn't do > recursive calls and i tried to identify when multiplication by 1 or > j was happening so to avoid that chore (nowadays it doesn't make > much difference, you can multiply numbers as quickly as moving > them). anyway, if you can unwrap the lines of C code, this should > spell out what you might need to do to write a radix-2 FFT in the > asm language you are stuck with. if you want, i can look up a > corresponding piece of code for the old 68K assembly, but i > wouldn't expect it to translate any better. > > > -- > > r b-j rbj@audioimagination.com > > "Imagination is more important than knowledge." > > > > /* > A set of utility programs to compute the Fast Fourier Transform > (FFT): > > N-1 > X[k] = SUM { x[n] exp(-j 2pi nk/N) } > n=0 > > and inverse Fast Fourier Transform (iFFT): > > N-1 > x[n] = 1/N SUM { X[k] exp(+j 2pi nk/N) } > k=0 > > To speed things up, multiplication by 1 and j are avoided. The > input, x[], is an array of > complex numbers (pairs of doubles) of length N = 2^p. The > calling program supplies > p = log2(N) not the array length, N. The output is placed in > BIT REVERSED order in x[]. > Call bitreverse(x, p) to swap back to normal order, if needed. > However, iFFT(X, p, stbl) > requires its input, X[], to be in bit reversed order making bit > reversing unnecessary in > some cases, such as convolution. stbl is an array of doubles > of length N/4 containing the > sine function from 0 to pi/2 used to compute the FFT. Call > sintable(stbl, p) ONLY ONCE > before either FFT(x, p, stbl) or iFFT(X, p, stbl) to set up a > sin table for FFT computation. > > Written in THINK C by Robert Bristow-Johnson. > > copyright (c) 1985 Robert Bristow-Johnson. > */ > > #if 0 > > #include "complex.h" > > #else > > #include > > #define PI 3.141592653589793 > > typedef struct > { > double real; > double imag; > } complex; > > #define Re(z) (z).real > #define Im(z) (z).imag > > #endif > > void FFT(complex *x, int p, double *stbl); > void iFFT(complex *X, int p, double *stbl); > void sin_table(double *stbl, int p); > void bit_reverse(register complex *x, int p); > > > void FFT(complex *x, int p, double *stbl) > { > long size; > register long length, step, stepsize, end; > register complex *top, *bottom; / > * top & bottom of FFT butterfly */ > complex temp; > > size = 1L<<(p-2); > end = (long)x + 4*sizeof(temp)*size; > > length = size; > stepsize = 1; > while (length >= 1) > { > top = x; > while ((long)top < end) > { > bottom = top + 2*length; > > Re(temp) = Re(*top) - Re(*bottom); / > * butterfly: twiddle = 1 */ > Im(temp) = Im(*top) - Im(*bottom); > Re(*top) += Re(*bottom); > Im(*top) += Im(*bottom); > *bottom = temp; > top++; > bottom++; > > for (step=stepsize; step { > Re(temp) = Re(*top) - Re(*bottom); /* > butterfly: twiddle = exp(-j*theta) */ > Im(temp) = Im(*top) - Im(*bottom); > Re(*top) += Re(*bottom); > Im(*top) += Im(*bottom); > Re(*bottom) = Re(temp)*stbl[size - step] + Im(temp) > *stbl[step]; > Im(*bottom) = Im(temp)*stbl[size - step] - Re(temp) > *stbl[step]; > top++; > bottom++; > } > > Re(temp) = Im(*top) - Im(*bottom); / > * butterfly: twiddle = -j */ > Im(temp) = Re(*bottom) - Re(*top); > Re(*top) += Re(*bottom); > Im(*top) += Im(*bottom); > *bottom = temp; > top++; > bottom++; > > for (step=stepsize; step { > Re(temp) = Im(*top) - Im(*bottom); /* > butterfly: twiddle = -j*exp(-j*theta) */ > Im(temp) = Re(*bottom) - Re(*top); > Re(*top) += Re(*bottom); > Im(*top) += Im(*bottom); > Re(*bottom) = Re(temp)*stbl[size - step] + Im(temp) > *stbl[step]; > Im(*bottom) = Im(temp)*stbl[size - step] - Re(temp) > *stbl[step]; > top++; > bottom++; > } > top = bottom; > } > length >>= 1; > stepsize <<= 1; > } > > top = x; > bottom = x + 1; > while ((long)top < end) > { > Re(temp) = Re(*top) - Re(*bottom); / > * butterfly: twiddle = 1 */ > Im(temp) = Im(*top) - Im(*bottom); > Re(*top) += Re(*bottom); > Im(*top) += Im(*bottom); > *bottom = temp; > top += 2; > bottom += 2; > } > } > > > void iFFT(complex *X, int p, double *stbl) > { > long size; > register long length, step, stepsize, end; > double scale; > register complex *top, *bottom; / > * top & bottom of FFT butterfly */ > complex temp; > > size = 1L<<(p-2); > end = (long)X + 4*sizeof(temp)*size; > > scale = 0.25/(double)size; > top = X; > bottom = X + 1; > while ((long)top < end) > { > Re(temp) = (Re(*top) - Re(*bottom))*scale; / > * butterfly: twiddle = 1/N */ > Im(temp) = (Im(*top) - Im(*bottom))*scale; > Re(*top) = (Re(*top) + Re(*bottom))*scale; > Im(*top) = (Im(*top) + Im(*bottom))*scale; > *bottom = temp; > top += 2; > bottom += 2; > } > > length = 1; > stepsize = size; > while (stepsize >= 1) > { > top = X; > while ((long)top < end) > { > bottom = top + 2*length; > > temp = *bottom; / > * butterfly: twiddle = 1 */ > Re(*bottom) = Re(*top) - Re(temp); > Im(*bottom) = Im(*top) - Im(temp); > Re(*top) += Re(temp); > Im(*top) += Im(temp); > top++; > bottom++; > > for (step=stepsize; step { /* > butterfly: twiddle = exp(+j*theta) */ > Re(temp) = Re(*bottom)*stbl[size - step] - Im > (*bottom)*stbl[step]; > Im(temp) = Im(*bottom)*stbl[size - step] + Re > (*bottom)*stbl[step]; > Re(*bottom) = Re(*top) - Re(temp); > Im(*bottom) = Im(*top) - Im(temp); > Re(*top) += Re(temp); > Im(*top) += Im(temp); > top++; > bottom++; > } > > Re(temp) = -Im(*bottom); / > * butterfly: twiddle = +j */ > Im(temp) = Re(*bottom); > Re(*bottom) = Re(*top) - Re(temp); > Im(*bottom) = Im(*top) - Im(temp); > Re(*top) += Re(temp); > Im(*top) += Im(temp); > top++; > bottom++; > > for (step=stepsize; step { /* > butterfly: twiddle = +j*exp(+j*theta) */ > Re(temp) = -Im(*bottom)*stbl[size - step] - Re > (*bottom)*stbl[step]; > Im(temp) = Re(*bottom)*stbl[size - step] - Im > (*bottom)*stbl[step]; > Re(*bottom) = Re(*top) - Re(temp); > Im(*bottom) = Im(*top) - Im(temp); > Re(*top) += Re(temp); > Im(*top) += Im(temp); > top++; > bottom++; > } > top = bottom; > } > length <<= 1; > stepsize >>= 1; > } > } > > > void sin_table(double *stbl, int p) > { > register long size, i; > double theta; > > size = 1L<<(p-2); > theta = PI/(2.0*(double)size); > > for (i=0; i { > stbl[i] = sin(theta*(double)i); > } > } > > > void bit_reverse(register complex *x, int p) > { > complex temp; > register long k, i, r, size, count; > > size = (1L< for (k=1L; k { > i = k; > r = 0; > for (count=p; count>0; count--) > { > r <<= 1; > r += (i & 0x00000001L); > i >>= 1; > } > if (r > k) > { > temp = x[r]; > x[r] = x[k]; > x[k] = temp; > } > } > } > > > > > > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book > reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From bogac at bteaudio.com Sat Apr 18 15:28:02 2009 From: bogac at bteaudio.com (Bogac Topaktas) Date: Sat Apr 18 15:28:57 2009 Subject: [music-dsp] fft in assmbler (htdm) Message-ID: <76ca4e73$279d5dc8$2861d041$@com> Isn't there a tightly coded (ASM) and royalty free FFT algorithm implementation in Freescale/Motorola DSP56xxx EVMs or SDKs? If not, the following site seems to contain exactly what you need: http://leo.sprossenwanne.at/dsp/Entwicklungsprogramme/Entpack/56000/ in particular: http://leo.sprossenwanne.at/dsp/Entwicklungsprogramme/Entpack/56000/FFT/ http://leo.sprossenwanne.at/dsp/Entwicklungsprogramme/Entpack/56000/FFT/FFT. ASM see also: http://leo.sprossenwanne.at/dsp/Entwicklungsprogramme/Download%20Motorola/ On the other hand, if you really want to reinvent the wheel then start here: http://www.freescale.com/files/dsp/doc/app_note/APR20.pdf -------- Original Message -------- > From: "bastian.schnuerle" > Sent: Saturday, April 18, 2009 9:38 PM > To: "A discussion list for music-related DSP" > Subject: Re: [music-dsp] fft in assmbler (htdm) > > thanks robert, thanks vesa, thank you very much. from your two posts > i am getting really excited to check this on the hardware. i was > wrong to write htdm, this is their old architecture. it is tdm and > their processor is an motorola 56k dsp. so i am a bit confused, > because i thought the XXk is signing some kind of memory amount > available and now you robert are writing you got some code for the > old 64k architecture. ?? or does this mean less memory available, > faster processing ? have a great day all, > > bastian > > Am 18.04.2009 um 19:59 schrieb robert bristow-johnson: > > > > > > > > > well, it's neither assembly nor C++, but a quarter century ago i > > wrote this little Radix-2 FFT and iFFT program in C (below) that i > > think is transparent. it isn't highly optimized but doesn't do > > recursive calls and i tried to identify when multiplication by 1 or > > j was happening so to avoid that chore (nowadays it doesn't make > > much difference, you can multiply numbers as quickly as moving > > them). anyway, if you can unwrap the lines of C code, this should > > spell out what you might need to do to write a radix-2 FFT in the > > asm language you are stuck with. if you want, i can look up a > > corresponding piece of code for the old 68K assembly, but i > > wouldn't expect it to translate any better. > > > > > > -- > > > > r b-j rbj@audioimagination.com > > > > "Imagination is more important than knowledge." > > > > > > > > /* > > A set of utility programs to compute the Fast Fourier Transform > > (FFT): > > > > N-1 > > X[k] = SUM { x[n] exp(-j 2pi nk/N) } > > n=0 > > > > and inverse Fast Fourier Transform (iFFT): > > > > N-1 > > x[n] = 1/N SUM { X[k] exp(+j 2pi nk/N) } > > k=0 > > > > To speed things up, multiplication by 1 and j are avoided. The > > input, x[], is an array of > > complex numbers (pairs of doubles) of length N = 2^p. The > > calling program supplies > > p = log2(N) not the array length, N. The output is placed in > > BIT REVERSED order in x[]. > > Call bitreverse(x, p) to swap back to normal order, if needed. > > However, iFFT(X, p, stbl) > > requires its input, X[], to be in bit reversed order making bit > > reversing unnecessary in > > some cases, such as convolution. stbl is an array of doubles > > of length N/4 containing the > > sine function from 0 to pi/2 used to compute the FFT. Call > > sintable(stbl, p) ONLY ONCE > > before either FFT(x, p, stbl) or iFFT(X, p, stbl) to set up a > > sin table for FFT computation. > > > > Written in THINK C by Robert Bristow-Johnson. > > > > copyright (c) 1985 Robert Bristow-Johnson. > > */ > > > > #if 0 > > > > #include "complex.h" > > > > #else > > > > #include > > > > #define PI 3.141592653589793 > > > > typedef struct > > { > > double real; > > double imag; > > } complex; > > > > #define Re(z) (z).real > > #define Im(z) (z).imag > > > > #endif > > > > void FFT(complex *x, int p, double *stbl); > > void iFFT(complex *X, int p, double *stbl); > > void sin_table(double *stbl, int p); > > void bit_reverse(register complex *x, int p); > > > > > > void FFT(complex *x, int p, double *stbl) > > { > > long size; > > register long length, step, stepsize, end; > > register complex *top, *bottom; / > > * top & bottom of FFT butterfly */ > > complex temp; > > > > size = 1L<<(p-2); > > end = (long)x + 4*sizeof(temp)*size; > > > > length = size; > > stepsize = 1; > > while (length >= 1) > > { > > top = x; > > while ((long)top < end) > > { > > bottom = top + 2*length; > > > > Re(temp) = Re(*top) - Re(*bottom); / > > * butterfly: twiddle = 1 */ > > Im(temp) = Im(*top) - Im(*bottom); > > Re(*top) += Re(*bottom); > > Im(*top) += Im(*bottom); > > *bottom = temp; > > top++; > > bottom++; > > > > for (step=stepsize; step > { > > Re(temp) = Re(*top) - Re(*bottom); /* > > butterfly: twiddle = exp(-j*theta) */ > > Im(temp) = Im(*top) - Im(*bottom); > > Re(*top) += Re(*bottom); > > Im(*top) += Im(*bottom); > > Re(*bottom) = Re(temp)*stbl[size - step] + Im(temp) > > *stbl[step]; > > Im(*bottom) = Im(temp)*stbl[size - step] - Re(temp) > > *stbl[step]; > > top++; > > bottom++; > > } > > > > Re(temp) = Im(*top) - Im(*bottom); / > > * butterfly: twiddle = -j */ > > Im(temp) = Re(*bottom) - Re(*top); > > Re(*top) += Re(*bottom); > > Im(*top) += Im(*bottom); > > *bottom = temp; > > top++; > > bottom++; > > > > for (step=stepsize; step > { > > Re(temp) = Im(*top) - Im(*bottom); /* > > butterfly: twiddle = -j*exp(-j*theta) */ > > Im(temp) = Re(*bottom) - Re(*top); > > Re(*top) += Re(*bottom); > > Im(*top) += Im(*bottom); > > Re(*bottom) = Re(temp)*stbl[size - step] + Im(temp) > > *stbl[step]; > > Im(*bottom) = Im(temp)*stbl[size - step] - Re(temp) > > *stbl[step]; > > top++; > > bottom++; > > } > > top = bottom; > > } > > length >>= 1; > > stepsize <<= 1; > > } > > > > top = x; > > bottom = x + 1; > > while ((long)top < end) > > { > > Re(temp) = Re(*top) - Re(*bottom); / > > * butterfly: twiddle = 1 */ > > Im(temp) = Im(*top) - Im(*bottom); > > Re(*top) += Re(*bottom); > > Im(*top) += Im(*bottom); > > *bottom = temp; > > top += 2; > > bottom += 2; > > } > > } > > > > > > void iFFT(complex *X, int p, double *stbl) > > { > > long size; > > register long length, step, stepsize, end; > > double scale; > > register complex *top, *bottom; / > > * top & bottom of FFT butterfly */ > > complex temp; > > > > size = 1L<<(p-2); > > end = (long)X + 4*sizeof(temp)*size; > > > > scale = 0.25/(double)size; > > top = X; > > bottom = X + 1; > > while ((long)top < end) > > { > > Re(temp) = (Re(*top) - Re(*bottom))*scale; / > > * butterfly: twiddle = 1/N */ > > Im(temp) = (Im(*top) - Im(*bottom))*scale; > > Re(*top) = (Re(*top) + Re(*bottom))*scale; > > Im(*top) = (Im(*top) + Im(*bottom))*scale; > > *bottom = temp; > > top += 2; > > bottom += 2; > > } > > > > length = 1; > > stepsize = size; > > while (stepsize >= 1) > > { > > top = X; > > while ((long)top < end) > > { > > bottom = top + 2*length; > > > > temp = *bottom; / > > * butterfly: twiddle = 1 */ > > Re(*bottom) = Re(*top) - Re(temp); > > Im(*bottom) = Im(*top) - Im(temp); > > Re(*top) += Re(temp); > > Im(*top) += Im(temp); > > top++; > > bottom++; > > > > for (step=stepsize; step > { /* > > butterfly: twiddle = exp(+j*theta) */ > > Re(temp) = Re(*bottom)*stbl[size - step] - Im > > (*bottom)*stbl[step]; > > Im(temp) = Im(*bottom)*stbl[size - step] + Re > > (*bottom)*stbl[step]; > > Re(*bottom) = Re(*top) - Re(temp); > > Im(*bottom) = Im(*top) - Im(temp); > > Re(*top) += Re(temp); > > Im(*top) += Im(temp); > > top++; > > bottom++; > > } > > > > Re(temp) = -Im(*bottom); / > > * butterfly: twiddle = +j */ > > Im(temp) = Re(*bottom); > > Re(*bottom) = Re(*top) - Re(temp); > > Im(*bottom) = Im(*top) - Im(temp); > > Re(*top) += Re(temp); > > Im(*top) += Im(temp); > > top++; > > bottom++; > > > > for (step=stepsize; step > { /* > > butterfly: twiddle = +j*exp(+j*theta) */ > > Re(temp) = -Im(*bottom)*stbl[size - step] - Re > > (*bottom)*stbl[step]; > > Im(temp) = Re(*bottom)*stbl[size - step] - Im > > (*bottom)*stbl[step]; > > Re(*bottom) = Re(*top) - Re(temp); > > Im(*bottom) = Im(*top) - Im(temp); > > Re(*top) += Re(temp); > > Im(*top) += Im(temp); > > top++; > > bottom++; > > } > > top = bottom; > > } > > length <<= 1; > > stepsize >>= 1; > > } > > } > > > > > > void sin_table(double *stbl, int p) > > { > > register long size, i; > > double theta; > > > > size = 1L<<(p-2); > > theta = PI/(2.0*(double)size); > > > > for (i=0; i > { > > stbl[i] = sin(theta*(double)i); > > } > > } > > > > > > void bit_reverse(register complex *x, int p) > > { > > complex temp; > > register long k, i, r, size, count; > > > > size = (1L< > for (k=1L; k > { > > i = k; > > r = 0; > > for (count=p; count>0; count--) > > { > > r <<= 1; > > r += (i & 0x00000001L); > > i >>= 1; > > } > > if (r > k) > > { > > temp = x[r]; > > x[r] = x[k]; > > x[k] = temp; > > } > > } > > } > > > > > > > > > > > > > > -- > > dupswapdrop -- the music-dsp mailing list and website: > > subscription info, FAQ, source code archive, list archive, book > > reviews, dsp links > > http://music.columbia.edu/cmc/music-dsp > > http://music.columbia.edu/mailman/listinfo/music-dsp > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From bastian.schnuerle at silberstein.de Sat Apr 18 15:37:58 2009 From: bastian.schnuerle at silberstein.de (bastian.schnuerle) Date: Sat Apr 18 15:38:21 2009 Subject: [music-dsp] fft in assmbler (htdm) In-Reply-To: <76ca4e73$279d5dc8$2861d041$@com> References: <76ca4e73$279d5dc8$2861d041$@com> Message-ID: i spent a while on motorolas dev website searching for a 56k DSP without luck. so i thought waiting for the hardware would be the only option. i hope the dont use custom dsps without their branding and product code. but this i will know within the next two weeks... until then i will search through your links. thanks a lot bogac .. basti Am 18.04.2009 um 21:28 schrieb Bogac Topaktas: > > Isn't there a tightly coded (ASM) and royalty free FFT algorithm > implementation in Freescale/Motorola DSP56xxx EVMs or SDKs? > > If not, the following site seems to contain exactly what you need: > > http://leo.sprossenwanne.at/dsp/Entwicklungsprogramme/Entpack/56000/ > > in particular: > > http://leo.sprossenwanne.at/dsp/Entwicklungsprogramme/Entpack/56000/ > FFT/ > http://leo.sprossenwanne.at/dsp/Entwicklungsprogramme/Entpack/56000/ > FFT/FFT. > ASM > > see also: > > http://leo.sprossenwanne.at/dsp/Entwicklungsprogramme/Download% > 20Motorola/ > > On the other hand, if you really want to reinvent the wheel then start > here: > > http://www.freescale.com/files/dsp/doc/app_note/APR20.pdf > > -------- Original Message -------- >> From: "bastian.schnuerle" >> Sent: Saturday, April 18, 2009 9:38 PM >> To: "A discussion list for music-related DSP" > >> Subject: Re: [music-dsp] fft in assmbler (htdm) >> >> thanks robert, thanks vesa, thank you very much. from your two posts >> i am getting really excited to check this on the hardware. i was >> wrong to write htdm, this is their old architecture. it is tdm and >> their processor is an motorola 56k dsp. so i am a bit confused, >> because i thought the XXk is signing some kind of memory amount >> available and now you robert are writing you got some code for the >> old 64k architecture. ?? or does this mean less memory available, >> faster processing ? have a great day all, >> >> bastian >> >> Am 18.04.2009 um 19:59 schrieb robert bristow-johnson: >> >>> >>> >>> >>> well, it's neither assembly nor C++, but a quarter century ago i >>> wrote this little Radix-2 FFT and iFFT program in C (below) that i >>> think is transparent. it isn't highly optimized but doesn't do >>> recursive calls and i tried to identify when multiplication by 1 or >>> j was happening so to avoid that chore (nowadays it doesn't make >>> much difference, you can multiply numbers as quickly as moving >>> them). anyway, if you can unwrap the lines of C code, this should >>> spell out what you might need to do to write a radix-2 FFT in the >>> asm language you are stuck with. if you want, i can look up a >>> corresponding piece of code for the old 68K assembly, but i >>> wouldn't expect it to translate any better. >>> >>> >>> -- >>> >>> r b-j rbj@audioimagination.com >>> >>> "Imagination is more important than knowledge." >>> >>> >>> >>> /* >>> A set of utility programs to compute the Fast Fourier Transform >>> (FFT): >>> >>> N-1 >>> X[k] = SUM { x[n] exp(-j 2pi nk/N) } >>> n=0 >>> >>> and inverse Fast Fourier Transform (iFFT): >>> >>> N-1 >>> x[n] = 1/N SUM { X[k] exp(+j 2pi nk/N) } >>> k=0 >>> >>> To speed things up, multiplication by 1 and j are avoided. The >>> input, x[], is an array of >>> complex numbers (pairs of doubles) of length N = 2^p. The >>> calling program supplies >>> p = log2(N) not the array length, N. The output is placed in >>> BIT REVERSED order in x[]. >>> Call bitreverse(x, p) to swap back to normal order, if needed. >>> However, iFFT(X, p, stbl) >>> requires its input, X[], to be in bit reversed order making bit >>> reversing unnecessary in >>> some cases, such as convolution. stbl is an array of doubles >>> of length N/4 containing the >>> sine function from 0 to pi/2 used to compute the FFT. Call >>> sintable(stbl, p) ONLY ONCE >>> before either FFT(x, p, stbl) or iFFT(X, p, stbl) to set up a >>> sin table for FFT computation. >>> >>> Written in THINK C by Robert Bristow-Johnson. >>> >>> copyright (c) 1985 Robert Bristow-Johnson. >>> */ >>> >>> #if 0 >>> >>> #include "complex.h" >>> >>> #else >>> >>> #include >>> >>> #define PI 3.141592653589793 >>> >>> typedef struct >>> { >>> double real; >>> double imag; >>> } complex; >>> >>> #define Re(z) (z).real >>> #define Im(z) (z).imag >>> >>> #endif >>> >>> void FFT(complex *x, int p, double *stbl); >>> void iFFT(complex *X, int p, double *stbl); >>> void sin_table(double *stbl, int p); >>> void bit_reverse(register complex *x, int p); >>> >>> >>> void FFT(complex *x, int p, double *stbl) >>> { >>> long size; >>> register long length, step, stepsize, end; >>> register complex *top, *bottom; / >>> * top & bottom of FFT butterfly */ >>> complex temp; >>> >>> size = 1L<<(p-2); >>> end = (long)x + 4*sizeof(temp)*size; >>> >>> length = size; >>> stepsize = 1; >>> while (length >= 1) >>> { >>> top = x; >>> while ((long)top < end) >>> { >>> bottom = top + 2*length; >>> >>> Re(temp) = Re(*top) - Re(*bottom); / >>> * butterfly: twiddle = 1 */ >>> Im(temp) = Im(*top) - Im(*bottom); >>> Re(*top) += Re(*bottom); >>> Im(*top) += Im(*bottom); >>> *bottom = temp; >>> top++; >>> bottom++; >>> >>> for (step=stepsize; step>> { >>> Re(temp) = Re(*top) - Re(*bottom); /* >>> butterfly: twiddle = exp(-j*theta) */ >>> Im(temp) = Im(*top) - Im(*bottom); >>> Re(*top) += Re(*bottom); >>> Im(*top) += Im(*bottom); >>> Re(*bottom) = Re(temp)*stbl[size - step] + Im(temp) >>> *stbl[step]; >>> Im(*bottom) = Im(temp)*stbl[size - step] - Re(temp) >>> *stbl[step]; >>> top++; >>> bottom++; >>> } >>> >>> Re(temp) = Im(*top) - Im(*bottom); / >>> * butterfly: twiddle = -j */ >>> Im(temp) = Re(*bottom) - Re(*top); >>> Re(*top) += Re(*bottom); >>> Im(*top) += Im(*bottom); >>> *bottom = temp; >>> top++; >>> bottom++; >>> >>> for (step=stepsize; step>> { >>> Re(temp) = Im(*top) - Im(*bottom); /* >>> butterfly: twiddle = -j*exp(-j*theta) */ >>> Im(temp) = Re(*bottom) - Re(*top); >>> Re(*top) += Re(*bottom); >>> Im(*top) += Im(*bottom); >>> Re(*bottom) = Re(temp)*stbl[size - step] + Im(temp) >>> *stbl[step]; >>> Im(*bottom) = Im(temp)*stbl[size - step] - Re(temp) >>> *stbl[step]; >>> top++; >>> bottom++; >>> } >>> top = bottom; >>> } >>> length >>= 1; >>> stepsize <<= 1; >>> } >>> >>> top = x; >>> bottom = x + 1; >>> while ((long)top < end) >>> { >>> Re(temp) = Re(*top) - Re(*bottom); / >>> * butterfly: twiddle = 1 */ >>> Im(temp) = Im(*top) - Im(*bottom); >>> Re(*top) += Re(*bottom); >>> Im(*top) += Im(*bottom); >>> *bottom = temp; >>> top += 2; >>> bottom += 2; >>> } >>> } >>> >>> >>> void iFFT(complex *X, int p, double *stbl) >>> { >>> long size; >>> register long length, step, stepsize, end; >>> double scale; >>> register complex *top, *bottom; / >>> * top & bottom of FFT butterfly */ >>> complex temp; >>> >>> size = 1L<<(p-2); >>> end = (long)X + 4*sizeof(temp)*size; >>> >>> scale = 0.25/(double)size; >>> top = X; >>> bottom = X + 1; >>> while ((long)top < end) >>> { >>> Re(temp) = (Re(*top) - Re(*bottom))*scale; / >>> * butterfly: twiddle = 1/N */ >>> Im(temp) = (Im(*top) - Im(*bottom))*scale; >>> Re(*top) = (Re(*top) + Re(*bottom))*scale; >>> Im(*top) = (Im(*top) + Im(*bottom))*scale; >>> *bottom = temp; >>> top += 2; >>> bottom += 2; >>> } >>> >>> length = 1; >>> stepsize = size; >>> while (stepsize >= 1) >>> { >>> top = X; >>> while ((long)top < end) >>> { >>> bottom = top + 2*length; >>> >>> temp = *bottom; / >>> * butterfly: twiddle = 1 */ >>> Re(*bottom) = Re(*top) - Re(temp); >>> Im(*bottom) = Im(*top) - Im(temp); >>> Re(*top) += Re(temp); >>> Im(*top) += Im(temp); >>> top++; >>> bottom++; >>> >>> for (step=stepsize; step>> { /* >>> butterfly: twiddle = exp(+j*theta) */ >>> Re(temp) = Re(*bottom)*stbl[size - step] - Im >>> (*bottom)*stbl[step]; >>> Im(temp) = Im(*bottom)*stbl[size - step] + Re >>> (*bottom)*stbl[step]; >>> Re(*bottom) = Re(*top) - Re(temp); >>> Im(*bottom) = Im(*top) - Im(temp); >>> Re(*top) += Re(temp); >>> Im(*top) += Im(temp); >>> top++; >>> bottom++; >>> } >>> >>> Re(temp) = -Im(*bottom); / >>> * butterfly: twiddle = +j */ >>> Im(temp) = Re(*bottom); >>> Re(*bottom) = Re(*top) - Re(temp); >>> Im(*bottom) = Im(*top) - Im(temp); >>> Re(*top) += Re(temp); >>> Im(*top) += Im(temp); >>> top++; >>> bottom++; >>> >>> for (step=stepsize; step>> { /* >>> butterfly: twiddle = +j*exp(+j*theta) */ >>> Re(temp) = -Im(*bottom)*stbl[size - step] - Re >>> (*bottom)*stbl[step]; >>> Im(temp) = Re(*bottom)*stbl[size - step] - Im >>> (*bottom)*stbl[step]; >>> Re(*bottom) = Re(*top) - Re(temp); >>> Im(*bottom) = Im(*top) - Im(temp); >>> Re(*top) += Re(temp); >>> Im(*top) += Im(temp); >>> top++; >>> bottom++; >>> } >>> top = bottom; >>> } >>> length <<= 1; >>> stepsize >>= 1; >>> } >>> } >>> >>> >>> void sin_table(double *stbl, int p) >>> { >>> register long size, i; >>> double theta; >>> >>> size = 1L<<(p-2); >>> theta = PI/(2.0*(double)size); >>> >>> for (i=0; i>> { >>> stbl[i] = sin(theta*(double)i); >>> } >>> } >>> >>> >>> void bit_reverse(register complex *x, int p) >>> { >>> complex temp; >>> register long k, i, r, size, count; >>> >>> size = (1L<>> for (k=1L; k>> { >>> i = k; >>> r = 0; >>> for (count=p; count>0; count--) >>> { >>> r <<= 1; >>> r += (i & 0x00000001L); >>> i >>= 1; >>> } >>> if (r > k) >>> { >>> temp = x[r]; >>> x[r] = x[k]; >>> x[k] = temp; >>> } >>> } >>> } >>> >>> >>> >>> >>> >>> >>> -- >>> dupswapdrop -- the music-dsp mailing list and website: >>> subscription info, FAQ, source code archive, list archive, book >>> reviews, dsp links >>> http://music.columbia.edu/cmc/music-dsp >>> http://music.columbia.edu/mailman/listinfo/music-dsp >> >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, source code archive, list archive, book >> reviews, > dsp links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp > > > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book > reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From lseltzer at alumni.caltech.edu Sat Apr 18 16:51:07 2009 From: lseltzer at alumni.caltech.edu (Linda Seltzer) Date: Sat Apr 18 16:47:56 2009 Subject: [music-dsp] Re: (FFT question) music-dsp Digest, Vol 64, Issue 15 In-Reply-To: <20090418180000.A454665F830@music.columbia.edu> References: <20090418180000.A454665F830@music.columbia.edu> Message-ID: <1186.71.231.103.249.1240087867.squirrel@mail.alumni.caltech.edu> Hi Folks, If you need a highly optimized FFT: -Precompute the sines and cosines you need and put them in a table. Both the computations and the function calls take too much time. -Figure out the different classifications of butterflies you have and use a C switch statement or something similar to choose the right butterfly code. -Unroll the loop and precompute indexes -Remember that macros and inline functions don't incur function call overhead. There are some problems that can a hundred thousand 3-D FFTs and even on a general purpose computer you could suddenly incur large time costs. Linda Seltzer Senior Consultant lseltzer@alumni.caltech.edu "If your project has a bug I will find it and fix it." From rbj at audioimagination.com Sat Apr 18 17:57:07 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sat Apr 18 17:57:28 2009 Subject: [music-dsp] fft in assmbler (htdm) Message-ID: <20090418215707.B98BC54D737@ws6-9.us4.outblaze.com> > ----- Original Message ----- > From: "bastian.schnuerle" > To: "A discussion list for music-related DSP" > Subject: Re: [music-dsp] fft in assmbler (htdm) > Date: Sat, 18 Apr 2009 20:38:07 +0200 > > > thanks robert, thanks vesa, thank you very much. from your two posts i am > getting really excited to check this on the hardware. i was wrong to write > htdm, this is their old architecture. it is tdm as in digi? > and their processor is an motorola 56k dsp. if you want some 56K FFT code, there is a couple of ways for doing it. somewhere, i have some block-floating point 56K FFT code that uses that sticky "S" bit to detect for potential scaling overflow. if overflow is impending, the following pass is in divide-by-2 mode in the 56K. if overflow is not impending, then the following pass is in normal mode. if you don't do block-floating point, then you should invoke the divide-by-2 mode in every other pass; the so-called "unitary" DFT which has 1/sqrt(N) in front of both the forward and inverse DFT and where signal energy (or the so-called "L^2 norm") is preserved. > so i am a bit confused, because i thought the XXk is > signing some kind of memory amount available and now you robert are writing > you got some code for the old 64k architecture. ?? i have, of the same vintage as this C code, a very similar radix-2 FFT, iFFT, and bit_reverse routines written for the Motorola MC68000. it's very old and it's sorta optimized for this processor that hasn't been really in use anywhere i am aware of for well over a decade. it was written back in the days that a fixed-point multiply instruction was 20 or 30 times the cost of a move or add instruction. i can't imagine it still would be of value, but if you want me to pop in a few old floppy disks into my old, old Mac (that has a floppy drive) and look for that old 680x0 code, i can do it. can't guarantee that i'll find it, but i think i will. > or does this mean less memory available, faster processing ? the amount of program code is incidental. the size of the FFT array is 2N words which is fixed. the only trade-off of memory use against speed is computing the twiddle factors on-the-fly vs. computing them once and putting them in a table (i've only done the latter; a table of N/4 words). so, if you *really* want this old 68K asm code, lemme know. but i won't bother looking it up otherwise, because i think you'll be able to hand-translate the C code to your assembly language more easily than translating from one assembly language to another. but if it's 56K FFT code, i have something that is a lot like their general FFT benchmark but a little cleaner. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From rbj at audioimagination.com Sat Apr 18 18:17:43 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sat Apr 18 18:18:02 2009 Subject: [music-dsp] fft in assmbler (htdm) Message-ID: <20090418221743.90EC110AAC7@ws6-4.us4.outblaze.com> > ----- Original Message ----- > From: "bastian.schnuerle" > To: "A discussion list for music-related DSP" > Subject: Re: [music-dsp] fft in assmbler (htdm) > Date: Sat, 18 Apr 2009 21:37:58 +0200 > > > i spent a while on motorolas dev website searching for a 56k DSP without > luck. below is the 56K block-floating point FFT code i was referring to before. i haven't used if for a decade and a half. it should work in the context you need. i can't guarantee that it is optimized for the DSP563xx, but you can try it out. make sure the S, S0, and S1 bits in the SR are in the same location as they had been for the DSP56002. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." page 255 opt cex,mex lstcol 8,8,10,13,13 ; ; copyright (C) 1994 by Robert Bristow-Johnson ; tel: 802/865-4525 ; e-mail: ; ; ; ; This subroutine is identical to the Motorola benchmark fftr2a ; except that scaling is optimized using block-floating point. ; This requires a DSP56002, DSP56004, DSP56007 or DSP56001A. ; Some FFT passes have the divide by 2 scaling mode set (depending ; on the result of the S bit in the CCR). This insures ; against, overflow for any signal. N must be a power of 2. ; ; To be completely safe, the input should be scaled so that ; the magnitude of every real or imaginary part does not ; exceed 0.31066 ($27C3B5) . ; ; ; N-1 ; X[n] = 1/M SUM{ x[k]*exp(-j*2*PI*n*k/N) } ; k=0 ; ; where ; x[k] = input in normal order ; X[n] = output in bit reverse order ; ; N = 2^p ; ; M = 2^q (q = integer, number of passes that ; right shifting was necessary. ; 0 <= q <= p ) ; ; ; input: r1 -> data; x:(r1) is real part, y:(r1) is imag part ; r2 -> coefficients; x:(r2) is cos, y:(r2) is sin ; n1 = log2(number of points) = p ; r4 = block floating point exponent input (perhaps initialized to 0) ; ; output: r4 = block floating point exponent output ; = q + input r4 ; ; uses: a, b, x0, x1, y0, y1, mr, ccr ; r1, r2, r3, r4, r5, r6 ; n1, n2, n3, n4, n5, n6 ; m1, m2, m3, m4, m5, m6 ; x:-1,m5 ;2 init A and B address modifiers move m5,m6 ;1 for linear addressing move m5,m4 ;1 move m5,m1 ;1 move m5,m2 ;1 move #<0,m3 ;1 init C address modifier ; for bit-reversed addressing andi #$7F,ccr ;1 clear sticky bit ; ; Do FFT passes with triple nested DO loop. ; do n1,end_pass ;3 move x:-1,m5 move m5,m2 clr a #delta_table,r5 move #<2,n5 move #<1,a1 do n1,_shift lsl a (r5)+n5 _shift lsr a #<-1.0,x0 ; -cos move p:(r5)+,x1 ; -cosdel move p:(r5)+,y1 ; -sindel move a1,r5 ; N/2 move #<0.0,y0 ; -sin move x0,x:(r2) ; -cos(0) move y0,y:(r2)+ ; -sin(0) mpyr -x0,x1,a (r5)- ; N/2 - 1 do r5,_sincos_loop mpy -y1,x0,b a,x0 macr -x1,y0,b a,x:(r2) ; b = new sin mpy -x1,x0,a b,y0 macr y1,y0,a b,y:(r2)+ ; a = new cos _sincos_loop rts twopi equ 6.28318530717959 delta_table dc -@cos(twopi/1.0) dc -@sin(twopi/1.0) dc -@cos(twopi/2.0) dc -@sin(twopi/2.0) dc -@cos(twopi/4.0) dc -@sin(twopi/4.0) dc -@cos(twopi/8.0) dc -@sin(twopi/8.0) dc -@cos(twopi/16.0) dc -@sin(twopi/16.0) dc -@cos(twopi/32.0) dc -@sin(twopi/32.0) dc -@cos(twopi/64.0) dc -@sin(twopi/64.0) dc -@cos(twopi/128.0) dc -@sin(twopi/128.0) dc -@cos(twopi/256.0) dc -@sin(twopi/256.0) dc -@cos(twopi/512.0) dc -@sin(twopi/512.0) dc -@cos(twopi/1024.0) dc -@sin(twopi/1024.0) dc -@cos(twopi/2048.0) dc -@sin(twopi/2048.0) dc -@cos(twopi/4096.0) dc -@sin(twopi/4096.0) dc -@cos(twopi/8192.0) dc -@sin(twopi/8192.0) dc -@cos(twopi/16384.0) dc -@sin(twopi/16384.0) dc -@cos(twopi/32768.0) dc -@sin(twopi/32768.0) end From bastian.schnuerle at silberstein.de Sat Apr 18 18:28:52 2009 From: bastian.schnuerle at silberstein.de (bastian.schnuerle) Date: Sat Apr 18 18:29:12 2009 Subject: [music-dsp] fft in assmbler (htdm) In-Reply-To: <20090418221743.90EC110AAC7@ws6-4.us4.outblaze.com> References: <20090418221743.90EC110AAC7@ws6-4.us4.outblaze.com> Message-ID: that is fantastic. i getting so excited to check this on the hardware. in assembler these new terms of sticky "S" bit, overflow (divide-by-2 mode), do or dont block-floating point seem to me as the biggest step and hand translating is for sure needed to achieve a mental visualization. but this will help for sure massively because for the first task i only have to take the signal to the complex domain and hand it over to the c++ host code for visualization. thank you so much robert .. bastian Am 19.04.2009 um 00:17 schrieb robert bristow-johnson: > >> ----- Original Message ----- >> From: "bastian.schnuerle" >> To: "A discussion list for music-related DSP" > dsp@music.columbia.edu> >> Subject: Re: [music-dsp] fft in assmbler (htdm) >> Date: Sat, 18 Apr 2009 21:37:58 +0200 >> >> >> i spent a while on motorolas dev website searching for a 56k DSP >> without >> luck. > > below is the 56K block-floating point FFT code i was referring to > before. i haven't used if for a decade and a half. it should work > in the context you need. i can't guarantee that it is optimized > for the DSP563xx, but you can try it out. make sure the S, S0, and > S1 bits in the SR are in the same location as they had been for the > DSP56002. > > -- > > r b-j rbj@audioimagination.com > > "Imagination is more important than knowledge." > > > > > > page 255 > opt cex,mex > lstcol 8,8,10,13,13 > > ; > ; copyright (C) 1994 by Robert Bristow-Johnson > ; tel: 802/865-4525 > ; e-mail: > ; > ; > ; > ; This subroutine is identical to the Motorola benchmark fftr2a > ; except that scaling is optimized using block-floating point. > ; This requires a DSP56002, DSP56004, DSP56007 or DSP56001A. > ; Some FFT passes have the divide by 2 scaling mode set > (depending > ; on the result of the S bit in the CCR). This insures > ; against, overflow for any signal. N must be a power of 2. > ; > ; To be completely safe, the input should be scaled so that > ; the magnitude of every real or imaginary part does not > ; exceed 0.31066 ($27C3B5) . > ; > ; > ; N-1 > ; X[n] = 1/M SUM{ x[k]*exp(-j*2*PI*n*k/N) } > ; k=0 > ; > ; where > ; x[k] = input in normal order > ; X[n] = output in bit reverse order > ; > ; N = 2^p > ; > ; M = 2^q (q = integer, number of passes that > ; right shifting was necessary. > ; 0 <= q <= p ) > ; > ; > ; input: r1 -> data; x:(r1) is real part, y:(r1) is imag part > ; r2 -> coefficients; x:(r2) is cos, y:(r2) is sin > ; n1 = log2(number of points) = p > ; r4 = block floating point exponent input (perhaps > initialized to 0) > ; > ; output: r4 = block floating point exponent output > ; = q + input r4 > ; > ; uses: a, b, x0, x1, y0, y1, mr, ccr > ; r1, r2, r3, r4, r5, r6 > ; n1, n2, n3, n4, n5, n6 > ; m1, m2, m3, m4, m5, m6 > ; x: ; x: ; > ; Leaves mr in no scaling mode. > ; > ; Requires 78 words of internal p: memory > ; and p*( 3*N + 20 ) + 8*N + 15 instruction cycles. > ; > ; To execute optimally, the fft routine sould be in > ; internal p: space. > ; > ; > > org x:$0 > data ds $1 > n_grp ds $1 > coef ds $1 > > org p:$40 > fft > clr a r1,x: move #<1,n4 ;1 > init groups per pass > move n4,a1 ;1 > do r3,_shift ;3 > lsl a ;p > _shift > lsr a r2,x: lsr a a1,n5 ;1 > init bfy per group > move a1,n3 ;1 > init C pointer offset > move #>-1,m5 ;2 > init A and B address modifiers > > move m5,m6 ;1 > for linear addressing > move m5,m4 ;1 > move m5,m1 ;1 > move m5,m2 ;1 > move #<0,m3 ;1 > init C address modifier > ; f > or bit-reversed addressing > andi #$7F,ccr ;1 > clear sticky bit > > ; > ; Do FFT passes with triple nested DO loop. > ; > do n1,end_pass ;3 > > move x: init A input pointer > move r5,r1 ;p > init A output pointer > lua (r5)+n5,r6 ;2p > init B input pointer > move x: init C input pointer > lua (r6)-,r2 ;2p > init B output pointer > move n5,n6 ;p > init pointer offsets > move n5,n1 ;p > move n5,n2 ;p > > jset #7,sr,scale_down ; > 2p test scaling bit > > andi # > $F3,mr ;p reset scaling > to normal scaling mode > > do n4,_end_grp1 ;3p > move x:(r6),x1 y: > (r3),y0 ;N-1 lookup -sine and > ; > -cosine values > move x:(r2),a y: > (r5),b ;N-1 preload b and > ; > update C pointer > move x:(r3)+n3,x0 ;N-1 > > do n5,_end_bfy1 ;3 > (N-1) > mac x1,y0,b y:(r6)+,y1 ;pN/2 > macr -x0,y1,b a,x:(r2)+ y:(r5),a ;pN/2 > subl b,a x:(r5),b b,y:(r1) ;pN/2 > mac -x1,x0,b x:(r5)+,a a,y:(r2) ;pN/2 > macr -y1,y0,b x:(r6),x1 ;pN/2 > subl b,a b,x:(r1)+ y:(r5),b ;pN/2 > _end_bfy1 > move a,x:(r2)+n2 y:(r6) > +n6,y1 ;N-1 update A and B pointers > move x:(r5)+n5,x1 y:(r1)+n1,y1 ;N-1 > _end_grp1 > jmp > scale_down > move (r4)+ ;p > increment block exponent > ; > each time we scale down > andi #$7F,ccr ;p > clear sticky bit > ori #$04,mr ;p > set scaling mode to divide by 2 > > do n4,_end_grp2 ;3p > move x:(r6),x1 y: > (r3),y0 ;N-1 lookup -sine and > ; > -cosine values > move x:(r2),a y: > (r5),b ;N-1 preload b and > ; > update C pointer > asl a x:(r3) > +n3,x0 ;N-1 double a to compensate > ; > for div by 2 scaling > do n5,_end_bfy2 ;3 > (N-1) > mac x1,y0,b y:(r6)+,y1 ;pN/2 > macr -x0,y1,b a,x:(r2)+ y:(r5),a ;pN/2 > subl b,a x:(r5),b b,y:(r1) ;pN/2 > mac -x1,x0,b x:(r5)+,a a,y:(r2) ;pN/2 > macr -y1,y0,b x:(r6),x1 ;pN/2 > subl b,a b,x:(r1)+ y:(r5),b ;pN/2 > _end_bfy2 > move a,x:(r2)+n2 y:(r6) > +n6,y1 ;N-1 update A and B pointers > move x:(r5)+n5,x1 y:(r1)+n1,y1 ;N-1 > _end_grp2 > > pass_common > move n5,b1 ;p > divide bfy per group by 2 > lsr b n4,a1 ;p > multiply groups per pass by 2 > lsl a b1,n5 ;p > move a1,n4 ;p > end_pass > andi #$F3,mr ;1 > reset scaling to normal scaling mode > rts ;2 > > ; > ;pi equ 3.141592654 > ;freq equ 2.0*pi/@cvf(points) > ; > ; org x:coef > ;count set 0 > ; dup points/2 > ; dc -@cos(@cvf(count)*freq) > ;count set count+1 > ; endm > ; > ; org y:coef > ;count set 0 > ; dup points/2 > ; dc -@sin(@cvf(count)*freq) > ;count set count+1 > ; endm > ; > ; endm ;end of sincos macro > ; > > sincos > andi #$F3,mr > move #>-1,m5 > move m5,m2 > clr a #delta_table,r5 > move #<2,n5 > move #<1,a1 > do n1,_shift > lsl a (r5)+n5 > _shift > lsr a #<-1.0,x0 ; -cos > move p:(r5)+,x1 ; - > cosdel > move p:(r5)+,y1 ; - > sindel > move a1,r5 ; N/2 > move #<0.0,y0 ; -sin > move x0,x:(r2) ; - > cos(0) > move y0,y:(r2)+ ; - > sin(0) > mpyr -x0,x1,a (r5)- ; N/ > 2 - 1 > do r5,_sincos_loop > mpy -y1,x0,b a,x0 > macr -x1,y0,b a,x:(r2) ; b > = new sin > mpy -x1,x0,a b,y0 > macr y1,y0,a b,y:(r2)+ ; a > = new cos > _sincos_loop > rts > > twopi equ 6.28318530717959 > > delta_table > dc -@cos(twopi/1.0) > dc -@sin(twopi/1.0) > dc -@cos(twopi/2.0) > dc -@sin(twopi/2.0) > dc -@cos(twopi/4.0) > dc -@sin(twopi/4.0) > dc -@cos(twopi/8.0) > dc -@sin(twopi/8.0) > dc -@cos(twopi/16.0) > dc -@sin(twopi/16.0) > dc -@cos(twopi/32.0) > dc -@sin(twopi/32.0) > dc -@cos(twopi/64.0) > dc -@sin(twopi/64.0) > dc -@cos(twopi/128.0) > dc -@sin(twopi/128.0) > dc -@cos(twopi/256.0) > dc -@sin(twopi/256.0) > dc -@cos(twopi/512.0) > dc -@sin(twopi/512.0) > dc -@cos(twopi/1024.0) > dc -@sin(twopi/1024.0) > dc -@cos(twopi/2048.0) > dc -@sin(twopi/2048.0) > dc -@cos(twopi/4096.0) > dc -@sin(twopi/4096.0) > dc -@cos(twopi/8192.0) > dc -@sin(twopi/8192.0) > dc -@cos(twopi/16384.0) > dc -@sin(twopi/16384.0) > dc -@cos(twopi/32768.0) > dc -@sin(twopi/32768.0) > > end > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book > reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From bastian.schnuerle at silberstein.de Sat Apr 18 18:33:27 2009 From: bastian.schnuerle at silberstein.de (bastian.schnuerle) Date: Sat Apr 18 18:33:50 2009 Subject: [music-dsp] fft in assmbler (htdm) In-Reply-To: <20090418221743.90EC110AAC7@ws6-4.us4.outblaze.com> References: <20090418221743.90EC110AAC7@ws6-4.us4.outblaze.com> Message-ID: <51B938E1-E61F-477E-BC1E-B65D2CE34C1A@silberstein.de> and scaling. bastian Am 19.04.2009 um 00:17 schrieb robert bristow-johnson: > >> ----- Original Message ----- >> From: "bastian.schnuerle" >> To: "A discussion list for music-related DSP" > dsp@music.columbia.edu> >> Subject: Re: [music-dsp] fft in assmbler (htdm) >> Date: Sat, 18 Apr 2009 21:37:58 +0200 >> >> >> i spent a while on motorolas dev website searching for a 56k DSP >> without >> luck. > > below is the 56K block-floating point FFT code i was referring to > before. i haven't used if for a decade and a half. it should work > in the context you need. i can't guarantee that it is optimized > for the DSP563xx, but you can try it out. make sure the S, S0, and > S1 bits in the SR are in the same location as they had been for the > DSP56002. > > -- > > r b-j rbj@audioimagination.com > > "Imagination is more important than knowledge." > > > > > > page 255 > opt cex,mex > lstcol 8,8,10,13,13 > > ; > ; copyright (C) 1994 by Robert Bristow-Johnson > ; tel: 802/865-4525 > ; e-mail: > ; > ; > ; > ; This subroutine is identical to the Motorola benchmark fftr2a > ; except that scaling is optimized using block-floating point. > ; This requires a DSP56002, DSP56004, DSP56007 or DSP56001A. > ; Some FFT passes have the divide by 2 scaling mode set > (depending > ; on the result of the S bit in the CCR). This insures > ; against, overflow for any signal. N must be a power of 2. > ; > ; To be completely safe, the input should be scaled so that > ; the magnitude of every real or imaginary part does not > ; exceed 0.31066 ($27C3B5) . > ; > ; > ; N-1 > ; X[n] = 1/M SUM{ x[k]*exp(-j*2*PI*n*k/N) } > ; k=0 > ; > ; where > ; x[k] = input in normal order > ; X[n] = output in bit reverse order > ; > ; N = 2^p > ; > ; M = 2^q (q = integer, number of passes that > ; right shifting was necessary. > ; 0 <= q <= p ) > ; > ; > ; input: r1 -> data; x:(r1) is real part, y:(r1) is imag part > ; r2 -> coefficients; x:(r2) is cos, y:(r2) is sin > ; n1 = log2(number of points) = p > ; r4 = block floating point exponent input (perhaps > initialized to 0) > ; > ; output: r4 = block floating point exponent output > ; = q + input r4 > ; > ; uses: a, b, x0, x1, y0, y1, mr, ccr > ; r1, r2, r3, r4, r5, r6 > ; n1, n2, n3, n4, n5, n6 > ; m1, m2, m3, m4, m5, m6 > ; x: ; x: ; > ; Leaves mr in no scaling mode. > ; > ; Requires 78 words of internal p: memory > ; and p*( 3*N + 20 ) + 8*N + 15 instruction cycles. > ; > ; To execute optimally, the fft routine sould be in > ; internal p: space. > ; > ; > > org x:$0 > data ds $1 > n_grp ds $1 > coef ds $1 > > org p:$40 > fft > clr a r1,x: move #<1,n4 ;1 > init groups per pass > move n4,a1 ;1 > do r3,_shift ;3 > lsl a ;p > _shift > lsr a r2,x: lsr a a1,n5 ;1 > init bfy per group > move a1,n3 ;1 > init C pointer offset > move #>-1,m5 ;2 > init A and B address modifiers > > move m5,m6 ;1 > for linear addressing > move m5,m4 ;1 > move m5,m1 ;1 > move m5,m2 ;1 > move #<0,m3 ;1 > init C address modifier > ; f > or bit-reversed addressing > andi #$7F,ccr ;1 > clear sticky bit > > ; > ; Do FFT passes with triple nested DO loop. > ; > do n1,end_pass ;3 > > move x: init A input pointer > move r5,r1 ;p > init A output pointer > lua (r5)+n5,r6 ;2p > init B input pointer > move x: init C input pointer > lua (r6)-,r2 ;2p > init B output pointer > move n5,n6 ;p > init pointer offsets > move n5,n1 ;p > move n5,n2 ;p > > jset #7,sr,scale_down ; > 2p test scaling bit > > andi # > $F3,mr ;p reset scaling > to normal scaling mode > > do n4,_end_grp1 ;3p > move x:(r6),x1 y: > (r3),y0 ;N-1 lookup -sine and > ; > -cosine values > move x:(r2),a y: > (r5),b ;N-1 preload b and > ; > update C pointer > move x:(r3)+n3,x0 ;N-1 > > do n5,_end_bfy1 ;3 > (N-1) > mac x1,y0,b y:(r6)+,y1 ;pN/2 > macr -x0,y1,b a,x:(r2)+ y:(r5),a ;pN/2 > subl b,a x:(r5),b b,y:(r1) ;pN/2 > mac -x1,x0,b x:(r5)+,a a,y:(r2) ;pN/2 > macr -y1,y0,b x:(r6),x1 ;pN/2 > subl b,a b,x:(r1)+ y:(r5),b ;pN/2 > _end_bfy1 > move a,x:(r2)+n2 y:(r6) > +n6,y1 ;N-1 update A and B pointers > move x:(r5)+n5,x1 y:(r1)+n1,y1 ;N-1 > _end_grp1 > jmp > scale_down > move (r4)+ ;p > increment block exponent > ; > each time we scale down > andi #$7F,ccr ;p > clear sticky bit > ori #$04,mr ;p > set scaling mode to divide by 2 > > do n4,_end_grp2 ;3p > move x:(r6),x1 y: > (r3),y0 ;N-1 lookup -sine and > ; > -cosine values > move x:(r2),a y: > (r5),b ;N-1 preload b and > ; > update C pointer > asl a x:(r3) > +n3,x0 ;N-1 double a to compensate > ; > for div by 2 scaling > do n5,_end_bfy2 ;3 > (N-1) > mac x1,y0,b y:(r6)+,y1 ;pN/2 > macr -x0,y1,b a,x:(r2)+ y:(r5),a ;pN/2 > subl b,a x:(r5),b b,y:(r1) ;pN/2 > mac -x1,x0,b x:(r5)+,a a,y:(r2) ;pN/2 > macr -y1,y0,b x:(r6),x1 ;pN/2 > subl b,a b,x:(r1)+ y:(r5),b ;pN/2 > _end_bfy2 > move a,x:(r2)+n2 y:(r6) > +n6,y1 ;N-1 update A and B pointers > move x:(r5)+n5,x1 y:(r1)+n1,y1 ;N-1 > _end_grp2 > > pass_common > move n5,b1 ;p > divide bfy per group by 2 > lsr b n4,a1 ;p > multiply groups per pass by 2 > lsl a b1,n5 ;p > move a1,n4 ;p > end_pass > andi #$F3,mr ;1 > reset scaling to normal scaling mode > rts ;2 > > ; > ;pi equ 3.141592654 > ;freq equ 2.0*pi/@cvf(points) > ; > ; org x:coef > ;count set 0 > ; dup points/2 > ; dc -@cos(@cvf(count)*freq) > ;count set count+1 > ; endm > ; > ; org y:coef > ;count set 0 > ; dup points/2 > ; dc -@sin(@cvf(count)*freq) > ;count set count+1 > ; endm > ; > ; endm ;end of sincos macro > ; > > sincos > andi #$F3,mr > move #>-1,m5 > move m5,m2 > clr a #delta_table,r5 > move #<2,n5 > move #<1,a1 > do n1,_shift > lsl a (r5)+n5 > _shift > lsr a #<-1.0,x0 ; -cos > move p:(r5)+,x1 ; - > cosdel > move p:(r5)+,y1 ; - > sindel > move a1,r5 ; N/2 > move #<0.0,y0 ; -sin > move x0,x:(r2) ; - > cos(0) > move y0,y:(r2)+ ; - > sin(0) > mpyr -x0,x1,a (r5)- ; N/ > 2 - 1 > do r5,_sincos_loop > mpy -y1,x0,b a,x0 > macr -x1,y0,b a,x:(r2) ; b > = new sin > mpy -x1,x0,a b,y0 > macr y1,y0,a b,y:(r2)+ ; a > = new cos > _sincos_loop > rts > > twopi equ 6.28318530717959 > > delta_table > dc -@cos(twopi/1.0) > dc -@sin(twopi/1.0) > dc -@cos(twopi/2.0) > dc -@sin(twopi/2.0) > dc -@cos(twopi/4.0) > dc -@sin(twopi/4.0) > dc -@cos(twopi/8.0) > dc -@sin(twopi/8.0) > dc -@cos(twopi/16.0) > dc -@sin(twopi/16.0) > dc -@cos(twopi/32.0) > dc -@sin(twopi/32.0) > dc -@cos(twopi/64.0) > dc -@sin(twopi/64.0) > dc -@cos(twopi/128.0) > dc -@sin(twopi/128.0) > dc -@cos(twopi/256.0) > dc -@sin(twopi/256.0) > dc -@cos(twopi/512.0) > dc -@sin(twopi/512.0) > dc -@cos(twopi/1024.0) > dc -@sin(twopi/1024.0) > dc -@cos(twopi/2048.0) > dc -@sin(twopi/2048.0) > dc -@cos(twopi/4096.0) > dc -@sin(twopi/4096.0) > dc -@cos(twopi/8192.0) > dc -@sin(twopi/8192.0) > dc -@cos(twopi/16384.0) > dc -@sin(twopi/16384.0) > dc -@cos(twopi/32768.0) > dc -@sin(twopi/32768.0) > > end > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book > reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From rbj at audioimagination.com Sat Apr 18 21:14:01 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sat Apr 18 21:14:19 2009 Subject: [music-dsp] fft in assmbler (htdm) Message-ID: <20090419011401.CB46616EB0F@ws6-8.us4.outblaze.com> > ----- Original Message ----- > From: "bastian.schnuerle" > To: "A discussion list for music-related DSP" > Subject: Re: [music-dsp] fft in assmbler (htdm) > Date: Sun, 19 Apr 2009 00:28:52 +0200 > > > that is fantastic. i getting so excited to check this on the hardware. in > assembler these new terms of sticky "S" bit, overflow (divide-by-2 mode), do > or dont block-floating point seem to me as the biggest step and hand > translating is for sure needed to achieve a mental visualization. but this > will help for sure massively because for the first task i only have to take > the signal to the complex domain and hand it over to the c++ host code for > visualization. > ... > > > and scaling. okay, Bastian, i am trying to understand what you are needing/thinking/asking. do you want 56K code to run on Digidesign TDM hardware? if so, how are you gonna "check this on the hardware"? or do you want to run code on a host computer? if the former, it's gonna be some kind of fixed-point arithmetic. "block-floating point" is a technique to do a form of floating-point arithmetic on a fixed-point machine (like the 56K). if you are doing this on a host PC (intel), then you may as well do this with regular floating-point arithmetic. or do you want a basic FFT structure that you can either use directly (with a C/C++ compiler) or translate to your target device? is this FFT going to be used for spectral analysis or display (time-to-frequency transformation) of audio? or is it used to process audio to spectrum and back to audio? in any case, feel free to use, modify, mangle, or discard any of that code. i am just not sure what it is that you're ultimately trying to do. but i don't need to know. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From bastian.schnuerle at silberstein.de Sat Apr 18 21:43:47 2009 From: bastian.schnuerle at silberstein.de (bastian.schnuerle) Date: Sat Apr 18 21:44:01 2009 Subject: [music-dsp] fft in assmbler (htdm) In-Reply-To: <20090419011401.CB46616EB0F@ws6-8.us4.outblaze.com> References: <20090419011401.CB46616EB0F@ws6-8.us4.outblaze.com> Message-ID: <60D52748-4436-4FEF-80CA-FF1D8A542299@silberstein.de> Am 19.04.2009 um 03:14 schrieb robert bristow-johnson: > >> ----- Original Message ----- >> From: "bastian.schnuerle" >> To: "A discussion list for music-related DSP" > dsp@music.columbia.edu> >> Subject: Re: [music-dsp] fft in assmbler (htdm) >> Date: Sun, 19 Apr 2009 00:28:52 +0200 >> >> >> that is fantastic. i getting so excited to check this on the >> hardware. in >> assembler these new terms of sticky "S" bit, overflow (divide-by-2 >> mode), do >> or dont block-floating point seem to me as the biggest step and hand >> translating is for sure needed to achieve a mental visualization. >> but this >> will help for sure massively because for the first task i only >> have to take >> the signal to the complex domain and hand it over to the c++ host >> code for >> visualization. >> > ... >> >> >> and scaling. > > okay, Bastian, i am trying to understand what you are needing/ > thinking/asking. > > do you want 56K code to run on Digidesign TDM hardware? if so, how > are you gonna "check this on the hardware"? yes, exactly. a 192 with the hd1. it is ordered and i will soon get it. > > or do you want to run code on a host computer? yesno, because as far as what i have learned from digis sdk.pdf the processed audio for display will be hand over to the c++ host code. > > if the former, it's gonna be some kind of fixed-point arithmetic. > "block-floating point" is a technique to do a form of floating- > point arithmetic on a fixed-point machine (like the 56K). if you > are doing this on a host PC (intel), then you may as well do this > with regular floating-point arithmetic. that it what i am used to. and now i am understanding this term. thanks... stayin at home on a saturday night can be very productive thanks. > > or do you want a basic FFT structure that you can either use > directly (with a C/C++ compiler) or translate to your target device? no, the code you have just posted will be a tremendous step into the right direction .. > > is this FFT going to be used for spectral analysis or display (time- > to-frequency transformation) of audio? for getting used to this i am lucky that it only will be used for analysis .. > or is it used to process audio to spectrum and back to audio? for the next task, yes .. > > in any case, feel free to use, modify, mangle, or discard any of > that code. i am just not sure what it is that you're ultimately > trying to do. but i don't need to know. yeah, really ?! this is what i was trying the whole time to put down into words. maybe this .. (see your inbox) .. bastian > -- > > r b-j rbj@audioimagination.com > > "Imagination is more important than knowledge." > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book > reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From developer at netcologne.de Mon Apr 20 06:05:53 2009 From: developer at netcologne.de (Thomas Rehaag) Date: Mon Apr 20 06:06:08 2009 Subject: [music-dsp] Zoelzer & Holters 4th order EQ filters References: <50B2AB19-8533-47DD-87FF-9490DAF3B865@silberstein.de> <49E86401.30E9E9ED@netcologne.de> <001901c9bf5c$14d57640$0201a8c0@mooncode> Message-ID: <49EC4901.75D93D02@netcologne.de> Hello, I'm still looking for 4th order peak filters. Thanks to Martin Eisenberg's reply to my last mail I read about the Zoelzer/Holters filter: http://www.dafx.ca/proceedings/papers/p_037.pdf and gave up my investigations in simply cascading RBJ's peak filters. I'm shure Zoelzer/Holters wouldn't have made such an effort, if cascading peak filters would be as easy as cascading lowpasses. Those people know what they are doing. (I hope!) But now I'm stuck on the Zoelzer/Holters filter since days! So - is there anyone around who succeded to translate the PDF's information into code? Or maybe anyone who'd also like to have that filter and will work out the problems with me? A step by step description of what I did and the C++ classes are here: http://ismism.de/zf/zf.html I first started from the (a bit confusing) diagram "Figure 1". But that lead to an instable system. Then I restarted with equation 13. .. And received a bit by bit identical respose to my input sine sweep. So I checked my allpass filter (the replacement for the delays for the LP->BP transformation): stable and unity gain. And re-replacing the allpasses with "one sample delays" also didn't lead to a low shelf filter in both cases. But to a similar instability. So probably I made a mistake calculating the base parameters K, V, cm and a0,m^-1 : cm = cos( ( 1/2 - (2m-1)/2M)*Pi ); K = tan(OmegaB/2)/ g^(1/2M) = tan(Pi * (fu - fl) / 2 * SampleRate)) / g^(1/2*M) V = (g^(1/M)) - 1; a0[m]^-1 = 1 / 1 + K * cm + K^2; Maybe the only confusion is to set the values for m and M for a single, non cascaded instance of the filter. I set M = 4 (fourth order) and m = 1 (first and only instance of the filter). I even tried M = 2 cause of the low shelf filter, that is second order. Thanks, Thomas From martin.eisenberg at udo.edu Mon Apr 20 09:01:46 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Mon Apr 20 09:01:14 2009 Subject: [music-dsp] Zoelzer & Holters 4th order EQ filters References: <50B2AB19-8533-47DD-87FF-9490DAF3B865@silberstein.de><49E86401.30E9E9ED@netcologne.de><001901c9bf5c$14d57640$0201a8c0@mooncode> <49EC4901.75D93D02@netcologne.de> Message-ID: <000501c9c1b8$2d496de0$0201a8c0@mooncode> From: "Thomas Rehaag" > I'm shure Zoelzer/Holters wouldn't have made such an > effort, if cascading peak filters would be as easy as > cascading lowpasses. The reason for their work is that a *maximally flat* (= Butterworth) filter does not result from cascading individually max-flat stages. > http://ismism.de/zf/zf.html | for a single filter block I set m=1 and M=4 For a 4th-order EQ, the low-shelf prototype order is M=2 because the LP-BP transformation will double the order. | m_fK = (float)(tan(fOmegaB / 2.f) / | pow(fAmplitude, 1.f / 2 * m_lTotalFilterOrder)); Bzzt, parenthesis alarm! Should be 0.5f/m_lTotalFilterOrder. | m_fInvA0 = 1.f / 1.f + m_fK * m_fCosM + m_fK * m_fK; Bzzt again, should be 1.f/(...). I'll stop looking over the code for now, but I can tell you that both eq. 11 and 13 are algebraically correct and stable. Martin From developer at netcologne.de Mon Apr 20 09:25:14 2009 From: developer at netcologne.de (Thomas Rehaag) Date: Mon Apr 20 09:25:24 2009 Subject: [music-dsp] Zoelzer & Holters 4th order EQ filters References: <50B2AB19-8533-47DD-87FF-9490DAF3B865@silberstein.de><49E86401.30E9E9ED@netcologne.de><001901c9bf5c$14d57640$0201a8c0@mooncode> <49EC4901.75D93D02@netcologne.de> <000501c9c1b8$2d496de0$0201a8c0@mooncode> Message-ID: <49EC77BA.FDAC5270@netcologne.de> > | m_fK = (float)(tan(fOmegaB / 2.f) / > | pow(fAmplitude, 1.f / 2 * m_lTotalFilterOrder)); > > Bzzt, parenthesis alarm! Should be 0.5f/m_lTotalFilterOrder. how embarrassing! Missing brackets in min. two cases!! Thanks a lot! Thomas From dgm at baykitty.com Mon Apr 20 16:25:21 2009 From: dgm at baykitty.com (Don Morgan (E-mail)) Date: Mon Apr 20 16:25:36 2009 Subject: [music-dsp] audio and a .1% shift in clocks Message-ID: I have an application that could very well require that my main clock slow by .1%. Of course, this will affect the word and bit clocks to a DAC. Has anyone had experience with the result? The reasons for the slow is the keep it in sync with video. If the clocks are slower (by 0.1%) they will be slow through out the presentation and WILL NOT be varying during it. What can I expect in artifacts? Thanks, Don From developer at netcologne.de Tue Apr 21 13:33:16 2009 From: developer at netcologne.de (Thomas Rehaag) Date: Tue Apr 21 13:33:34 2009 Subject: [music-dsp] Zoelzer & Holters 4th order EQ filters References: <50B2AB19-8533-47DD-87FF-9490DAF3B865@silberstein.de><49E86401.30E9E9ED@netcologne.de><001901c9bf5c$14d57640$0201a8c0@mooncode> <49EC4901.75D93D02@netcologne.de> <000501c9c1b8$2d496de0$0201a8c0@mooncode> Message-ID: <49EE035C.8955391C@netcologne.de> Hi Martin, hi all, sorry again for bothering you the last time with my incompetent coding. The 4th order low shelf filter works fine now after I've found two more bugs. But I've still got the problem with the lowpass to bandpass transfer by replacing the delay elements by allpasses as suggested in Eq. 16 in http://www.dafx.ca/proceedings/papers/p_037.pdf Maybe it's again a case of coding incomptence. I first rewrote Eq. 16 to A(z) = (z^-1 * cosOM - z^-2) / (1 - z^-1 * cosOM) And that lead to the following code float CAp::Process(float fIn) { m_fPrevIn2 = m_fPrevIn1; m_fPrevIn1 = m_fIn; m_fIn = fIn; float fOut = m_fCosOmM * m_fPrevIn1 - m_fPrevIn2 + m_fCosOmM * m_fPrevOut1; m_fPrevOut2 = m_fPrevOut1; m_fPrevOut1 = fOut; return fOut; } for A(z). Of course there is one instance of CAp for each of the both allpasses. And is m_fCosOmM set with m_fCosOmM = cos(2 * PI * sqrt(fFreqMax - fFreqMax) / fSampleRate); before the processing. Replacing the delays in the filter code by this function leads to instability, not to a bp shelf filter. Then I found http://www-mmdb.iai.uni-bonn.de/konferenzen/daga-sitzung06/ParametricShelving_deutsch.pdf with a nice figure of the allpass on page 13. The drived code: float Process(float fIn) { m_fPrevIn = m_fIn; m_fPrevA = m_fA; m_fIn = fIn; m_fA = m_fPrevIn + m_fCosOmM * (m_fPrevIn - m_fPrevA); float fOut = m_fPrevA + m_fCosOmM * (m_fPrevIn - m_fPrevA); m_fPrevOut1 = fOut; return fOut; } behaves the same. Both functions are stable and apply unity gain to an input sine sweep. Any help for me? Thanks, Thomas ps.: I don't have any clue why replacing the delays with allpasses should work at all. But as I wrote before, I think they know what they are doing. From earlevel at earlevel.com Tue Apr 21 21:34:05 2009 From: earlevel at earlevel.com (Nigel Redmon) Date: Tue Apr 21 21:34:00 2009 Subject: [music-dsp] fft in assmbler (htdm) In-Reply-To: <60D52748-4436-4FEF-80CA-FF1D8A542299@silberstein.de> References: <20090419011401.CB46616EB0F@ws6-8.us4.outblaze.com> <60D52748-4436-4FEF-80CA-FF1D8A542299@silberstein.de> Message-ID: <3398FAF6-BBFA-4F47-AA82-994D2B832B55@earlevel.com> On Apr 18, 2009, at 12:37 PM, bastian.schnuerle wrote: >i spent a while on motorolas dev website searching for a 56k DSP without luck. The Motorola processors were spun off via Freescale a few years ago-- try http://www.freescale.com. Motorola had an application note with an FFT implementation years ago, so I'd expect you might find it there. Otherwise, you can probably contact a field rep or technical support by phone or email and they can point you to one. (Sorry if this appears on the list twice, but after sending I remembered that the list had problems with embedded html font tags when I've sent from Mail.app as default rich text without first converting to plain text... if the other one shows up, I'll know that the problem has been addressed on the list...) From martin.eisenberg at udo.edu Wed Apr 22 09:33:26 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Wed Apr 22 09:31:18 2009 Subject: [music-dsp] Zoelzer & Holters 4th order EQ filters References: <50B2AB19-8533-47DD-87FF-9490DAF3B865@silberstein.de><49E86401.30E9E9ED@netcologne.de><001901c9bf5c$14d57640$0201a8c0@mooncode><49EC4901.75D93D02@netcologne.de><000501c9c1b8$2d496de0$0201a8c0@mooncode> <49EE035C.8955391C@netcologne.de> Message-ID: <001f01c9c34e$ee754ce0$0201a8c0@mooncode> From: "Thomas Rehaag" > A(z) = (z^-1 * cosOM - z^-2) / (1 - z^-1 * cosOM) > And that lead to the following code The code looks right from here, but combining the numerator has led you to use one too many states (and m_fPrevOut2 is also unneeded), besides making CAp a non-reusable class with a lying name. There are various ways to formulate the code using three states, but I think the clearest is simply to insert ordinary 1st-order AP's before the delays the shelf filter already contains. > m_fCosOmM = cos(2 * PI > * sqrt(fFreqMax - fFreqMax) / fSampleRate); No. First of all, that's always 1.0 because fFreqMin is misspelled. Second, the subtraction is wrong because a) this isn't about bandwidth, b) the geometric mean uses a multiply. Finally, Omega_M is actually defined by eq. 19. With the trig identity cos(atan(x)) = 1/sqrt(1+x^2), that makes the allpass coefficient c = 1/sqrt(1 + tan(OmU/2)*tan(OmL/2)). You can easily check using a plot tool that c2 = cos(sqrt(OmU*OmL)) is only a reasonable approximation of c for both edge frequencies below pi/6 or thereabouts. > ps.: I don't have any clue why replacing the delays with > allpasses should work at all. Imagine wrapping a sheet of carbon paper around a cylinder to cover the cylinder exactly n times. Now draw a wavy line looping around the cylinder's waist. Unfold the carbon paper, and what you'll see is n copies of the original line. That is basically what replacing delays with an allpass does. The cylinder's circumference The wavy loop stands for the spectrum of some filter H(z'), living on the z'-plane unit circle which is the cylinder's circumference. The width of the carbon sheet symbolizes one 2pi-length around the z-plane unit circle, and the allpass map z' = A(z) acts to relate each point in the z'-plane with multiple z values according to its order. What the analogy misses is that the angle coordinate is possibly not just replicated but also stretched and rotated -- that's how you get from lowpass to bandpass. Read more in Moorer's famous paper "The Manifold Joys of Conformal Mapping" at http://www.jamminpower.com:8080/jp/PDF/The%20Manifold%20Joys.jsp (note that when Moorer writes "z transform" he means the bilinear transform). Martin From developer at netcologne.de Wed Apr 22 12:35:12 2009 From: developer at netcologne.de (Thomas Rehaag) Date: Wed Apr 22 12:35:25 2009 Subject: [music-dsp] Zoelzer & Holters 4th order EQ filters References: <50B2AB19-8533-47DD-87FF-9490DAF3B865@silberstein.de><49E86401.30E9E9ED@netcologne.de><001901c9bf5c$14d57640$0201a8c0@mooncode><49EC4901.75D93D02@netcologne.de><000501c9c1b8$2d496de0$0201a8c0@mooncode> <49EE035C.8955391C@netcologne.de> <001f01c9c34e$ee754ce0$0201a8c0@mooncode> Message-ID: <49EF4740.BCE8EE9C@netcologne.de> Hi Martin, thanks a lot. > > m_fCosOmM = cos(2 * PI > > * sqrt(fFreqMax - fFreqMax) / fSampleRate); sorry, I shouldn't write emails after working more than 10 hours. > The code looks right from here, but combining the numerator has > led you to use one too many states so the allpass should be: float CAp::Process(float fIn) { m_fPrevIn1 = m_fIn; m_fIn = fIn; float fOut = m_fCosOmM * m_fIn - m_fPrevIn1 + m_fCosOmM * m_fPrevOut1; m_fPrevOut2 = m_fPrevOut1; m_fPrevOut1 = fOut; return fOut; } ? > but I think the clearest is simply to insert ordinary > 1st-order AP's before the delays the shelf filter already > contains. Doesn't that lead to the same result as my erroneous one state too many? I just replaced my Delay() function by the Process() above. > c = 1/sqrt(1 + tan(OmU/2)*tan(OmL/2)) Where c is my cosOM? I did that and still have an unstable system after replacing the delays. Maybe I misunderstood "replacing delay by allpass" in principle. My actual code with two forms of working low shelf filters is here: www.ismism.de/zf/eq4.zip > http://www.jamminpower.com:8080/jp/PDF/The%20Manifold%20Joys.jsp thanks again! Had a glance at it. Looks great. Best Regards, Thomas Martin Eisenberg schrieb: > > From: "Thomas Rehaag" > > > A(z) = (z^-1 * cosOM - z^-2) / (1 - z^-1 * cosOM) > > And that lead to the following code > > The code looks right from here, but combining the numerator has > led you to use one too many states (and m_fPrevOut2 is also > unneeded), besides making CAp a non-reusable class with a lying > name. There are various ways to formulate the code using three > states, but I think the clearest is simply to insert ordinary > 1st-order AP's before the delays the shelf filter already > contains. > > > m_fCosOmM = cos(2 * PI > > * sqrt(fFreqMax - fFreqMax) / fSampleRate); > > No. First of all, that's always 1.0 because fFreqMin is > misspelled. Second, the subtraction is wrong because a) this > isn't about bandwidth, b) the geometric mean uses a multiply. > Finally, Omega_M is actually defined by eq. 19. With the trig > identity cos(atan(x)) = 1/sqrt(1+x^2), that makes the allpass > coefficient > c = 1/sqrt(1 + tan(OmU/2)*tan(OmL/2)). You can easily check > using a plot tool that c2 = cos(sqrt(OmU*OmL)) is only a > reasonable approximation of c for both edge frequencies below > pi/6 or thereabouts. > > > ps.: I don't have any clue why replacing the delays with > > allpasses should work at all. > > Imagine wrapping a sheet of carbon paper around a cylinder to > cover the cylinder exactly n times. Now draw a wavy line looping > around the cylinder's waist. Unfold the carbon paper, and what > you'll see is n copies of the original line. > > That is basically what replacing delays with an allpass does. The > cylinder's circumference The wavy loop stands for the spectrum of > some filter H(z'), living on the z'-plane unit circle which is > the cylinder's circumference. The width of the carbon sheet > symbolizes one 2pi-length around the z-plane unit circle, and the > allpass map z' = A(z) acts to relate each point in the z'-plane > with multiple z values according to its order. > > What the analogy misses is that the angle coordinate is possibly > not just replicated but also stretched and rotated -- that's how > you get from lowpass to bandpass. Read more in Moorer's famous > paper "The Manifold Joys of Conformal Mapping" at > http://www.jamminpower.com:8080/jp/PDF/The%20Manifold%20Joys.jsp > (note that when Moorer writes "z transform" he means the bilinear > transform). > > Martin > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From developer at netcologne.de Wed Apr 22 12:54:25 2009 From: developer at netcologne.de (Thomas Rehaag) Date: Wed Apr 22 12:54:37 2009 Subject: [music-dsp] Zoelzer & Holters 4th order EQ filters References: <50B2AB19-8533-47DD-87FF-9490DAF3B865@silberstein.de><49E86401.30E9E9ED@netcologne.de><001901c9bf5c$14d57640$0201a8c0@mooncode><49EC4901.75D93D02@netcologne.de><000501c9c1b8$2d496de0$0201a8c0@mooncode> <49EE035C.8955391C@netcologne.de> <001f01c9c34e$ee754ce0$0201a8c0@mooncode> Message-ID: <49EF4BC1.D93D1A84@netcologne.de> Hello again, I followed your advice: > but I think the clearest is simply to insert ordinary > 1st-order AP's before the delays the shelf filter already > contains. and suddenly there's a band shelving filter!!!! So I'll celebrate that today. And tomorrow I'll try to understand the difference between a + z^-1 H(z) = z^-1 * ---------- 1 + a * z^-1 and a * z^-1 + z^-2 H(z) = ---------------- 1 + a * z^-1 :) Thomas Martin Eisenberg schrieb: > > From: "Thomas Rehaag" > > > A(z) = (z^-1 * cosOM - z^-2) / (1 - z^-1 * cosOM) > > And that lead to the following code > > The code looks right from here, but combining the numerator has > led you to use one too many states (and m_fPrevOut2 is also > unneeded), besides making CAp a non-reusable class with a lying > name. There are various ways to formulate the code using three > states, but I think the clearest is simply to insert ordinary > 1st-order AP's before the delays the shelf filter already > contains. > > > m_fCosOmM = cos(2 * PI > > * sqrt(fFreqMax - fFreqMax) / fSampleRate); > > No. First of all, that's always 1.0 because fFreqMin is > misspelled. Second, the subtraction is wrong because a) this > isn't about bandwidth, b) the geometric mean uses a multiply. > Finally, Omega_M is actually defined by eq. 19. With the trig > identity cos(atan(x)) = 1/sqrt(1+x^2), that makes the allpass > coefficient > c = 1/sqrt(1 + tan(OmU/2)*tan(OmL/2)). You can easily check > using a plot tool that c2 = cos(sqrt(OmU*OmL)) is only a > reasonable approximation of c for both edge frequencies below > pi/6 or thereabouts. > > > ps.: I don't have any clue why replacing the delays with > > allpasses should work at all. > > Imagine wrapping a sheet of carbon paper around a cylinder to > cover the cylinder exactly n times. Now draw a wavy line looping > around the cylinder's waist. Unfold the carbon paper, and what > you'll see is n copies of the original line. > > That is basically what replacing delays with an allpass does. The > cylinder's circumference The wavy loop stands for the spectrum of > some filter H(z'), living on the z'-plane unit circle which is > the cylinder's circumference. The width of the carbon sheet > symbolizes one 2pi-length around the z-plane unit circle, and the > allpass map z' = A(z) acts to relate each point in the z'-plane > with multiple z values according to its order. > > What the analogy misses is that the angle coordinate is possibly > not just replicated but also stretched and rotated -- that's how > you get from lowpass to bandpass. Read more in Moorer's famous > paper "The Manifold Joys of Conformal Mapping" at > http://www.jamminpower.com:8080/jp/PDF/The%20Manifold%20Joys.jsp > (note that when Moorer writes "z transform" he means the bilinear > transform). > > Martin > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From martin.eisenberg at udo.edu Wed Apr 22 17:24:46 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Wed Apr 22 17:22:44 2009 Subject: [music-dsp] Zoelzer & Holters 4th order EQ filters References: <50B2AB19-8533-47DD-87FF-9490DAF3B865@silberstein.de><49E86401.30E9E9ED@netcologne.de><001901c9bf5c$14d57640$0201a8c0@mooncode><49EC4901.75D93D02@netcologne.de><000501c9c1b8$2d496de0$0201a8c0@mooncode><49EE035C.8955391C@netcologne.de><001f01c9c34e$ee754ce0$0201a8c0@mooncode> <49EF4740.BCE8EE9C@netcologne.de> Message-ID: <000e01c9c390$c6ce8520$0201a8c0@mooncode> From: "Thomas Rehaag" > thanks a lot. Linving in the same timezone should count for something, no? ;) > > The code looks right from here, but combining the > > numerator has led you to use one too many states To clarify, that's not a logic error (although given your newfound success -- congrats! -- there may have been one after all), just wasteful of cache space in view of the fact that you'll have several peak filter objects, all in the same working set. > so the allpass should be: > > float CAp::Process(float fIn) > { > m_fPrevIn1 = m_fIn; > m_fIn = fIn; > float fOut = m_fCosOmM * m_fIn - m_fPrevIn1 > + m_fCosOmM * m_fPrevOut1; > m_fPrevOut2 = m_fPrevOut1; > m_fPrevOut1 = fOut; > return fOut; > } > > ? Yes with regard to factoring out the 1/z, but you haven't reduced the *overall* number of states. Actually, the structure in Holters' slides that you found uses still one state less than I had realized! In your implementation of that topology, you duplicated the expression with the multiply -- although compilers should detect that and compute it only once, I suggest you get rid of the clutter. So it would look like this: float Process(float fIn) { float fA = m_fA; float fB = m_fCosOmM * (fIn - fA); m_fA = fIn + fB; return fA + fB; } Martin From sdiedrichsen at mac.com Fri Apr 24 16:53:14 2009 From: sdiedrichsen at mac.com (Steffan Diedrichsen) Date: Fri Apr 24 16:54:51 2009 Subject: [music-dsp] fft in assmbler (htdm) In-Reply-To: <60D52748-4436-4FEF-80CA-FF1D8A542299@silberstein.de> References: <20090419011401.CB46616EB0F@ws6-8.us4.outblaze.com> <60D52748-4436-4FEF-80CA-FF1D8A542299@silberstein.de> Message-ID: Bastian, I've found an original piece of history: "Implemantation of Fast Fourier Transforms on Motorola's DSP56000/ DSP56001 and DSP96002 Digital Signal Processors". by Guy R.L. Sohie. APR4/D, REV 1 Motorola 1989 It's from times of printed application notes. If you want it, you can have it. It would be great, if those examples or maybe the complete thing will end in the MusicDSP source code archive. Contact me privately. Best, Steffan Am 19.04.2009 um 03:43 schrieb bastian.schnuerle: > > Am 19.04.2009 um 03:14 schrieb robert bristow-johnson: > >> >>> ----- Original Message ----- >>> From: "bastian.schnuerle" >>> To: "A discussion list for music-related DSP" >> > >>> Subject: Re: [music-dsp] fft in assmbler (htdm) >>> Date: Sun, 19 Apr 2009 00:28:52 +0200 >>> >>> >>> that is fantastic. i getting so excited to check this on the >>> hardware. in >>> assembler these new terms of sticky "S" bit, overflow (divide-by-2 >>> mode), do >>> or dont block-floating point seem to me as the biggest step and >>> hand >>> translating is for sure needed to achieve a mental visualization. >>> but this >>> will help for sure massively because for the first task i only >>> have to take >>> the signal to the complex domain and hand it over to the c++ host >>> code for >>> visualization. >>> >> ... >>> >>> >>> and scaling. >> >> okay, Bastian, i am trying to understand what you are needing/ >> thinking/asking. >> >> do you want 56K code to run on Digidesign TDM hardware? if so, how >> are you gonna "check this on the hardware"? > yes, exactly. a 192 with the hd1. it is ordered and i will soon get > it. >> >> or do you want to run code on a host computer? > yesno, because as far as what i have learned from digis sdk.pdf the > processed audio for display will be hand over to the c++ host code. >> >> if the former, it's gonna be some kind of fixed-point arithmetic. >> "block-floating point" is a technique to do a form of floating- >> point arithmetic on a fixed-point machine (like the 56K). if you >> are doing this on a host PC (intel), then you may as well do this >> with regular floating-point arithmetic. > that it what i am used to. and now i am understanding this term. > thanks... stayin at home on a saturday night can be very productive > thanks. >> >> or do you want a basic FFT structure that you can either use >> directly (with a C/C++ compiler) or translate to your target device? > no, the code you have just posted will be a tremendous step into the > right direction .. >> >> is this FFT going to be used for spectral analysis or display (time- >> to-frequency transformation) of audio? > for getting used to this i am lucky that it only will be used for > analysis .. > >> or is it used to process audio to spectrum and back to audio? > for the next task, yes .. >> >> in any case, feel free to use, modify, mangle, or discard any of >> that code. i am just not sure what it is that you're ultimately >> trying to do. but i don't need to know. > yeah, really ?! this is what i was trying the whole time to put down > into words. maybe this .. (see your inbox) .. > > bastian > >> -- >> >> r b-j rbj@audioimagination.com >> >> "Imagination is more important than knowledge." >> >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, source code archive, list archive, book >> reviews, dsp links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp > > -- > dupswapdrop -- the music-dsp mailing list and website:subscription > info, FAQ, source code archive, list archive, book reviews, dsp linkshttp://music.columbia.edu/cmc/music-dsphttp://music.columbia.edu/mailman/listinfo/music-dsp From bogac at bteaudio.com Fri Apr 24 17:55:21 2009 From: bogac at bteaudio.com (Bogac Topaktas) Date: Fri Apr 24 17:56:13 2009 Subject: [music-dsp] fft in assmbler (htdm) Message-ID: <3a2ee76a$13c97205$3cca9c7e$@com> > I've found an original piece of history: > "Implemantation of Fast Fourier Transforms on Motorola's DSP56000/ > DSP56001 and DSP96002 Digital Signal Processors". > by Guy R.L. Sohie. > APR4/D, REV 1 > Motorola 1989 Rev. 3 is available online: http://www.chameleon.synth.net/files/developer/pdf/motorola/APR4.pdf and more Motorola stuff: http://www.chameleon.synth.net/english/developers/techdocs.shtml -------- Original Message -------- > From: "Steffan Diedrichsen" > Sent: Friday, April 24, 2009 11:55 PM > To: "A discussion list for music-related DSP" > Subject: Re: [music-dsp] fft in assmbler (htdm) > > Bastian, > > I've found an original piece of history: > "Implemantation of Fast Fourier Transforms on Motorola's DSP56000/ > DSP56001 and DSP96002 Digital Signal Processors". > by Guy R.L. Sohie. > APR4/D, REV 1 > Motorola 1989 > > It's from times of printed application notes. If you want it, you can > have it. It would be great, if those examples or maybe the complete > thing will end in the MusicDSP source code archive. > > Contact me privately. > > Best, > > Steffan > > Am 19.04.2009 um 03:43 schrieb bastian.schnuerle: > > > > > Am 19.04.2009 um 03:14 schrieb robert bristow-johnson: > > > >> > >>> ----- Original Message ----- > >>> From: "bastian.schnuerle" > >>> To: "A discussion list for music-related DSP" >>> > > >>> Subject: Re: [music-dsp] fft in assmbler (htdm) > >>> Date: Sun, 19 Apr 2009 00:28:52 +0200 > >>> > >>> > >>> that is fantastic. i getting so excited to check this on the > >>> hardware. in > >>> assembler these new terms of sticky "S" bit, overflow (divide-by-2 > >>> mode), do > >>> or dont block-floating point seem to me as the biggest step and > >>> hand > >>> translating is for sure needed to achieve a mental visualization. > >>> but this > >>> will help for sure massively because for the first task i only > >>> have to take > >>> the signal to the complex domain and hand it over to the c++ host > >>> code for > >>> visualization. > >>> > >> ... > >>> > >>> > >>> and scaling. > >> > >> okay, Bastian, i am trying to understand what you are needing/ > >> thinking/asking. > >> > >> do you want 56K code to run on Digidesign TDM hardware? if so, how > >> are you gonna "check this on the hardware"? > > yes, exactly. a 192 with the hd1. it is ordered and i will soon get > > it. > >> > >> or do you want to run code on a host computer? > > yesno, because as far as what i have learned from digis sdk.pdf the > > processed audio for display will be hand over to the c++ host code. > >> > >> if the former, it's gonna be some kind of fixed-point arithmetic. > >> "block-floating point" is a technique to do a form of floating- > >> point arithmetic on a fixed-point machine (like the 56K). if you > >> are doing this on a host PC (intel), then you may as well do this > >> with regular floating-point arithmetic. > > that it what i am used to. and now i am understanding this term. > > thanks... stayin at home on a saturday night can be very productive > > thanks. > >> > >> or do you want a basic FFT structure that you can either use > >> directly (with a C/C++ compiler) or translate to your target device? > > no, the code you have just posted will be a tremendous step into the > > right direction .. > >> > >> is this FFT going to be used for spectral analysis or display (time- > >> to-frequency transformation) of audio? > > for getting used to this i am lucky that it only will be used for > > analysis .. > > > >> or is it used to process audio to spectrum and back to audio? > > for the next task, yes .. > >> > >> in any case, feel free to use, modify, mangle, or discard any of > >> that code. i am just not sure what it is that you're ultimately > >> trying to do. but i don't need to know. > > yeah, really ?! this is what i was trying the whole time to put down > > into words. maybe this .. (see your inbox) .. > > > > bastian > > > >> -- > >> > >> r b-j rbj@audioimagination.com > >> > >> "Imagination is more important than knowledge." > >> > >> -- > >> dupswapdrop -- the music-dsp mailing list and website: > >> subscription info, FAQ, source code archive, list archive, book > >> reviews, dsp links > >> http://music.columbia.edu/cmc/music-dsp > >> http://music.columbia.edu/mailman/listinfo/music-dsp > > > > -- > > dupswapdrop -- the music-dsp mailing list and website:subscription > > info, FAQ, source code archive, list archive, book reviews, dsp linkshttp://music.columbia.edu/cmc/music-dsphttp://music.columbia.edu/mailma n/listinfo/music-dsp > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From bastian.schnuerle at silberstein.de Sun Apr 26 14:07:01 2009 From: bastian.schnuerle at silberstein.de (bastian.schnuerle) Date: Sun Apr 26 14:07:13 2009 Subject: [music-dsp] fft in assmbler (htdm) In-Reply-To: References: <20090419011401.CB46616EB0F@ws6-8.us4.outblaze.com> <60D52748-4436-4FEF-80CA-FF1D8A542299@silberstein.de> Message-ID: <6688C746-00CE-415A-B1B2-ECE6A2BDC6E7@silberstein.de> hi steffan, this sounds amazing, i would really like to read it. and i can easily port it to digital, that is would i have done while studying for all of my professors. so this will go easy for me. how do we dnt to manage this ? greets, bastian Am 24.04.2009 um 22:53 schrieb Steffan Diedrichsen: > Bastian, > > I've found an original piece of history: > "Implemantation of Fast Fourier Transforms on Motorola's DSP56000/ > DSP56001 and DSP96002 Digital Signal Processors". > by Guy R.L. Sohie. > APR4/D, REV 1 > Motorola 1989 > > It's from times of printed application notes. If you want it, you > can have it. It would be great, if those examples or maybe the > complete thing will end in the MusicDSP source code archive. > > Contact me privately. > > Best, > > Steffan > > Am 19.04.2009 um 03:43 schrieb bastian.schnuerle: > >> >> Am 19.04.2009 um 03:14 schrieb robert bristow-johnson: >> >>> >>>> ----- Original Message ----- >>>> From: "bastian.schnuerle" >>>> To: "A discussion list for music-related DSP" >>> dsp@music.columbia.edu> >>>> Subject: Re: [music-dsp] fft in assmbler (htdm) >>>> Date: Sun, 19 Apr 2009 00:28:52 +0200 >>>> >>>> >>>> that is fantastic. i getting so excited to check this on the >>>> hardware. in >>>> assembler these new terms of sticky "S" bit, overflow (divide- >>>> by-2 mode), do >>>> or dont block-floating point seem to me as the biggest step and >>>> hand >>>> translating is for sure needed to achieve a mental >>>> visualization. but this >>>> will help for sure massively because for the first task i only >>>> have to take >>>> the signal to the complex domain and hand it over to the c++ >>>> host code for >>>> visualization. >>>> >>> ... >>>> >>>> >>>> and scaling. >>> >>> okay, Bastian, i am trying to understand what you are needing/ >>> thinking/asking. >>> >>> do you want 56K code to run on Digidesign TDM hardware? if so, >>> how are you gonna "check this on the hardware"? >> yes, exactly. a 192 with the hd1. it is ordered and i will soon >> get it. >>> >>> or do you want to run code on a host computer? >> yesno, because as far as what i have learned from digis sdk.pdf >> the processed audio for display will be hand over to the c++ host >> code. >>> >>> if the former, it's gonna be some kind of fixed-point >>> arithmetic. "block-floating point" is a technique to do a form >>> of floating-point arithmetic on a fixed-point machine (like the >>> 56K). if you are doing this on a host PC (intel), then you may >>> as well do this with regular floating-point arithmetic. >> that it what i am used to. and now i am understanding this term. >> thanks... stayin at home on a saturday night can be very >> productive thanks. >>> >>> or do you want a basic FFT structure that you can either use >>> directly (with a C/C++ compiler) or translate to your target device? >> no, the code you have just posted will be a tremendous step into >> the right direction .. >>> >>> is this FFT going to be used for spectral analysis or display >>> (time-to-frequency transformation) of audio? >> for getting used to this i am lucky that it only will be used for >> analysis .. >> >>> or is it used to process audio to spectrum and back to audio? >> for the next task, yes .. >>> >>> in any case, feel free to use, modify, mangle, or discard any of >>> that code. i am just not sure what it is that you're ultimately >>> trying to do. but i don't need to know. >> yeah, really ?! this is what i was trying the whole time to put >> down into words. maybe this .. (see your inbox) .. >> >> bastian >> >>> -- >>> >>> r b-j rbj@audioimagination.com >>> >>> "Imagination is more important than knowledge." >>> >>> -- >>> dupswapdrop -- the music-dsp mailing list and website: >>> subscription info, FAQ, source code archive, list archive, book >>> reviews, dsp links >>> http://music.columbia.edu/cmc/music-dsp >>> http://music.columbia.edu/mailman/listinfo/music-dsp >> >> -- >> dupswapdrop -- the music-dsp mailing list and website:subscription >> info, FAQ, source code archive, list archive, book reviews, dsp >> linkshttp://music.columbia.edu/cmc/music-dsphttp:// >> music.columbia.edu/mailman/listinfo/music-dsp > > -- > dupswapdrop -- the music-dsp mailing list and website:subscription > info, FAQ, source code archive, list archive, book reviews, dsp > linkshttp://music.columbia.edu/cmc/music-dsphttp:// > music.columbia.edu/mailman/listinfo/music-dsp From bastian.schnuerle at silberstein.de Sun Apr 26 14:16:23 2009 From: bastian.schnuerle at silberstein.de (bastian.schnuerle) Date: Sun Apr 26 14:16:41 2009 Subject: [music-dsp] fft in assmbler (htdm) In-Reply-To: <3a2ee76a$13c97205$3cca9c7e$@com> References: <3a2ee76a$13c97205$3cca9c7e$@com> Message-ID: <71060EF2-E73F-47F1-9B6C-D80DAAEB05B2@silberstein.de> hoppala, have i been to quick ? (i wouldnt wonder) Am 24.04.2009 um 23:55 schrieb Bogac Topaktas: > >> I've found an original piece of history: >> "Implemantation of Fast Fourier Transforms on Motorola's DSP56000/ >> DSP56001 and DSP96002 Digital Signal Processors". >> by Guy R.L. Sohie. >> APR4/D, REV 1 >> Motorola 1989 > > Rev. 3 is available online: > > http://www.chameleon.synth.net/files/developer/pdf/motorola/APR4.pdf > > and more Motorola stuff: > > http://www.chameleon.synth.net/english/developers/techdocs.shtml > > -------- Original Message -------- >> From: "Steffan Diedrichsen" >> Sent: Friday, April 24, 2009 11:55 PM >> To: "A discussion list for music-related DSP" > >> Subject: Re: [music-dsp] fft in assmbler (htdm) >> >> Bastian, >> >> I've found an original piece of history: >> "Implemantation of Fast Fourier Transforms on Motorola's DSP56000/ >> DSP56001 and DSP96002 Digital Signal Processors". >> by Guy R.L. Sohie. >> APR4/D, REV 1 >> Motorola 1989 >> >> It's from times of printed application notes. If you want it, you can >> have it. It would be great, if those examples or maybe the complete >> thing will end in the MusicDSP source code archive. >> >> Contact me privately. >> >> Best, >> >> Steffan >> >> Am 19.04.2009 um 03:43 schrieb bastian.schnuerle: >> >>> >>> Am 19.04.2009 um 03:14 schrieb robert bristow-johnson: >>> >>>> >>>>> ----- Original Message ----- >>>>> From: "bastian.schnuerle" >>>>> To: "A discussion list for music-related DSP" > >>>>> >>>>> Subject: Re: [music-dsp] fft in assmbler (htdm) >>>>> Date: Sun, 19 Apr 2009 00:28:52 +0200 >>>>> >>>>> >>>>> that is fantastic. i getting so excited to check this on the >>>>> hardware. in >>>>> assembler these new terms of sticky "S" bit, overflow (divide-by-2 >>>>> mode), do >>>>> or dont block-floating point seem to me as the biggest step and >>>>> hand >>>>> translating is for sure needed to achieve a mental visualization. >>>>> but this >>>>> will help for sure massively because for the first task i only >>>>> have to take >>>>> the signal to the complex domain and hand it over to the c++ host >>>>> code for >>>>> visualization. >>>>> >>>> ... >>>>> >>>>> >>>>> and scaling. >>>> >>>> okay, Bastian, i am trying to understand what you are needing/ >>>> thinking/asking. >>>> >>>> do you want 56K code to run on Digidesign TDM hardware? if so, how >>>> are you gonna "check this on the hardware"? >>> yes, exactly. a 192 with the hd1. it is ordered and i will soon get >>> it. >>>> >>>> or do you want to run code on a host computer? >>> yesno, because as far as what i have learned from digis sdk.pdf the >>> processed audio for display will be hand over to the c++ host code. >>>> >>>> if the former, it's gonna be some kind of fixed-point arithmetic. >>>> "block-floating point" is a technique to do a form of floating- >>>> point arithmetic on a fixed-point machine (like the 56K). if you >>>> are doing this on a host PC (intel), then you may as well do this >>>> with regular floating-point arithmetic. >>> that it what i am used to. and now i am understanding this term. >>> thanks... stayin at home on a saturday night can be very productive >>> thanks. >>>> >>>> or do you want a basic FFT structure that you can either use >>>> directly (with a C/C++ compiler) or translate to your target >>>> device? >>> no, the code you have just posted will be a tremendous step into the >>> right direction .. >>>> >>>> is this FFT going to be used for spectral analysis or display >>>> (time- >>>> to-frequency transformation) of audio? >>> for getting used to this i am lucky that it only will be used for >>> analysis .. >>> >>>> or is it used to process audio to spectrum and back to audio? >>> for the next task, yes .. >>>> >>>> in any case, feel free to use, modify, mangle, or discard any of >>>> that code. i am just not sure what it is that you're ultimately >>>> trying to do. but i don't need to know. >>> yeah, really ?! this is what i was trying the whole time to put down >>> into words. maybe this .. (see your inbox) .. >>> >>> bastian >>> >>>> -- >>>> >>>> r b-j rbj@audioimagination.com >>>> >>>> "Imagination is more important than knowledge." >>>> >>>> -- >>>> dupswapdrop -- the music-dsp mailing list and website: >>>> subscription info, FAQ, source code archive, list archive, book >>>> reviews, dsp links >>>> http://music.columbia.edu/cmc/music-dsp >>>> http://music.columbia.edu/mailman/listinfo/music-dsp >>> >>> -- >>> dupswapdrop -- the music-dsp mailing list and website:subscription >>> info, FAQ, source code archive, list archive, book reviews, dsp > linkshttp://music.columbia.edu/cmc/music-dsphttp:// > music.columbia.edu/mailma > n/listinfo/music-dsp >> >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, source code archive, list archive, book >> reviews, > dsp links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp > > > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book > reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From mailbjl at yahoo.com Sun Apr 26 17:24:59 2009 From: mailbjl at yahoo.com (Brent Lehman) Date: Sun Apr 26 17:25:16 2009 Subject: [music-dsp] Tuned Recursive Amplitude Modulation Synthesis In-Reply-To: <797899.43800.qm@web51707.mail.re2.yahoo.com> Message-ID: <289314.13287.qm@web51702.mail.re2.yahoo.com> Okay, so it's been over a year since I said I'd do this. I did try putting my idea down in writing, but I discovered that it's so elementary that there isn't much to say. After having it on the back burner for a while, I figured I'd share what I have so far and see if anyone has any ideas about either augmenting my content or publishing a single-page writeup. I don't have an introduction or conclusion section yet. TUNED RECURSIVE AMPLITUDE MODULATION SYNTHESIS ABSTRACT Amplitude modulation in digital applications involves the sample-wise multiplication of two signals in the time domain. It is known to result in the convolution of spectra in the frequency domain. This article discusses a very simple technique that takes advantage of this effect to create rich harmonic spectra, generating N partials in log N time. The algorithm also exposes several parameters to the musician for her tweaking pleasure, making a wide variety of timbres available. The number of generated partials is a power of two, but with some care and extra computation, it is possible to make any desired number. INTRODUCTION ALGORITHM We start with x0[n] = cos wn and develop successive powers of two using cosine's double-angle identity (cos 2t = 2 cos^2 t - 1), which involves only one multiplication and two additions*. Then * c <= cos(t); c2 <= c * c; c2 <= c2 + c2 - 1; I count a subtraction as an addition. x1[n] = 2 x0[n]^2 - 1 x2[n] = 2 x1[n]^2 - 1 etc. The output y is given by y[n] = -1 + PI {0..N-1} (xk[n] + Wk) / PI (1 + Wk) (Eq. 1) { "PI" represents big-pi multiplication notation. } The Ws are weighting parameters that are exposed to the musician. Figure 1 shows how each successive factor doubles the number of partials. Given some spectrum where the partials are 2^(k+1) w apart, the next factor introduces new images of the spectrum shifted to the left and right by 2^k w, resulting in a new spectrum with twice as many partials. {Figure 1} ALIAS REJECTION The frequency of the highest partial is (2^N - 1) w. Let's say we're computing (Eq. 1) in a "for" loop. Figure 2 shows why we should compute with decreasing k. If k increases, many partials can appear above the Nyquist frequency all at once; if k decreases, no more than one aliasing partial can appear per iteration, allowing us to remove them much more easily. {Figure 2} Therefore, we subtract away each aliasing partial as it appears. This requires that we keep track of the amplitude of the highest non-aliasing partial. Call this amplitude Acrit. Then, when we multiply by the kth factor, the amplitude of the highest partial is Acrit Wk. We also need the aliasing partial itself. Its frequency is walias = wcrit + 2^k w, so xalias[n] = cos (walias n) = cos (wcrit n + 2^k w n) = cos (wcrit n) cos (2^k w n) - sin (wcrit n) sin (2^k w n) = xcrit[n] xk[n] - sin (wcrit n) sin (2^k w n) (Eq. 2) We have wcrit and xcrit because we always keep track of the highest partial, whether it aliases or not. The sine values in (Eq. 2) require that we compute and store a sine counterpart to every important cosine value. Fortunately, they are easily generated from cos wn and sin wn. {Figure 3 -- pseudocode} SAMPLING RATE Of course, if the sampling rate is high enough, none of this anti-aliasing work is necessary. Call our highest perceivable frequency fmax. We want there to exist an N such that 2^N w >= fmax and fsamp - 2^N+1 w > fmax. This would insure the presence of energy throughout our hearing range while keeping any aliasing inaudibly high in frequency. These inequalities reduce to fsamp > 3fmax and the nominal value fmax = 20 kHz yields fsamp > 60 kHz. A sampling rate of 44.1 kHz corresponds to an fmax between 14 and 15 kHz, which is sufficiently high for some applications. {Take a look at the amount of energy above this range for various instruments.} APPLICATION The object of this algorithm was never to emulate real instruments, merely to add to the musician's toolbox. That said, it does various organs quite well, and approximates some other sounds, such as a sawtooth wave, a square wave, a bass guitar, and a harpsichord. Most of the other timbres produced by this algorithm sound very synthetic. I prefer to work with a very simple version of the algorithm that uses only five parameters and makes no attempt to avoid aliasing. It's computationally cheap, and in practice I've found that parameters beyond the fifth or sixth are rarely useful. Either they affect partials that will be culled anyway, or they make the sound disagreeable. Instead I put a low-pass filtered impulse train in the mix. It gives the sound needed presence in the higher frequencies where partials might not be generated. I'm not a musician, however, and the reader might prefer a different approach. Sawtooth Perhaps the best approximation of a sawtooth achievable using Tuned Recursive Amplitude Modulation Synthesis is that of a smoothly decreasing spectrum. The only way this can be done is if W0 = W1 = ... = W(N-1) = 0.5. Then the spectrum falls linearly with frequency. A value other than 0.5 results in an unsmooth, self-similar spectrum. A 1/f^beta spectrum is impossible. Consider the spectrum after the second iteration. We have a partials at frequencies 0, 2^N-2 w, 2^N-1 w, and 3 2^N-2 w, with amplitudes 1, (1 + W(N-1)) W(N-2), W(N-1), and W(N-1) W(N-2), respectively. The 1/f^beta curve requires a constant amplitude ratio between adjacent partials, but there exist no non-zero W(N-1) and W(N-2) such that (1 + W(N-1)) W(N-2) = W(N-1) / [(1 + W(N-1)) W(N-2)] = W(N-2). The fact that further iterations introduce new intermediate partials changes nothing. Square When Wk < 1 except W0 >> 1, the odd partials are much stronger than the even partials, giving the resulting sound a "squarelike" quality. Bass (W0, W1, W2, W3, W4) = (1.5, 0.56, 1.9, 0.52, 0.089) gives a sound not entirely unlike a bass guitar when played in the lower registers with the proper amplitude envelope applied. Harpsichord To get something that sounds vaguely like a harpsichord, use a sharp attack with the settings (W0, W1, W2, W3, W4) = (0.22, 0.95, 0.0, 0.89, 0.78). --- On Fri, 11/30/07, Brent Lehman wrote: > From: Brent Lehman > Subject: Re: [music-dsp] Publishing In Peer-Reviewed Journals > To: "A discussion list for music-related DSP" > > Date: Friday, November 30, 2007, 4:39 PM > Thanks to everyone for your responses. I'll go ahead > and put something together, post it on the web, and > just accept critiques from anyone. I'll put notice up > here in a week or two. Maybe later, if I feel good > about what I have, I'll submit to DAFx. I > particularly like about DAFx that they make their > papers freely available online. > > Brent > > --- Michael Gogins wrote: > > > I have published in Computer Music Journal as an > > independent researcher, also in an academic religion > > journal, both times a while back. No problem either > > time. No page charges. > > > > Also presented 2 papers and 1 poster at various > > ICMCs over the year. No problems. Of course I had to > > pay to go to the conferences myself. My impression > > is that most papers that are not obviously wacky > > will be accepted. I always immensely enjoyed the > > ICMCs. > > > > Also self-published on-line (wwww.ruccas.org). No > > problem, one paper was referenced in the Wikipedia a > > few months after I posted it (not referenced by me, > > either), others in the field have commented to me > > about the papers. > > > > So, my experience as an independent researcher with > > academic journals and conferences has been good. So > > far I have found editors, referees, and such to be > > open minded and willing to work with me. My > > experience with on-line self-publication also is not > > so bad. > > > > Either if you are not completely sure about your > > technicalities, or if you like it that papers seem > > to have more prestige, I suggest you try to get a > > paper published in a journal -- you may find the > > referee comments helpful (I found the religion > > referees very helpful, the computer music referees a > > little bit helpful). But this is a time-consuming > > process (a year or so). > > > > Hope this helps, > > Mike > > > > >From: Victor Lazzarini > > > > > > >I never had to pay to get articles published (but > > >never got paid either). I think Erik's idea of > > >publishing at DAFx is good. You can demo the > > >basic idea there and then expand it for journal > > >publication. That'll also be good if you'd like > > >to get comments or suggestions before going into > > >the submission process. > > > > > >Victor > > > > > >> > > >> Brent Lehman wrote: > > >> > > >> > I have an oscillator algorithm that appears to > > >> > be novel. Publication has been suggested to > > >> > me, > > >> > > >> Publication is good. > > >> > > >> > I'm not sure what my chances are of getting a > > >> > paper accepted anywhere. > > >> > > >> The obvious choices for this sould be the Journal > > >> of the Audio Engineering Society [0] or the > > >> Computer Music Journal [1]. Both journals have > > >> been known to publish papers from people outside > > >> academia. > > >> > > >> However, these old school paper journals tend to > > >> lock the content behind subscriber only or pay- > > >> to-view firewalls which means that for anyone > > >> to read this they have to be a subscriber or be > > >> willing to pay (in the US$20-30 range) for the > > >> right to read. This practice on the part of the > > >> journal advertisers is particularly galling > > >> because usually, the author has to pay to get > > >> their article into the journal and the referees > > >> and academic editorial staff usually work for > > >> free (hello IEEE Transactions on Signal Processing). > > >> > > >> Another (highly recommended) option would be to > > >> present the paper at a conference like DAFX [2] > > >> which always make the papers available for free > > >> on the net. > > >> > > >> Finally, you could self publish. Write something > > >> up, get someone here or elsewhere to review it > > >> for you and when you and the reviewer are both > > >> happy, put it up on a web site. > > >> > > >> Hope this helps, > > >> Erik > > >> > > >> [0] http://www.aes.org/journal/ > > >> [1] http://204.151.38.11/cmj/ > > >> [2] http://www.dafx.de/ From Victor.Lazzarini at nuim.ie Sun Apr 26 18:20:58 2009 From: Victor.Lazzarini at nuim.ie (victor) Date: Sun Apr 26 18:21:15 2009 Subject: [music-dsp] Tuned Recursive Amplitude Modulation Synthesis In-Reply-To: <289314.13287.qm@web51702.mail.re2.yahoo.com> References: <289314.13287.qm@web51702.mail.re2.yahoo.com> Message-ID: <8BDEC7B7CC9C470695B4E573ED9CCD71@LazzariniPC> I think there is a lot here that can be made into a longer paper. Although the idea is simple, it needs to be fleshed out a bit more. In particular the expressions of the algorithm need to be a lot more clear ( things like c2 <= c2 + c2 - 1 are somewhat confusing.). The operation count can be more explicit, as from what I understand the multiplication comes in two stages, the recurring powers of two and then the multiplication of the each of these terms together to generate the output (or perhaps I misunderstood the algorithm). So for N terms generating 2^N - 1 components, you have N multiplications, 2N additions for the first stage and then what looks like N divisions, N multiplications and 2N additions for the second stage. Having an idea of the typical order of N would also help. Things like the aliasing suppression might also be implemented by limiting N as you say and this can be examined in more detail (like plotting the max N for a given fundamental. N can possibly be changed in time for dynamic spectra? The applications could be discussed in more detail, esp. the role Wk has in shaping the spectrum. It would be useful to have a section on evaluation of the algorithm, perhaps comparing it to other methods. One thing I say for sure, it's definitely not a 1-page paper, if you want to do it properly. Regards Victor Lazzarini ----- Original Message ----- From: "Brent Lehman" To: "A discussion list for music-related DSP" Sent: Sunday, April 26, 2009 10:24 PM Subject: [music-dsp] Tuned Recursive Amplitude Modulation Synthesis > > Okay, so it's been over a year since I said I'd do this. I did try > putting my idea down in writing, but I discovered that it's so > elementary that there isn't much to say. After having it on the > back burner for a while, I figured I'd share what I have so far and > see if anyone has any ideas about either augmenting my content or > publishing a single-page writeup. I don't have an introduction or > conclusion section yet. > > > TUNED RECURSIVE AMPLITUDE MODULATION SYNTHESIS > > > ABSTRACT > > Amplitude modulation in digital applications involves the sample-wise > multiplication of two signals in the time domain. It is known to result > in the convolution of spectra in the frequency domain. This article > discusses a very simple technique that takes advantage of this effect to > create rich harmonic spectra, generating N partials in log N time. The > algorithm also exposes several parameters to the musician for her tweaking > pleasure, making a wide variety of timbres available. The number of > generated partials is a power of two, but with some care and extra > computation, it is possible to make any desired number. > > > INTRODUCTION > > > ALGORITHM > > We start with x0[n] = cos wn and develop successive powers of two using > cosine's double-angle identity (cos 2t = 2 cos^2 t - 1), which involves > only one multiplication and two additions*. Then > > * c <= cos(t); c2 <= c * c; c2 <= c2 + c2 - 1; I count a subtraction as an > addition. > > x1[n] = 2 x0[n]^2 - 1 > x2[n] = 2 x1[n]^2 - 1 > etc. > > The output y is given by > > y[n] = -1 + PI {0..N-1} (xk[n] + Wk) / PI (1 + Wk) (Eq. 1) > > { "PI" represents big-pi multiplication notation. } > > The Ws are weighting parameters that are exposed to the musician. Figure > 1 shows how each successive factor doubles the number of partials. Given > some spectrum where the partials are 2^(k+1) w apart, the next factor > introduces new images of the spectrum shifted to the left and right by 2^k > w, resulting in a new spectrum with twice as many partials. > > {Figure 1} > > > ALIAS REJECTION > > The frequency of the highest partial is (2^N - 1) w. Let's say we're > computing (Eq. 1) in a "for" loop. Figure 2 shows why we should compute > with decreasing k. If k increases, many partials can appear above the > Nyquist frequency all at once; if k decreases, no more than one aliasing > partial can appear per iteration, allowing us to remove them much more > easily. > > {Figure 2} > > Therefore, we subtract away each aliasing partial as it appears. This > requires that we keep track of the amplitude of the highest non-aliasing > partial. Call this amplitude Acrit. Then, when we multiply by the kth > factor, the amplitude of the highest partial is Acrit Wk. > > We also need the aliasing partial itself. Its frequency is walias = wcrit > + 2^k w, so > > xalias[n] = cos (walias n) > = cos (wcrit n + 2^k w n) > = cos (wcrit n) cos (2^k w n) - sin (wcrit n) sin (2^k w n) > = xcrit[n] xk[n] - sin (wcrit n) sin (2^k w n) (Eq. 2) > > We have wcrit and xcrit because we always keep track of the highest > partial, whether it aliases or not. The sine values in (Eq. 2) require > that we compute and store a sine counterpart to every important cosine > value. Fortunately, they are easily generated from cos wn and sin wn. > > {Figure 3 -- pseudocode} > > > SAMPLING RATE > > Of course, if the sampling rate is high enough, none of this anti-aliasing > work is necessary. Call our highest perceivable frequency fmax. We want > there to exist an N such that 2^N w >= fmax and fsamp - 2^N+1 w > fmax. > This would insure the presence of energy throughout our hearing range > while keeping any aliasing inaudibly high in frequency. These > inequalities reduce to fsamp > 3fmax and the nominal value fmax = 20 kHz > yields fsamp > 60 kHz. A sampling rate of 44.1 kHz corresponds to an fmax > between 14 and 15 kHz, which is sufficiently high for some applications. > {Take a look at the amount of energy above this range for various > instruments.} > > > APPLICATION > > The object of this algorithm was never to emulate real instruments, merely > to add to the musician's toolbox. That said, it does various organs quite > well, and approximates some other sounds, such as a sawtooth wave, a > square wave, a bass guitar, and a harpsichord. Most of the other timbres > produced by this algorithm sound very synthetic. > > I prefer to work with a very simple version of the algorithm that uses > only five parameters and makes no attempt to avoid aliasing. It's > computationally cheap, and in practice I've found that parameters beyond > the fifth or sixth are rarely useful. Either they affect partials that > will be culled anyway, or they make the sound disagreeable. Instead I put > a low-pass filtered impulse train in the mix. It gives the sound needed > presence in the higher frequencies where partials might not be generated. > I'm not a musician, however, and the reader might prefer a different > approach. > > Sawtooth > > Perhaps the best approximation of a sawtooth achievable using Tuned > Recursive Amplitude Modulation Synthesis is that of a smoothly decreasing > spectrum. The only way this can be done is if W0 = W1 = ... = W(N-1) = > 0.5. Then the spectrum falls linearly with frequency. A value other than > 0.5 results in an unsmooth, self-similar spectrum. > > A 1/f^beta spectrum is impossible. Consider the spectrum after the second > iteration. We have a partials at frequencies 0, 2^N-2 w, 2^N-1 w, and 3 > 2^N-2 w, with amplitudes 1, (1 + W(N-1)) W(N-2), W(N-1), and W(N-1) > W(N-2), respectively. The 1/f^beta curve requires a constant amplitude > ratio between adjacent partials, but there exist no non-zero W(N-1) and > W(N-2) such that (1 + W(N-1)) W(N-2) = W(N-1) / [(1 + W(N-1)) W(N-2)] = > W(N-2). The fact that further iterations introduce new intermediate > partials changes nothing. > > Square > > When Wk < 1 except W0 >> 1, the odd partials are much stronger than the > even partials, giving the resulting sound a "squarelike" quality. > > Bass > > (W0, W1, W2, W3, W4) = (1.5, 0.56, 1.9, 0.52, 0.089) gives a sound not > entirely unlike a bass guitar when played in the lower registers with the > proper amplitude envelope applied. > > Harpsichord > > To get something that sounds vaguely like a harpsichord, use a sharp > attack with the settings (W0, W1, W2, W3, W4) = (0.22, 0.95, 0.0, 0.89, > 0.78). > > > > --- On Fri, 11/30/07, Brent Lehman wrote: > >> From: Brent Lehman >> Subject: Re: [music-dsp] Publishing In Peer-Reviewed Journals >> To: "A discussion list for music-related DSP" >> >> Date: Friday, November 30, 2007, 4:39 PM >> Thanks to everyone for your responses. I'll go ahead >> and put something together, post it on the web, and >> just accept critiques from anyone. I'll put notice up >> here in a week or two. Maybe later, if I feel good >> about what I have, I'll submit to DAFx. I >> particularly like about DAFx that they make their >> papers freely available online. >> >> Brent >> >> --- Michael Gogins wrote: >> >> > I have published in Computer Music Journal as an >> > independent researcher, also in an academic religion >> > journal, both times a while back. No problem either >> > time. No page charges. >> > >> > Also presented 2 papers and 1 poster at various >> > ICMCs over the year. No problems. Of course I had to >> > pay to go to the conferences myself. My impression >> > is that most papers that are not obviously wacky >> > will be accepted. I always immensely enjoyed the >> > ICMCs. >> > >> > Also self-published on-line (wwww.ruccas.org). No >> > problem, one paper was referenced in the Wikipedia a >> > few months after I posted it (not referenced by me, >> > either), others in the field have commented to me >> > about the papers. >> > >> > So, my experience as an independent researcher with >> > academic journals and conferences has been good. So >> > far I have found editors, referees, and such to be >> > open minded and willing to work with me. My >> > experience with on-line self-publication also is not >> > so bad. >> > >> > Either if you are not completely sure about your >> > technicalities, or if you like it that papers seem >> > to have more prestige, I suggest you try to get a >> > paper published in a journal -- you may find the >> > referee comments helpful (I found the religion >> > referees very helpful, the computer music referees a >> > little bit helpful). But this is a time-consuming >> > process (a year or so). >> > >> > Hope this helps, >> > Mike >> > >> > >From: Victor Lazzarini >> >> > > >> > >I never had to pay to get articles published (but >> > >never got paid either). I think Erik's idea of >> > >publishing at DAFx is good. You can demo the >> > >basic idea there and then expand it for journal >> > >publication. That'll also be good if you'd like >> > >to get comments or suggestions before going into >> > >the submission process. >> > > >> > >Victor >> > > >> > >> >> > >> Brent Lehman wrote: >> > >> >> > >> > I have an oscillator algorithm that appears to >> > >> > be novel. Publication has been suggested to >> > >> > me, >> > >> >> > >> Publication is good. >> > >> >> > >> > I'm not sure what my chances are of getting a >> > >> > paper accepted anywhere. >> > >> >> > >> The obvious choices for this sould be the Journal >> > >> of the Audio Engineering Society [0] or the >> > >> Computer Music Journal [1]. Both journals have >> > >> been known to publish papers from people outside >> > >> academia. >> > >> >> > >> However, these old school paper journals tend to >> > >> lock the content behind subscriber only or pay- >> > >> to-view firewalls which means that for anyone >> > >> to read this they have to be a subscriber or be >> > >> willing to pay (in the US$20-30 range) for the >> > >> right to read. This practice on the part of the >> > >> journal advertisers is particularly galling >> > >> because usually, the author has to pay to get >> > >> their article into the journal and the referees >> > >> and academic editorial staff usually work for >> > >> free (hello IEEE Transactions on Signal Processing). >> > >> >> > >> Another (highly recommended) option would be to >> > >> present the paper at a conference like DAFX [2] >> > >> which always make the papers available for free >> > >> on the net. >> > >> >> > >> Finally, you could self publish. Write something >> > >> up, get someone here or elsewhere to review it >> > >> for you and when you and the reviewer are both >> > >> happy, put it up on a web site. >> > >> >> > >> Hope this helps, >> > >> Erik >> > >> >> > >> [0] http://www.aes.org/journal/ >> > >> [1] http://204.151.38.11/cmj/ >> > >> [2] http://www.dafx.de/ > > > > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From mailbjl at yahoo.com Sun Apr 26 22:32:00 2009 From: mailbjl at yahoo.com (Brent Lehman) Date: Sun Apr 26 22:32:16 2009 Subject: [music-dsp] Tuned Recursive Amplitude Modulation Synthesis In-Reply-To: <8BDEC7B7CC9C470695B4E573ED9CCD71@LazzariniPC> Message-ID: <777436.24809.qm@web51702.mail.re2.yahoo.com> Thanks, Victor. Comments below. --- On Sun, 4/26/09, victor wrote: > From: victor > Subject: Re: [music-dsp] Tuned Recursive Amplitude Modulation Synthesis > To: "A discussion list for music-related DSP" > > Date: Sunday, April 26, 2009, 3:20 PM > I think there is a lot here that can be made into a longer paper. Although the idea is simple, it needs to be fleshed out a bit more. In particular the expressions of the algorithm need to be a lot more clear (things like c2 <= c2 + c2 - 1 are somewhat confusing.). Yeah, I know I need to move to LaTeX eventually. I was trying to make an assignment operator. Maybe "c2 := c2 + c2 - 1" would have been better. > The operation count can be more explicit, as from what I understand the multiplication comes in two stages, the recurring powers of two and then the multiplication of the each of these terms together to generate the output (or perhaps I misunderstood the algorithm). So for N terms generating 2^N - 1 components, you have N multiplications, 2N additions for the first stage and then what looks like N divisions, N multiplications and 2N additions for the second stage. Having an idea of the typical order of N would also help. Here again my poor typefacing is a problem. It's just one division. Instead of PI {stuff / PI {other stuff}} it's PI {stuff} / PI {other stuff}. Also, the number of additions in the second stage is just N. Regarding the order of N, I do mention in the applications section that N is about 5 or maybe more, but maybe that statement belongs in the algorithm section. > Things like the aliasing suppression might also be implemented by limiting N as you say and this can be examined in more detail (like plotting the max N for a given fundamental. N can possibly be changed in time for dynamic spectra? I see now that the paper needs some discussion about computing the maximum useful value of N given the sampling rate and fundamental. If you decrease N (which is limited to the natural numbers) while rendering, the number of partials will change suddenly and dramatically. It's equivalent to putting a brickwall lowpass filter before the output. Increasing N won't do anything since the goal is to render all the way out to the Nyquist frequency. But maybe this information is worth adding to the paper. > The applications could be discussed in more detail, esp. the role Wk has in shaping the spectrum. The spectrum is self-similar. I agree that this should be discussed in the paper. > It would be useful to have a section on evaluation of the algorithm, perhaps comparing it to other methods. You're not the first person to suggest comparing the algorithm to other methods. The thing is, except for the importance of tuned v. detuned modulation, it's quite different from everything else I've ever seen. I'm prepared to be corrected on that point, however. Aside from comparisons, how else would I go about evaluating it? Right now the best I can come up with in that regard is, "It's pretty cool." > One thing I say for sure, it's definitely not a 1-page paper, if you want to do it properly. > > Regards > > Victor Lazzarini Thanks again, Victor. > ----- Original Message ----- From: "Brent Lehman" > > To: "A discussion list for music-related DSP" > > Sent: Sunday, April 26, 2009 10:24 PM > Subject: [music-dsp] Tuned Recursive Amplitude Modulation > Synthesis > > > > > > Okay, so it's been over a year since I said > I'd do this. I did try > > putting my idea down in writing, but I discovered that > it's so > > elementary that there isn't much to say. After > having it on the > > back burner for a while, I figured I'd share what > I have so far and > > see if anyone has any ideas about either augmenting my > content or > > publishing a single-page writeup. I don't have an > introduction or > > conclusion section yet. > > > > > > TUNED RECURSIVE AMPLITUDE MODULATION SYNTHESIS > > > > > > ABSTRACT > > > > Amplitude modulation in digital applications involves > the sample-wise multiplication of two signals in the time > domain. It is known to result in the convolution of spectra > in the frequency domain. This article discusses a very > simple technique that takes advantage of this effect to > create rich harmonic spectra, generating N partials in log N > time. The algorithm also exposes several parameters to the > musician for her tweaking pleasure, making a wide variety of > timbres available. The number of generated partials is a > power of two, but with some care and extra computation, it > is possible to make any desired number. > > > > > > INTRODUCTION > > > > > > ALGORITHM > > > > We start with x0[n] = cos wn and develop successive > powers of two using cosine's double-angle identity (cos > 2t = 2 cos^2 t - 1), which involves only one multiplication > and two additions*. Then > > > > * c <= cos(t); c2 <= c * c; c2 <= c2 + c2 - > 1; I count a subtraction as an addition. > > > > x1[n] = 2 x0[n]^2 - 1 > > x2[n] = 2 x1[n]^2 - 1 > > etc. > > > > The output y is given by > > > > y[n] = -1 + PI {0..N-1} (xk[n] + Wk) / PI (1 + Wk) > (Eq. 1) > > > > { "PI" represents big-pi multiplication > notation. } > > > > The Ws are weighting parameters that are exposed to > the musician. Figure 1 shows how each successive factor > doubles the number of partials. Given some spectrum where > the partials are 2^(k+1) w apart, the next factor introduces > new images of the spectrum shifted to the left and right by > 2^k w, resulting in a new spectrum with twice as many > partials. > > > > {Figure 1} > > > > > > ALIAS REJECTION > > > > The frequency of the highest partial is (2^N - 1) w. > Let's say we're computing (Eq. 1) in a > "for" loop. Figure 2 shows why we should compute > with decreasing k. If k increases, many partials can appear > above the Nyquist frequency all at once; if k decreases, no > more than one aliasing partial can appear per iteration, > allowing us to remove them much more easily. > > > > {Figure 2} > > > > Therefore, we subtract away each aliasing partial as > it appears. This requires that we keep track of the > amplitude of the highest non-aliasing partial. Call this > amplitude Acrit. Then, when we multiply by the kth factor, > the amplitude of the highest partial is Acrit Wk. > > > > We also need the aliasing partial itself. Its > frequency is walias = wcrit + 2^k w, so > > > > xalias[n] = cos (walias n) > > = cos (wcrit n + 2^k w n) > > = cos (wcrit n) cos (2^k w n) - sin (wcrit n) sin (2^k > w n) > > = xcrit[n] xk[n] - sin (wcrit n) sin (2^k w n) (Eq. 2) > > > > We have wcrit and xcrit because we always keep track > of the highest partial, whether it aliases or not. The sine > values in (Eq. 2) require that we compute and store a sine > counterpart to every important cosine value. Fortunately, > they are easily generated from cos wn and sin wn. > > > > {Figure 3 -- pseudocode} > > > > > > SAMPLING RATE > > > > Of course, if the sampling rate is high enough, none > of this anti-aliasing work is necessary. Call our highest > perceivable frequency fmax. We want there to exist an N > such that 2^N w >= fmax and fsamp - 2^N+1 w > fmax. > This would insure the presence of energy throughout our > hearing range while keeping any aliasing inaudibly high in > frequency. These inequalities reduce to fsamp > 3fmax > and the nominal value fmax = 20 kHz yields fsamp > 60 > kHz. A sampling rate of 44.1 kHz corresponds to an fmax > between 14 and 15 kHz, which is sufficiently high for some > applications. {Take a look at the amount of energy above > this range for various instruments.} > > > > > > APPLICATION > > > > The object of this algorithm was never to emulate real > instruments, merely to add to the musician's toolbox. > That said, it does various organs quite well, and > approximates some other sounds, such as a sawtooth wave, a > square wave, a bass guitar, and a harpsichord. Most of the > other timbres produced by this algorithm sound very > synthetic. > > > > I prefer to work with a very simple version of the > algorithm that uses only five parameters and makes no > attempt to avoid aliasing. It's computationally cheap, > and in practice I've found that parameters beyond the > fifth or sixth are rarely useful. Either they affect > partials that will be culled anyway, or they make the sound > disagreeable. Instead I put a low-pass filtered impulse > train in the mix. It gives the sound needed presence in the > higher frequencies where partials might not be generated. > I'm not a musician, however, and the reader might prefer > a different approach. > > > > Sawtooth > > > > Perhaps the best approximation of a sawtooth > achievable using Tuned Recursive Amplitude Modulation > Synthesis is that of a smoothly decreasing spectrum. The > only way this can be done is if W0 = W1 = ... = W(N-1) = > 0.5. Then the spectrum falls linearly with frequency. A > value other than 0.5 results in an unsmooth, self-similar > spectrum. > > > > A 1/f^beta spectrum is impossible. Consider the > spectrum after the second iteration. We have a partials at > frequencies 0, 2^N-2 w, 2^N-1 w, and 3 2^N-2 w, with > amplitudes 1, (1 + W(N-1)) W(N-2), W(N-1), and W(N-1) > W(N-2), respectively. The 1/f^beta curve requires a > constant amplitude ratio between adjacent partials, but > there exist no non-zero W(N-1) and W(N-2) such that (1 + > W(N-1)) W(N-2) = W(N-1) / [(1 + W(N-1)) W(N-2)] = W(N-2). > The fact that further iterations introduce new intermediate > partials changes nothing. > > > > Square > > > > When Wk < 1 except W0 >> 1, the odd partials > are much stronger than the even partials, giving the > resulting sound a "squarelike" quality. > > > > Bass > > > > (W0, W1, W2, W3, W4) = (1.5, 0.56, 1.9, 0.52, 0.089) > gives a sound not entirely unlike a bass guitar when played > in the lower registers with the proper amplitude envelope > applied. > > > > Harpsichord > > > > To get something that sounds vaguely like a > harpsichord, use a sharp attack with the settings (W0, W1, > W2, W3, W4) = (0.22, 0.95, 0.0, 0.89, 0.78). > > > > > > > > --- On Fri, 11/30/07, Brent Lehman > wrote: > > > >> From: Brent Lehman > >> Subject: Re: [music-dsp] Publishing In > Peer-Reviewed Journals > >> To: "A discussion list for music-related > DSP" > >> > >> Date: Friday, November 30, 2007, 4:39 PM > >> Thanks to everyone for your responses. I'll > go ahead > >> and put something together, post it on the web, > and > >> just accept critiques from anyone. I'll put > notice up > >> here in a week or two. Maybe later, if I feel > good > >> about what I have, I'll submit to DAFx. I > >> particularly like about DAFx that they make their > >> papers freely available online. > >> > >> Brent > >> > >> --- Michael Gogins > wrote: > >> > >> > I have published in Computer Music Journal as > an > >> > independent researcher, also in an academic > religion > >> > journal, both times a while back. No problem > either > >> > time. No page charges. > >> > > >> > Also presented 2 papers and 1 poster at > various > >> > ICMCs over the year. No problems. Of course I > had to > >> > pay to go to the conferences myself. My > impression > >> > is that most papers that are not obviously > wacky > >> > will be accepted. I always immensely enjoyed > the > >> > ICMCs. > >> > > >> > Also self-published on-line > (wwww.ruccas.org). No > >> > problem, one paper was referenced in the > Wikipedia a > >> > few months after I posted it (not referenced > by me, > >> > either), others in the field have commented > to me > >> > about the papers. > >> > > >> > So, my experience as an independent > researcher with > >> > academic journals and conferences has been > good. So > >> > far I have found editors, referees, and such > to be > >> > open minded and willing to work with me. My > >> > experience with on-line self-publication also > is not > >> > so bad. > >> > > >> > Either if you are not completely sure about > your > >> > technicalities, or if you like it that papers > seem > >> > to have more prestige, I suggest you try to > get a > >> > paper published in a journal -- you may find > the > >> > referee comments helpful (I found the > religion > >> > referees very helpful, the computer music > referees a > >> > little bit helpful). But this is a > time-consuming > >> > process (a year or so). > >> > > >> > Hope this helps, > >> > Mike > >> > > >> > >From: Victor Lazzarini > >> > >> > > > >> > >I never had to pay to get articles > published (but > >> > >never got paid either). I think > Erik's idea of > >> > >publishing at DAFx is good. You can demo > the > >> > >basic idea there and then expand it for > journal > >> > >publication. That'll also be good if > you'd like > >> > >to get comments or suggestions before > going into > >> > >the submission process. > >> > > > >> > >Victor > >> > > > >> > >> > >> > >> Brent Lehman wrote: > >> > >> > >> > >> > I have an oscillator algorithm > that appears to > >> > >> > be novel. Publication has been > suggested to > >> > >> > me, > >> > >> > >> > >> Publication is good. > >> > >> > >> > >> > I'm not sure what my > chances are of getting a > >> > >> > paper accepted anywhere. > >> > >> > >> > >> The obvious choices for this sould > be the Journal > >> > >> of the Audio Engineering Society [0] > or the > >> > >> Computer Music Journal [1]. Both > journals have > >> > >> been known to publish papers from > people outside > >> > >> academia. > >> > >> > >> > >> However, these old school paper > journals tend to > >> > >> lock the content behind subscriber > only or pay- > >> > >> to-view firewalls which means that > for anyone > >> > >> to read this they have to be a > subscriber or be > >> > >> willing to pay (in the US$20-30 > range) for the > >> > >> right to read. This practice on the > part of the > >> > >> journal advertisers is particularly > galling > >> > >> because usually, the author has to > pay to get > >> > >> their article into the journal and > the referees > >> > >> and academic editorial staff usually > work for > >> > >> free (hello IEEE Transactions on > Signal Processing). > >> > >> > >> > >> Another (highly recommended) option > would be to > >> > >> present the paper at a conference > like DAFX [2] > >> > >> which always make the papers > available for free > >> > >> on the net. > >> > >> > >> > >> Finally, you could self publish. > Write something > >> > >> up, get someone here or elsewhere to > review it > >> > >> for you and when you and the > reviewer are both > >> > >> happy, put it up on a web site. > >> > >> > >> > >> Hope this helps, > >> > >> Erik > >> > >> > >> > >> [0] http://www.aes.org/journal/ > >> > >> [1] http://204.151.38.11/cmj/ > >> > >> [2] http://www.dafx.de/ > > > > > > > > > > -- > > dupswapdrop -- the music-dsp mailing list and website: > > subscription info, FAQ, source code archive, list > archive, book reviews, dsp links > > http://music.columbia.edu/cmc/music-dsp > > http://music.columbia.edu/mailman/listinfo/music-dsp > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, > book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From padawan12 at obiwannabe.co.uk Sun Apr 26 23:43:36 2009 From: padawan12 at obiwannabe.co.uk (Andy Farnell) Date: Mon Apr 27 00:43:18 2009 Subject: [music-dsp] Tuned Recursive Amplitude Modulation Synthesis In-Reply-To: <777436.24809.qm@web51702.mail.re2.yahoo.com> References: <8BDEC7B7CC9C470695B4E573ED9CCD71@LazzariniPC> <777436.24809.qm@web51702.mail.re2.yahoo.com> Message-ID: <20090427044336.773de570.padawan12@obiwannabe.co.uk> On Sun, 26 Apr 2009 19:32:00 -0700 (PDT) Brent Lehman wrote: > Yeah, I know I need to move to LaTeX eventually. > I was trying to make an assignment operator. > Maybe "c2 := c2 + c2 - 1" would have been better. If you're going to give a pseudocode rendition then go for the LaTeX Algorithm Package, a la Knuth. It has the classical arrow style a <- 0 Otherwise, use C snippets as I suggested (yes it's fairly common in DSP papers), but whatever you do don't mix styles or invent your own hybridised notations. --- truncated -- Use the source From Victor.Lazzarini at nuim.ie Mon Apr 27 03:45:09 2009 From: Victor.Lazzarini at nuim.ie (victor) Date: Mon Apr 27 03:45:24 2009 Subject: [music-dsp] Tuned Recursive Amplitude Modulation Synthesis In-Reply-To: <777436.24809.qm@web51702.mail.re2.yahoo.com> References: <777436.24809.qm@web51702.mail.re2.yahoo.com> Message-ID: > >> The applications could be discussed in more detail, esp. the role Wk has >> in shaping the spectrum. > > The spectrum is self-similar. I agree that this should be discussed in > the paper. That in itself is an interesting idea that could be explored and discussed (self-similarity). > >> It would be useful to have a section on evaluation of the algorithm, >> perhaps comparing it to other methods. > > You're not the first person to suggest comparing the algorithm to other > methods. The thing is, except for the importance of tuned v. detuned > modulation, it's quite different from everything else I've ever seen. I'm > prepared to be corrected on that point, however. What I meant was comparing to other methods of Virtual Analogue oscillators in terms of how well it approximates the target waveforms, computation complexity, etc. Basically an assessment of the algorithm against the current practice. > Aside from comparisons, how else would I go about evaluating it? Right > now the best I can come up with in that regard is, "It's pretty cool." Well comparisons are part of it, but some tests might be useful. You can look around at other papers discussing this type of algorithm (online for instance, DAFx proceedings are good place to start) to see some examples of what can be done. Victor From sdiedrichsen at mac.com Mon Apr 27 04:32:21 2009 From: sdiedrichsen at mac.com (STEFFAN DIEDRICHSEN) Date: Mon Apr 27 04:32:44 2009 Subject: [music-dsp] fft in assmbler (htdm) / [Alert: German only, please excuse] In-Reply-To: <6688C746-00CE-415A-B1B2-ECE6A2BDC6E7@silberstein.de> References: <20090419011401.CB46616EB0F@ws6-8.us4.outblaze.com> <60D52748-4436-4FEF-80CA-FF1D8A542299@silberstein.de> <6688C746-00CE-415A-B1B2-ECE6A2BDC6E7@silberstein.de> Message-ID: <121203195771701611706411366481189729394-Webmail@me.com> Hi Bastian, sende einfach Deine Adresse an sdiedrichsen@mac.com. Dann schicke ich Dir das Teil zu. Gruss, Steffan On Sunday, April 26, 2009, at 08:07PM, "bastian.schnuerle" wrote: >hi steffan, > >this sounds amazing, i would really like to read it. and i can easily >port it to digital, that is would i have done while studying for all >of my professors. so this will go easy for me. how do we dnt to >manage this ? > >greets, > >bastian > >Am 24.04.2009 um 22:53 schrieb Steffan Diedrichsen: > >> Bastian, >> >> I've found an original piece of history: >> "Implemantation of Fast Fourier Transforms on Motorola's DSP56000/ >> DSP56001 and DSP96002 Digital Signal Processors". >> by Guy R.L. Sohie. >> APR4/D, REV 1 >> Motorola 1989 >> >> It's from times of printed application notes. If you want it, you >> can have it. It would be great, if those examples or maybe the >> complete thing will end in the MusicDSP source code archive. >> >> Contact me privately. >> >> Best, >> >> Steffan >> From vesa.norilo at saunalahti.fi Mon Apr 27 10:15:22 2009 From: vesa.norilo at saunalahti.fi (Vesa Norilo) Date: Mon Apr 27 10:15:38 2009 Subject: [music-dsp] audio and a .1% shift in clocks In-Reply-To: References: Message-ID: <49F5BDFA.6090609@saunalahti.fi> Hi, I have used it rather than implemented it, but good equipment can pull off pretty radical clock shifts without losing the lock. RME is a vendor especially good with slaving to clock signals. You might want to take a look at this: http://www.rme-audio.de/en_support_techinfo.php?page=content/support/en_support_techinfo_steadyclock I think if you can interpolate the clock changes slowly over a number of samples you'll be in better shape. Vesa > I have an application that could very well require that my main clock > slow by .1%. Of course, this will affect the word and bit clocks to a > DAC. Has anyone had experience with the result? The reasons for the > slow is the keep it in sync with video. If the clocks are slower (by > 0.1%) they will be slow through out the presentation and WILL NOT be > varying during it. > > What can I expect in artifacts? > > Thanks, > Don > -- > dupswapdrop -- the music-dsp mailing list and website:subscription > info, FAQ, source code archive, list archive, book reviews, dsp > linkshttp://music.columbia.edu/cmc/music-dsphttp://music.columbia.edu/mailman/listinfo/music-dsp > From martin.eisenberg at udo.edu Mon Apr 27 10:50:54 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Mon Apr 27 10:49:09 2009 Subject: [music-dsp] Tuned Recursive Amplitude Modulation Synthesis References: <777436.24809.qm@web51702.mail.re2.yahoo.com> Message-ID: <002101c9c747$94ba1bc0$0201a8c0@mooncode> From: "Brent Lehman" > From: victor > > It would be useful to have a section on evaluation of > > the algorithm, perhaps comparing it to other methods. > > You're not the first person to suggest comparing the > algorithm to other methods. The thing is, except for the > importance of tuned v. detuned modulation, it's quite > different from everything else I've ever seen. So, does the oscillator's behavior feel different in a structured or an incidental way? Does it access timbre regions that other methods don't easily enter? Even if not, would its natural trajectories under parameter modulation take lots of tweaking with other methods? And do they have gestural, textural, or otherwise evocative qualities? Martin From dgm at baykitty.com Mon Apr 27 11:10:18 2009 From: dgm at baykitty.com (Don Morgan (E-mail)) Date: Mon Apr 27 11:10:29 2009 Subject: [music-dsp] audio and a .1% shift in clocks In-Reply-To: <49F5BDFA.6090609@saunalahti.fi> References: <49F5BDFA.6090609@saunalahti.fi> Message-ID: <280C3468-1F76-42E8-B191-30B4FD4285B7@baykitty.com> thanks, I will look at this. Don On 2009, Apr, 27, at 7:15 AM, Vesa Norilo wrote: > Hi, > > I have used it rather than implemented it, but good equipment can > pull off pretty radical clock shifts without losing the lock. > > RME is a vendor especially good with slaving to clock signals. You > might want to take a look at this: > > http://www.rme-audio.de/en_support_techinfo.php?page=content/support/en_support_techinfo_steadyclock > > I think if you can interpolate the clock changes slowly over a > number of samples you'll be in better shape. > > Vesa >> I have an application that could very well require that my main >> clock slow by .1%. Of course, this will affect the word and bit >> clocks to a DAC. Has anyone had experience with the result? The >> reasons for the slow is the keep it in sync with video. If the >> clocks are slower (by 0.1%) they will be slow through out the >> presentation and WILL NOT be varying during it. >> >> What can I expect in artifacts? >> >> Thanks, >> Don >> -- >> dupswapdrop -- the music-dsp mailing list and website:subscription >> info, FAQ, source code archive, list archive, book reviews, dsp >> linkshttp://music.columbia.edu/cmc/music-dsphttp://music.columbia.edu/mailman/listinfo/music-dsp > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription > info, FAQ, source code archive, list archive, book reviews, dsp > links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp > From martin.eisenberg at udo.edu Mon Apr 27 12:28:11 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Mon Apr 27 12:26:03 2009 Subject: [music-dsp] Tuned Recursive Amplitude Modulation Synthesis References: <289314.13287.qm@web51702.mail.re2.yahoo.com> Message-ID: <002d01c9c755$2bd07880$0201a8c0@mooncode> From: "Brent Lehman" > x1[n] = 2 x0[n]^2 - 1 > x2[n] = 2 x1[n]^2 - 1 > etc. > > The output y is given by > > y[n] = -1 + PI {0..N-1} (xk[n] + Wk) / PI (1 + Wk) (Eq. 1) This expression for y[n] together with the stipulation that xk[n] has frequency 2^k w is really the method's core. On the other hand, the fact that you generate the xk's by recurrence is conceptually nonessential. And the recurrence depth is a-priori bounded. For these reasons I think the name "recursive AM" is misleading. How about "iterated" or more specific "dyadic AM"? > Call our highest perceivable frequency fmax. We want > there to exist an N such that 2^N w >= fmax and > fsamp - 2^N+1 w > fmax. You need to explain how you arrived at the second inequality. > A 1/f^beta spectrum is impossible. Consider the spectrum > after the second iteration. We have a partials at frequencies > 0, 2^N-2 w, 2^N-1 w, and 3 2^N-2 w, with amplitudes 1, > (1 + W(N-1)) W(N-2), W(N-1), and W(N-1) W(N-2), > respectively. Way too terse, and wrong. The respective amplitudes, neglecting the denominator of (1), are W(N-1)*W(N-2), 1/2+W(N-1), W(N-2), 1/2. > The 1/f^beta curve requires a constant amplitude ratio > between adjacent partials That is false, unless you meant "between partials associated with adjacent indices k in (1)". Martin From mailbjl at yahoo.com Mon Apr 27 14:26:27 2009 From: mailbjl at yahoo.com (Brent Lehman) Date: Mon Apr 27 14:26:39 2009 Subject: [music-dsp] Tuned Recursive Amplitude Modulation Synthesis In-Reply-To: <002d01c9c755$2bd07880$0201a8c0@mooncode> Message-ID: <11296.77808.qm@web51708.mail.re2.yahoo.com> > > x1[n] = 2 x0[n]^2 - 1 > > x2[n] = 2 x1[n]^2 - 1 > > etc. > > > > The output y is given by > > > > y[n] = -1 + PI {0..N-1} (xk[n] + Wk) / PI (1 + Wk) > (Eq. 1) > > And the recurrence depth is a-priori bounded. For these reasons I think > the name "recursive AM" is misleading. How about "iterated" or more > specific "dyadic AM"? Works for me, although I did like having a pronounceable acronym. > > Call our highest perceivable frequency fmax. We want > > there to exist an N such that 2^N w >= fmax and > > fsamp - 2^N+1 w > fmax. > > You need to explain how you arrived at the second > inequality. Good point. I'll add that to the paper. > > A 1/f^beta spectrum is impossible. Consider the spectrum > > after the second iteration. We have a partials at frequencies > > 0, 2^N-2 w, 2^N-1 w, and 3 2^N-2 w, with amplitudes 1, > > (1 + W(N-1)) W(N-2), W(N-1), and W(N-1) W(N-2), > > respectively. > > Way too terse, and wrong. The respective amplitudes, neglecting > the denominator of (1), are W(N-1)*W(N-2), 1/2+W(N-1), > W(N-2), 1/2. Oh dear, I did get it wrong, and I confess I forgot all about the denominator of (1). But now I think the amplitudes are W(N-1)*W(N-2), 1+W(N-1), W(N-2), 1. Where did you get the '1/2's from? > > The 1/f^beta curve requires a constant amplitude ratio > > between adjacent partials > > That is false, unless you meant "between partials associated with > adjacent indices k in (1)". Yikes, I got 1/f^beta mixed up with 1/beta^f. Because of these two mistakes, I'll need to rethink large parts of the paper. Thanks for pointing these out! From mailbjl at yahoo.com Mon Apr 27 15:10:32 2009 From: mailbjl at yahoo.com (Brent Lehman) Date: Mon Apr 27 15:10:53 2009 Subject: [music-dsp] Tuned Recursive Amplitude Modulation Synthesis In-Reply-To: <002101c9c747$94ba1bc0$0201a8c0@mooncode> Message-ID: <523882.6397.qm@web51709.mail.re2.yahoo.com> From: Martin Eisenberg > So, does the oscillator's behavior feel different in a structured or an > incidental way? Does it access timbre regions that other methods don't > easily enter? Even if not, would its natural trajectories under parameter > modulation take lots of tweaking with other methods? And do > they have gestural, textural, or otherwise evocative qualities? Yikes, I don't know the answers to these questions. I've been thinking in terms of how it behaves mathematically. The spectra this oscillator creates are different from what you easily get with other methods, and I can say that parameter tweaks sound different from other sweeps you hear, like FM, PWM, filter sweeps, sync sweeps, etc. The higher parameters sound a bit like EQ changes since they effect large groups of adjacent partials, but the lower parameters are, well, different. From martin.eisenberg at udo.edu Mon Apr 27 17:32:25 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Mon Apr 27 17:30:16 2009 Subject: [music-dsp] Tuned Recursive Amplitude Modulation Synthesis References: <11296.77808.qm@web51708.mail.re2.yahoo.com> Message-ID: <001701c9c77f$abf05c40$0201a8c0@mooncode> From: "Brent Lehman" > > How about "iterated" or more specific "dyadic AM"? > > Works for me, although I did like having a pronounceable > acronym. "Dham" (h for "harmonic" which is more precise than "tuned") is Hindi for "temple, shrine" if you go in for that kind of reference. > > > Consider the spectrum after the second iteration. > > > We have a partials at frequencies 0, 2^N-2 w, 2^N-1 w, > > > and 3 2^N-2 w, with amplitudes 1, (1 + W(N-1)) W(N-2), > > > W(N-1), and W(N-1) W(N-2), respectively. > > > > Way too terse, and wrong. The respective amplitudes, > > neglecting the denominator of (1), are W(N-1)*W(N-2), > > 1/2+W(N-1), W(N-2), 1/2. > > Oh dear, I did get it wrong, and I confess I forgot all about > the denominator of (1). But now I think the amplitudes are > W(N-1)*W(N-2), 1+W(N-1), W(N-2), 1. Where did you get > the '1/2's from? We have 2 x(N-1) x(N-2) = cos((2^(N-1) + 2^(N-2)) wt) + cos((2^(N-1) - 2^(N-2)) wt) = cos(3 2^(N-2) wt) + x(N-2), and so (x(N-1) + W(N-1)) (x(N-2) + W(N-2)) - W(N-1) W(N-2) = (1/2 + W(N-1)) x(N-2) + W(N-2) x(N-1) + 1/2 cos(3 2^(N-2) wt). Martin From martin.eisenberg at udo.edu Mon Apr 27 18:12:20 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Mon Apr 27 18:10:16 2009 Subject: [music-dsp] Tuned Recursive Amplitude Modulation Synthesis References: <289314.13287.qm@web51702.mail.re2.yahoo.com> Message-ID: <002301c9c785$3f6c26c0$0201a8c0@mooncode> From: "Brent Lehman" > parameters beyond the fifth or sixth are rarely useful. > Either they affect partials that will be culled anyway, > or they make the sound disagreeable. How so? Valuation needs supporting description. Many grid levels mean a low fundamental and concomitant dense partial spacing. The latter might perceptually approach a continuous (rather than line) spectrum as characterizes stochastic processes, if the "fine" partials are strong. If they become weak enough, perceived pitch could switch from the true fundamental up to some wider-spaced prominent subseries -- perhaps even jump back and forth among several apparent octaves only to dissolve back into noise as the parameters change! Now that's just my imagination playing, but if you can in fact identify such phenomena it would answer to the texture/gesture aspect I brought up and could actually be rather interesting. Should you have little taste for such non-melodic behavior, I suppose it would be fine to leave investigating its controllability to those who do. Martin From Victor.Lazzarini at nuim.ie Mon Apr 27 18:43:34 2009 From: Victor.Lazzarini at nuim.ie (victor) Date: Mon Apr 27 18:43:44 2009 Subject: [music-dsp] Tuned Recursive Amplitude Modulation Synthesis In-Reply-To: <002301c9c785$3f6c26c0$0201a8c0@mooncode> References: <289314.13287.qm@web51702.mail.re2.yahoo.com> <002301c9c785$3f6c26c0$0201a8c0@mooncode> Message-ID: It looks like there might just be a lot more potential to this algorithm than quasi-bandlimited waveforms. This should be worth a look. Victor ----- Original Message ----- From: "Martin Eisenberg" To: "A discussion list for music-related DSP" Sent: Monday, April 27, 2009 11:12 PM Subject: Re: [music-dsp] Tuned Recursive Amplitude Modulation Synthesis > From: "Brent Lehman" > >> parameters beyond the fifth or sixth are rarely useful. >> Either they affect partials that will be culled anyway, >> or they make the sound disagreeable. > > How so? Valuation needs supporting description. > > Many grid levels mean a low fundamental and concomitant dense > partial spacing. The latter might perceptually approach a > continuous (rather than line) spectrum as characterizes > stochastic processes, if the "fine" partials are strong. If they > become weak enough, perceived pitch could switch from the true > fundamental up to some wider-spaced prominent subseries -- > perhaps even jump back and forth among several apparent octaves > only to dissolve back into noise as the parameters change! > > Now that's just my imagination playing, but if you can in fact > identify such phenomena it would answer to the texture/gesture > aspect I brought up and could actually be rather interesting. > Should you have little taste for such non-melodic behavior, I > suppose it would be fine to leave investigating its > controllability to those who do. > > > Martin > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From mailbjl at yahoo.com Mon Apr 27 18:54:01 2009 From: mailbjl at yahoo.com (Brent Lehman) Date: Mon Apr 27 18:54:12 2009 Subject: [music-dsp] Tuned Recursive Amplitude Modulation Synthesis In-Reply-To: <002301c9c785$3f6c26c0$0201a8c0@mooncode> Message-ID: <235865.17790.qm@web51702.mail.re2.yahoo.com> From: Martin Eisenberg > From: "Brent Lehman" > > > parameters beyond the fifth or sixth are rarely useful. > > Either they affect partials that will be culled anyway, > > or they make the sound disagreeable. > > How so? Valuation needs supporting description. Good point. I'll be more descriptive and objective. > Many grid levels mean a low fundamental and concomitant > dense partial spacing. The latter might perceptually approach a > continuous (rather than line) spectrum as characterizes > stochastic processes, if the "fine" partials are > strong. If they become weak enough, perceived pitch could switch > from the true fundamental up to some wider-spaced prominent > subseries -- perhaps even jump back and forth among several apparent > octaves only to dissolve back into noise as the parameters change! I'm so glad you brought this up. I never considered the possibility of a fundamental below 40 Hz or so. Just now I fired it up and played around in the range of 6-9 octaves below middle C and got some interesting textures out of it. The implementation I have handy does only N=9. When I have time I'll throw one together with N=20 and check out fundamentals in the multi-milliHertz range. Thanks so much! From TSV at TSVDESIGN.NEt Tue Apr 28 06:53:45 2009 From: TSV at TSVDESIGN.NEt (Toni Simonen) Date: Tue Apr 28 05:54:13 2009 Subject: [music-dsp] GUI design offer (many screenshots) Message-ID: <49F6E039.9090105@TSVDESIGN.NEt> Hello everyone, I am once again offering high quality GUI design and other graphic services for music instruments. You can find more on my updated site at www.tsvdesign.net. You can view my portfolio and details there. TSV Design / www.tsvdesign.net tsv@tsvdesign.net Thank you! From TSV at TSVDESIGN.NEt Tue Apr 28 07:57:37 2009 From: TSV at TSVDESIGN.NEt (Toni Simonen) Date: Tue Apr 28 06:58:13 2009 Subject: [music-dsp] GUI design offer (many screenshots) In-Reply-To: <49F6E039.9090105@TSVDESIGN.NEt> References: <49F6E039.9090105@TSVDESIGN.NEt> Message-ID: <49F6EF31.7010307@TSVDESIGN.NEt> Alright, the site should be working now (at least for firefox and IE). Accidentally deleted xml file from the server when updating! www.tsvdesign.net Sorry. From TSV at TSVDESIGN.NEt Tue Apr 28 13:48:01 2009 From: TSV at TSVDESIGN.NEt (Toni Simonen) Date: Tue Apr 28 12:48:40 2009 Subject: [music-dsp] GUI design offer (many screenshots) In-Reply-To: <49F6E039.9090105@TSVDESIGN.NEt> References: <49F6E039.9090105@TSVDESIGN.NEt> Message-ID: <49F74151.5050908@TSVDESIGN.NEt> The site is working now for all browsers (please give it time to load in the beginning). Some people also missed that theres more than one section on the portfolio page! www.tsvdesign.net Thanks. -- Toni Simonen TSV Design From Gualtiero.Volpe at unige.it Tue Apr 28 13:01:03 2009 From: Gualtiero.Volpe at unige.it (Gualtiero Volpe) Date: Tue Apr 28 13:01:26 2009 Subject: [music-dsp] REMINDER - eNTERFACE'09 Call for Participation Message-ID: <000a01c9c822$eb120600$c1361200$@Volpe@unige.it> [Sorry for cross-postings] *************************************************************************** CALL FOR PARTICIPATION *************************************************************************** Casa Paganini - InfoMus Lab in collaboration with the Openinterface Foundation, the EU IST CALLAS and the EU ICT SAME Projects present eNTERFACE'09 the 5th Intl. Summer Workshop on Multimodal Interfaces Genova, Italy, July 13th - August 7th, 2009 Call for Participation The eNTERFACE 2009 Workshop is being organized this summer in Genova, Italy, from July 13th to August 7th, 2009. The Workshop will be held at Casa Paganini - InfoMus Lab (www.casapaganini.org), DIST-University of Genova. The eNTERFACE Workshops present an opportunity of collaborative research and software development by gathering, in a single place, a team of senior project leaders in multimodal interfaces, PhD students, and (undergraduate) students, to work on a pre-specified list of challenges, for the duration of four weeks. Participants are organized in teams, assigned to specific projects. eNTERFACE'09 will also encompass presentation sessions, including tutorial state-of-the-art surveys on several aspects of design of multimodal interfaces, given by invited senior researchers, and periodical presentations of the results achieved by each project group. The ultimate goal is to make this event a unique opportunity for students and experts all over the world to meet and effectively work together, so as to foster the development of tomorrow's multimodal research community. Outcome of synergy and success stories of past eNTERFACE Workshops held in Mons, Belgium (2005), Dubrovnik, Croatia (2006), Istanbul, Turkey (2007), and Paris, France (2008), can be seen at www.enterface.net. Senior researchers, PhD, or undergraduate students interested in participating to the Workshop should send their application by emailing the Organizing Committee at enterface09@casapaganini.org on or before April 30, 2009. The application should contain: * A short CV * A list of three preferred projects to work on * A list of skills to offer for these projects. Participants must procure their own travel and accommodation expenses. Information about the venue location and stay are provided on the eNTERFACE'09 website (www.infomus.org/enterface09). Note that although no scholarships are available for PhD students, there are no application fees and the estimated cost of lodging and meals for the full four weeks is about 1000 Euros. eNTERFACE'09 will welcome students, researchers, and seniors, working in teams on the following projects: #01 Multimodal monitoring of the behavioural and physiological state of the user in interactive VR games #02 Coordination between signal and semantic fusion of multimodal data #03 Multimodal guitar: performance toolkit and/or study workbench #04 Video navigation tool: application to browsing a database of dancers' performances #05 A multi-player game using neurophysiological sensors #06 Playful interaction in a multi-tracking environment #07 Attention-based gestures expressivity analysis in a collective context #08 AVLaughterCycle #09 Interactivity of an affective puppet The full detailed description of the projects is available at www.infomus.org/enterface09 From mailbjl at yahoo.com Thu Apr 30 01:11:17 2009 From: mailbjl at yahoo.com (Brent Lehman) Date: Thu Apr 30 01:11:32 2009 Subject: [music-dsp] Tuned Recursive Amplitude Modulation Synthesis In-Reply-To: <235865.17790.qm@web51702.mail.re2.yahoo.com> Message-ID: <608554.99543.qm@web51703.mail.re2.yahoo.com> I did some quick prototyping in an app called SynthMaker. It's a great environment if you want to throw together a meat-and-potatoes virtual synth, but if you want to do anything the designers didn't think of, it's a pain in the butt. I say this because the results I got were strange and I don't trust them because of the app. The pitch seemed to shift by a quarter tone occasionally, and once in a while the amplitude values became quantized. It makes me want to try it again using double-precision arithmetic, which really isn't possible in SynthMaker. So I'll see what I can whip up this weekend. Despite the somewhat wonky output, however, a couple of things are clear. The output is rhythmic, which makes sense considering the spectrum is self-similar and everything's related by powers of two. Also, the output needs to go through heavy compression because the partials all have zero phase. It results in big amplitude spikes with very quiet sound in between. > > Many grid levels mean a low fundamental and concomitant > > dense partial spacing. The latter might perceptually approach a > > continuous (rather than line) spectrum as characterizes > > stochastic processes, if the "fine" partials are > > strong. If they become weak enough, perceived pitch could switch > > from the true fundamental up to some wider-spaced prominent > > subseries -- perhaps even jump back and forth among several apparent > > octaves only to dissolve back into noise as the parameters change! > > I'm so glad you brought this up. I never considered > the possibility of a fundamental below 40 Hz or so. Just > now I fired it up and played around in the range of 6-9 > octaves below middle C and got some interesting textures out > of it. The implementation I have handy does only N=9. When > I have time I'll throw one together with N=20 and check > out fundamentals in the multi-milliHertz range. Thanks so > much!