From douglas at music.columbia.edu Fri May 1 07:00:00 2009 From: douglas at music.columbia.edu (douglas repetto) Date: Fri May 1 07:00:03 2009 Subject: [music-dsp] [admin] music-dsp FAQ Message-ID: <20090501110000.599B47277DB@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 improvization at rocketmail.com Sat May 2 10:07:05 2009 From: improvization at rocketmail.com (improvization) Date: Sat May 2 10:07:19 2009 Subject: [music-dsp] Digitally tuned oscilllator Message-ID: <743105.19744.qm@web52403.mail.re2.yahoo.com> I would like to know how to step down the following digitally tuned ocsillator....one with a?3 ghz output so it does not blow my speaker for recording music From czhenry at gmail.com Sat May 2 15:36:53 2009 From: czhenry at gmail.com (Charles Henry) Date: Sat May 2 15:37:07 2009 Subject: [music-dsp] Digitally tuned oscilllator In-Reply-To: <743105.19744.qm@web52403.mail.re2.yahoo.com> References: <743105.19744.qm@web52403.mail.re2.yahoo.com> Message-ID: <518fe7b20905021236q269f1400s7c941b5fa99197ec@mail.gmail.com> Frequency divider IC's. You can always cascade them to get whatever factor of division you need. Division by multiples of 2 is the most common. You'll get a square wave output. ummm.... 3 GHz would take a lot of volts to blow your speakers, just because they won't respond at anything like that frequency. The loudspeaker impedance at 3GHZ should be some enormous number, so there's little to no power transmitted. Chuck On Sat, May 2, 2009 at 9:07 AM, improvization wrote: > > I would like to know how to step down the following digitally tuned ocsillator....one with a?3 ghz output so it does not blow my speaker for recording music > > > > -- > 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 May 3 05:37:13 2009 From: padawan12 at obiwannabe.co.uk (Andy Farnell) Date: Sun May 3 06:36:39 2009 Subject: [music-dsp] Tuned Recursive Amplitude Modulation Synthesis In-Reply-To: <289314.13287.qm@web51702.mail.re2.yahoo.com> References: <797899.43800.qm@web51707.mail.re2.yahoo.com> <289314.13287.qm@web51702.mail.re2.yahoo.com> Message-ID: <20090503103713.11e789bd.padawan12@obiwannabe.co.uk> On self similarity and proximity to other models, perhaps look at the fractal nature and relationship to the form x[n] = x[n-1]^2 + c. For the right initial conditions you could be zooming in on the edge of {M} And hence the very small phase/amplitude values. (??) a. On Sun, 26 Apr 2009 14:24:59 -0700 (PDT) Brent Lehman wrote: > > 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 -- Use the source From thevinn at yahoo.com Sun May 3 08:21:47 2009 From: thevinn at yahoo.com (Vinnie) Date: Sun May 3 08:21:59 2009 Subject: [music-dsp] A Collection of C++ Classes for Digital Signal Processing In-Reply-To: <20090503103638.D9E267451A1@music.columbia.edu> Message-ID: <969779.35743.qm@web58201.mail.re3.yahoo.com> I will soon be publishing this as an open source (MIT License) project on SourceForge. Before I put it out I would love some feedback. I have not compiled it anywhere except Microsoft Visual Studio 2008. It is a single C++ header file: http://www.box.net/shared/93x1v1aedn There are some optional functions for SSE3 optimized processing (MSVC specific). >From the header: Support is provided for performing N-order Dsp floating point filter operations on M-channel data with a caller specified floating point type. The implementation breaks a high order IIR filter down into a series of cascaded second order stages. Tests conclude that numerical stability is maintained even at higher orders. For example the Butterworth low pass filter is stable at up to 53 poles. Processing functions are provided to use either Direct Form I or Direct Form II of the filter transfer function. Direct Form II is slightly faster but can cause discontinuities in the output if filter parameters are changed during processing. Direct Form I is slightly slower, but maintains fidelity even when parameters are changed during processing. To support fast parameter changes, filters provide two functions for adjusting parameters. A high accuracy Setup() function, and a faster form called SetupFast() that uses approximations for trigonometric functions. The approximations work quite well and should be suitable for most applications. The following filters are currently available: BiquadLowPass BiquadHighPass BiquadBandPass1 BiquadBandPass2 BiquadBandStop BiquadAllPass BiquadPeakEq BiquadLowShelf BiquadHighShelf ButterLowPass ButterHighPass ButterBandPass ButterBandStop Cheby1LowPass Cheby1HighPass Cheby1BandPass Cheby1BandStop Cheby2LowPass Cheby2HighPass Cheby2BandPass Cheby2BandStop Biquads of course are order 2, while the Butterworth and Chebyshev varieties can go to any order. The cascade is optimized so that processing N interleaved channels at once is much faster than filtering each channel individual (especially for the SSE3 optimized cases). From andrew.capon at zen.co.uk Sun May 3 08:26:22 2009 From: andrew.capon at zen.co.uk (Andrew Capon) Date: Sun May 3 08:26:32 2009 Subject: [music-dsp] A Collection of C++ Classes for Digital Signal Processing In-Reply-To: <969779.35743.qm@web58201.mail.re3.yahoo.com> References: <969779.35743.qm@web58201.mail.re3.yahoo.com> Message-ID: <786FC36A-A1D8-41AE-BF1D-B63DC54DC477@zen.co.uk> Looks interesting, I could give you some help with an OS X build if you fancy. I think you need examples of use as templates can confuse many! Andy On 3 May 2009, at 13:21, Vinnie wrote: > > I will soon be publishing this as an open source (MIT License) > project on SourceForge. Before I put it out I would love some > feedback. I have not compiled it anywhere except Microsoft Visual > Studio 2008. It is a single C++ header file: > > http://www.box.net/shared/93x1v1aedn > > There are some optional functions for SSE3 optimized processing > (MSVC specific). > >> From the header: > > Support is provided for performing N-order Dsp floating point filter > operations on M-channel data with a caller specified floating point > type. The implementation breaks a high order IIR filter down into a > series of cascaded second order stages. Tests conclude that > numerical stability is maintained even at higher orders. For example > the Butterworth low pass filter is stable at up to 53 poles. > > Processing functions are provided to use either Direct Form I or > Direct Form II of the filter transfer function. Direct Form II is > slightly faster but can cause discontinuities in the output if > filter parameters are changed during processing. Direct Form I is > slightly slower, but maintains fidelity even when parameters are > changed during processing. > > To support fast parameter changes, filters provide two functions for > adjusting parameters. A high accuracy Setup() function, and a faster > form called SetupFast() that uses approximations for trigonometric > functions. The approximations work quite well and should be suitable > for most applications. > > The following filters are currently available: > BiquadLowPass > BiquadHighPass > BiquadBandPass1 > BiquadBandPass2 > BiquadBandStop > BiquadAllPass > BiquadPeakEq > BiquadLowShelf > BiquadHighShelf > ButterLowPass > ButterHighPass > ButterBandPass > ButterBandStop > Cheby1LowPass > Cheby1HighPass > Cheby1BandPass > Cheby1BandStop > Cheby2LowPass > Cheby2HighPass > Cheby2BandPass > Cheby2BandStop > > Biquads of course are order 2, while the Butterworth and Chebyshev > varieties can go to any order. The cascade is optimized so that > processing N interleaved channels at once is much faster than > filtering each channel individual (especially for the SSE3 optimized > cases). > > > -- > 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 didid at skynet.be Sun May 3 09:39:26 2009 From: didid at skynet.be (Didier Dambrin) Date: Sun May 3 09:39:39 2009 Subject: [music-dsp] A Collection of C++ Classes for Digital SignalProcessing In-Reply-To: <969779.35743.qm@web58201.mail.re3.yahoo.com> References: <969779.35743.qm@web58201.mail.re3.yahoo.com> Message-ID: Interesting. I have my own SSE2-optimized biquad processing, and tried to switch to the ones in Intel's IPP, but they don't support interlaced channels, and as you wrote, one can get much better performances by processing interlaced channels (considering IIR processing isn't much parallelizable). That's for my need of processing interlaced stereo, however are you saying you did the same for cascaded biquads, in layers lagging each by 1 sample maybe? Sounds very useful. Btw, which SSE3 instruction(s) did you find useful here? > I will soon be publishing this as an open source (MIT License) project on > SourceForge. Before I put it out I would love some feedback. I have not > compiled it anywhere except Microsoft Visual Studio 2008. It is a single > C++ header file: > > http://www.box.net/shared/93x1v1aedn > > There are some optional functions for SSE3 optimized processing (MSVC > specific). > >>From the header: > > Support is provided for performing N-order Dsp floating point filter > operations on M-channel data with a caller specified floating point type. > The implementation breaks a high order IIR filter down into a series of > cascaded second order stages. Tests conclude that numerical stability is > maintained even at higher orders. For example the Butterworth low pass > filter is stable at up to 53 poles. > > Processing functions are provided to use either Direct Form I or Direct > Form II of the filter transfer function. Direct Form II is slightly faster > but can cause discontinuities in the output if filter parameters are > changed during processing. Direct Form I is slightly slower, but maintains > fidelity even when parameters are changed during processing. > > To support fast parameter changes, filters provide two functions for > adjusting parameters. A high accuracy Setup() function, and a faster form > called SetupFast() that uses approximations for trigonometric functions. > The approximations work quite well and should be suitable for most > applications. > > The following filters are currently available: > BiquadLowPass > BiquadHighPass > BiquadBandPass1 > BiquadBandPass2 > BiquadBandStop > BiquadAllPass > BiquadPeakEq > BiquadLowShelf > BiquadHighShelf > ButterLowPass > ButterHighPass > ButterBandPass > ButterBandStop > Cheby1LowPass > Cheby1HighPass > Cheby1BandPass > Cheby1BandStop > Cheby2LowPass > Cheby2HighPass > Cheby2BandPass > Cheby2BandStop > > Biquads of course are order 2, while the Butterworth and Chebyshev > varieties can go to any order. The cascade is optimized so that processing > N interleaved channels at once is much faster than filtering each channel > individual (especially for the SSE3 optimized cases). > > > -- > 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.5.325 / Virus Database: 270.12.15/2093 - Release Date: 05/02/09 14:23:00 From thevinn at yahoo.com Sun May 3 10:07:01 2009 From: thevinn at yahoo.com (Vinnie) Date: Sun May 3 10:07:19 2009 Subject: [music-dsp] Re: A Collection of C++ Classes for Digital Signal Processing In-Reply-To: <20090503133953.2CE04746C8D@music.columbia.edu> Message-ID: <761763.62822.qm@web58202.mail.re3.yahoo.com> > From: Andrew Capon > I could give you some help with an OS X > build if you fancy. That would be great. Hopefully it will all work without change but if I need to modify anything just let me know. I would love to make sure this works on as many compilers and systems as possible. I am fairly confident that the actual algorithms should work fine. Although I think I did make some assumptions that the underlying floating point representation is IEEE compliant. > I think you need examples of use as templates can confuse many! I agree! Thanks for pointing this out, I totally forgot. I just uploaded a new version of the code with an example function at the bottom of the header, its called FilteringExample(). Let me know if I need to provide more examples (I think I covered everything). > From: "Didier Dambrin" > are you saying you did the same for cascaded biquads > in layers lagging each by 1 sample The CascadeFilter class implements an abitrary order IIR filter by using a series cascade of second order stages. Each channel's stage maintains its own history but the coefficients for a stage are shared between channels. There is no "lag" other than that expected phase response from a filter of that type and order. Note that for the case where the underlying data is in a smaller floating point representation than the type used for calculation, the optimized results will be slightly different than the unoptimized. That is because the data is processed in a different order, with intermediate stage results getting written back into the destination instead of carried through in the calculation type. > Btw, which SSE3 instruction(s) did you find useful here? This was my first ever SSE3 code (and the first assembly in quite a long time) so it is possible that it could be improved. The one SSE3 instruction that I needed was _mm_hadd_pd(). The rest use the SSE2 instruction set. If anyone wants to show me how I could do it better, with fewer registers, or without the need for SSE3 instructions (does that even matter?), or tell me why I should be using more SSE3 instructions, or anything whatsoever, I'm all ears. From andrew.capon at zen.co.uk Sun May 3 10:31:35 2009 From: andrew.capon at zen.co.uk (Andrew Capon) Date: Sun May 3 10:31:47 2009 Subject: [music-dsp] Re: A Collection of C++ Classes for Digital Signal Processing In-Reply-To: <761763.62822.qm@web58202.mail.re3.yahoo.com> References: <761763.62822.qm@web58202.mail.re3.yahoo.com> Message-ID: <9A061195-966E-4EBC-9EA0-9D2EAA34140D@zen.co.uk> > >> I think you need examples of use as templates can confuse many! > > I agree! Thanks for pointing this out, I totally forgot. I just > uploaded a new version of the code with an example function at the > bottom of the header, its called FilteringExample(). Let me know if > I need to provide more examples (I think I covered everything). Looks good to me, it is enough to get non template sort of people going. I will look at building it in XCode, from a quick look at the code I think it will work with no issues, but then again I have been wrong before! From didid at skynet.be Sun May 3 10:50:26 2009 From: didid at skynet.be (Didier Dambrin) Date: Sun May 3 10:50:50 2009 Subject: [music-dsp] Re: A Collection of C++ Classes for Digital SignalProcessing In-Reply-To: <761763.62822.qm@web58202.mail.re3.yahoo.com> References: <761763.62822.qm@web58202.mail.re3.yahoo.com> Message-ID: <26F66C856C5F4FB4A4F78DF36D1FA831@GOLAMD> > The CascadeFilter class implements an abitrary order IIR filter by using a > series cascade of second order stages. Each channel's stage maintains its > own history but the coefficients for a stage are shared between channels. > There is no "lag" other than that expected phase response from a filter of > that type and order. > Then I'm confused, what did you mean by: "The cascade is optimized so that processing N interleaved channels at once is much faster than filtering each channel individual" We're talking about independent interleaved channels as interleaved stereo, right? That's what I'm doing right now (mem & coeff as double float, so that SSE2 processes stereo & mono at pretty much the same speed). However I believe it's also possible to process stages together using packed instructions if there's a lag of 1 sample (in the processing, not the result) so that the second filter processes the result of the first filter, while the first filter processes the current sample, but I never bothered with that. I'm also wondering what you used HADDPD for. Most likely our codes are pretty different. If that matters, here's the amount of instructions for my main loop of a biquad, for a pair of stereo samples (in/out is single precision, coeff & mem is double): // lr MOVAPD xmm0,xmm6 // x1 MULPD xmm7,xmm1 // x2*b2 MULPD xmm0,[ESI+16] // *b1 MULPD xmm5,xmm3 // y2*a2 SUBPD xmm0,xmm5 MOVAPD xmm5,xmm4 // y2:=y1 ADDPD xmm0,xmm7 MULPD xmm4,xmm2 // *a1 SUBPD xmm0,xmm4 MOVAPD xmm7,xmm6 // x2:=x1 // x1:=SourceBuffer^ CVTPS2PD xmm4,[ECX+EBX*8] // convert to doubles MOVAPD xmm6,xmm4 // x1 // y1:=v+b0*x1 MULPD xmm4,[ESI] // *b0 ADDPD xmm4,xmm0 CVTPD2PS xmm0,xmm4 // convert to singles MOVLPS [EDI+EBX*8],xmm0 // store From thevinn at yahoo.com Sun May 3 10:59:42 2009 From: thevinn at yahoo.com (Vinnie) Date: Sun May 3 10:59:54 2009 Subject: [music-dsp] Re: A Collection of C++ Classes for Digital Signal Processing In-Reply-To: <20090503145048.B4FAA747832@music.columbia.edu> Message-ID: <507677.15040.qm@web58208.mail.re3.yahoo.com> > From: "Didier Dambrin" > I'm also wondering what you used HADDPD for. Most > likely our codes are pretty different. Like I said this is my first SSE code ever, and I haven't done any assembler in well over a decade. There is probably a better way than how I did it. I am not familiar with the SSE instruction set so I dont know what is available. I did not think to process both channels at the same time, my implementation processes one channel at a time but it performs the multiplications in parallel. I will study your code and see if I can get an improvement by processing the samples together. Doing so might help me eliminate the HADDPD. Thanks, Vinnie From martin.eisenberg at udo.edu Sun May 3 11:30:03 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Sun May 3 11:27:51 2009 Subject: [music-dsp] A Collection of C++ Classes for Digital SignalProcessing References: <969779.35743.qm@web58201.mail.re3.yahoo.com> Message-ID: <001d01c9cc04$0b49ef20$0201a8c0@mooncode> From: "Vinnie" > http://www.box.net/shared/93x1v1aedn > Processing functions are provided to use either Direct > Form I or Direct Form II of the filter transfer function. The DF2 is numerically inferior to DF2-transposed which is what you should implement. Besides, the current code is broken, as a statement like "a = b = c;" just gives both a and b the value of c, it does not shift the values. | #include | #include That's redundant. | // Complex number template, inspired by Java. I avoided | so that // this header file could stand alone. I don't get what the problem with is -- after all you don't reimplement the required subset of either. On the other hand, if I'm going to filter complex data then probably I already have a complex class in use (and chances are it's std::complex), so your decision means some hassle for me. | template | class CascadeFilter This contains several things that really don't depend on the template parameters (or at least not on their being statically known). Move those things into a non-template base class to reduce code bloat. I'm also not convinced of the value in making "skip" a template parameter. | // ALL SSE OPTIMIZATIONS ASSUME CalcT as double Then I should be unable to run them differently to begin with. Insert a compile-time assertion to that effect in the relevant CascadeFilter section. Martin From thevinn at yahoo.com Mon May 4 05:38:51 2009 From: thevinn at yahoo.com (Vinnie) Date: Mon May 4 05:39:07 2009 Subject: [music-dsp] Pure Genius In-Reply-To: <20090503103638.D9E267451A1@music.columbia.edu> Message-ID: <548408.87368.qm@web58205.mail.re3.yahoo.com> Apparently I am too dumb to figure out how to upload my one DSP header file to SourceForge, I just wasted the last 20 minutes trying to figure it out. I am so frustrated I think I am going to give up trying. From thevinn at yahoo.com Mon May 4 06:05:17 2009 From: thevinn at yahoo.com (Vinnie) Date: Mon May 4 06:05:29 2009 Subject: [music-dsp] Re: A Collection of C++ Classes for Digital Signal Processing In-Reply-To: <20090504093909.434DA7535F4@music.columbia.edu> Message-ID: <916997.89658.qm@web58204.mail.re3.yahoo.com> > From: "Martin Eisenberg" > The DF2 is numerically inferior to DF2-transposed which is > what you should implement. Can you please give me a link? All I could find were the diagrams and I have trouble reading those. > Besides, the current code is broken, > as a statement like "a = b = c;" just gives both a and > b the value of c, it does not shift the values. I guess you are talking about CalcT d2=h->v[2]=h->v[1]; CalcT d1=h->v[1]=h->v[0]; These statements seem to be working fine. v[1]->v[2] and v[0]->v[1] which is exactly what is intended. d1 and d2 get copies in registers for computation. And it sounds great! This was all tested in a production application with real audio data. > I don't get what the problem with is -- > after all you don't reimplement the required subset of > either. What do you mean by required subset? I wanted a complex class that was under my control. At some point I will be using approximations for the trigonometric functions in the ComplexT class itself. Especially for operations like ::sqrt(). > On the other hand, if I'm going to filter complex data then > probably I already have a complex class in use (and chances are > it's std::complex), so your decision means some hassle for me. Say what? You mean run the filter on an array of complex numbers? I did not know that was a use case. I'm not sure my code supports that. It definitely doesn't work with integers as the underlying type. I wouldn't even know how to test such a thing to see if it sounded right. But regardless, if you wanted to run the filter on complex numbers and it somehow works I don't see a problem. You can still use std::complex as template parameter T, its just that the pole computations will use ComplexT. > This contains several things that really don't depend > on the template parameters (or at least not on their being > statically known). Yes I see what you mean. There is also the problem that if one wanted to dynamically choose the number of poles at runtime it could be a bit unwieldly to use. I will try to factor the class a bit better. > Move those things into a non-template base class to > reduce code bloat. When you say code bloat do you mean the generated code? Shouldn't the compiler know when a method doesn't truly depend on template parameters and just emit one copy for all instantiations? > I'm also not convinced of the value > in making "skip" a template parameter. Do you mean it should be a paramter to the function with a default value of 0? Thats a good idea. Or do you mean that having 'skip' is unneccesary? I feel that it is necessary for the case where one wishes to process only a subset of multichannel data. Having it as a parameter would be helpful though, I will change it. Thanks! > | // ALL SSE OPTIMIZATIONS ASSUME CalcT as double > > Then I should be unable to run them differently to begin > with. Insert a compile-time assertion to that effect in the > relevant CascadeFilter section. I agree 100%. My C++/template knowledge has gaps though. How exactly do I write a compile-time assertion to check CalcT==double? I would also like to provide SSE implementation where CalcT is float, how would I do that? There's also that annoying warning about "conditional expression is constant" in ProcessI() where I do the following: #ifdef SSE3_OPTIMIZED if( channels==2 ) ProcessISSE2( frames, dest ); else #endif I wanted to do this using a partial template specialization but that is either impossible, MSVC doesn't support it, or I just don't know the syntax. How can I specialize just one parameter from the template? Specifically if I have template template void CascadeFilter::ProcessI( size_t frames, T *dest ); And I want to provide a version where stages is configurable but channels is 2 how do I do that? This doesn't work: template template void CascadeFilter::ProcessI( size_t frames, T *dest ) Nor does this template template void CascadeFilter::ProcessI( size_t frames, T *dest ) And finally as you pointed out some routines don't depend on the template arguments. In fact, the Process() functions certainly don't. stages and channels could be simply passed in as parameters, with default values from the derived template class' stages and channels template parameters. I will take everything you described under consideration and make some changes. From Victor.Lazzarini at nuim.ie Mon May 4 06:14:24 2009 From: Victor.Lazzarini at nuim.ie (victor) Date: Mon May 4 06:14:55 2009 Subject: [music-dsp] Pure Genius In-Reply-To: <548408.87368.qm@web58205.mail.re3.yahoo.com> References: <548408.87368.qm@web58205.mail.re3.yahoo.com> Message-ID: Are you using CVS, subversion or just the file release facility? For the latter, it should just be a simple case of web upload, but you can use ssh and other tools too, whichever is the one you are most happy with. I don't know much subversion, but with CVS it should be just a case of using 'cvs import'. Victor ----- Original Message ----- From: "Vinnie" To: Sent: Monday, May 04, 2009 10:38 AM Subject: [music-dsp] Pure Genius > > Apparently I am too dumb to figure out how to upload my one DSP header > file to SourceForge, I just wasted the last 20 minutes trying to figure it > out. I am so frustrated I think I am going to give up trying. > > -- > 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 thevinn at yahoo.com Mon May 4 06:24:48 2009 From: thevinn at yahoo.com (Vinnie) Date: Mon May 4 06:25:02 2009 Subject: [music-dsp] Re: A Collection of C++ Classes for Digital Signal In-Reply-To: <20090504101455.8BE2C753BED@music.columbia.edu> Message-ID: <172703.89891.qm@web58202.mail.re3.yahoo.com> > From: "Martin Eisenberg" > This contains several things that really don't > depend on the template parameters (or at least not on their > being statically known). If I factor the class as you suggested (and its a good idea to), then how do I keep the function in the header file? If its not templatized then I have to inline it and we're back to the bloat. I like the single-header distribution model it keeps things simple. From thevinn at yahoo.com Mon May 4 07:07:37 2009 From: thevinn at yahoo.com (Vinnie) Date: Mon May 4 07:07:46 2009 Subject: [music-dsp] Re: music-dsp Digest, Vol 65, Issue 4 In-Reply-To: <20090504093909.434DA7535F4@music.columbia.edu> Message-ID: <709830.38742.qm@web58208.mail.re3.yahoo.com> > From: "Martin Eisenberg" > ... Oh yeah by the way...obviously you spent some time looking at the code and I just wanted to say thanks, it is appreciated. From martin.eisenberg at udo.edu Mon May 4 09:33:08 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Mon May 4 09:31:01 2009 Subject: [music-dsp] Re: A Collection of C++ Classes for Digital SignalProcessing References: <916997.89658.qm@web58204.mail.re3.yahoo.com> Message-ID: <001e01c9ccbc$e02f8b60$0201a8c0@mooncode> From: "Vinnie" > > From: "Martin Eisenberg" > > The DF2 is numerically inferior to DF2-transposed > > which is what you should implement. > > Can you please give me a link? All I could find were the > diagrams and I have trouble reading those. It seems harder to ferret out a link than give the code: out = in * b[0] + v[0]; v[0] = in * b[1] + out * a[1] + v[1]; v[1] = in * b[2] + out * a[2]; Surely you can see how this corresponds to the flow diagram. In general, each output or state cell generates an assignment, and each path backwards from that object up to another state, output, or input generates a term on the right-hand side. The rest is sequencing. > CalcT d2=h->v[2]=h->v[1]; > CalcT d1=h->v[1]=h->v[0]; > > These statements seem to be working fine. Sorry, I misread what you're doing! > > I don't get what the problem with is -- > > after all you don't reimplement the required subset > > of either. > > What do you mean by required subset? The part of that your file uses. > I wanted a complex class that was under my control. > At some point I will be using approximations for the > trigonometric functions in the ComplexT class itself. > Especially for operations like ::sqrt(). But you could provide those either way, like you did for reals. What is it that you want to control? > Say what? You mean run the filter on an array of > complex numbers? I did not know that was a use case. It's hardly an everyday use in the audio context. I had just convinced myself there were complex Process() overloads but now I see it was something else. > > I'm also not convinced of the value > > in making "skip" a template parameter. > > Do you mean it should be a paramter to the function with > a default value of 0? Yes, that's what I meant. I'll address the other template points later. Martin From martin.eisenberg at udo.edu Mon May 4 09:41:50 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Mon May 4 09:39:35 2009 Subject: [music-dsp] Re: A Collection of C++ Classes for Digital SignalProcessing References: <916997.89658.qm@web58204.mail.re3.yahoo.com> Message-ID: <000701c9ccbe$175579a0$0201a8c0@mooncode> You should also document the polarity of denominator coefficients that your code expects, since both forms 1 + sum ai/z^i and 1 - sum ai/z^i are common in the literature. Martin From thevinn at yahoo.com Mon May 4 10:47:51 2009 From: thevinn at yahoo.com (Vinnie) Date: Mon May 4 10:48:04 2009 Subject: [music-dsp] Re: A Collection of C++ Classes for Digital Signal Processing In-Reply-To: <20090504133103.127AF755BE4@music.columbia.edu> Message-ID: <427572.87857.qm@web58204.mail.re3.yahoo.com> The file has been updated: http://www.box.net/shared/93x1v1aedn As per advice here I have made the following changes: - Factored CascadeFilter into CascadeStages to work mostly without templates - Moved skip from a template argument into a function parameter - Changed ComplexT to an interface compatible with std::complex - Compile time switch for using std::complex instead of ComplexT From thevinn at yahoo.com Mon May 4 14:56:19 2009 From: thevinn at yahoo.com (Vinnie) Date: Mon May 4 14:56:30 2009 Subject: [music-dsp] A Collection of C++ Classes for Digital Signal Processing (SourceForge) In-Reply-To: <20090504133103.127AF755BE4@music.columbia.edu> Message-ID: <474594.23142.qm@web58204.mail.re3.yahoo.com> I finally figured out how to get the file up to SourceForge. Here it is: http://sourceforge.net/projects/dspfilterscpp/ From developer at netcologne.de Tue May 5 08:40:06 2009 From: developer at netcologne.de (Thomas Rehaag) Date: Tue May 5 08:40:32 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: <4A0033A6.AC15F46B@netcologne.de> Hi Martin, I just came back to the filters after some relaxing jobs and found an error. You wrote: > 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)). and as far as I can see, this would be true if Eq. 19 was (tan(OmM))^2 = tan(OmU/2) * tan(OmL/2) but it is (tan(OmM/2))^2 = tan(OmU/2) * tan(OmL/2) and so c = cos(OmM) = cos( 2 * atan(sqrt(tan(OmU/2) * tan(OmL/2)))) I've tried this equation with the example filters in table 1 and it seems to work fine. Now my question: do you know a trig identity to simplify cos(2 * atan(x))? 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 Tue May 5 09:28:16 2009 From: developer at netcologne.de (Thomas Rehaag) Date: Tue May 5 09:28:33 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> <4A0033A6.AC15F46B@netcologne.de> Message-ID: <4A003EF0.BCB18CC2@netcologne.de> found it myselfe, thanks to my good old math book: cos(2*x) = (1 - tan(x)^2) / (1 - tan(x)^2) so c = cos(OmM) = (1 - tan(OmU/2)*tan(OmL/2))/(1 + tan(OmU/2)*tan(OmL/2)) nice! Best Regards, Thomas Thomas Rehaag schrieb: > > Hi Martin, > > I just came back to the filters after some relaxing jobs and found an > error. > You wrote: > > > 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)). > > and as far as I can see, this would be true if Eq. 19 was > > (tan(OmM))^2 = tan(OmU/2) * tan(OmL/2) > > but it is > > (tan(OmM/2))^2 = tan(OmU/2) * tan(OmL/2) > > and so > > c = cos(OmM) = cos( 2 * atan(sqrt(tan(OmU/2) * tan(OmL/2)))) > > I've tried this equation with the example filters in table 1 and it > seems to work fine. > Now my question: do you know a trig identity to simplify cos(2 * > atan(x))? > > 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 > -- > 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 Tue May 5 09:47:15 2009 From: developer at netcologne.de (Thomas Rehaag) Date: Tue May 5 09:47:38 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> <4A0033A6.AC15F46B@netcologne.de> <4A003EF0.BCB18CC2@netcologne.de> Message-ID: <4A004363.E17FF0A7@netcologne.de> and even better: c = cos(OmM) = cos(OmU + OmL) / cos(OmU - OmL) Thomas Rehaag schrieb: > > found it myselfe, thanks to my good old math book: > > cos(2*x) = (1 - tan(x)^2) / (1 - tan(x)^2) > > so > > c = cos(OmM) = (1 - tan(OmU/2)*tan(OmL/2))/(1 + tan(OmU/2)*tan(OmL/2)) > > nice! > > Best Regards, > > Thomas > > Thomas Rehaag schrieb: > > > > Hi Martin, > > > > I just came back to the filters after some relaxing jobs and found an > > error. > > You wrote: > > > > > 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)). > > > > and as far as I can see, this would be true if Eq. 19 was > > > > (tan(OmM))^2 = tan(OmU/2) * tan(OmL/2) > > > > but it is > > > > (tan(OmM/2))^2 = tan(OmU/2) * tan(OmL/2) > > > > and so > > > > c = cos(OmM) = cos( 2 * atan(sqrt(tan(OmU/2) * tan(OmL/2)))) > > > > I've tried this equation with the example filters in table 1 and it > > seems to work fine. > > Now my question: do you know a trig identity to simplify cos(2 * > > atan(x))? > > > > 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 > > -- > > 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 May 5 09:53:14 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Tue May 5 09:51:04 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> <4A0033A6.AC15F46B@netcologne.de> Message-ID: <002301c9cd88$d9ecf040$0201a8c0@mooncode> From: "Thomas Rehaag" > c = cos(OmM) = cos( 2 * atan(sqrt(tan(OmU/2) * tan(OmL/2)))) You're right, I lost a factor 2. > Now my question: do you know a trig identity to simplify > cos(2 * atan(x))? Inserting the previously cited cos(atan(x)) = 1/sqrt(1+x^2) in the cosine double-angle formula yields cos(2*atan(x)) = 2/(1+x^2)-1 = (1-x^2)/(1+x^2), with lower numerical error in the second form. Martin From vadim.zavalishin at native-instruments.de Wed May 6 08:12:25 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Wed May 6 08:12:32 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing Message-ID: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077> Hi everyone Here's a new article about the sine waveform syncing antialiasing. Three different methods are proposed. I don't know if this is a pioneering work, or just repeating someone else's footsteps, anyway FWIW. http://www.native-instruments.de/index.php?id=dsparticles Comments welcome. One correction: in the references the article says that the full preview of the current edition of NR in C++ is available online. Apparently, this is no longer the case, but I was somewhat loath to correct the already finished article after finding out. I apologize for the mistake. Anyway, an older edition still is. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From martin.eisenberg at udo.edu Wed May 6 11:06:29 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Wed May 6 11:04:26 2009 Subject: [music-dsp] Re: A Collection of C++ Classes for Digital SignalProcessing References: <427572.87857.qm@web58204.mail.re3.yahoo.com> Message-ID: <001601c9ce5c$3ff98500$0201a8c0@mooncode> > http://www.box.net/shared/93x1v1aedn | - Need fast version of pow( 10, x ) I have only skimmed it, but this looks interesting: http://cnl.salk.edu/~schraudo/pubs.html#exp | typedef int Int32; // Must be 32 bits Only long int is guaranteed to be that wide. | template | ComplexT operator+ ( const ComplexT &c ) const; Having these operators makes the non-template overloads superfluous since their To == T instantiations will do exactly the same thing. recip(): Both versions miss a minus sign in the result imaginary part. BrentMinimize(): | static const CalcT SQRT_DBL_EPSILON = | ::sqrt(DBL_EPSILON); Being unfamiliar with Brent's method I'm not sure how important it is, but I suppose if you want to allow CalcT == float then the above line ought to use std::numeric_limits::epsilon(). Also, a quick comparison with the treatment in [1] seems to indicate that you have switched the roles of that constant and parameter epsilon in the line below: | tol = SQRT_DBL_EPSILON*::fabs(x) + epsilon; [1] Numerical Recipes, ch. 10-2 http://www.nrbook.com/a/bookcpdf.php CascadeFilter::Reset(): Is this actually useful? Wherever you call it the coefficients immediately receive new values anyway. [Reading some more...] Oh, I get it. You're relying on this so that SetA/BStage will latch onto the next slot on each call. That's not only a needless hack but also makes the runtime of Setup() overriders quadratic in the number of stages. Just pass an index into SetA/BStage. I know that interferes with your trick of folding successive 1st-order sections (a bug: s->b[0]=x0 should use *= -- but it's moot, read on), which is kinda neat as long as coefficients are fixed. But when they vary in time such that section folding is incidentally triggered, all downstream history states will suddenly get operated upon by different coef sets. This means glitches -- and more glitches when the particular subfilter gets back its own stage a bit later. The only way to ensure smooth state evolution is to forgo the optimization of section folding in the time-varying case. But you could have a separate function FoldStages() that also calls Clear() and invoking which constitutes a promise that stage orders won't change before the next call to Clear() or FoldStages(). xxBandPass::PassbandHint(): That should be a geometric, not arithmetic, mean; and except at bandwidths up to about pi/6 you need to form the mean of BLT-unwarped values and warp that back. So the body would be: return 2*atan(sqrt(tan(m_wc*0.5) * tan(m_wc2*0.5))); Unfortunately the simplifications from my recent exchange with Thomas don't apply here. xxBandStop::PassbandHint(): Isn't the magnitude the same at 0 and pi anyway? And BrentHint(), all versions: I suspect it's superfluous to contract the interval by some delta as you do. Martin From martin.eisenberg at udo.edu Wed May 6 11:29:36 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Wed May 6 11:27:26 2009 Subject: [music-dsp] Re: A Collection of C++ Classes for Digital SignalProcessing References: <916997.89658.qm@web58204.mail.re3.yahoo.com> Message-ID: <001d01c9ce5f$7a59f2e0$0201a8c0@mooncode> From: "Vinnie" > > From: "Martin Eisenberg" > > Move those things into a non-template base class to > > reduce code bloat. > > When you say code bloat do you mean the generated > code? Shouldn't the compiler know when a method doesn't > truly depend on template parameters and just emit one > copy for all instantiations? That's not mandated. It's even been argued to be non-conformant because unless the compiler inserts some no-ops, instantiation merging makes formally different functions have the same address. And depending on the precise way the toolchain implements templates, it may still generate the code n times, increasing compile duration if not executable size. Finally, merging can only work if the instantiations are truly identical which most things you've now extracted weren't. > If I factor the class as you suggested (and its a good idea > to), then how do I keep the function in the header file? If its > not templatized then I have to inline it and we're back to > the bloat. Not quite. First, nontrivial inline-declared functions don't necessarily get expanded just because they're visible. Second and in contrast to above, copies of an inline function in multiple translation units are also formally the same. They are easily marked in object files so the linker need not second-guess the code generator in this case, though this does nothing for compile duration either. > How exactly do I write a compile-time assertion to check > CalcT==double? Here's a simple version, expanding slightly on https://www.securecoding.cert.org/confluence/display/seccode /DCL03-C.+Use+a+static+assertion+to+test+the+value+of+a+ constant+expression #define JOIN(x, y) JOIN_AGAIN(x, y) #define JOIN_AGAIN(x, y) x ## y #define STATIC_ASSERT(e, msg) \ typedef char JOIN(assertion_ ## msg ## _failed_at_line_, __LINE__) [(e) ? 1 : -1] template struct is_same { enum { value = false }; }; template struct is_same { enum { value = true }; }; typedef int T; STATIC_ASSERT((is_same::value), T_is_not_double); > template > template > void CascadeFilter::ProcessI( > size_t frames, T *dest ) You can't do that without partially specializing the whole class template first, duplicating -- or moving to another helper base -- everything beside the specific function. This is because a (partial or full) specialization is an independent entity and can be totally different from the general case. > And finally as you pointed out some routines don't depend > on the template arguments. In fact, the Process() functions > certainly don't. The same is true of virtually all the subclasses. Actually, given the way the new CascadeStages class looks, both remaining template parameters could just as well go into the constructor leaving you with no integral template parameters anywhere... Martin From thevinn at yahoo.com Wed May 6 12:01:51 2009 From: thevinn at yahoo.com (Vinnie) Date: Wed May 6 12:02:04 2009 Subject: [music-dsp] Re: A Collection of C++ Classes for Digital Signal Processing Message-ID: <590977.62854.qm@web58202.mail.re3.yahoo.com> > From: "Martin Eisenberg" Let me just open up by saying that I am by no means an expert on signal processing. I just started into the field from scratch a couple of weeks ago. Most of the algorithms in the code I published came from elsewhere. Paul Falstad's Java applet in particular (see the credits). My "value-add" was in putting it all together in C++, making it easy to integrate (single header file), use of templates for flexibility in the underlying type and number of channels, and some optimizations (including SSE3), and testing in a professional (unreleased) application. I was frustrated at what I perceived to be a lack of production quality C++ filtering code published under a commercial-use friendly license so I threw this together. > | template > | ComplexT operator+ ( const ComplexT &c ) > const; > Having these operators makes the non-template overloads > superfluous since their To == T instantiations will do > exactly the same thing. Yep I see that. I added the other operators as an afterthought and never cleaned out the old ones. However, I did provide a compiler switch for doing away with my Complex class completely. When I put in the trigonometric approximations I will see if I can get rid of the ComplexT class. I haven't figured out how the API for the fast setup of PoleFilter parameters is going to work yet. The Biquads were easy. > recip(): Both versions miss a minus sign in the result > imaginary > part. Are you saying it should read return std::complex( n*c.real(), - n*c.imag() ); Apparently it doesn't matter because I tried it that way and it produces the same results. I tested the Chebyshev 2 filters (those are the only ones that use recip()). > BrentMinimize(): > | static const CalcT SQRT_DBL_EPSILON = > | ::sqrt(DBL_EPSILON); > > Being unfamiliar with Brent's method I'm not sure > how important it is, but I suppose if you want to allow CalcT == float > then the above line ought to use > std::numeric_limits::epsilon(). Brent's method is a function minimization algorithm that is similar to gradient descent, but using parabolas. I use it to find the top of the ripple on chebyshev filters to normalize them for unity gain in the passband. I already do HintPassband() for as many cases as possible but for the bandpass chebyshev type I there is no "safe" place to sample the magnitude response so I must resort to a numerical technique. > Also, a quick comparison with the treatment in [1] seems to > indicate that you have switched the roles of that constant > and parameter epsilon in the line below: > > | tol = SQRT_DBL_EPSILON*::fabs(x) + epsilon; I have to admit I am fuzzy on the math. I just took Brent's method from the Internet. I have Numerical Recipes but the code is restricted so I am prevented from using it. I don't understand the math behind Brent's method. > That's not only a needless hack but also makes the > runtime of Setup() overriders quadratic in the number of stages. Just > pass an index into SetA/BStage. Quadratic performance is unacceptible, especially after my efforts at implementing SetupFast()! Major oversight on my part. I didn't understand exactly what Set#Stage() were doing but now that you've explained it, I understand better. I will fix it! > I know that interferes with your trick of folding > successive 1st-order sections (a bug: s->b[0]=x0 should use *= -- > but it's moot, read on) Its not "my" trick and I didn't know what it was doing until you explained it. So there's a bug? > which is kinda neat as long as coefficients > are fixed. But when they vary in time such that section folding > is incidentally triggered, all downstream history states will > suddenly get operated upon by different coef sets. I don't understand what you are saying. If coefficients vary then all stages need to be recalculated. > The only way to ensure smooth state evolution is to forgo > the optimization of section folding in the time-varying case. > But you could have a separate function FoldStages() that also calls > Clear() and invoking which constitutes a promise that stage > orders won't change before the next call to Clear() or > FoldStages(). What is state evolution? What is the time-varying case? > xxBandPass::PassbandHint(): That should be a geometric, not > arithmetic, mean; and except at bandwidths up to about pi/6 > you need to form the mean of BLT-unwarped values and warp that > back. So the body would be: > return 2*atan(sqrt(tan(m_wc*0.5) * tan(m_wc2*0.5))); I'm guessing BLT doesn't mean Bacon Lettuce and Tomato. For PassbandHint() all I wanted to do was choose a value for the angular frequency that was as far away as possible from anything that deviates from unity gain. I figured the middle of the passband was ideal since it is the farthest from the rolloffs at either side. Are you saying that the formula you provided can be used in place of Brent's method for finding the top of the ripple in the case of Chebyshev Type I band-pass filters? > xxBandStop::PassbandHint(): Isn't the magnitude the > same at 0 and pi anyway? Yes but just in case there are artifacts caused by extreme parameter values and floating point quantization, I choose the side that is farther away from the roll off area. > And BrentHint(), all versions: I suspect > it's superfluous to contract the interval by some delta as you > do. I did that just in case the evaluation of the magnitude response at 0 and PI is undefined. Once again thanks for the tips. From thevinn at yahoo.com Wed May 6 12:04:16 2009 From: thevinn at yahoo.com (Vinnie) Date: Wed May 6 12:04:27 2009 Subject: [music-dsp] Blurps and Chirps when changing filter parameters In-Reply-To: <20090506150436.69F7B775390@music.columbia.edu> Message-ID: <108217.42179.qm@web58206.mail.re3.yahoo.com> In my library "A Collection of C++ Classes for Digital Signal Processing", when I sweep the frequency on Biquads it sounds great. But when I sweep the frequency on some of the higher order low pass and high pass types (Butterworth in particular) I hear some weirdness. The faster I change frequencies, the bigger the extra sound. Initially I was using Direct Form II which is very succeptible to that. So I switched to Direct form I and my 2-poles sounded great but when I use higher orders, even with Direct Form I there is some extra sound when changing parameter values. Is this research paper directly relevant to my problem: http://www.native-instruments.de/fileadmin/redaktion_upload/pdf/KeepTopology.pdf It sounds like it is. Unfortunately it is almost impossible for me to understand!! Can anyone help? From bogac at bteaudio.com Wed May 6 13:17:55 2009 From: bogac at bteaudio.com (Bogac Topaktas) Date: Wed May 6 13:18:53 2009 Subject: [music-dsp] Blurps and Chirps when changing filter parameters Message-ID: <40b185f8$4645eba5$1bbc81db$@com> If you want to eliminate signal disturbances during real-time coefficient update then you need to pay special attention during selecting/designing your filter topologies. Dr. Robin John Clark's Ph.D. thesis is a relatively comprehensive resource on this subject: http://www.tech.plym.ac.uk/spmc/rclark.html http://www.tech.plym.ac.uk/spmc/pdf/audio/RobClarkPhD.pdf Please be aware that although the coverage is rather comprehensive it is limited to general and well-known topologies. It is possible to achieve higher performance levels with more advanced topologies (some of which are proprietary designs). -------- Original Message -------- > From: "Vinnie" > Sent: Wednesday, May 06, 2009 7:04 PM > To: music-dsp@music.columbia.edu > Subject: [music-dsp] Blurps and Chirps when changing filter parameters > > In my library "A Collection of C++ Classes for Digital Signal Processing", when I sweep the frequency on Biquads it sounds great. But when I sweep the frequency on some of the higher order low pass and high pass types (Butterworth in particular) I hear some weirdness. The faster I change frequencies, the bigger the extra sound. > > Initially I was using Direct Form II which is very succeptible to that. So I switched to Direct form I and my 2-poles sounded great but when I use higher orders, even with Direct Form I there is some extra sound when changing parameter values. > > Is this research paper directly relevant to my problem: > http://www.native-instruments.de/fileadmin/redaktion_upload/pdf/KeepTopology .pdf > > It sounds like it is. Unfortunately it is almost impossible for me to understand!! Can anyone help? > > -- > 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 May 6 13:48:04 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Wed May 6 13:46:01 2009 Subject: [music-dsp] Blurps and Chirps when changing filter parameters References: <108217.42179.qm@web58206.mail.re3.yahoo.com> Message-ID: <002501c9ce72$d1fecc60$0201a8c0@mooncode> From: "Vinnie" > Is this research paper directly relevant to my problem: > http://www.native-instruments.de/fileadmin/ > redaktion_upload/pdf/KeepTopology.pdf No, it isn't. Martin From rbj at audioimagination.com Wed May 6 17:19:15 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Wed May 6 17:19:45 2009 Subject: [music-dsp] Blurps and Chirps when changing filter parameters Message-ID: <20090506211915.67E5A54809C@ws6-6.us4.outblaze.com> > ----- Original Message ----- > From: Vinnie > To: music-dsp@music.columbia.edu > Subject: [music-dsp] Blurps and Chirps when changing filter parameters > Date: Wed, 6 May 2009 09:04:16 -0700 (PDT) > > > > In my library "A Collection of C++ Classes for Digital Signal Processing", > when I sweep the frequency on Biquads it sounds great. But when I sweep the > frequency on some of the higher order low pass and high pass types > (Butterworth in particular) I hear some weirdness. The faster I change > frequencies, the bigger the extra sound. > > Initially I was using Direct Form II which is very succeptible to that. So I > switched to Direct form I and my 2-poles sounded great but when I use higher > orders, even with Direct Form I there is some extra sound when changing > parameter values. unless you're doing this in fixed-point and your DF2 was saturating its states as a consequence of the rapid changing of coefficients, it shouldn't make much of a mathematical difference. the resonant frequency is dependent solely on the a2 coefficient for a biquad section. for an analog butterworth, each biquad section would be tuned to the same resonant frequency and would have the same a2. but because of frequency warping, i am not sure that that would remain for a properly designed butterworth. and for a tchebyshev, their not tuned to the same resonant frequency anyway. so, depending on how you're slewing the coefficients, the resonant frequencies of the individual sections may not track together. if you are recomputing each coefficient from the swept parameters *every*sample*, then that's a different story. all the sections are tracking each other, but just from the dynamic excitation you get from having non-zero states and rapidly changing coefficients you can get some nasty psuedo-signal generated inside. it shouldn't be the case, for the standard DF1 or DF2 biquads that if you sweep from one stable set of coefficients to another stable set, you should not be passing through unstable combinations. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From Victor.Lazzarini at nuim.ie Wed May 6 17:33:55 2009 From: Victor.Lazzarini at nuim.ie (victor) Date: Wed May 6 17:34:10 2009 Subject: [music-dsp] Blurps and Chirps when changing filter parameters In-Reply-To: <20090506211915.67E5A54809C@ws6-6.us4.outblaze.com> References: <20090506211915.67E5A54809C@ws6-6.us4.outblaze.com> Message-ID: <06253818888C4CC68D354F9FCF2F6ADE@LazzariniPC> Is there any literature on the effects of this audio-rate change of coefficients? Just a few weeks ago, we were doing some work on phase distortion effects of time-varying IIRs and I was wondering about background on this, so I'd be interested to hear more about it. Victor ==================================================== if you are recomputing each coefficient from the swept parameters *every*sample*, then that's a different story. all the sections are tracking each other, but just from the dynamic excitation you get from having non-zero states and rapidly changing coefficients you can get some nasty psuedo-signal generated inside. =================================================== -- 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 rbj at audioimagination.com Wed May 6 20:23:54 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Wed May 6 20:24:37 2009 Subject: [music-dsp] Blurps and Chirps when changing filter parameters Message-ID: <20090507002354.3691354809C@ws6-6.us4.outblaze.com> > ----- Original Message ----- > From: victor > To: "A discussion list for music-related DSP" > Subject: Re: [music-dsp] Blurps and Chirps when changing filter parameters > Date: Wed, 06 May 2009 22:33:55 +0100 > > > Is there any literature on the effects of this audio-rate change of > coefficients? Just a few > weeks ago, we were doing some work on phase distortion effects of > time-varying IIRs > and I was wondering about background on this, so I'd be interested to hear > more about > it. > > Victor > ==================================================== > if you are recomputing each coefficient from the swept parameters > *every*sample*, then that's a different story. all the sections are tracking > each other, but just from the dynamic excitation you get from having non-zero > states and rapidly changing coefficients you can get some nasty psuedo-signal > generated inside. > =================================================== i'm sure there is something about this in some IEEE or Bell Labs paper, but the only paper i remember seeing is from Jean Laroche: http://www.aes.org/e-lib/browse.cfm?elib=14168 i don't think i have that on pdf, but maybe i can get if for free (since i was an AES member in 2007). -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From mike at psychonic.net Wed May 6 20:42:43 2009 From: mike at psychonic.net (Mike) Date: Wed May 6 20:38:34 2009 Subject: [music-dsp] Re: Blurps and Chirps when changing filter parameters In-Reply-To: <20090507002502.D118F77CD18@music.columbia.edu> References: <20090507002502.D118F77CD18@music.columbia.edu> Message-ID: <4A022E83.1060200@psychonic.net> My casual informal understanding of this (or something like this) is that the problem is the energy stored in the states (z's) is not normalized (e.g. the ratio of the average magnitude) varies greatly as the coefficients change), so that if the coefs are not changed slowly, then the energy essentially "dumps" into the output signal. A solution that was told to me was to use 2 parallel all-pass filters and sum them together in the proper way (depending on the desired type of filter). Unfortunately I don't have a reference handy. -Mike Shonle From sfx at sfxmachine.com Wed May 6 21:09:35 2009 From: sfx at sfxmachine.com (Earl Vickers) Date: Wed May 6 21:09:44 2009 Subject: [music-dsp] Blurps and Chirps when changing filter parameters In-Reply-To: <20090507002503.3E96C77CD1C@music.columbia.edu> References: <20090507002503.3E96C77CD1C@music.columbia.edu> Message-ID: r b-j wrote: >i'm sure there is something about this in some IEEE or Bell Labs >paper, but the only paper i remember seeing is from Jean Laroche: >http://www.aes.org/e-lib/browse.cfm?elib=14168 It includes the somewhat surprising result that a time-varying filter can be unstable even through the coefficients at any instant are those of a stable filter. An earlier, somewhat related paper is "Using Resonant Filters for the Synthesis of Time-Varying Sinusoids" by Jean Laroche, http://www.atc.creative.com/users/jeanl/Papers/using_resonant.ps -- Earl Vickers The Sound Guy, Inc. http://www.sfxmachine.com From Victor.Lazzarini at nuim.ie Thu May 7 02:30:32 2009 From: Victor.Lazzarini at nuim.ie (victor) Date: Thu May 7 02:31:10 2009 Subject: [music-dsp] Blurps and Chirps when changing filter parameters In-Reply-To: <20090507002354.3691354809C@ws6-6.us4.outblaze.com> References: <20090507002354.3691354809C@ws6-6.us4.outblaze.com> Message-ID: Thanks, I will be able to get this. ----- Original Message ----- From: "robert bristow-johnson" To: "A discussion list for music-related DSP" Sent: Thursday, May 07, 2009 1:23 AM Subject: Re: [music-dsp] Blurps and Chirps when changing filter parameters > ----- Original Message ----- > From: victor > To: "A discussion list for music-related DSP" > > Subject: Re: [music-dsp] Blurps and Chirps when changing filter parameters > Date: Wed, 06 May 2009 22:33:55 +0100 > > > Is there any literature on the effects of this audio-rate change of > coefficients? Just a few > weeks ago, we were doing some work on phase distortion effects of > time-varying IIRs > and I was wondering about background on this, so I'd be interested to hear > more about > it. > > Victor > ==================================================== > if you are recomputing each coefficient from the swept parameters > *every*sample*, then that's a different story. all the sections are > tracking > each other, but just from the dynamic excitation you get from having > non-zero > states and rapidly changing coefficients you can get some nasty > psuedo-signal > generated inside. > =================================================== i'm sure there is something about this in some IEEE or Bell Labs paper, but the only paper i remember seeing is from Jean Laroche: http://www.aes.org/e-lib/browse.cfm?elib=14168 i don't think i have that on pdf, but maybe i can get if for free (since i was an AES member in 2007). -- 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 vadim.zavalishin at native-instruments.de Thu May 7 05:45:26 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Thu May 7 05:45:37 2009 Subject: [music-dsp] Blurps and Chirps when changing filter parameters In-Reply-To: <002501c9ce72$d1fecc60$0201a8c0@mooncode> References: <108217.42179.qm@web58206.mail.re3.yahoo.com> <002501c9ce72$d1fecc60$0201a8c0@mooncode> Message-ID: <27C0FB3B66874FAF9C5CEE8D2EC90911@nibln01077> > From: "Vinnie" > >> Is this research paper directly relevant to my problem: >> http://www.native-instruments.de/fileadmin/ >> redaktion_upload/pdf/KeepTopology.pdf > > No, it isn't. > > > Martin Hi Martin Would you mind explaining? Because I would think it is :-) Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From vadim.zavalishin at native-instruments.de Thu May 7 05:47:46 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Thu May 7 05:47:54 2009 Subject: [music-dsp] Blurps and Chirps when changing filter parameters In-Reply-To: <108217.42179.qm@web58206.mail.re3.yahoo.com> References: <108217.42179.qm@web58206.mail.re3.yahoo.com> Message-ID: > Is this research paper directly relevant to my problem: > http://www.native-instruments.de/fileadmin/redaktion_upload/pdf/KeepTopology.pdf > > It sounds like it is. Unfortunately it is almost impossible for me to > understand!! Can anyone help? I would like to answer your questions if you have any. After all I didn't want to write an article which no one understands :-) Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From thevinn at yahoo.com Thu May 7 06:15:19 2009 From: thevinn at yahoo.com (Vinnie) Date: Thu May 7 06:16:14 2009 Subject: [music-dsp] Re: Blurps and Chirps when changing filter parameters In-Reply-To: <20090507063108.887B17808B6@music.columbia.edu> Message-ID: <329649.28854.qm@web58206.mail.re3.yahoo.com> > From: Mike > My casual informal understanding of this (or something like > this) is > that the problem is the energy stored in the states > (z's) is not > normalized (e.g. the ratio of the average magnitude) varies > greatly as > the coefficients change), so that if the coefs are not > changed slowly, > then the energy essentially "dumps" into the > output signal. That is my conclusion as well although I didn't recognize the analysis you described. I just noticed that for Direct Form II, there is less history information. I studied the code and in my layman's view I realized that the history was getting coefficient information along with both input and output samples mixed up and jumbled together. I view the Direct Forrm II history as a sort of "precalc" that caches the result of what would normally be a separate multiply in Direct Form I. The problem is that when you change filter parameters this precalculation becomes invalid. Someone said that there shouldn't be a difference when going from Direct Form II to Direct Form I if the coefficients are stable and I have to disagree, there is a big difference and it is because of the history buffer. From rrsounds at aol.com Thu May 7 06:34:24 2009 From: rrsounds at aol.com (David Reaves) Date: Thu May 7 06:35:20 2009 Subject: [music-dsp] Re: Blurps and Chirps when changing filter parameters In-Reply-To: <20090507101615.85EFE782AF9@music.columbia.edu> References: <20090507101615.85EFE782AF9@music.columbia.edu> Message-ID: <984D881A-475A-46EC-9A92-F108DDC44E41@aol.com> Vinnie, I'm no expert, but my understanding of IIR filters is that they ALL make use of 'history,' in one way or another. This is the "infinite" aspect of their design. It would make sense to me that some filter designs have more sensitivity to coefficient change than others, and that the number of feedback points would have a bearing on this. David Reaves On Thu, 7 May 2009 03:15:19 -0700 (PDT), Vinnie wrote: >> From: Mike >> My casual informal understanding of this (or something like >> this) is that the problem is the energy stored in the states (z's) >> is not >> normalized (e.g. the ratio of the average magnitude) varies greatly >> as >> the coefficients change), so that if the coefs are not changed >> slowly, >> then the energy essentially "dumps" into the output signal. > > That is my conclusion as well although I didn't recognize the > analysis you described. I just noticed that for Direct Form II, > there is less history information. I studied the code and in my > layman's view I realized that the history was getting coefficient > information along with both input and output samples mixed up and > jumbled together. > > I view the Direct Forrm II history as a sort of "precalc" that > caches the result of what would normally be a separate multiply in > Direct Form I. The problem is that when you change filter parameters > this precalculation becomes invalid. > > Someone said that there shouldn't be a difference when going from > Direct Form II to Direct Form I if the coefficients are stable and I > have to disagree, there is a big difference and it is because of the > history buffer. From thevinn at yahoo.com Thu May 7 06:57:04 2009 From: thevinn at yahoo.com (Vinnie) Date: Thu May 7 06:57:16 2009 Subject: [music-dsp] Re: music-dsp Digest, Vol 65, Issue 14 In-Reply-To: <20090507101615.85EFE782AF9@music.columbia.edu> Message-ID: <774035.44883.qm@web58205.mail.re3.yahoo.com> > From: "Vadim Zavalishin" > I would like to answer your questions if you have any. > After all I didn't want to write an article which no one understands :-) I just started out serious DSP work a couple of weeks ago. I'm extremely weak on the math. I don't understand the transfer function, bilinear transformation (BLT?). I'm still studying the fundamentals. The code that I published was crafted from contributions from various sources. I did not develop the formulas, nor do I understand, the calculations for the pole placement. I agree that your paper sounds like it is directly relevant to my problem of blurps and chirps. I appreciate your offer to answer questions and if I knew which ones to ask I would take you up on it! The next step for me is to continue re-reading the books I have until I understand the basics. From music-dsp at zenprobe.com Thu May 7 07:24:09 2009 From: music-dsp at zenprobe.com (Dylan Menzies) Date: Thu May 7 07:24:34 2009 Subject: [music-dsp] Re: music-dsp Digest, Vol 65, Issue 14 (fwd) Message-ID: Vadim, I would like to ask a question about 'keepTopology.pdf'. As I read it you effectively break G down to g(n), s(n) which represent discrete parameters and state, which enables you to make an instantaneous solution for the next iteration of the outer loop. So if G is an integrator, just use a standard discrete integrator state model with this? Is this method maybe not optimal at high frequency? thanks, Dylan On Thu, 7 May 2009, Vinnie wrote: > >> From: "Vadim Zavalishin" >> I would like to answer your questions if you have any. >> After all I didn't want to write an article which no one understands :-) > > I just started out serious DSP work a couple of weeks ago. I'm extremely weak > on the math. I don't understand the transfer function, bilinear > transformation (BLT?). I'm still studying the fundamentals. The code that I > published was crafted from contributions from various sources. I did not > develop the formulas, nor do I understand, the calculations for the pole > placement. > > I agree that your paper sounds like it is directly relevant to my problem of > blurps and chirps. > > I appreciate your offer to answer questions and if I knew which ones to ask I > would take you up on it! The next step for me is to continue re-reading the > books I have until I understand the basics. > -- > 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 didid at skynet.be Thu May 7 07:36:57 2009 From: didid at skynet.be (Didier Dambrin) Date: Thu May 7 07:37:37 2009 Subject: [music-dsp] Re: Blurps and Chirps when changing filter parameters In-Reply-To: <984D881A-475A-46EC-9A92-F108DDC44E41@aol.com> References: <20090507101615.85EFE782AF9@music.columbia.edu> <984D881A-475A-46EC-9A92-F108DDC44E41@aol.com> Message-ID: <44DDFE3B8AB7456BA7865EADB78EBC44@GOLAMD> I never really fully understood IIR's, but isn't it theorically possible, when you change the coefficients, to adapt the existing memory to how it'd be if you had processed data using the new coefficients? Or at least to put the memory in a stable state, while avoiding discontinuities? > Vinnie, > I'm no expert, but my understanding of IIR filters is that they ALL > make use of 'history,' in one way or another. > This is the "infinite" aspect of their design. > > It would make sense to me that some filter designs have more > sensitivity to coefficient change than others, and that the number of > feedback points would have a bearing on this. > > David Reaves > > > On Thu, 7 May 2009 03:15:19 -0700 (PDT), Vinnie > wrote: >>> From: Mike >>> My casual informal understanding of this (or something like >>> this) is that the problem is the energy stored in the states (z's) >>> is not >>> normalized (e.g. the ratio of the average magnitude) varies greatly >>> as >>> the coefficients change), so that if the coefs are not changed >>> slowly, >>> then the energy essentially "dumps" into the output signal. >> >> That is my conclusion as well although I didn't recognize the >> analysis you described. I just noticed that for Direct Form II, >> there is less history information. I studied the code and in my >> layman's view I realized that the history was getting coefficient >> information along with both input and output samples mixed up and >> jumbled together. >> >> I view the Direct Forrm II history as a sort of "precalc" that >> caches the result of what would normally be a separate multiply in >> Direct Form I. The problem is that when you change filter parameters >> this precalculation becomes invalid. >> >> Someone said that there shouldn't be a difference when going from >> Direct Form II to Direct Form I if the coefficients are stable and I >> have to disagree, there is a big difference and it is because of the >> history buffer. > > -- > 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.5.325 / Virus Database: 270.12.21/2101 - Release Date: 05/06/09 17:58:00 From thevinn at yahoo.com Thu May 7 07:58:23 2009 From: thevinn at yahoo.com (Vinnie) Date: Thu May 7 07:58:36 2009 Subject: [music-dsp] Re: Blurps and Chirps when changing filter parameters In-Reply-To: <20090507112432.CD9F4783595@music.columbia.edu> Message-ID: <614186.84437.qm@web58204.mail.re3.yahoo.com> > From: David Reaves > but my understanding of IIR filters is > that they ALL make use of 'history,' in one way or another. > This is the "infinite" aspect of their design. Yes but with Direct Form I, two of the history elements are the original inputs completely preserved. In Direct Form II, that information is mixed with some of the output. The original input data is not available. Therefore when changing parameters in Direct Form II, the history blends some information that had to do with the old coefficients. But in Direct Form I, those inputs are unmolested and readily applicable to the new coefficients as if they never changed. Now it is true that the outputs even in Direct Form I still contain information from the previous set of coefficients. And it seems probable that there is some effect on the audio output. However, in practice at least for Biquads which have only a single stage, the difference is inaudible. Maybe its a small phase distortion, which can't be heard. From vadim.zavalishin at native-instruments.de Thu May 7 08:27:27 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Thu May 7 08:27:46 2009 Subject: [music-dsp] Re: music-dsp Digest, Vol 65, Issue 14 (fwd) In-Reply-To: References: Message-ID: <85CD8187116F4E1CB450B439FF33FE5A@nibln01077> > Vadim, I would like to ask a question about 'keepTopology.pdf'. As I read > it you effectively break G down to g(n), s(n) which represent discrete > parameters and state, which enables you to make an instantaneous solution > for the next iteration of the outer loop. So if G is an integrator, just > use a standard discrete integrator state model with this? Is this method > maybe not optimal at high frequency? > > thanks, > Dylan Hi Dylan I think I mentioned that in the article. Actually the transfer function you get is exactly the one you would have gotten if you have used the respective transform on the entire system. E.g. if you use bilinear-transformed integrators, then the resulting system's transfer function will be the same as if you had applied the bilinear transform to the s-domain function. Or at least unless I'm missing something :-) Actually, I recently noticed that it seems that the method proposed in my article is more or less equivalent to the one briefly outlined here (except that the paper concerns itself with a slightly different topic): http://www.simulanalog.org/statevariable.pdf That is an equivalent representation of the method is to apply the transform directly to the differential equations describing the analog prototype. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From music-dsp at zenprobe.com Thu May 7 10:52:10 2009 From: music-dsp at zenprobe.com (Dylan Menzies) Date: Thu May 7 10:52:32 2009 Subject: [music-dsp] Re: music-dsp Digest, Vol 65, Issue 14 (fwd) In-Reply-To: <85CD8187116F4E1CB450B439FF33FE5A@nibln01077> References: <85CD8187116F4E1CB450B439FF33FE5A@nibln01077> Message-ID: > > Hi Dylan > > I think I mentioned that in the article. Actually the transfer function you > get is exactly the one you would have gotten if you have used the respective > transform on the entire system. E.g. if you use bilinear-transformed > integrators, then the resulting system's transfer function will be the same > as if you had applied the bilinear transform to the s-domain function. Or at > least unless I'm missing something :-) Yes, I ok I see it, you are calculating the unambiguous discrete response, With nonlinear components there is no such simple statement because there is no simple linear transform, but it makes even more sense to keep the topology using the same approach. Cool, thanks. From martin.eisenberg at udo.edu Thu May 7 12:58:37 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Thu May 7 12:56:31 2009 Subject: [music-dsp] Blurps and Chirps when changing filter parameters References: <108217.42179.qm@web58206.mail.re3.yahoo.com><002501c9ce72$d1fecc60$0201a8c0@mooncode> <27C0FB3B66874FAF9C5CEE8D2EC90911@nibln01077> Message-ID: <005c01c9cf35$14a5db40$0201a8c0@mooncode> From: "Vadim Zavalishin" > From: "Vinnie" > > > >> Is this research paper directly relevant to my problem: > >> http://www.native-instruments.de/fileadmin/ > >> redaktion_upload/pdf/KeepTopology.pdf > > > > No, it isn't. > Would you mind explaining? Because I would think it is :-) Vinnie was talking about changing coefficients during filter operation. Your paper (as I read it) is about a way to sequence filter calculations, given whatever coefficients the analog blocks imply. Of course these issues have some overlap in that different ways to calculate will influence the form tweaking artifacts take, and the paper does allude to that. But it is mainly concerned with the *analog* system's topology, which never enters in what Vinnie's doing because the code he pilfered BLT's each s-root of an abstract prototype individually and then assembles the results into a digital filter. So I guess whether he can apply your presentation at his current level really depends on his understanding of tunable analog filters. Martin From martin.eisenberg at udo.edu Thu May 7 13:14:03 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Thu May 7 13:11:55 2009 Subject: [music-dsp] Blurps and Chirps when changing filter parameters References: <108217.42179.qm@web58206.mail.re3.yahoo.com><002501c9ce72$d1fecc60$0201a8c0@mooncode> <27C0FB3B66874FAF9C5CEE8D2EC90911@nibln01077> Message-ID: <005d01c9cf37$3c40cb40$0201a8c0@mooncode> > >> http://www.native-instruments.de/fileadmin/ > >> redaktion_upload/pdf/KeepTopology.pdf By the way, this seems to be regarded as the method's first description: A. H?rm?. Implementation of recursive filters having delay free loops. In Proc. IEEE Int. Conf. Acoustics, Speech, and Signal Processing, volume III, pages 1261-1264, Seattle, Washington, May 1998 http://www.acoustics.hut.fi/~aqi/papers/icassp98.ps.gz Martin From martin.eisenberg at udo.edu Thu May 7 13:40:25 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Thu May 7 13:38:26 2009 Subject: [music-dsp] Re: A Collection of C++ Classes for Digital SignalProcessing References: <590977.62854.qm@web58202.mail.re3.yahoo.com> Message-ID: <008901c9cf3a$eada5600$0201a8c0@mooncode> From: "Vinnie" > Are you saying it should read > return std::complex( n*c.real(), - n*c.imag() ); Exactly; 1/z = conj(z)/|z|^2. > Apparently it doesn't matter because I tried it that way and > it produces the same results. I tested the Chebyshev 2 > filters (those are the only ones that use recip()). The coding error is hidden since each pole and zero is combined with its conjugate brother to make a real-coefficient filter. > > | static const CalcT SQRT_DBL_EPSILON = > > | ::sqrt(DBL_EPSILON); > > > > Being unfamiliar with Brent's method I'm not sure > > how important it is, but I suppose if you want to allow > > CalcT == float then the above line ought to use > > std::numeric_limits::epsilon(). > > | tol = SQRT_DBL_EPSILON*::fabs(x) + epsilon; > > I have to admit I am fuzzy on the math. In that case I'll just stick my neck out and assert that the statement should in fact read tol = epsilon * ::fabs(x) + SQRT_CALCT_EPSILON; As explained in NR, epsilon (called tol there) specifies the fractional accuracy the iteration should attain while the additive constant enforces a lower bound to avoid nontermination. > I have Numerical Recipes but the code is restricted so > I am prevented from using it. You are only prevented from using it in the least valuable of ways, which is direct copying. Additionally, in the present case, how many reasonable renditions of that statement are there? > > I know that interferes with your trick of folding > > successive 1st-order sections (a bug: s->b[0]=x0 > > should use *= -- but it's moot, read on) > > Its not "my" trick and I didn't know what it was doing until > you explained it. So there's a bug? Yes. Say that some stage S[i] is purely a non-unity scaling and is not itself integrated with the previous stage S[i-1] (either because i == 0 or S[i-1] has coefficient b[2] != 0). Then, setting S[i+1] will overwrite S[i]'s scale factor rather than properly absorbing it into S[i+1]. > > xxBandPass::PassbandHint(): That should be a geometric, not > > arithmetic, mean; and except at bandwidths up to about pi/6 > > you need to form the mean of BLT-unwarped values and warp > > that back. So the body would be: > > return 2*atan(sqrt(tan(m_wc*0.5) * tan(m_wc2*0.5))); > > I'm guessing BLT doesn't mean Bacon Lettuce and Tomato. :) It means Bilinear Transform. > For PassbandHint() all I wanted to do was choose a value > for the angular frequency that was as far away as possible > from anything that deviates from unity gain. I figured the > middle of the passband was ideal since it is the farthest > from the rolloffs at either side. Good thinking. However the center frequency is in the middle of the passband *on a logarithmic axis*, hence the geometric mean. That's in continuous time; on top of that, after discretization via BLT we get the tan mapping. > Are you saying that the formula you provided can be used in > place of Brent's method for finding the top of the ripple in > the case of Chebyshev Type I band-pass filters? Well, there's a detail that I forgot about. But essentially, the answer is yes. The formula gives you the frequency that is the image of 0 Hz under the lowpass-to-bandpass transformation (*), so we know the magnitude response behaves there like the lowpass response does at DC. Now, for an odd-order Chebyshev-I LP, this is indeed a peak; for even order it's a trough, which by definition differs from a peak by the ripple factor. (*) Indeed, the value a in PoleFilter::BandPassTransform() equals the cosine of the passband hint, a == cos(2*atan(...)). Martin From jos at ccrma.stanford.edu Thu May 7 13:47:08 2009 From: jos at ccrma.stanford.edu (Julius Smith) Date: Thu May 7 13:47:28 2009 Subject: [music-dsp] Re: Blurps and Chirps when changing filter parameters In-Reply-To: <614186.84437.qm@web58204.mail.re3.yahoo.com> References: <20090507112432.CD9F4783595@music.columbia.edu> <614186.84437.qm@web58204.mail.re3.yahoo.com> Message-ID: <200905071747.n47HlDLV021549@jujube.cc.columbia.edu> Hi All, I haven't read this whole thread, but to isolate coefficient variation from filter state, you can realize your filter as a normalized ladder filter. Cheers, Julius At 04:58 AM 5/7/2009, Vinnie wrote: > > From: David Reaves > > but my understanding of IIR filters is > > that they ALL make use of 'history,' in one way or another. > > This is the "infinite" aspect of their design. > >Yes but with Direct Form I, two of the history elements are the >original inputs completely preserved. In Direct Form II, that >information is mixed with some of the output. The original input >data is not available. > >Therefore when changing parameters in Direct Form II, the history >blends some information that had to do with the old coefficients. >But in Direct Form I, those inputs are unmolested and readily >applicable to the new coefficients as if they never changed. > >Now it is true that the outputs even in Direct Form I still contain >information from the previous set of coefficients. And it seems >probable that there is some effect on the audio output. However, in >practice at least for Biquads which have only a single stage, the >difference is inaudible. Maybe its a small phase distortion, which >can't be heard. > >-- >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 Julius O. Smith III Prof. of Music and Assoc. Prof. (by courtesy) of Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ From hybridalienrob at hotmail.com Thu May 7 14:29:49 2009 From: hybridalienrob at hotmail.com (Rob Belcham) Date: Thu May 7 14:30:03 2009 Subject: [music-dsp] Blurps and Chirps when changing filter parameters Message-ID: You need to interpolate the coefficients in real time to remove the 'zipper noise' you get when changing filter parameters rapidly. There are a number of approaches, the simplest o which is exponential ramping, so each time you ramp your coeffs you'd do.. b0 = ( b0_target - b0) * ramp_factor where b0 is the coeff you use in the audio processing & b0_target is the output of your coefficient calculator. ramp_factor is typicaly a small number & would be related to how quick you want the coefficient to settle. You can also interpolate linearly which produces a more natural sweep imo, so each time you ramp.. b0 = b0 + (b0_target - b0_last)*ramp_factor Ramping every other sample is ideal, any artifacts will be at Nyquist (or so i was told by a learned colleague ;) Regards Rob From didid at skynet.be Thu May 7 15:28:30 2009 From: didid at skynet.be (Didier Dambrin) Date: Thu May 7 15:29:15 2009 Subject: [music-dsp] Blurps and Chirps when changing filter parameters In-Reply-To: References: Message-ID: <2C1A8D05E2A444C6B2EEEFD704F46E27@GOLAMD> Talking about exponential ramping, what do you think of stacking exponential ramps to produce a more natural curve (one that doesn't start too abruptly)? (that's the way I smooth up my compressor's gain envelope) Are there other better known ramping methods? Exluding the ones that produce values out of [source,destination] range, that is. > > You need to interpolate the coefficients in real time to remove the > 'zipper > noise' you get when changing filter parameters rapidly. > > There are a number of approaches, the simplest o which is exponential > ramping, so each time you ramp your coeffs you'd do.. > > b0 = ( b0_target - b0) * ramp_factor > > where b0 is the coeff you use in the audio processing & b0_target is the > output of your coefficient calculator. ramp_factor is typicaly a small > number & would be related to how quick you want the coefficient to settle. > > You can also interpolate linearly which produces a more natural sweep imo, > so each time you ramp.. > > b0 = b0 + (b0_target - b0_last)*ramp_factor > > Ramping every other sample is ideal, any artifacts will be at Nyquist (or > so > i was told by a learned colleague ;) > > Regards > Rob > > From rbj at audioimagination.com Thu May 7 21:35:47 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Thu May 7 21:36:01 2009 Subject: [music-dsp] Blurps and Chirps when changing filter parameters Message-ID: <20090508013547.AD91A2D00EA@ws6-13.us4.outblaze.com> > ----- Original Message ----- > From: "Rob Belcham" > To: "Music DSP" > Subject: [music-dsp] Blurps and Chirps when changing filter parameters > Date: Thu, 7 May 2009 19:29:49 +0100 > > > > > You need to interpolate the coefficients in real time to remove the 'zipper > noise' you get when changing filter parameters rapidly. > > There are a number of approaches, the simplest o which is exponential > ramping, so each time you ramp your coeffs you'd do.. > > b0 = b0 + (b0_target - b0)*ramp_factor you needed a "b0 + " on this one too. > where b0 is the coeff you use in the audio processing & b0_target is the > output of your coefficient calculator. ramp_factor is typicaly a small number > & would be related to how quick you want the coefficient to settle. one problem about first-order exponential slewing of coefficients with fixed-point arithmetic is that, because of rounding and limit-cycles, you can get stuck on a value before it reaches the target. this can be cured with "fraction saving" or first-order noise shaping just like in a DC blocking filter. > You can also interpolate linearly which produces a more natural sweep imo, so > each time you ramp.. > > b0 = b0 + (b0_target - b0_last)*ramp_factor > > Ramping every other sample is ideal, any artifacts will be at Nyquist (or so > i was told by a learned colleague ;) i think ramping every sample is more ideal than just half of them. if you process samples in chunks or blocks, you can usually calculate coefs from the parameters once per block and then let the coefs ramp (or exponentially slew) to their new targets on a per sample basis. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From rbj at audioimagination.com Thu May 7 21:41:04 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Thu May 7 21:41:22 2009 Subject: [music-dsp] Re: Blurps and Chirps when changing filter parameters Message-ID: <20090508014104.D613854D82F@ws6-9.us4.outblaze.com> > ----- Original Message ----- > From: "Julius Smith" > To: "A discussion list for music-related DSP" > Cc: music-dsp@music.columbia.edu > Subject: Re: [music-dsp] Re: Blurps and Chirps when changing filter parameters > Date: Thu, 07 May 2009 10:47:08 -0700 > > > I haven't read this whole thread, but to isolate coefficient variation from > filter state, you can realize your filter as a normalized ladder filter. Julius, what do you mean by "isolate coefficient variation from filter state"? i think i know what a normalized ladder form is, i think i know how k1 and k2 are derived from and are dependent on the biquad poles, and i know that the magnitudes of the states are limited in an L^2 norm kinda way. but wouldn't sweeping the k1 and k2 values possibly introduce artifacts in the normalized ladder? i'm sure i'm missing something. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From Gualtiero.Volpe at unige.it Fri May 8 05:10:10 2009 From: Gualtiero.Volpe at unige.it (Gualtiero Volpe) Date: Fri May 8 05:10:26 2009 Subject: [music-dsp] CFPs: Workshop on Social Behavior in Music at IEEE SocialCom-09 -- DEADLINE EXTENSION Message-ID: <001201c9cfbc$ca1f9b00$5e5ed100$@Volpe@unige.it> [Sorry for cross-postings] *************************************************************************** FINAL CALL FOR PAPERS *************************************************************************** SBM2009- Social Behavior in Music www.infomus.org/SBM2009 Vancouver, Canada, August 29, 2009 Workshop in the framework of IEEE Intl. SocialCom-09 Conference Music making and listening are a clear example of human activities that are above all interactive and social. On the one hand, however, nowadays mediated music making and listening is usually still a passive, non-interactive, non-context sensitive, and non-social experience. The current electronic technologies have not yet been able to support and promote these essential aspects. On the other hand, new mediated forms of sharing music experience in a social context with local or remote users or as a part of a community are emerging. At the same time we observe an increasing need for paradigms for embodied and active experience of music where non-verbal communication channels, and in particular movement and gesture, play a central role. This workshop focuses on the social signals and their features that are most significant for a qualitative and quantitative analysis of social behavior and experience in music. The workshop will discuss computational models, algorithms, techniques for analysis of social behavior in music, their application in concrete test-beds, and their evaluation in experimental set-ups. We are interested in exploring many-to-many human interplay, such as the performer-listener, performer-performer, and listener-listener interaction, in novel scenarios where the distinction between listeners and performers fades out and users become producers and consumers of music experience. WORKSHOP TOPICS We encourage papers and demos addressing fundamental research issues including, but not limited to, the following topics: - theoretical approaches to social behavior in music - experimental methodologies for analysis of social behavior in music - computational models of social behavior in music - analysis of social signals in music - synchronization of human behavior in music - analysis of social roles in performers and listeners groups - analysis of attention and salience in social music experiences - multimodal interfaces for active and social music experience - cooperative social environments for participative music experience - multi-user systems and application for social music experience ELECTRONIC SUBMISSIONS Submissions should follow the IEEE conference paper format. Submissions should include: title, author(s), affiliation(s), e-mail address(es), tel/fax number(s), and postal address(es). The contributions can be submitted at: http://infomus.org/SBM2009/commence Both accepted papers and demos will be presented at the workshop as oral presentation or in a demo session. The accepted contributions will appear in the Proceedings of Social-Com09 Workshops published by IEEE Computer Society Press. Authors of accepted contributions will be required to submit a camera ready version. At least one author for each accepted paper or demo is required to attend the workshop to present the work. Papers submission: Manuscripts should be 8 pages maximum, including references, tables, and pictures. Demo submission: Proposal for demonstrations should be submitted as a (max) 2-pages extended abstract including pictures and technical details. IMPORTANT DATES May 17, 2009: Submissions deadline June 5, 2009: Notification of acceptance June 15, 2009: Camera ready version due to electronic form August 29, 2009: SBM2009 Workshop WORKSHOP ORGANIZERS AND CHAIRS Antonio Camurri Donald Glowinski Maurizio Mancini Giovanna Varni Gualtiero Volpe PROGRAM COMMITTEE Frederic Bevilacqua (IRCAM, France) Roberto Bresin (KTH, Sweden) Shuji Hashimoto (Waseda University, Japan) Ben Knapp (Queen's University Belfast, UK) Marc Leman (Univeristeit Ghent) Anton Nijholt (University of Twente, NL) Maja Pantic (Imperial College London, UK and University of Twente, NL) Catherine Pelachaud (CNRS, France) Isabella Poggi (Universit? Roma 3, Italy) Xavier Serra (UPF, Spain) Alessandro Vinciarelli (IDIAP, Switzerland) The workshop is partially supported by the FP7 EU-ICT Strep Project SAME (www.sameproject.eu). From vadim.zavalishin at native-instruments.de Fri May 8 06:13:58 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Fri May 8 06:14:08 2009 Subject: [music-dsp] Blurps and Chirps when changing filter parameters In-Reply-To: <005d01c9cf37$3c40cb40$0201a8c0@mooncode> References: <108217.42179.qm@web58206.mail.re3.yahoo.com><002501c9ce72$d1fecc60$0201a8c0@mooncode><27C0FB3B66874FAF9C5CEE8D2EC90911@nibln01077> <005d01c9cf37$3c40cb40$0201a8c0@mooncode> Message-ID: >> >> http://www.native-instruments.de/fileadmin/ >> >> redaktion_upload/pdf/KeepTopology.pdf > > By the way, this seems to be regarded as the method's first > description: > > A. H?rm?. Implementation of recursive filters having delay free > loops. In Proc. IEEE Int. Conf. Acoustics, Speech, and Signal > Processing, volume III, pages 1261-1264, Seattle, Washington, May > 1998 > http://www.acoustics.hut.fi/~aqi/papers/icassp98.ps.gz Hi Matrin Thanks a lot for the link, I wasn't aware of that article. However, my article is not only about delay-free loops, but also about the topology-preserving transformation method, which is based on integrator replacement. In this respect it is closer to what Serafini/Zamboni paper I mentioned earler is doing (again I don't know where this method was described first). In regards to whether this is relevant to Vinnie's problems, in my experience analog state-space topologies feature much better modulatability than both discrete-time direct forms, which property is more or less preserved after the conversion. Although, I'm not sure if this is the absolutely best solution to problem, or whether it is enough for his requirements. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From vadim.zavalishin at native-instruments.de Fri May 8 06:18:26 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Fri May 8 06:18:34 2009 Subject: [music-dsp] Re: music-dsp Digest, Vol 65, Issue 14 (fwd) In-Reply-To: References: <85CD8187116F4E1CB450B439FF33FE5A@nibln01077> Message-ID: <594BA9EFD0744FEAA4EEA26FCAF0EF23@nibln01077> > Yes, I ok I see it, you are calculating the unambiguous discrete response, > With nonlinear components there is no such simple statement because there > is no simple linear transform, but it makes even more sense to keep the > topology using the same approach. Actually, with nonlinear components you can make more or less the same statement, just without the transfer function. This is probably better seen if applying the same thing directly to the differential equations, as done in the Serafini/Zamboni paper. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From didid at skynet.be Fri May 8 10:29:19 2009 From: didid at skynet.be (Didier Dambrin) Date: Fri May 8 10:29:59 2009 Subject: [music-dsp] Filterbank In-Reply-To: <594BA9EFD0744FEAA4EEA26FCAF0EF23@nibln01077> References: <85CD8187116F4E1CB450B439FF33FE5A@nibln01077> <594BA9EFD0744FEAA4EEA26FCAF0EF23@nibln01077> Message-ID: I'm trying to build a filterbank out of RBJ's bandpasses, it works quite well. My problem: to reconstruct the (44khz, musical) signal properly, I need bands from around 15Hz to 40kHz (I oversample bands above 10k btw). But that's a big waste of useless bands that I only need to avoid deformation/ringing on the reconstructed signal. I'm not interested in playing with individual bands under 40Hz & above 16k. At 1/3oct per band, it results in 8 useless bands out of 35, almost 1/4 wasted for the reconstruction. But I can't find any other way. -I've tried slowly enlarging the lower/higher bands, but it has its limits, to keep artefacts inaudible I may just spare a band or 2. -the most obvious would be a low/highpass, but I can't imagine how they would fit the neighboring bandpasses. I'd have to stack a lot of second order lowpasses to match the steep bandpass slope, as I increase the # of bands, defeating the point. The ideal would be the same bandpass with the same characteristics, but turned into a low or highpass, but I don't think that's possible, is it? Any idea? From didid at skynet.be Fri May 8 10:45:05 2009 From: didid at skynet.be (Didier Dambrin) Date: Fri May 8 10:45:49 2009 Subject: [music-dsp] Filterbank In-Reply-To: References: <85CD8187116F4E1CB450B439FF33FE5A@nibln01077><594BA9EFD0744FEAA4EEA26FCAF0EF23@nibln01077> Message-ID: <1DE70F2A59DE4A3A8563A9BA9375F6C8@GOLAMD> > I'm trying to build a filterbank out of RBJ's bandpasses, it works quite > well. > Update: another idea is to compute the residual of the sum of all bands, and to split it in 2 using a low/highpass, to get my low & high bands. Because each band is made of 2 RBJ's bandpasses, one at the freq of the neighbor band, the result sums up pretty much like the original & thus the residual really is the low & high. But I haven't tested yet how it would sum with the bands. While it sounds like a bad idea for phasing reasons, it seems to work better than I expected. From music.maker at gte.net Fri May 8 11:05:27 2009 From: music.maker at gte.net (Scott Gravenhorst) Date: Fri May 8 11:05:36 2009 Subject: [music-dsp] Filterbank - What does it do? Message-ID: <200905081505.n48F5R6Z031549@linux7.lan> A discussion list for music-related DSP wrote: >I'm trying to build a filterbank out of RBJ's bandpasses, it works quite >well. > >My problem: to reconstruct the (44khz, musical) signal properly, I need >bands from around 15Hz to 40kHz (I oversample bands above 10k btw). But >that's a big waste of useless bands that I only need to avoid >deformation/ringing on the reconstructed signal. I'm not interested in >playing with individual bands under 40Hz & above 16k. > >At 1/3oct per band, it results in 8 useless bands out of 35, almost 1/4 >wasted for the reconstruction. But I can't find any other way. > >-I've tried slowly enlarging the lower/higher bands, but it has its limits, >to keep artefacts inaudible I may just spare a band or 2. > >-the most obvious would be a low/highpass, but I can't imagine how they >would fit the neighboring bandpasses. I'd have to stack a lot of second >order lowpasses to match the steep bandpass slope, as I increase the # of >bands, defeating the point. >The ideal would be the same bandpass with the same characteristics, but >turned into a low or highpass, but I don't think that's possible, is it? > >Any idea? I really wish I could help, but I don't know enough. I've heard _of_ filter banks and that lots of people like to use them - but I have no idea what they sound like. I like to make electronic music, synths of various types, mostly digital and a few analog synths. My question, if you will pardon a newbie/lurker, is what does a filter bank do? What could I expect? What kinds of sounds are best processed through a filter bank and for what purposes? Sorry for the thread break, but I can't think of a better place to ask this. Thanks for the great list discussions. -- ScottG ________________________________________________________________________ -- Scott Gravenhorst -- FPGA MIDI Synthesizer Information: home1.gte.net/res0658s/FPGA_synth/ -- FatMan: home1.gte.net/res0658s/fatman/ -- NonFatMan: home1.gte.net/res0658s/electronics/ -- When the going gets tough, the tough use the command line. From andrew.capon at zen.co.uk Fri May 8 11:10:40 2009 From: andrew.capon at zen.co.uk (Andrew Capon) Date: Fri May 8 11:11:05 2009 Subject: [music-dsp] Filterbank - What does it do? In-Reply-To: <200905081505.n48F5R6Z031549@linux7.lan> References: <200905081505.n48F5R6Z031549@linux7.lan> Message-ID: Hi Scott, For a musical FX of filter bank have a look at the Sherman Filter Bank http://www.sherman.be/ There are some audio samples on the site. Cheers Andy On 8 May 2009, at 16:05, Scott Gravenhorst wrote: > A discussion list for music-related DSP dsp@music.columbia.edu> wrote: >> I'm trying to build a filterbank out of RBJ's bandpasses, it works >> quite >> well. >> >> My problem: to reconstruct the (44khz, musical) signal properly, I >> need >> bands from around 15Hz to 40kHz (I oversample bands above 10k btw). >> But >> that's a big waste of useless bands that I only need to avoid >> deformation/ringing on the reconstructed signal. I'm not interested >> in >> playing with individual bands under 40Hz & above 16k. >> >> At 1/3oct per band, it results in 8 useless bands out of 35, almost >> 1/4 >> wasted for the reconstruction. But I can't find any other way. >> >> -I've tried slowly enlarging the lower/higher bands, but it has its >> limits, >> to keep artefacts inaudible I may just spare a band or 2. >> >> -the most obvious would be a low/highpass, but I can't imagine how >> they >> would fit the neighboring bandpasses. I'd have to stack a lot of >> second >> order lowpasses to match the steep bandpass slope, as I increase >> the # of >> bands, defeating the point. >> The ideal would be the same bandpass with the same characteristics, >> but >> turned into a low or highpass, but I don't think that's possible, >> is it? >> >> Any idea? > > I really wish I could help, but I don't know enough. > > I've heard _of_ filter banks and that lots of people like to use > them - but I have no idea what > they sound like. I like to make electronic music, synths of various > types, mostly digital and a > few analog synths. > > My question, if you will pardon a newbie/lurker, is what does a > filter bank do? What could I > expect? What kinds of sounds are best processed through a filter > bank and for what purposes? > > Sorry for the thread break, but I can't think of a better place to > ask this. > > Thanks for the great list discussions. > > -- ScottG > ________________________________________________________________________ > -- Scott Gravenhorst > -- FPGA MIDI Synthesizer Information: home1.gte.net/res0658s/ > FPGA_synth/ > -- FatMan: home1.gte.net/res0658s/fatman/ > -- NonFatMan: home1.gte.net/res0658s/electronics/ > -- When the going gets tough, the tough use the command line. > > -- > 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 didid at skynet.be Fri May 8 11:21:36 2009 From: didid at skynet.be (Didier Dambrin) Date: Fri May 8 11:22:26 2009 Subject: [music-dsp] Filterbank - What does it do? In-Reply-To: References: <200905081505.n48F5R6Z031549@linux7.lan> Message-ID: <274100983ED1497580DACB7DFF254668@GOLAMD> not sure it's the right example, as a filterbank is simply a bank of bandpasses, that split the signal into bands to ultimately reconstruct it, used for EQs, vocoders, compressors, etc. http://en.wikipedia.org/wiki/Filter_bank (& the reason to want a bank of IIR's is that FFT's musically suck at this job [you want to play in a nice octave [not Hz] scale, and the last thing you want is latency]) It's ultimately what a crossover does, but with more & narrower bands. And because we need narrower bands, I can't imagine butterworth low/highpasses used anymore. > Hi Scott, > > For a musical FX of filter bank have a look at the Sherman Filter Bank > http://www.sherman.be/ > > There are some audio samples on the site. > > Cheers > > Andy > > > > On 8 May 2009, at 16:05, Scott Gravenhorst wrote: > >> A discussion list for music-related DSP > dsp@music.columbia.edu> wrote: >>> I'm trying to build a filterbank out of RBJ's bandpasses, it works >>> quite >>> well. >>> >>> My problem: to reconstruct the (44khz, musical) signal properly, I >>> need >>> bands from around 15Hz to 40kHz (I oversample bands above 10k btw). >>> But >>> that's a big waste of useless bands that I only need to avoid >>> deformation/ringing on the reconstructed signal. I'm not interested >>> in >>> playing with individual bands under 40Hz & above 16k. >>> >>> At 1/3oct per band, it results in 8 useless bands out of 35, almost >>> 1/4 >>> wasted for the reconstruction. But I can't find any other way. >>> >>> -I've tried slowly enlarging the lower/higher bands, but it has its >>> limits, >>> to keep artefacts inaudible I may just spare a band or 2. >>> >>> -the most obvious would be a low/highpass, but I can't imagine how >>> they >>> would fit the neighboring bandpasses. I'd have to stack a lot of >>> second >>> order lowpasses to match the steep bandpass slope, as I increase >>> the # of >>> bands, defeating the point. >>> The ideal would be the same bandpass with the same characteristics, >>> but >>> turned into a low or highpass, but I don't think that's possible, >>> is it? >>> >>> Any idea? >> >> I really wish I could help, but I don't know enough. >> >> I've heard _of_ filter banks and that lots of people like to use >> them - but I have no idea what >> they sound like. I like to make electronic music, synths of various >> types, mostly digital and a >> few analog synths. >> >> My question, if you will pardon a newbie/lurker, is what does a >> filter bank do? What could I >> expect? What kinds of sounds are best processed through a filter >> bank and for what purposes? >> >> Sorry for the thread break, but I can't think of a better place to >> ask this. >> >> Thanks for the great list discussions. >> >> -- ScottG >> ________________________________________________________________________ >> -- Scott Gravenhorst >> -- FPGA MIDI Synthesizer Information: home1.gte.net/res0658s/ >> FPGA_synth/ >> -- FatMan: home1.gte.net/res0658s/fatman/ >> -- NonFatMan: home1.gte.net/res0658s/electronics/ >> -- When the going gets tough, the tough use the command line. >> >> -- >> 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 -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.325 / Virus Database: 270.12.21/2103 - Release Date: 05/07/09 18:05:00 From contact at quikquak.com Fri May 8 11:33:37 2009 From: contact at quikquak.com (contact) Date: Fri May 8 11:33:55 2009 Subject: [music-dsp] Filterbank - What does it do? References: <200905081505.n48F5R6Z031549@linux7.lan> <274100983ED1497580DACB7DFF254668@GOLAMD> Message-ID: <00f901c9cff2$5b639d20$6401a8c0@DaveUpstairs> Hang-on Didier, didn't you write EQUO? - The impressive and insanely efficient 31 band EQ for FL Studio? Here:- http://www.image-line.com/documents/equo.html Does that use wavelets BTW? : ) Dave > not sure it's the right example, as a filterbank is simply a bank of > bandpasses, that split the signal into bands to ultimately reconstruct it, > used for EQs, vocoders, compressors, etc. > > http://en.wikipedia.org/wiki/Filter_bank > > (& the reason to want a bank of IIR's is that FFT's musically suck at this > job [you want to play in a nice octave [not Hz] scale, and the last thing > you want is latency]) > > It's ultimately what a crossover does, but with more & narrower bands. And > because we need narrower bands, I can't imagine butterworth low/highpasses > used anymore. > > > >> Hi Scott, >> >> For a musical FX of filter bank have a look at the Sherman Filter Bank >> http://www.sherman.be/ >> >> There are some audio samples on the site. >> >> Cheers >> >> Andy >> >> >> >> On 8 May 2009, at 16:05, Scott Gravenhorst wrote: >> >>> A discussion list for music-related DSP >> dsp@music.columbia.edu> wrote: >>>> I'm trying to build a filterbank out of RBJ's bandpasses, it works >>>> quite >>>> well. >>>> >>>> My problem: to reconstruct the (44khz, musical) signal properly, I >>>> need >>>> bands from around 15Hz to 40kHz (I oversample bands above 10k btw). >>>> But >>>> that's a big waste of useless bands that I only need to avoid >>>> deformation/ringing on the reconstructed signal. I'm not interested >>>> in >>>> playing with individual bands under 40Hz & above 16k. >>>> >>>> At 1/3oct per band, it results in 8 useless bands out of 35, almost >>>> 1/4 >>>> wasted for the reconstruction. But I can't find any other way. >>>> >>>> -I've tried slowly enlarging the lower/higher bands, but it has its >>>> limits, >>>> to keep artefacts inaudible I may just spare a band or 2. >>>> >>>> -the most obvious would be a low/highpass, but I can't imagine how >>>> they >>>> would fit the neighboring bandpasses. I'd have to stack a lot of >>>> second >>>> order lowpasses to match the steep bandpass slope, as I increase >>>> the # of >>>> bands, defeating the point. >>>> The ideal would be the same bandpass with the same characteristics, >>>> but >>>> turned into a low or highpass, but I don't think that's possible, >>>> is it? >>>> >>>> Any idea? >>> >>> I really wish I could help, but I don't know enough. >>> >>> I've heard _of_ filter banks and that lots of people like to use >>> them - but I have no idea what >>> they sound like. I like to make electronic music, synths of various >>> types, mostly digital and a >>> few analog synths. >>> >>> My question, if you will pardon a newbie/lurker, is what does a >>> filter bank do? What could I >>> expect? What kinds of sounds are best processed through a filter >>> bank and for what purposes? >>> >>> Sorry for the thread break, but I can't think of a better place to >>> ask this. >>> >>> Thanks for the great list discussions. >>> >>> -- ScottG >>> ________________________________________________________________________ >>> -- Scott Gravenhorst >>> -- FPGA MIDI Synthesizer Information: home1.gte.net/res0658s/ >>> FPGA_synth/ >>> -- FatMan: home1.gte.net/res0658s/fatman/ >>> -- NonFatMan: home1.gte.net/res0658s/electronics/ >>> -- When the going gets tough, the tough use the command line. >>> >>> -- >>> 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 > > > -------------------------------------------------------------------------------- > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.325 / Virus Database: 270.12.21/2103 - Release Date: 05/07/09 > 18:05:00 > > -- > 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 didid at skynet.be Fri May 8 11:45:48 2009 From: didid at skynet.be (Didier Dambrin) Date: Fri May 8 11:46:33 2009 Subject: [music-dsp] Filterbank - What does it do? In-Reply-To: <00f901c9cff2$5b639d20$6401a8c0@DaveUpstairs> References: <200905081505.n48F5R6Z031549@linux7.lan><274100983ED1497580DACB7DFF254668@GOLAMD> <00f901c9cff2$5b639d20$6401a8c0@DaveUpstairs> Message-ID: <848E58E0CF574EFD916268C94AAB8BB7@GOLAMD> Yes and that's my point: it's not perfect thus I don't like to consider it as a mastering tool. See how it works on 20Hz-20kHz, because as a user you don't need more to play with. But it really loses some part of the audible spectrum, way above 20hz and way under 20k. And as I wrote, it can be improved but through a big waste of bands, which I'd like to avoid. I also need steeper slopes on the bands, hence I'm doubling the filters. > Hang-on Didier, didn't you write EQUO? - The impressive and insanely > efficient 31 band EQ for FL Studio? > Here:- http://www.image-line.com/documents/equo.html > > Does that use wavelets BTW? : ) > > Dave > > >> not sure it's the right example, as a filterbank is simply a bank of >> bandpasses, that split the signal into bands to ultimately reconstruct >> it, used for EQs, vocoders, compressors, etc. >> >> http://en.wikipedia.org/wiki/Filter_bank >> >> (& the reason to want a bank of IIR's is that FFT's musically suck at >> this job [you want to play in a nice octave [not Hz] scale, and the last >> thing you want is latency]) >> >> It's ultimately what a crossover does, but with more & narrower bands. >> And because we need narrower bands, I can't imagine butterworth >> low/highpasses used anymore. >> >> >> >>> Hi Scott, >>> >>> For a musical FX of filter bank have a look at the Sherman Filter Bank >>> http://www.sherman.be/ >>> >>> There are some audio samples on the site. >>> >>> Cheers >>> >>> Andy >>> >>> >>> >>> On 8 May 2009, at 16:05, Scott Gravenhorst wrote: >>> >>>> A discussion list for music-related DSP >>> dsp@music.columbia.edu> wrote: >>>>> I'm trying to build a filterbank out of RBJ's bandpasses, it works >>>>> quite >>>>> well. >>>>> >>>>> My problem: to reconstruct the (44khz, musical) signal properly, I >>>>> need >>>>> bands from around 15Hz to 40kHz (I oversample bands above 10k btw). >>>>> But >>>>> that's a big waste of useless bands that I only need to avoid >>>>> deformation/ringing on the reconstructed signal. I'm not interested >>>>> in >>>>> playing with individual bands under 40Hz & above 16k. >>>>> >>>>> At 1/3oct per band, it results in 8 useless bands out of 35, almost >>>>> 1/4 >>>>> wasted for the reconstruction. But I can't find any other way. >>>>> >>>>> -I've tried slowly enlarging the lower/higher bands, but it has its >>>>> limits, >>>>> to keep artefacts inaudible I may just spare a band or 2. >>>>> >>>>> -the most obvious would be a low/highpass, but I can't imagine how >>>>> they >>>>> would fit the neighboring bandpasses. I'd have to stack a lot of >>>>> second >>>>> order lowpasses to match the steep bandpass slope, as I increase >>>>> the # of >>>>> bands, defeating the point. >>>>> The ideal would be the same bandpass with the same characteristics, >>>>> but >>>>> turned into a low or highpass, but I don't think that's possible, >>>>> is it? >>>>> >>>>> Any idea? >>>> >>>> I really wish I could help, but I don't know enough. >>>> >>>> I've heard _of_ filter banks and that lots of people like to use >>>> them - but I have no idea what >>>> they sound like. I like to make electronic music, synths of various >>>> types, mostly digital and a >>>> few analog synths. >>>> >>>> My question, if you will pardon a newbie/lurker, is what does a >>>> filter bank do? What could I >>>> expect? What kinds of sounds are best processed through a filter >>>> bank and for what purposes? >>>> >>>> Sorry for the thread break, but I can't think of a better place to >>>> ask this. >>>> >>>> Thanks for the great list discussions. >>>> >>>> -- ScottG >>>> ________________________________________________________________________ >>>> -- Scott Gravenhorst >>>> -- FPGA MIDI Synthesizer Information: home1.gte.net/res0658s/ >>>> FPGA_synth/ >>>> -- FatMan: home1.gte.net/res0658s/fatman/ >>>> -- NonFatMan: home1.gte.net/res0658s/electronics/ >>>> -- When the going gets tough, the tough use the command line. >>>> >>>> -- >>>> 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 >> >> >> -------------------------------------------------------------------------------- >> >> >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 8.5.325 / Virus Database: 270.12.21/2103 - Release Date: >> 05/07/09 18:05:00 >> >> -- >> 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 -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.325 / Virus Database: 270.12.21/2103 - Release Date: 05/07/09 18:05:00 From martin.eisenberg at udo.edu Fri May 8 14:18:31 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Fri May 8 14:16:29 2009 Subject: [music-dsp] Blurps and Chirps when changing filter parameters References: <108217.42179.qm@web58206.mail.re3.yahoo.com><002501c9ce72$d1fecc60$0201a8c0@mooncode><27C0FB3B66874FAF9C5CEE8D2EC90911@nibln01077><005d01c9cf37$3c40cb40$0201a8c0@mooncode> Message-ID: <006401c9d009$682f8e80$0201a8c0@mooncode> From: "Vadim Zavalishin" > However, my article is not only about delay-free loops, but > also about the topology-preserving transformation method, > which is based on integrator replacement. Yes, I understand. > In this respect it is closer to what Serafini/Zamboni paper > I mentioned earler is doing Hmm, their example circuit doesn't even have any modules to treat separately, and sure enough they lump everything into a single equation. Thus I can't see that they're concerned with topology at all (despite use of the word in the abstract -- which franky strikes me, equally as when I first encountered the paper, as setting up a strawman problem). > (again I don't know where this method was described first). I believe that would be their ref. 4 (Borin et al. 2000) which introduced the K-method. That also cites Harma 1998 since the common theme of both techniques is splitting a network's linear dynamics into the part directly connected to a troublesome subsystem (instantaneous feedback in one case, both feedback and nonlinearity in the other) and all the rest, and then implementing the former part without rewiring the latter. Martin From jos at ccrma.stanford.edu Fri May 8 19:12:12 2009 From: jos at ccrma.stanford.edu (Julius Smith) Date: Fri May 8 19:18:13 2009 Subject: [music-dsp] Re: Blurps and Chirps when changing filter parameters In-Reply-To: <20090508014104.D613854D82F@ws6-9.us4.outblaze.com> References: <20090508014104.D613854D82F@ws6-9.us4.outblaze.com> Message-ID: <200905082318.n48NI3Rk003572@feta.cc.columbia.edu> Hi Robert! At 06:41 PM 5/7/2009, robert bristow-johnson wrote: > > ----- Original Message ----- > > From: "Julius Smith" > > To: "A discussion list for music-related DSP" > > > Cc: music-dsp@music.columbia.edu > > Subject: Re: [music-dsp] Re: Blurps and Chirps when changing > filter parameters > > Date: Thu, 07 May 2009 10:47:08 -0700 > > > > > > I haven't read this whole thread, but to isolate coefficient > variation from > > filter state, you can realize your filter as a normalized ladder filter. > >Julius, what do you mean by "isolate coefficient variation from filter state"? I mean that coefficient variation does not affect instantaneous signal power at all - they are decoupled. In old analog terms, you can say there is no "parametric amplification" (or attenuation). >i think i know what a normalized ladder form is, i think i know how >k1 and k2 are derived from and are dependent on the biquad poles, >and i know that the magnitudes of the states are limited in an L^2 >norm kinda way. but wouldn't sweeping the k1 and k2 values possibly >introduce artifacts in the normalized ladder? Sweeping k1 and k2 can only affect tuning and damping. (Of course, they should be swept at the full sampling rate, like any filter coefficient, as opposed to some lower "K-rate".) Below is the normalized ladder resonator I wrote for osc.lib in Faust: // USAGE: nlf2(f,r), where // f : resonance frequency (Hz) // r : loss factor for exponential decay // (set to 1 to make a sinusoidal oscillator) // // Reference: // http://ccrma.stanford.edu/~jos/pasp/Power_Normalized_Waveguide_Filters.html // nlf2(f,r,x) = ((_<:_,_),(_<:_,_) : (*(s),*(c),*(c),*(0-s)) :> (*(r),+(x))) ~ cross with { th = 2*PI*f/SR; c = cos(th); s = sin(th); cross = _,_ <: !,_,_,!; }; Since probably few people work in Faust, below is the C++ program generated by Faust from the following test program: // Faust source in file tnlf2.dsp: import("filter.lib"); f = hslider("f",440,0,10000,1); r = hslider("r",0.9,0,1,0.001); process = nlf2(f,r); C++ generated by the command "faust tnlf2.dsp": //----------------------------------------------------- // // Code generated with Faust 0.9.9.5b2 (http://faust.grame.fr) //----------------------------------------------------- /* link with */ #include class mydsp : public dsp { private: float fslider0; float fConst0; float fslider1; float fRec0[2]; float fRec1[2]; public: // ... virtual int getNumInputs() { return 1; } virtual int getNumOutputs() { return 2; } static void classInit(int samplingFreq) { } virtual void instanceInit(int samplingFreq) { fSamplingFreq = samplingFreq; fslider0 = 440.0f; fConst0 = (6.283185f / fSamplingFreq); fslider1 = 0.9f; for (int i=0; i<2; i++) fRec0[i] = 0; for (int i=0; i<2; i++) fRec1[i] = 0; } virtual void init(int samplingFreq) { classInit(samplingFreq); instanceInit(samplingFreq); } virtual void buildUserInterface(UI* interface) { interface->openVerticalBox("tnlf2"); interface->addHorizontalSlider("f", &fslider0, 440.0f, 0.0f, 10000.0f, 1.0f); interface->addHorizontalSlider("r", &fslider1, 0.9f, 0.0f, 1.0f, 1.000000e-03f); interface->closeBox(); } virtual void compute (int count, float** input, float** output) { float fSlow0 = (fConst0 * fslider0); float fSlow1 = sinf(fSlow0); float fSlow2 = cosf(fSlow0); float fSlow3 = fslider1; float fSlow4 = (0 - fSlow1); float* input0 = input[0]; float* output0 = output[0]; float* output1 = output[1]; for (int i=0; i Prof. of Music and Assoc. Prof. (by courtesy) of Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ From jos at ccrma.stanford.edu Fri May 8 21:29:28 2009 From: jos at ccrma.stanford.edu (Julius Smith) Date: Sat May 9 02:39:29 2009 Subject: [music-dsp] Re: Blurps and Chirps when changing filter parameters In-Reply-To: <200905082318.n48NI3Rk003572@feta.cc.columbia.edu> References: <20090508014104.D613854D82F@ws6-9.us4.outblaze.com> <200905082318.n48NI3Rk003572@feta.cc.columbia.edu> Message-ID: <200905090639.n496dH52009749@tepin.cc.columbia.edu> It occurred to me that my example should follow my own advice (!) and run each slider through a one-pole filter so that the coefficients are updated at the full sampling rate: // Revised Faust program: import("filter.lib"); f = hslider("f",440,0,10000,1) : smooth(0.999); r = hslider("r",0.9,0,1,0.001) : smooth(0.999); process = nlf2(f,r); // Generated C++ code: //----------------------------------------------------- // Code generated with Faust 0.9.9.5b2 (http://faust.grame.fr) //----------------------------------------------------- #include class mydsp : public dsp { private: float fslider0; float fRec2[2]; float fConst0; float fslider1; float fRec3[2]; float fRec0[2]; float fRec1[2]; public: //... virtual int getNumInputs() { return 1; } virtual int getNumOutputs() { return 2; } static void classInit(int samplingFreq) { } virtual void instanceInit(int samplingFreq) { fSamplingFreq = samplingFreq; fslider0 = 440.0f; for (int i=0; i<2; i++) fRec2[i] = 0; fConst0 = (6.283185f / fSamplingFreq); fslider1 = 0.9f; for (int i=0; i<2; i++) fRec3[i] = 0; for (int i=0; i<2; i++) fRec0[i] = 0; for (int i=0; i<2; i++) fRec1[i] = 0; } virtual void init(int samplingFreq) { classInit(samplingFreq); instanceInit(samplingFreq); } virtual void buildUserInterface(UI* interface) { interface->openVerticalBox("tnlf2"); interface->addHorizontalSlider("f", &fslider0, 440.0f, 0.0f, 10000.0f, 1.0f); interface->addHorizontalSlider("r", &fslider1, 0.9f, 0.0f, 1.0f, 1.000000e-03f); interface->closeBox(); } virtual void compute (int count, float** input, float** output) { float fSlow0 = (9.999871e-04f * fslider0); float fSlow1 = (9.999871e-04f * fslider1); float* input0 = input[0]; float* output0 = output[0]; float* output1 = output[1]; for (int i=0; iHi Robert! > >At 06:41 PM 5/7/2009, robert bristow-johnson wrote: > >> > ----- Original Message ----- >> > From: "Julius Smith" >> > To: "A discussion list for music-related DSP" >> >> > Cc: music-dsp@music.columbia.edu >> > Subject: Re: [music-dsp] Re: Blurps and Chirps when changing >> filter parameters >> > Date: Thu, 07 May 2009 10:47:08 -0700 >> > >> > >> > I haven't read this whole thread, but to isolate coefficient >> variation from >> > filter state, you can realize your filter as a normalized ladder filter. >> >>Julius, what do you mean by "isolate coefficient variation from >>filter state"? > >I mean that coefficient variation does not affect instantaneous >signal power at all - they are decoupled. In old analog terms, you >can say there is no "parametric amplification" (or attenuation). > >>i think i know what a normalized ladder form is, i think i know how >>k1 and k2 are derived from and are dependent on the biquad poles, >>and i know that the magnitudes of the states are limited in an L^2 >>norm kinda way. but wouldn't sweeping the k1 and k2 values >>possibly introduce artifacts in the normalized ladder? > >Sweeping k1 and k2 can only affect tuning and damping. (Of course, >they should be swept at the full sampling rate, like any filter >coefficient, as opposed to some lower "K-rate".) > >Below is the normalized ladder resonator I wrote for osc.lib in Faust: > >// USAGE: nlf2(f,r), where >// f : resonance frequency (Hz) >// r : loss factor for exponential decay >// (set to 1 to make a sinusoidal oscillator) >// >// Reference: >// http://ccrma.stanford.edu/~jos/pasp/Power_Normalized_Waveguide_Filters.html >// >nlf2(f,r,x) = ((_<:_,_),(_<:_,_) : (*(s),*(c),*(c),*(0-s)) :> > (*(r),+(x))) ~ cross >with { > th = 2*PI*f/SR; > c = cos(th); > s = sin(th); > cross = _,_ <: !,_,_,!; >}; > >Since probably few people work in Faust, below is the C++ program >generated by Faust from the following test program: > >// Faust source in file tnlf2.dsp: >import("filter.lib"); >f = hslider("f",440,0,10000,1); >r = hslider("r",0.9,0,1,0.001); >process = nlf2(f,r); > >C++ generated by the command "faust tnlf2.dsp": > >//----------------------------------------------------- >// >// Code generated with Faust 0.9.9.5b2 (http://faust.grame.fr) >//----------------------------------------------------- >/* link with */ >#include > >class mydsp : public dsp { > private: > float fslider0; > float fConst0; > float fslider1; > float fRec0[2]; > float fRec1[2]; > public: > // ... > virtual int getNumInputs() { return 1; } > virtual int getNumOutputs() { return 2; } > static void classInit(int samplingFreq) { > } > virtual void instanceInit(int samplingFreq) { > fSamplingFreq = samplingFreq; > fslider0 = 440.0f; > fConst0 = (6.283185f / fSamplingFreq); > fslider1 = 0.9f; > for (int i=0; i<2; i++) fRec0[i] = 0; > for (int i=0; i<2; i++) fRec1[i] = 0; > } > virtual void init(int samplingFreq) { > classInit(samplingFreq); > instanceInit(samplingFreq); > } > virtual void buildUserInterface(UI* interface) { > interface->openVerticalBox("tnlf2"); > interface->addHorizontalSlider("f", &fslider0, > 440.0f, 0.0f, 10000.0f, 1.0f); > interface->addHorizontalSlider("r", &fslider1, > 0.9f, 0.0f, 1.0f, 1.000000e-03f); > interface->closeBox(); > } > virtual void compute (int count, float** input, float** output) { > float fSlow0 = (fConst0 * fslider0); > float fSlow1 = sinf(fSlow0); > float fSlow2 = cosf(fSlow0); > float fSlow3 = fslider1; > float fSlow4 = (0 - fSlow1); > float* input0 = input[0]; > float* output0 = output[0]; > float* output1 = output[1]; > for (int i=0; i fRec0[0] = (fSlow3 * ((fSlow2 * fRec0[1]) + > (fSlow1 * fRec1[1]))); > fRec1[0] = ((fSlow2 * fRec1[1]) + > (input0[i] + (fSlow4 * fRec0[1]))); > output0[i] = fRec0[0]; > output1[i] = fRec1[0]; > // post processing > fRec1[1] = fRec1[0]; > fRec0[1] = fRec0[0]; > } > } >}; > > > >Julius O. Smith III >Prof. of Music and Assoc. Prof. (by courtesy) of Electrical Engineering >CCRMA, Stanford University >http://ccrma.stanford.edu/~jos/ > >-- >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 Julius O. Smith III Prof. of Music and Assoc. Prof. (by courtesy) of Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ From jos at ccrma.stanford.edu Fri May 8 21:34:05 2009 From: jos at ccrma.stanford.edu (Julius Smith) Date: Sat May 9 02:45:06 2009 Subject: [music-dsp] Re: Blurps and Chirps when changing filter parameters In-Reply-To: <200905082318.n48NI3Rk003572@feta.cc.columbia.edu> References: <20090508014104.D613854D82F@ws6-9.us4.outblaze.com> <200905082318.n48NI3Rk003572@feta.cc.columbia.edu> Message-ID: <200905090644.n496ioKO010356@tepin.cc.columbia.edu> This is kind of neat. It's a Faust program that uses the second-order normalized-ladder-filter as an oscillator in a basic FM configuration. Try that with your other filter structures! - Julius // Faust source toscr.dsp: import("osc.lib"); amp = hslider("[0] gain [unit:dB]",0,-60,40,0.1) : db2linear; fc = hslider("[1] carrier frequency",220,0,10000,1) : smooth(0.999); fm = hslider("[2] modulation frequency",220,0,10000,1) : smooth(0.999); beta = hslider("[3] FM index",440,0,10,0.001) : smooth(0.999); process = amp*oscr(fc*(1+beta*oscr(fm))); // Example usage: // faust2coreaudio toscr.dsp // open toscr.app Julius O. Smith III Prof. of Music and Assoc. Prof. (by courtesy) of Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ From jos at ccrma.stanford.edu Sat May 9 03:57:00 2009 From: jos at ccrma.stanford.edu (Julius Smith) Date: Sat May 9 02:57:27 2009 Subject: [music-dsp] Re: Blurps and Chirps when changing filter parameters In-Reply-To: <200905090644.n496ioKO010356@tepin.cc.columbia.edu> References: <20090508014104.D613854D82F@ws6-9.us4.outblaze.com> <200905082318.n48NI3Rk003572@feta.cc.columbia.edu> <200905090644.n496ioKO010356@tepin.cc.columbia.edu> Message-ID: <200905090657.n496vAEu022959@calabash.cc.columbia.edu> Typo alert: replace the beta line by the following: beta = hslider("[3] FM index",1,0,10,0.001) : smooth(0.999); (I didn't notice this in the coreaudio app because the slider default values seem to be overridden by last values used in that case.) At 06:34 PM 5/8/2009, Julius Smith wrote: >This is kind of neat. It's a Faust program that uses the >second-order normalized-ladder-filter as an oscillator in a basic FM >configuration. Try that with your other filter structures! - Julius > >// Faust source toscr.dsp: > >import("osc.lib"); > >amp = hslider("[0] gain [unit:dB]",0,-60,40,0.1) : db2linear; >fc = hslider("[1] carrier frequency",220,0,10000,1) : smooth(0.999); >fm = hslider("[2] modulation frequency",220,0,10000,1) : smooth(0.999); >beta = hslider("[3] FM index",440,0,10,0.001) : smooth(0.999); > >process = amp*oscr(fc*(1+beta*oscr(fm))); > >// Example usage: >// faust2coreaudio toscr.dsp >// open toscr.app > > > >Julius O. Smith III >Prof. of Music and Assoc. Prof. (by courtesy) of Electrical Engineering >CCRMA, Stanford University >http://ccrma.stanford.edu/~jos/ > >-- >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 Julius O. Smith III Prof. of Music and Assoc. Prof. (by courtesy) of Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ From richarddobson at blueyonder.co.uk Sat May 9 11:39:27 2009 From: richarddobson at blueyonder.co.uk (Richard Dobson) Date: Sat May 9 11:41:12 2009 Subject: [music-dsp] Re: Blurps and Chirps when changing filter parameters In-Reply-To: <200905090644.n496ioKO010356@tepin.cc.columbia.edu> References: <20090508014104.D613854D82F@ws6-9.us4.outblaze.com> <200905082318.n48NI3Rk003572@feta.cc.columbia.edu> <200905090644.n496ioKO010356@tepin.cc.columbia.edu> Message-ID: <4A05A3AF.70803@blueyonder.co.uk> Julius Smith wrote: .. > > // Example usage: > // faust2coreaudio toscr.dsp > // open toscr.app > I have barely started looking at faust, but (with the current 0.9.9.4b release) I can't find anything referring to coreaudio, such as "faust2coreaudio". Have I missed something obvious or is this something yet to be released? Richard Dobson From Victor.Lazzarini at nuim.ie Sat May 9 12:11:50 2009 From: Victor.Lazzarini at nuim.ie (victor) Date: Sat May 9 12:12:13 2009 Subject: [music-dsp] Re: Blurps and Chirps when changing filter parameters In-Reply-To: <4A05A3AF.70803@blueyonder.co.uk> References: <20090508014104.D613854D82F@ws6-9.us4.outblaze.com> <200905082318.n48NI3Rk003572@feta.cc.columbia.edu> <200905090644.n496ioKO010356@tepin.cc.columbia.edu> <4A05A3AF.70803@blueyonder.co.uk> Message-ID: <27AB80CF33094BE4ABE60371BD222854@LazzariniPC> I am not sure about coreaudio, but generally speaking you need to supply the architecture file (eg. csound.cpp) with -a to get a C++ source for that particular target. Victor ----- Original Message ----- From: "Richard Dobson" To: "A discussion list for music-related DSP" Sent: Saturday, May 09, 2009 4:39 PM Subject: Re: [music-dsp] Re: Blurps and Chirps when changing filter parameters > Julius Smith wrote: > .. >> >> // Example usage: >> // faust2coreaudio toscr.dsp >> // open toscr.app >> > > I have barely started looking at faust, but (with the current 0.9.9.4b > release) I can't find anything referring to coreaudio, such as > "faust2coreaudio". Have I missed something obvious or is this something > yet to be released? > > Richard Dobson > > > > -- > 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 richarddobson at blueyonder.co.uk Sat May 9 12:29:32 2009 From: richarddobson at blueyonder.co.uk (Richard Dobson) Date: Sat May 9 12:31:00 2009 Subject: [music-dsp] Re: Blurps and Chirps when changing filter parameters In-Reply-To: <27AB80CF33094BE4ABE60371BD222854@LazzariniPC> References: <20090508014104.D613854D82F@ws6-9.us4.outblaze.com> <200905082318.n48NI3Rk003572@feta.cc.columbia.edu> <200905090644.n496ioKO010356@tepin.cc.columbia.edu> <4A05A3AF.70803@blueyonder.co.uk> <27AB80CF33094BE4ABE60371BD222854@LazzariniPC> Message-ID: <4A05AF6C.4040800@blueyonder.co.uk> victor wrote: > > I am not sure about coreaudio, but generally speaking you need to supply > the > architecture file (eg. csound.cpp) with -a to get a C++ source for that > particular > target. > Hmm well, I don't have csound.cpp either. Perhaps there is some external library of architecture files that I am missing? The distribution has material for pd, sc, and stuff for jack, alsa etc. One readme file refers to architecture files "provided by various contributors". So either there is some site externally where these can be found, or some files are missing from the distribution. I would happily join a mailing list for faust where such questions might be better asked; but I see no indication of such a list on the Grame web pages. ?? Richard Dobson From Victor.Lazzarini at nuim.ie Sat May 9 12:44:53 2009 From: Victor.Lazzarini at nuim.ie (victor) Date: Sat May 9 12:45:21 2009 Subject: [music-dsp] Re: Blurps and Chirps when changing filter parameters In-Reply-To: <4A05AF6C.4040800@blueyonder.co.uk> References: <20090508014104.D613854D82F@ws6-9.us4.outblaze.com> <200905082318.n48NI3Rk003572@feta.cc.columbia.edu> <200905090644.n496ioKO010356@tepin.cc.columbia.edu> <4A05A3AF.70803@blueyonder.co.uk> <27AB80CF33094BE4ABE60371BD222854@LazzariniPC> <4A05AF6C.4040800@blueyonder.co.uk> Message-ID: <9E9B893ADF0E46D4A44EE1EB041582A2@LazzariniPC> csound.cpp is in CVS only at the moment. Victor ----- Original Message ----- From: "Richard Dobson" To: "A discussion list for music-related DSP" Sent: Saturday, May 09, 2009 5:29 PM Subject: Re: [music-dsp] Re: Blurps and Chirps when changing filter parameters > victor wrote: >> >> I am not sure about coreaudio, but generally speaking you need to supply >> the >> architecture file (eg. csound.cpp) with -a to get a C++ source for that >> particular >> target. >> > > > Hmm well, I don't have csound.cpp either. Perhaps there is some external > library of architecture files that I am missing? The distribution has > material for pd, sc, and stuff for jack, alsa etc. One readme file refers > to architecture files "provided by various contributors". So either there > is some site externally where these can be found, or some files are > missing from the distribution. I would happily join a mailing list for > faust where such questions might be better asked; but I see no indication > of such a list on the Grame web pages. > > ?? > > Richard Dobson > > > > > -- > 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 Victor.Lazzarini at nuim.ie Sat May 9 12:46:08 2009 From: Victor.Lazzarini at nuim.ie (victor) Date: Sat May 9 12:46:30 2009 Subject: [music-dsp] Re: Blurps and Chirps when changing filter parameters In-Reply-To: <4A05AF6C.4040800@blueyonder.co.uk> References: <20090508014104.D613854D82F@ws6-9.us4.outblaze.com> <200905082318.n48NI3Rk003572@feta.cc.columbia.edu> <200905090644.n496ioKO010356@tepin.cc.columbia.edu> <4A05A3AF.70803@blueyonder.co.uk> <27AB80CF33094BE4ABE60371BD222854@LazzariniPC> <4A05AF6C.4040800@blueyonder.co.uk> Message-ID: <8CD52828291849DE9939CAAB707B3F4E@LazzariniPC> and the list is: faudiostream-devel@lists.sourceforge.net ----- Original Message ----- From: "Richard Dobson" To: "A discussion list for music-related DSP" Sent: Saturday, May 09, 2009 5:29 PM Subject: Re: [music-dsp] Re: Blurps and Chirps when changing filter parameters > victor wrote: >> >> I am not sure about coreaudio, but generally speaking you need to supply >> the >> architecture file (eg. csound.cpp) with -a to get a C++ source for that >> particular >> target. >> > > > Hmm well, I don't have csound.cpp either. Perhaps there is some external > library of architecture files that I am missing? The distribution has > material for pd, sc, and stuff for jack, alsa etc. One readme file refers > to architecture files "provided by various contributors". So either there > is some site externally where these can be found, or some files are > missing from the distribution. I would happily join a mailing list for > faust where such questions might be better asked; but I see no indication > of such a list on the Grame web pages. > > ?? > > Richard Dobson > > > > > -- > 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 jos at ccrma.stanford.edu Sat May 9 04:25:59 2009 From: jos at ccrma.stanford.edu (Julius Smith) Date: Sat May 9 13:25:44 2009 Subject: [music-dsp] Re: Blurps and Chirps when changing filter parameters In-Reply-To: <4A05A3AF.70803@blueyonder.co.uk> References: <20090508014104.D613854D82F@ws6-9.us4.outblaze.com> <200905082318.n48NI3Rk003572@feta.cc.columbia.edu> <200905090644.n496ioKO010356@tepin.cc.columbia.edu> <4A05A3AF.70803@blueyonder.co.uk> Message-ID: <200905091725.n49HPY40010382@noni.cc.columbia.edu> You can find faust2coreaudio in /tools/faust2appls/ If you cd there and type "make install", they get put in /usr/local/bin/ unless you change prefix in the Makefile. I prefer to use symbolic links instead: cd /opt/local/bin ln -s /tools/faust2appls/faust2* . I use the latest CVS myself, but I think faust2coreaudio has been around a pretty good while. Julius At 08:39 AM 5/9/2009, Richard Dobson wrote: >Julius Smith wrote: >.. >>// Example usage: >>// faust2coreaudio toscr.dsp >>// open toscr.app > >I have barely started looking at faust, but (with the current >0.9.9.4b release) I can't find anything referring to coreaudio, >such as "faust2coreaudio". Have I missed something obvious or is >this something yet to be released? > >Richard Dobson > > > >-- >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 Julius O. Smith III Prof. of Music and Assoc. Prof. (by courtesy) of Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ From vadim.zavalishin at native-instruments.de Mon May 11 06:13:50 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Mon May 11 06:14:07 2009 Subject: [music-dsp] Blurps and Chirps when changing filter parameters In-Reply-To: <006401c9d009$682f8e80$0201a8c0@mooncode> References: <108217.42179.qm@web58206.mail.re3.yahoo.com><002501c9ce72$d1fecc60$0201a8c0@mooncode><27C0FB3B66874FAF9C5CEE8D2EC90911@nibln01077><005d01c9cf37$3c40cb40$0201a8c0@mooncode> <006401c9d009$682f8e80$0201a8c0@mooncode> Message-ID: <437852DE9038454CBF3CF4FAA959BECD@nibln01077> >> In this respect it is closer to what Serafini/Zamboni paper >> I mentioned earler is doing > > Hmm, their example circuit doesn't even have any modules to treat > separately, and sure enough they lump everything into a single > equation. Thus I can't see that they're concerned with topology > at all (despite use of the word in the abstract -- which franky > strikes me, equally as when I first encountered the paper, as > setting up a strawman problem). The topology is implicitly present there in the form of differential equations. Actually, I believe, in linear systems there is effectively a kind of one-to-one relationship between the topology and the choice of state variables, as all possible topologies using exactly the same state variables should be completely equivalent (except for possibly different precision issues). Although, I agree that the usage of the term topology in that article is confusing, anyway it's not what I meant by "topology". > >> (again I don't know where this method was described first). > > I believe that would be their ref. 4 (Borin et al. 2000) which > introduced the K-method. That also cites Harma 1998 since the > common theme of both techniques is splitting a network's linear > dynamics into the part directly connected to a troublesome > subsystem (instantaneous feedback in one case, both feedback and > nonlinearity in the other) and all the rest, and then > implementing the former part without rewiring the latter. I don't have access to that article, so unfortunately I cannot check that. I found another paper on a similar subject where one of the authors was the same in DAFX'04 proceedings (p.113), which is again on a subject of eliminating delay-free loops. Anyway, when I was referring to Serafini/Zamboni paper, the main thing I meant was that you can apply the bilinear transform directly to the differential equations, which eliminates the delay-free loops implicitly. BTW in regards to nonlinear elements, there's another paper I wrote addressing analytical computation of nonlinearities in delay-free feedback loops by using 2nd order curve (conic sections) approximations, as the Newton-Raphson (which everyone seems to suggest) can have convergence problems. Thanks for the informative feedback. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From theover at tiscali.nl Tue May 12 09:25:23 2009 From: theover at tiscali.nl (theover) Date: Tue May 12 09:25:34 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth Message-ID: <23487108.post@talk.nabble.com> Hi, Years ago I made and mildly publically and internet-wise promoted this Open Source, Analog Devices Blackfin DSP, C based, synthesizer which emulates a traditional analog design synth: http://www.theover.org/Synth I suppose it contains a lot of usable open source parts, which may be freely used *for non-commercial purposes* (thus far). I recently considered to add more FPGA processing to it (like with the Spartan-3e devboard), would there be people interested in this? Or if I'd find a great idea to after a long time go to Silicon Valley or surroundings there are like 10,000 people who can get such things done easily? I know the drill about synthetic sound: making good sounding synths is another story (see still going strong Prophets against such a forest of hardly musically usable software), of course. Regards, Theo Verelst ------------------------------------------------------------------------------------------------- www.theover.org 'It keeps coming up hookers' - "Dirty" Harry Calahan in The Enforcer -- View this message in context: http://www.nabble.com/Open-Source-DSP-Analog-Simulation-Synth-tp23487108p23487108.html Sent from the Music-DSP mailing list archive at Nabble.com. From czhenry at gmail.com Tue May 12 11:45:29 2009 From: czhenry at gmail.com (Charles Henry) Date: Tue May 12 11:45:41 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: <23487108.post@talk.nabble.com> References: <23487108.post@talk.nabble.com> Message-ID: <518fe7b20905120845x137058bawec897c0fbcad7839@mail.gmail.com> Hi, Theo I don't mean to sound unimpressed or anything (I really don't), but have you considered porting your algorithm to Pure Data? My impression of DSP boards was that they were prohibitively expensive. The PC is a more accessible platform. What reason did you choose the Blackfin DSP? What kind of requirements does your algorithm have? Chuck On Tue, May 12, 2009 at 8:25 AM, theover wrote: > > Hi, > > Years ago I made and mildly publically and internet-wise promoted this Open > Source, Analog Devices Blackfin DSP, C based, synthesizer which emulates a > traditional analog design synth: > > ?http://www.theover.org/Synth > > I suppose it contains a lot of usable open source parts, which may be freely > used *for non-commercial purposes* (thus far). > > I recently considered to add more FPGA processing to it (like with the > Spartan-3e devboard), would there be people interested in this? Or if I'd > find a great idea to after a long time go to Silicon Valley or surroundings > there are like 10,000 people who can get such things done easily? I know the > drill about synthetic sound: making good sounding synths is another story > (see still going strong Prophets against such a forest of hardly musically > usable software), of course. > > Regards, > > ? Theo Verelst > ------------------------------------------------------------------------------------------------- > ? www.theover.org > ? 'It keeps coming up hookers' - "Dirty" Harry Calahan in The Enforcer > -- > View this message in context: http://www.nabble.com/Open-Source-DSP-Analog-Simulation-Synth-tp23487108p23487108.html > Sent from the Music-DSP mailing list archive at Nabble.com. > > -- > 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 theover at tiscali.nl Tue May 12 18:06:54 2009 From: theover at tiscali.nl (theover) Date: Tue May 12 18:07:12 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: <518fe7b20905120845x137058bawec897c0fbcad7839@mail.gmail.com> References: <23487108.post@talk.nabble.com> <518fe7b20905120845x137058bawec897c0fbcad7839@mail.gmail.com> Message-ID: <23511475.post@talk.nabble.com> Charles Henry wrote: > > Hi, Theo > > I don't mean to sound unimpressed or anything (I really don't), but > have you considered porting your algorithm to Pure Data? > > My impression of DSP boards was that they were prohibitively > expensive. The PC is a more accessible platform. > > What reason did you choose the Blackfin DSP? What kind of > requirements does your algorithm have? > > Chuck > Wel, I had a introduction deal on a Blackfin board with multiple pretty good 24 bit AD/DA converters from Analog Devices (via Silica IIRC) so it cost like 100 euros, which is really not much, and then it uses less power, can be connected to over a bus (I've made a working FPGA connection), and it screws in a machine much easier. A PC has the major disadvantage that often the DA conversion is far from great, like the way samples are handled: uneven timing, lost frames, not to mention unwanted sample rate conversion and such. Working with a good Linux and Jack can make most of that ok. The blackfin is a small, electronicaly nice, affordable, fairly powefull DSP with a decent IDE and C compiler from ADI (I think there's GNU too). I liekd to make a machine which starts up good (my synth makes sound after less then a second after putting it on) has no hassle, and especially: it responds to midi with absolute minimal, and constant delay (which rarely is the case, ever), is solid state more than a PC, and lighter. Pd is nice enough, Im not sure about all ins and outs though I have played with it a while ago, the real-time and block aspects are good. In principle a standalone jack/alsa application would be possible too with the application in the synth, I didn't take the time to do it, but it's Free and Open Source source code, and the sound is good because there is as little as I thought possible distortion in the digital signal path, compared with the analog counterparts, including bandwidth limited oscilators. In general, with more optimizations, DSPs can do quite a bit of processing compared with PCs, like I can use a computation intensive FFT based transform on a PC with SSE2 and such, but it is possible it can also run on a few watts of DSP, I guess that's a more interesting perspective. -- View this message in context: http://www.nabble.com/Open-Source-DSP-Analog-Simulation-Synth-tp23487108p23511475.html Sent from the Music-DSP mailing list archive at Nabble.com. From Victor.Lazzarini at nuim.ie Tue May 12 18:20:44 2009 From: Victor.Lazzarini at nuim.ie (victor) Date: Tue May 12 18:21:17 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: <23511475.post@talk.nabble.com> References: <23487108.post@talk.nabble.com> <518fe7b20905120845x137058bawec897c0fbcad7839@mail.gmail.com> <23511475.post@talk.nabble.com> Message-ID: <3C22680E207841989DF0D8A9AC06FBC2@LazzariniPC> > A PC has the major disadvantage that often the DA conversion is far from > great, like the way samples are handled: uneven timing, lost frames, not > to > mention unwanted sample rate conversion and such. Working with a good > Linux > and Jack can make most of that ok. If you permit me, I beg to differ. I have been working with audio synthesis on general-purpose computers for about 16 years (and in realtime for about 10-12). Some of the code I wrote when I started still works and produces audio. With a modern system, provided you are not trying to do something beyond the CPU power, there are no lost frames (dropouts) and there is good timing. I would not invest time and effort on a piece of hardware that will be obsolete next year. It's just not my thing. I'm very happy with the quality of what I get out of a PC. Victor From theover at tiscali.nl Tue May 12 18:55:31 2009 From: theover at tiscali.nl (theover) Date: Tue May 12 18:55:50 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: <3C22680E207841989DF0D8A9AC06FBC2@LazzariniPC> References: <23487108.post@talk.nabble.com> <518fe7b20905120845x137058bawec897c0fbcad7839@mail.gmail.com> <23511475.post@talk.nabble.com> <3C22680E207841989DF0D8A9AC06FBC2@LazzariniPC> Message-ID: <23512139.post@talk.nabble.com> Victor.Lazzarini wrote: > > >> A PC has the major disadvantage that often the DA conversion is far from >> great, like the way samples are handled: uneven timing, lost frames, not >> to... > I'm very happy with the quality of what I get out of a PC. > Victor > Well, when I started building and using synthesizers (like beginning to halfway the 80s) the computers I used could do very little DSP, a z80 couls do some sample table things, and the Atary ST with a 8 MHz 68000 could do some real-time FM but it was hard. Equipment like the Yamaga DX7 had custum VLSI chips in it, which was at the time I graduated (91) in different chip and computer design (computer graphics machine design) probably not the hottest hardware, but still good. In fact even now I can run a (Hexter) DX simulation on a PC, with 64 voices probably (I used three hexters and a few other programs on Linux regulalry) but unfortunately it doesn't sound as nice. And you need a good DA converter (I use a Lexicon 24 bit Omega), and even on a fast PC you'll still get delay between for instance a breath controller or such of a midi delay plus a frame of what have you, 256 samples ? For making music that isn't totally right. Long live a Open Source PCI-Express FPGA board with possibly some good DSP on it, too, but that isn't around, yet. And I guess for business similar things as for music needs be considered: before you know it your software is copied and illegally spread... Hardware can be made fairly secure, a FPGA board I can couple with the DSP even has hardware checksum facilities on it, and isn't very expensive either. Theo -- View this message in context: http://www.nabble.com/Open-Source-DSP-Analog-Simulation-Synth-tp23487108p23512139.html Sent from the Music-DSP mailing list archive at Nabble.com. From neolit123 at gmail.com Tue May 12 19:06:24 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Tue May 12 19:10:26 2009 Subject: [music-dsp] Filterbank References: <85CD8187116F4E1CB450B439FF33FE5A@nibln01077><594BA9EFD0744FEAA4EEA26FCAF0EF23@nibln01077> Message-ID: <003801c9d356$baee2ff0$0201a8c0@LuboPC> ----- Original Message ----- From: "Didier Dambrin" To: "A discussion list for music-related DSP" Sent: Friday, May 08, 2009 5:29 PM Subject: [music-dsp] Filterbank > I'm trying to build a filterbank out of RBJ's bandpasses, it works quite > well. > > My problem: to reconstruct the (44khz, musical) signal properly, I need > bands from around 15Hz to 40kHz (I oversample bands above 10k btw). But > that's a big waste of useless bands that I only need to avoid > deformation/ringing on the reconstructed signal. I'm not interested in > playing with individual bands under 40Hz & above 16k. > > At 1/3oct per band, it results in 8 useless bands out of 35, almost 1/4 > wasted for the reconstruction. But I can't find any other way. > > -I've tried slowly enlarging the lower/higher bands, but it has its > limits, to keep artefacts inaudible I may just spare a band or 2. Hello Didier, I think that, from a technical point of view the method of slowly enlarging the bandwidth, based on a accurate log scale and band number would be best. But yes artefacts may pop out, which I think can be dealt with. If artefacts are present in specific ranges (between bands), maybe separate BP type modes can be designed (different tweaks of the same filter or as a last option different filter types) to provide more flexibility - BPtypeA, BPtypeB, BPtypeC... etc. Where BPtypeA differs from BPtypeB,C - typeA is more appropriate for high frequencies for example. For log scaling I would use something like this one: (Posted it at the source code archive recently, similar to voxengo span ) y = floor(exp((16+x*1.20103)*log(1.059))*8.17742); where: x -> 0-100% (N bands to be spitted) y -> result in the 20hz -20khz range //x=0%, y=20hz //x=50%, y=639hz //x=100%, y=20000hz This can be easily tweaked so that the midpoint (audible range) is preserved while the equation is adjusted for a different range. and then an algorithm to decide which upper bands to be oversampled while - linked to N bands. But I have no idea, you may have already completed your design with something better. I was recently suprised to see that in a well know unit (from BBE), uses a quite cheap preudo-state-variable filter circuit (integral) for a "crossover gain" eq. The unit gets generaly possitive market feedback, but still a there are people complaining about top-end sharpness and phase issues. Lubomir I. Ivanov http://www.tu-varna.bg From richarddobson at blueyonder.co.uk Tue May 12 19:20:54 2009 From: richarddobson at blueyonder.co.uk (Richard Dobson) Date: Tue May 12 19:22:31 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: <3C22680E207841989DF0D8A9AC06FBC2@LazzariniPC> References: <23487108.post@talk.nabble.com> <518fe7b20905120845x137058bawec897c0fbcad7839@mail.gmail.com> <23511475.post@talk.nabble.com> <3C22680E207841989DF0D8A9AC06FBC2@LazzariniPC> Message-ID: <4A0A0456.7020500@blueyonder.co.uk> victor wrote: > >> A PC has the major disadvantage that often the DA conversion is far from >> great, like the way samples are handled: uneven timing, lost frames, >> not to >> mention unwanted sample rate conversion and such. Working with a good >> Linux >> and Jack can make most of that ok. > > If you permit me, I beg to differ. > I have been working with audio synthesis on general-purpose computers for > about 16 years (and in realtime for about 10-12). Some of the code I wrote > when I started still works and produces audio. With a modern system, > provided > you are not trying to do something beyond the CPU power, there are no lost > frames (dropouts) and there is good timing. I would not invest time and > effort > on a piece of hardware that will be obsolete next year. It's just not my > thing. > I'm very happy with the quality of what I get out of a PC. > I have replaced my PC twice since the first one I bought (386 CPU with 25MHz clock, added a 387 FPU later; make that thrice if you include the CDP-bought PII machine that I used next), the boxes are still taking up space at home waiting for me to decide what to do with them. My current PC is fast (relatively...) but a mere single Pentium 4, easily outpaced by our dual-core iMac. So PC hardware is just as capable of being obsolete (or just too under-specced for modern ambitions); while classic digital (as well as analog) synths command very respectable prices. The merits of low power consumption (no fans! usually not even any heatsinks) and single-sample latency (which no current or forthcoming PC is likely to achieve) together with turnkey performance (switch on and instantly be playing) are still very widely appreciated. And those who claim to be "in the know" say that the MIDI timing on the Atari has yet to be surpassed by any more modern platform. Running a machine with a 700W power supply just so you can play a softsynth in real time is already starting to seem very un-green these days. PCS and dedicated hardware dsp systems meet different if related needs, and if anything, more and more companies are jumping on the dedicated hardware approach, even if only for acceleration in conjunction with a PC. Richard Dobson From didid at skynet.be Tue May 12 19:50:47 2009 From: didid at skynet.be (Didier Dambrin) Date: Tue May 12 19:51:30 2009 Subject: [music-dsp] Filterbank In-Reply-To: <003801c9d356$baee2ff0$0201a8c0@LuboPC> References: <85CD8187116F4E1CB450B439FF33FE5A@nibln01077><594BA9EFD0744FEAA4EEA26FCAF0EF23@nibln01077> <003801c9d356$baee2ff0$0201a8c0@LuboPC> Message-ID: <4C841691AFF84641BB3EFF76A089AECB@GOLAMD> > But I have no idea, you may have already completed your design with > something better. > Hi, Well I had planned to make a generic filterbank that I'd use for various purposes, but started with a vocoder. But for a vocoder, bands properly overlapping, covering full range, summing to the original signal are really not important at all (& it's even better with large gaps between bands), so right now I have a lot more freedom. But yes for other uses I may just go for bandpasses enlarging on the sides of the spectrum. Someone of this list (Os) recently suggested this link about a filter designing tool btw: http://www-users.cs.york.ac.uk/~fisher/mkfilter/res.html which is talking about resonator bandpasses that may be useful for a filterbank? The tool only gives errors here (it works for other filters), though. ("Command failed (return code 256)", if that matters) >> I'm trying to build a filterbank out of RBJ's bandpasses, it works quite >> well. >> >> My problem: to reconstruct the (44khz, musical) signal properly, I need >> bands from around 15Hz to 40kHz (I oversample bands above 10k btw). But >> that's a big waste of useless bands that I only need to avoid >> deformation/ringing on the reconstructed signal. I'm not interested in >> playing with individual bands under 40Hz & above 16k. >> >> At 1/3oct per band, it results in 8 useless bands out of 35, almost 1/4 >> wasted for the reconstruction. But I can't find any other way. >> >> -I've tried slowly enlarging the lower/higher bands, but it has its >> limits, to keep artefacts inaudible I may just spare a band or 2. > > Hello Didier, > > I think that, from a technical point of view the method of slowly > enlarging > the bandwidth, > based on a accurate log scale and band number would be best. But yes > artefacts may > pop out, which I think can be dealt with. If artefacts are present in > specific ranges (between bands), > maybe separate BP type modes can be designed (different tweaks of the same > filter or as a last option > different filter types) to provide more flexibility - BPtypeA, BPtypeB, > BPtypeC... etc. > Where BPtypeA differs from BPtypeB,C - typeA is more appropriate for high > frequencies for example. > > For log scaling I would use something like this one: > (Posted it at the source code archive recently, similar to voxengo span ) > y = floor(exp((16+x*1.20103)*log(1.059))*8.17742); > where: > x -> 0-100% (N bands to be spitted) > y -> result in the 20hz -20khz range > //x=0%, y=20hz > //x=50%, y=639hz > //x=100%, y=20000hz > This can be easily tweaked so that the midpoint (audible range) is > preserved > while > the equation is adjusted for a different range. > > and then an algorithm to decide which upper bands to be oversampled > while - > linked to N bands. > > But I have no idea, you may have already completed your design with > something better. > > I was recently suprised to see that in a well know unit (from BBE), uses a > quite cheap preudo-state-variable > filter circuit (integral) for a "crossover gain" eq. > The unit gets generaly possitive market feedback, but still a there are > people complaining about top-end > sharpness and phase issues. > > Lubomir I. Ivanov > http://www.tu-varna.bg > From neolit123 at gmail.com Tue May 12 21:30:34 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Tue May 12 21:31:15 2009 Subject: [music-dsp] Filterbank References: <85CD8187116F4E1CB450B439FF33FE5A@nibln01077><594BA9EFD0744FEAA4EEA26FCAF0EF23@nibln01077><003801c9d356$baee2ff0$0201a8c0@LuboPC> <4C841691AFF84641BB3EFF76A089AECB@GOLAMD> Message-ID: <001201c9d36a$6dd8ab00$0201a8c0@LuboPC> the CGI script isn't working correctly there But Tony Fishers's source code for mkfilter can be found here: http://www-users.cs.york.ac.uk/~fisher/software/mkfilter/current/ It should compile with no problems. another online tool for a RLC circuit: http://sim.okawa-denshi.jp/en/RLCbpkeisan.htm Also you can check this PDF document for a quick voltage-division example and a good f / magnitude plot of the BP. http://www.ece.ndsu.nodak.edu/~glower/ECE_Labs/ECE311/Lab10.pdf The RLC has some great flexibuility and advantages. But I think this design may require bit more attention than the standart BP. You can definitevely give it a try though. I've seen some good phase shift / magnitude plots. But just theory... Also you can use the RLC for the "BPTypeA" previos example - as an extra filter type. Lubomir I. Ivanov http://www.tu-varna.bg ----- Original Message ----- From: "Didier Dambrin" To: "A discussion list for music-related DSP" Sent: Wednesday, May 13, 2009 2:50 AM Subject: Re: [music-dsp] Filterbank >> But I have no idea, you may have already completed your design with >> something better. >> > > Hi, > Well I had planned to make a generic filterbank that I'd use for various > purposes, but started with a vocoder. > But for a vocoder, bands properly overlapping, covering full range, > summing to the original signal are really not important at all (& it's > even better with large gaps between bands), so right now I have a lot more > freedom. > But yes for other uses I may just go for bandpasses enlarging on the sides > of the spectrum. > > Someone of this list (Os) recently suggested this link about a filter > designing tool btw: > http://www-users.cs.york.ac.uk/~fisher/mkfilter/res.html > which is talking about resonator bandpasses that may be useful for a > filterbank? The tool only gives errors here (it works for other filters), > though. > ("Command failed (return code 256)", if that matters) > > > >>> I'm trying to build a filterbank out of RBJ's bandpasses, it works quite >>> well. >>> >>> My problem: to reconstruct the (44khz, musical) signal properly, I need >>> bands from around 15Hz to 40kHz (I oversample bands above 10k btw). But >>> that's a big waste of useless bands that I only need to avoid >>> deformation/ringing on the reconstructed signal. I'm not interested in >>> playing with individual bands under 40Hz & above 16k. >>> >>> At 1/3oct per band, it results in 8 useless bands out of 35, almost 1/4 >>> wasted for the reconstruction. But I can't find any other way. >>> >>> -I've tried slowly enlarging the lower/higher bands, but it has its >>> limits, to keep artefacts inaudible I may just spare a band or 2. >> >> Hello Didier, >> >> I think that, from a technical point of view the method of slowly >> enlarging >> the bandwidth, >> based on a accurate log scale and band number would be best. But yes >> artefacts may >> pop out, which I think can be dealt with. If artefacts are present in >> specific ranges (between bands), >> maybe separate BP type modes can be designed (different tweaks of the >> same >> filter or as a last option >> different filter types) to provide more flexibility - BPtypeA, BPtypeB, >> BPtypeC... etc. >> Where BPtypeA differs from BPtypeB,C - typeA is more appropriate for high >> frequencies for example. >> >> For log scaling I would use something like this one: >> (Posted it at the source code archive recently, similar to voxengo span ) >> y = floor(exp((16+x*1.20103)*log(1.059))*8.17742); >> where: >> x -> 0-100% (N bands to be spitted) >> y -> result in the 20hz -20khz range >> //x=0%, y=20hz >> //x=50%, y=639hz >> //x=100%, y=20000hz >> This can be easily tweaked so that the midpoint (audible range) is >> preserved >> while >> the equation is adjusted for a different range. >> >> and then an algorithm to decide which upper bands to be oversampled >> while - >> linked to N bands. >> >> But I have no idea, you may have already completed your design with >> something better. >> >> I was recently suprised to see that in a well know unit (from BBE), uses >> a >> quite cheap preudo-state-variable >> filter circuit (integral) for a "crossover gain" eq. >> The unit gets generaly possitive market feedback, but still a there are >> people complaining about top-end >> sharpness and phase issues. >> >> Lubomir I. Ivanov >> http://www.tu-varna.bg >> > > -- > 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 Wed May 13 04:24:22 2009 From: vesa.norilo at saunalahti.fi (Vesa Norilo) Date: Wed May 13 04:24:42 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: <3C22680E207841989DF0D8A9AC06FBC2@LazzariniPC> References: <23487108.post@talk.nabble.com> <518fe7b20905120845x137058bawec897c0fbcad7839@mail.gmail.com> <23511475.post@talk.nabble.com> <3C22680E207841989DF0D8A9AC06FBC2@LazzariniPC> Message-ID: <4A0A83B6.8070605@saunalahti.fi> > > when I started still works and produces audio. With a modern system, > provided > you are not trying to do something beyond the CPU power, there are no > lost > frames (dropouts) and there is good timing. I would not invest time > and effort > on a piece of hardware that will be obsolete next year. It's just not > my thing. > I'm very happy with the quality of what I get out of a PC. Hi Victor, I beg to re-differ :) With a DSP board you can get a latency far below anything you can dream of on a non-realtime OS. When you take it to a gig, it does not take a minute to boot. There are no drivers or interfaces to worry about. It will not be obsolete, ever, as it will continue to work exactly like it did barring a electrical/mechanical failure. Unlike PC software. Try and see how much fun it is to run 15 year old music software today. PCs have their place. They are great for sound design, hacking and composition and decent enough for mixing. Playing gigs or making records - you have to pry DSP chips from my cold, dead hands :) V From didid at skynet.be Wed May 13 05:20:19 2009 From: didid at skynet.be (Didier Dambrin) Date: Wed May 13 05:20:47 2009 Subject: [music-dsp] Filterbank In-Reply-To: <001201c9d36a$6dd8ab00$0201a8c0@LuboPC> References: <85CD8187116F4E1CB450B439FF33FE5A@nibln01077><594BA9EFD0744FEAA4EEA26FCAF0EF23@nibln01077><003801c9d356$baee2ff0$0201a8c0@LuboPC><4C841691AFF84641BB3EFF76A089AECB@GOLAMD> <001201c9d36a$6dd8ab00$0201a8c0@LuboPC> Message-ID: <84B1E4354CA440E6AB2B29C573E83FBA@GOLAMD> So "RLC" filters, that's what they're called. Thanks. > the CGI script isn't working correctly there > > But Tony Fishers's source code for mkfilter can be found here: > http://www-users.cs.york.ac.uk/~fisher/software/mkfilter/current/ > It should compile with no problems. > > another online tool for a RLC circuit: > http://sim.okawa-denshi.jp/en/RLCbpkeisan.htm > > Also you can check this PDF document for a quick voltage-division example > and a good f / magnitude plot of the BP. > http://www.ece.ndsu.nodak.edu/~glower/ECE_Labs/ECE311/Lab10.pdf > > The RLC has some great flexibuility and advantages. But I think this > design > may require bit more attention than the standart BP. You can definitevely > give it a try though. I've seen some good phase shift / magnitude plots. > But > just theory... > Also you can use the RLC for the "BPTypeA" previos example - as an extra > filter type. > > Lubomir I. Ivanov > http://www.tu-varna.bg > > ----- Original Message ----- > From: "Didier Dambrin" > To: "A discussion list for music-related DSP" > > Sent: Wednesday, May 13, 2009 2:50 AM > Subject: Re: [music-dsp] Filterbank > > >>> But I have no idea, you may have already completed your design with >>> something better. >>> >> >> Hi, >> Well I had planned to make a generic filterbank that I'd use for various >> purposes, but started with a vocoder. >> But for a vocoder, bands properly overlapping, covering full range, >> summing to the original signal are really not important at all (& it's >> even better with large gaps between bands), so right now I have a lot >> more >> freedom. >> But yes for other uses I may just go for bandpasses enlarging on the >> sides >> of the spectrum. >> >> Someone of this list (Os) recently suggested this link about a filter >> designing tool btw: >> http://www-users.cs.york.ac.uk/~fisher/mkfilter/res.html >> which is talking about resonator bandpasses that may be useful for a >> filterbank? The tool only gives errors here (it works for other filters), >> though. >> ("Command failed (return code 256)", if that matters) >> >> >> >>>> I'm trying to build a filterbank out of RBJ's bandpasses, it works >>>> quite >>>> well. >>>> >>>> My problem: to reconstruct the (44khz, musical) signal properly, I need >>>> bands from around 15Hz to 40kHz (I oversample bands above 10k btw). But >>>> that's a big waste of useless bands that I only need to avoid >>>> deformation/ringing on the reconstructed signal. I'm not interested in >>>> playing with individual bands under 40Hz & above 16k. >>>> >>>> At 1/3oct per band, it results in 8 useless bands out of 35, almost 1/4 >>>> wasted for the reconstruction. But I can't find any other way. >>>> >>>> -I've tried slowly enlarging the lower/higher bands, but it has its >>>> limits, to keep artefacts inaudible I may just spare a band or 2. >>> >>> Hello Didier, >>> >>> I think that, from a technical point of view the method of slowly >>> enlarging >>> the bandwidth, >>> based on a accurate log scale and band number would be best. But yes >>> artefacts may >>> pop out, which I think can be dealt with. If artefacts are present in >>> specific ranges (between bands), >>> maybe separate BP type modes can be designed (different tweaks of the >>> same >>> filter or as a last option >>> different filter types) to provide more flexibility - BPtypeA, BPtypeB, >>> BPtypeC... etc. >>> Where BPtypeA differs from BPtypeB,C - typeA is more appropriate for >>> high >>> frequencies for example. >>> >>> For log scaling I would use something like this one: >>> (Posted it at the source code archive recently, similar to voxengo >>> span ) >>> y = floor(exp((16+x*1.20103)*log(1.059))*8.17742); >>> where: >>> x -> 0-100% (N bands to be spitted) >>> y -> result in the 20hz -20khz range >>> //x=0%, y=20hz >>> //x=50%, y=639hz >>> //x=100%, y=20000hz >>> This can be easily tweaked so that the midpoint (audible range) is >>> preserved >>> while >>> the equation is adjusted for a different range. >>> >>> and then an algorithm to decide which upper bands to be oversampled >>> while - >>> linked to N bands. >>> >>> But I have no idea, you may have already completed your design with >>> something better. >>> >>> I was recently suprised to see that in a well know unit (from BBE), uses >>> a >>> quite cheap preudo-state-variable >>> filter circuit (integral) for a "crossover gain" eq. >>> The unit gets generaly possitive market feedback, but still a there are >>> people complaining about top-end >>> sharpness and phase issues. >>> >>> Lubomir I. Ivanov >>> http://www.tu-varna.bg >>> >> >> -- >> 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 -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.325 / Virus Database: 270.12.27/2111 - Release Date: 05/12/09 18:03:00 From radarsat1 at gmail.com Wed May 13 11:01:32 2009 From: radarsat1 at gmail.com (Stephen Sinclair) Date: Wed May 13 11:01:52 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: <4A0A83B6.8070605@saunalahti.fi> References: <23487108.post@talk.nabble.com> <518fe7b20905120845x137058bawec897c0fbcad7839@mail.gmail.com> <23511475.post@talk.nabble.com> <3C22680E207841989DF0D8A9AC06FBC2@LazzariniPC> <4A0A83B6.8070605@saunalahti.fi> Message-ID: <9b3e2dc20905130801o4dbeaebcrb6a2399a8bbb58d7@mail.gmail.com> Just to interject into this conversation, while we're talking about hardware... Can anyone recommend a good, inexpensive (< $200) and physically *small* solution for doing embedded audio? Bonus points for: - analog inputs for reading sensors (or if not, tty / i2c to talk to digital sensors) - compatibility with a GNU or otherwise free C compiler - output audio digitally to plug into digital mixer using something like SPDIF - ethernet for communicating via Open Sound Control The reason is to embed audio synthesis into custom musical instruments. I've thought about trying the gumstix for this, does anyone have experience with it? It looks like it could do it, but it's annoying that it requires different attachments (i.e., more $$$) for almost each feature I want. Also, I think ARM lacks floating-point support which is a bit annoying for audio purposes. Another thought, would an FPGA be an interesting option for this? Why, why not? I think a "perfect" solution would be to add a DSP to an Arduino perhaps, but that would require my own electronics design, which is not my area of expertise. thanks, Steve On Wed, May 13, 2009 at 4:24 AM, Vesa Norilo wrote: > >> >> when I started still works and produces audio. With a modern system, >> provided >> you are not trying to do something beyond the CPU power, there are no lost >> frames (dropouts) and there is good timing. I would not invest time and >> effort >> on a piece of hardware that will be obsolete next year. It's just not my >> thing. >> I'm very happy with the quality of what I get out of a PC. > > Hi Victor, > > I beg to re-differ :) > > With a DSP board you can get a latency far below anything you can dream of > on a non-realtime OS. > > When you take it to a gig, it does not take a minute to boot. > > There are no drivers or interfaces to worry about. > > It will not be obsolete, ever, as it will continue to work exactly like it > did barring a electrical/mechanical failure. Unlike PC software. Try and see > how much fun it is to run 15 year old music software today. > > PCs have their place. They are great for sound design, hacking and > composition and decent enough for mixing. Playing gigs or making records - > you have to pry DSP chips from my cold, dead hands :) > > V > -- > 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 nostromo at arkaos.net Wed May 13 11:20:38 2009 From: nostromo at arkaos.net (M-.-n) Date: Wed May 13 11:20:34 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: <9b3e2dc20905130801o4dbeaebcrb6a2399a8bbb58d7@mail.gmail.com> References: <23487108.post@talk.nabble.com> <518fe7b20905120845x137058bawec897c0fbcad7839@mail.gmail.com> <23511475.post@talk.nabble.com> <3C22680E207841989DF0D8A9AC06FBC2@LazzariniPC> <4A0A83B6.8070605@saunalahti.fi> <9b3e2dc20905130801o4dbeaebcrb6a2399a8bbb58d7@mail.gmail.com> Message-ID: <4A0AE546.3030503@arkaos.net> I'd be interested to know too. So far I've been playing with the arduino piano and although the horse power is fairely limited, I had a blast using it. If you are ok with looking at unix/windows platform possibilities (with the aforementioned possible problems related to OS's), the eee pc 701 is pretty cheap (around 150 USD/EUR) and has pretty much all of that. I've done a custom digital MS-20 by stripping an eeepc running the ms-20 vst plugin from his lcd and stuffing it into the legacy edition controller and it's all running smooth and nice. See: http://nostromo.noisepages.com/2009/05/03/dms-20-first-assembly/ Pure:dyne is a real-time unix kernel and it seems to run very smoothly too (although I'm not really trying to develop for it at the moment). Sure it's not tons of power either but it's really easy to implement. So, depending on your goal, it might be worthwile looking at. Also I've never found fixed point on ARMS to be a real issue, but I'm that kind of gritty guy :) Hope this helps, Marc. Stephen Sinclair a ?crit : > Just to interject into this conversation, while we're talking about hardware... > > Can anyone recommend a good, inexpensive (< $200) and physically > *small* solution for doing embedded audio? Bonus points for: > > - analog inputs for reading sensors > (or if not, tty / i2c to talk to digital sensors) > > - compatibility with a GNU or otherwise free C compiler > > - output audio digitally to plug into digital mixer using something like SPDIF > > - ethernet for communicating via Open Sound Control > > The reason is to embed audio synthesis into custom musical instruments. > > I've thought about trying the gumstix for this, does anyone have > experience with it? It looks like it could do it, but it's annoying > that it requires different attachments (i.e., more $$$) for almost > each feature I want. Also, I think ARM lacks floating-point support > which is a bit annoying for audio purposes. > > Another thought, would an FPGA be an interesting option for this? Why, why not? > I think a "perfect" solution would be to add a DSP to an Arduino > perhaps, but that would require my own electronics design, which is > not my area of expertise. > From radarsat1 at gmail.com Wed May 13 11:27:36 2009 From: radarsat1 at gmail.com (Stephen Sinclair) Date: Wed May 13 11:27:50 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: <4A0AE546.3030503@arkaos.net> References: <23487108.post@talk.nabble.com> <518fe7b20905120845x137058bawec897c0fbcad7839@mail.gmail.com> <23511475.post@talk.nabble.com> <3C22680E207841989DF0D8A9AC06FBC2@LazzariniPC> <4A0A83B6.8070605@saunalahti.fi> <9b3e2dc20905130801o4dbeaebcrb6a2399a8bbb58d7@mail.gmail.com> <4A0AE546.3030503@arkaos.net> Message-ID: <9b3e2dc20905130827q2381b38n6f2acf391d2416d1@mail.gmail.com> *Very* cool project, thanks for sharing that!! Steve On Wed, May 13, 2009 at 11:20 AM, M-.-n wrote: > I'd be interested to know too. > > So far I've been playing with the arduino piano and although the horse power > is fairely limited, I had a blast using it. > > If you are ok with looking at unix/windows platform possibilities (with the > aforementioned possible problems related to OS's), the eee pc 701 is pretty > cheap (around 150 USD/EUR) and has pretty much all of that. > > I've done a custom digital MS-20 by stripping an eeepc running the ms-20 vst > plugin from his lcd and stuffing it into the legacy edition controller and > it's all running smooth and nice. > > See: > > http://nostromo.noisepages.com/2009/05/03/dms-20-first-assembly/ > > Pure:dyne is a real-time unix kernel and it seems to run very smoothly too > (although I'm not really trying to develop for it at the moment). > > Sure it's not tons of power either but it's really easy to implement. So, > depending on your goal, it might be worthwile looking at. > > Also I've never found fixed point on ARMS to be a real issue, but I'm that > kind of gritty guy :) > > Hope this helps, > Marc. > > Stephen Sinclair a ?crit : >> >> Just to interject into this conversation, while we're talking about >> hardware... >> >> Can anyone recommend a good, inexpensive (< $200) and physically >> *small* solution for doing embedded audio? ?Bonus points for: >> >> - analog inputs for reading sensors >> ?(or if not, tty / i2c to talk to digital sensors) >> >> - compatibility with a GNU or otherwise free C compiler >> >> - output audio digitally to plug into digital mixer using something like >> SPDIF >> >> - ethernet for communicating via Open Sound Control >> >> The reason is to embed audio synthesis into custom musical instruments. >> >> I've thought about trying the gumstix for this, does anyone have >> experience with it? ?It looks like it could do it, but it's annoying >> that it requires different attachments (i.e., more $$$) for almost >> each feature I want. ?Also, I think ARM lacks floating-point support >> which is a bit annoying for audio purposes. >> >> Another thought, would an FPGA be an interesting option for this? ?Why, >> why not? >> I think a "perfect" solution would be to add a DSP to an Arduino >> perhaps, but that would require my own electronics design, which is >> not my area of expertise. >> > > -- > 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 Wed May 13 11:28:06 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Wed May 13 11:28:27 2009 Subject: [music-dsp] Filterbank Message-ID: <20090513152806.6FCEA10ABB8@ws6-4.us4.outblaze.com> > ----- Original Message ----- > From: "Didier Dambrin" > To: "A discussion list for music-related DSP" > Subject: Re: [music-dsp] Filterbank > Date: Wed, 13 May 2009 11:20:19 +0200 > > > So "RLC" filters, that's what they're called. i guess, if you're making the filters outa resistors, inductors, and capacitors. otherwise, i would call it a "2nd-order bandpass" (or "lowpass" or "highpass" or "notch") or "biquad bandpass" filter. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From ebrombaugh1 at cox.net Wed May 13 11:28:40 2009 From: ebrombaugh1 at cox.net (Eric Brombaugh) Date: Wed May 13 11:29:27 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: <9b3e2dc20905130801o4dbeaebcrb6a2399a8bbb58d7@mail.gmail.com> References: <23487108.post@talk.nabble.com> <518fe7b20905120845x137058bawec897c0fbcad7839@mail.gmail.com> <23511475.post@talk.nabble.com> <3C22680E207841989DF0D8A9AC06FBC2@LazzariniPC> <4A0A83B6.8070605@saunalahti.fi> <9b3e2dc20905130801o4dbeaebcrb6a2399a8bbb58d7@mail.gmail.com> Message-ID: <4A0AE728.3000007@cox.net> Stephen Sinclair wrote: > Another thought, would an FPGA be an interesting option for this? Why, why not? > I think a "perfect" solution would be to add a DSP to an Arduino > perhaps, but that would require my own electronics design, which is > not my area of expertise. I've been fooling around with an ARM & FPGA synthesis project for a few months now: http://members.cox.net/ebrombaugh1/synth/armfpga/index.html The general idea is to marry a low to mid-range FPGA to a reasonably powerful embedded processor with plenty of I/O. The ARM processor provides USB, SD, MIDI and user-interface functions, while the FPGA implements the synthesis algorithms. I've only begun to explore the possibilities with this - a simple MIDI monosynth which only uses less than 20% of the FPGA resources. While I've chosen an ARM with lots of up-to-date I/O resources for this, I'd venture that an Arduino would probably work just fine if you don't need USB, etc. So yes, an FPGA is a pretty good platform for doing synthesis. I know there are others lurking on this list who have taken this further than I have and are using FPGAs for some complex and esoteric synthesis techniques. Eric From nostromo at arkaos.net Wed May 13 11:31:14 2009 From: nostromo at arkaos.net (M-.-n) Date: Wed May 13 11:31:17 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: <9b3e2dc20905130827q2381b38n6f2acf391d2416d1@mail.gmail.com> References: <23487108.post@talk.nabble.com> <518fe7b20905120845x137058bawec897c0fbcad7839@mail.gmail.com> <23511475.post@talk.nabble.com> <3C22680E207841989DF0D8A9AC06FBC2@LazzariniPC> <4A0A83B6.8070605@saunalahti.fi> <9b3e2dc20905130801o4dbeaebcrb6a2399a8bbb58d7@mail.gmail.com> <4A0AE546.3030503@arkaos.net> <9b3e2dc20905130827q2381b38n6f2acf391d2416d1@mail.gmail.com> Message-ID: <4A0AE7C2.3080503@arkaos.net> Thanks. It's more of a "refurbushing" project than any kind of wizardry I could be really proud of... but the result is cool to use indeed. Now I should settle my sight on doing my own 'twisted' version of ms-20 architecture using custom made filters and oscillators and run it on the same platform... now that would be awesome :) Stephen Sinclair a ?crit : > *Very* cool project, thanks for sharing that!! > > Steve > > > On Wed, May 13, 2009 at 11:20 AM, M-.-n wrote: > >> I'd be interested to know too. >> >> So far I've been playing with the arduino piano and although the horse power >> is fairely limited, I had a blast using it. >> >> If you are ok with looking at unix/windows platform possibilities (with the >> aforementioned possible problems related to OS's), the eee pc 701 is pretty >> cheap (around 150 USD/EUR) and has pretty much all of that. >> >> I've done a custom digital MS-20 by stripping an eeepc running the ms-20 vst >> plugin from his lcd and stuffing it into the legacy edition controller and >> it's all running smooth and nice. >> >> See: >> >> http://nostromo.noisepages.com/2009/05/03/dms-20-first-assembly/ >> >> Pure:dyne is a real-time unix kernel and it seems to run very smoothly too >> (although I'm not really trying to develop for it at the moment). >> >> Sure it's not tons of power either but it's really easy to implement. So, >> depending on your goal, it might be worthwile looking at. >> >> Also I've never found fixed point on ARMS to be a real issue, but I'm that >> kind of gritty guy :) >> >> Hope this helps, >> Marc. >> >> Stephen Sinclair a ?crit : >> >>> Just to interject into this conversation, while we're talking about >>> hardware... >>> >>> Can anyone recommend a good, inexpensive (< $200) and physically >>> *small* solution for doing embedded audio? Bonus points for: >>> >>> - analog inputs for reading sensors >>> (or if not, tty / i2c to talk to digital sensors) >>> >>> - compatibility with a GNU or otherwise free C compiler >>> >>> - output audio digitally to plug into digital mixer using something like >>> SPDIF >>> >>> - ethernet for communicating via Open Sound Control >>> >>> The reason is to embed audio synthesis into custom musical instruments. >>> >>> I've thought about trying the gumstix for this, does anyone have >>> experience with it? It looks like it could do it, but it's annoying >>> that it requires different attachments (i.e., more $$$) for almost >>> each feature I want. Also, I think ARM lacks floating-point support >>> which is a bit annoying for audio purposes. >>> >>> Another thought, would an FPGA be an interesting option for this? Why, >>> why not? >>> I think a "perfect" solution would be to add a DSP to an Arduino >>> perhaps, but that would require my own electronics design, which is >>> not my area of expertise. >>> >>> >> -- >> 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 rbj at audioimagination.com Wed May 13 11:34:19 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Wed May 13 11:34:38 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth Message-ID: <20090513153419.A507510ABA5@ws6-4.us4.outblaze.com> > ----- Original Message ----- > From: "Vesa Norilo" > To: "A discussion list for music-related DSP" > Subject: Re: [music-dsp] Open Source DSP Analog Simulation Synth > Date: Wed, 13 May 2009 11:24:22 +0300 > > > > > > > when I started still works and produces audio. With a modern system, provided > > you are not trying to do something beyond the CPU power, there are no lost > > frames (dropouts) and there is good timing. I would not invest time and > > effort on a piece of hardware that will be obsolete next year. It's just not > > my thing. > > I'm very happy with the quality of what I get out of a PC. > > I beg to re-differ :) > > With a DSP board you can get a latency far below anything you can dream of on > a non-realtime OS. > > When you take it to a gig, it does not take a minute to boot. a minute??!! i wish!! with AVG or whatever anti-virus is happening, it takes *multiple* minutes for my XP to transition from pushing the power button to being able to do anything with it. and i can't figure out how to clean it up, it's not like i can just disable some "Startup Items" like in the mac. it's unbelievable the giant steps backward that PC (and even the mac) are taking since the 90s. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From bastian.schnuerle at silberstein.de Wed May 13 11:41:06 2009 From: bastian.schnuerle at silberstein.de (bastian.schnuerle) Date: Wed May 13 11:41:22 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: <20090513153419.A507510ABA5@ws6-4.us4.outblaze.com> References: <20090513153419.A507510ABA5@ws6-4.us4.outblaze.com> Message-ID: you can disable "startup items", by open "start/Run.." and then write "msconfig" on xp systems .. then there is a tab, that lets you select startup items and the so called windows services .. bazt Am 13.05.2009 um 17:34 schrieb robert bristow-johnson: > >> ----- Original Message ----- >> From: "Vesa Norilo" >> To: "A discussion list for music-related DSP" > dsp@music.columbia.edu> >> Subject: Re: [music-dsp] Open Source DSP Analog Simulation Synth >> Date: Wed, 13 May 2009 11:24:22 +0300 >> >> >> >>> >>> when I started still works and produces audio. With a modern >>> system, provided >>> you are not trying to do something beyond the CPU power, there >>> are no lost >>> frames (dropouts) and there is good timing. I would not invest >>> time and >>> effort on a piece of hardware that will be obsolete next year. >>> It's just not >>> my thing. >>> I'm very happy with the quality of what I get out of a PC. >> >> I beg to re-differ :) >> >> With a DSP board you can get a latency far below anything you can >> dream of on >> a non-realtime OS. >> >> When you take it to a gig, it does not take a minute to boot. > > a minute??!! i wish!! with AVG or whatever anti-virus is > happening, it takes *multiple* minutes for my XP to transition from > pushing the power button to being able to do anything with it. and > i can't figure out how to clean it up, it's not like i can just > disable some "Startup Items" like in the mac. > > it's unbelievable the giant steps backward that PC (and even the > mac) are taking since the 90s. > > -- > > 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 rbj at audioimagination.com Wed May 13 11:45:36 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Wed May 13 11:45:59 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth Message-ID: <20090513154536.E3D8454D79B@ws6-9.us4.outblaze.com> > ----- Original Message ----- > From: "Eric Brombaugh" > To: "A discussion list for music-related DSP" > Subject: Re: [music-dsp] Open Source DSP Analog Simulation Synth > Date: Wed, 13 May 2009 08:28:40 -0700 > > > Stephen Sinclair wrote: > > Another thought, would an FPGA be an interesting option for this? Why, why > > not? > > I think a "perfect" solution would be to add a DSP to an Arduino > > perhaps, but that would require my own electronics design, which is > > not my area of expertise. > > I've been fooling around with an ARM & FPGA synthesis project for a few > months now: > > http://members.cox.net/ebrombaugh1/synth/armfpga/index.html > > The general idea is to marry a low to mid-range FPGA to a reasonably powerful > embedded processor with plenty of I/O. The ARM processor provides USB, SD, > MIDI and user-interface functions, while the FPGA implements the synthesis > algorithms. I've only begun to explore the possibilities with this - a simple > MIDI monosynth which only uses less than 20% of the FPGA resources. but what if you want dozens of voices simultaneously? > While I've chosen an ARM with lots of up-to-date I/O resources for this, I'd > venture that an Arduino would probably work just fine if you don't need USB, > etc. > > So yes, an FPGA is a pretty good platform for doing synthesis. I know there > are others lurking on this list who have taken this further than I have and > are using FPGAs for some complex and esoteric synthesis techniques. i know of at least one company that had been exploring this for multi-voice sample playback (the FPGA is doing all of the sinc-like interpolation effort). then they're gonna couple the sample-playback output into their existing chips for processing and effects which is really dumb. they had (and it isn't me) one insightful engineer who suggested also doing whatever necessary processing on individual voices on the same FPGA, but they didn't listen to him either. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From didid at skynet.be Wed May 13 11:51:33 2009 From: didid at skynet.be (Didier Dambrin) Date: Wed May 13 11:51:58 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: <20090513153419.A507510ABA5@ws6-4.us4.outblaze.com> References: <20090513153419.A507510ABA5@ws6-4.us4.outblaze.com> Message-ID: But to be honnest, why would you stick an antivirus in a PC dedicated to 1 single task, being a synth? There are surely OSes that will boot as instantly as you'd need, and they would still end up more versatile than something custom. > > > > when I started still works and produces audio. With a modern system, > > provided > > you are not trying to do something beyond the CPU power, there are no > > lost > > frames (dropouts) and there is good timing. I would not invest time and > > effort on a piece of hardware that will be obsolete next year. It's just > > not > > my thing. > > I'm very happy with the quality of what I get out of a PC. > > I beg to re-differ :) > > With a DSP board you can get a latency far below anything you can dream of > on > a non-realtime OS. > > When you take it to a gig, it does not take a minute to boot. a minute??!! i wish!! with AVG or whatever anti-virus is happening, it takes *multiple* minutes for my XP to transition from pushing the power button to being able to do anything with it. and i can't figure out how to clean it up, it's not like i can just disable some "Startup Items" like in the mac. it's unbelievable the giant steps backward that PC (and even the mac) are taking since the 90s. -- 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 -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.329 / Virus Database: 270.12.27/2111 - Release Date: 05/12/09 18:03:00 From vesa.norilo at saunalahti.fi Wed May 13 12:06:37 2009 From: vesa.norilo at saunalahti.fi (Vesa Norilo) Date: Wed May 13 12:06:51 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: References: <20090513153419.A507510ABA5@ws6-4.us4.outblaze.com> Message-ID: <4A0AF00D.20706@saunalahti.fi> > > There are surely OSes that will boot as instantly as you'd need, and > they would still end up more versatile than something custom. Versatile how? Like having more points of failure? Believe me, I like computer based music dsp coding as much as the next guy. I do it every day. I appreciate the software ecosystem, the boundless interfacing possibilities and the OS services. I also appreciate that a custom DSP solution can be more streamlined, more reliable, more optimal and more *fun*. It is not difficult, just different from host based work. Once one stops trying to use a hammer whenever one needs a tool, some suprising avenues may open up. It is much like the arguing over which programming language is the best. The design pattern is in your head, not in the software or hardware you are using. I can think of hundreds of things that are much easier to do on a DSP board using assembler than in pure data. Or cocoa. Or .net. Or whatever. I'll shut up now, enjoy your hacking, everyone :) Vesa From ebrombaugh1 at cox.net Wed May 13 12:06:55 2009 From: ebrombaugh1 at cox.net (Eric Brombaugh) Date: Wed May 13 12:07:20 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: <20090513154536.E3D8454D79B@ws6-9.us4.outblaze.com> References: <20090513154536.E3D8454D79B@ws6-9.us4.outblaze.com> Message-ID: <4A0AF01F.7060207@cox.net> robert bristow-johnson wrote: >> The general idea is to marry a low to mid-range FPGA to a reasonably powerful >> embedded processor with plenty of I/O. The ARM processor provides USB, SD, >> MIDI and user-interface functions, while the FPGA implements the synthesis >> algorithms. I've only begun to explore the possibilities with this - a simple >> MIDI monosynth which only uses less than 20% of the FPGA resources. > > but what if you want dozens of voices simultaneously? The present design is just a step along the way. For polyphony I'll be extending the FPGA logic to handle many simultaneous voices - I'm estimating that I can get several hundred oscillators running at once. The hardware can support a variety of synthesis techniques simply by loading different FPGA bitstreams from the SD card memory. > i know of at least one company that had been exploring this for multi-voice sample playback (the FPGA is doing all of the sinc-like interpolation effort). then they're gonna couple the sample-playback output into their existing chips for processing and effects which is really dumb. they had (and it isn't me) one insightful engineer who suggested also doing whatever necessary processing on individual voices on the same FPGA, but they didn't listen to him either. Just using the FPGA for sinc interpolation seems short sighted, but I imagine they're thinking along the lines of "we've already got the hardware/software synthesis problem nailed with our existing solution". Not very forward-looking, but probably cheaper and quicker to market. Eric From czhenry at gmail.com Wed May 13 13:29:38 2009 From: czhenry at gmail.com (Charles Henry) Date: Wed May 13 13:29:51 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: <23512139.post@talk.nabble.com> References: <23487108.post@talk.nabble.com> <518fe7b20905120845x137058bawec897c0fbcad7839@mail.gmail.com> <23511475.post@talk.nabble.com> <3C22680E207841989DF0D8A9AC06FBC2@LazzariniPC> <23512139.post@talk.nabble.com> Message-ID: <518fe7b20905131029k4f43c38ep4d436d9c3778771c@mail.gmail.com> On Tue, May 12, 2009 at 5:55 PM, theover wrote: > Long live a Open Source PCI-Express FPGA board with possibly some good DSP > on it, too, but that isn't around, yet. Personally, I would really like a platform that *just* handles buffers of samples through PCI-X. I'm aware there are some chips & FPGA implementations for it, but it's a little remote to me still. A project that I could really get behind (i.e. work on) would be an open sound card. Needs: a set of hardware buffers, a PCI (optional PCI-X) bridge, and a set of samplers (ideally in a breakout box). Software side, there has to be a kernel module written, and needs to be flexible enough to cover an arbitrary number of channels. From radarsat1 at gmail.com Wed May 13 14:27:07 2009 From: radarsat1 at gmail.com (Stephen Sinclair) Date: Wed May 13 14:27:16 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: <518fe7b20905131029k4f43c38ep4d436d9c3778771c@mail.gmail.com> References: <23487108.post@talk.nabble.com> <518fe7b20905120845x137058bawec897c0fbcad7839@mail.gmail.com> <23511475.post@talk.nabble.com> <3C22680E207841989DF0D8A9AC06FBC2@LazzariniPC> <23512139.post@talk.nabble.com> <518fe7b20905131029k4f43c38ep4d436d9c3778771c@mail.gmail.com> Message-ID: <9b3e2dc20905131127q24706859s31e9c45121078192@mail.gmail.com> On Wed, May 13, 2009 at 1:29 PM, Charles Henry wrote: > On Tue, May 12, 2009 at 5:55 PM, theover wrote: >> Long live a Open Source PCI-Express FPGA board with possibly some good DSP >> on it, too, but that isn't around, yet. > > Personally, I would really like a platform that *just* handles buffers > of samples through PCI-X. ?I'm aware there are some chips & FPGA > implementations for it, but it's a little remote to me still. > Actually, considering how useful it could be for parallel processing, physics simulation, cryptography, video decoding, etc., I've often wondered why a simple FPGA is not included by now as a standard component on any motherboard. Steve From theover at tiscali.nl Wed May 13 14:28:47 2009 From: theover at tiscali.nl (theover) Date: Wed May 13 14:29:04 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: <4A0AF01F.7060207@cox.net> References: <23487108.post@talk.nabble.com> <20090513154536.E3D8454D79B@ws6-9.us4.outblaze.com> <4A0AF01F.7060207@cox.net> Message-ID: <23526923.post@talk.nabble.com> Eric Brombaugh-2 wrote: > > robert bristow-johnson wrote: > >>> The general idea is to marry a low to mid-range FPGA to a reasonably >>> powerful >>> ......IDI monosynth which only uses less than 20% of the FPGA resources. >> >> but what if you want dozens of voices simultaneously? > > The present design is just a step along the way. For polyphony I'll be > extending the FPGA logic to handle many simultaneous voices - I'm > estimating that I can get several hundred oscillators running at once. > ... >> i know of at least one company that had been exploring this for >> multi-voice sample playback (the FPGA is doing all of the sinc-like >> interpolation effort). then they're gonna couple the sample-playback >> output into their existing chips for processing and effects which is >> really dumb. they had (and it isn't me) one insightful engineer who >> suggested also doing whatever necessary processing on individual voices >> on the same FPGA, but they didn't listen to him either. > > Just using the FPGA for sinc interpolation seems short sighted, but I > imagine they're thinking along the lines of "we've already got the > hardware/software synthesis problem nailed with our existing solution". > Not very forward-looking, but probably cheaper and quicker to market. > > Eric > -- > Open source is of course not the same dreamboat as commercial enterprise, but fundamental issues are for instance: what will voices do like sampling wise, delay-wise, accuracy-wise and how and how accurate and fast can they be controlled. Analog synths of 5 decades ago can easily be better at many of these issues than a nifty new fpga or dsp design when no care is taken. Also, many sounds based on samples are based on assumptions about the playboack equipment being used, and uses transforms which are seldom a bijection (i.e. impossible to invert by external processing to the original, intended sound). An important issue IMO is bandwidth limited oscillators (after my above synth design and prototype had received some attention but little feedback I was glad to read the latest kurzweils had ' bandwidth limited generators' even while of course I knew that is normal. A saw or triangle oscillator for a ' normal ' synth design which is well frequency band limited as to prevent aliasing, not even counting the spectrum of the multiplied ADSR or (theoretically) unlimited FM (bessel) spectrum of a swept filter resonance, can take more than a little work, and most commonly used interpolations are really very far from the sonic quality I like to monitor, granted on a extensive monitoring system, but many modern sounds sound alike and annoying also on a good notebook amplification, for instance, and all that seems most of the time to be taken for granted. That's among the reasons many not so much adding designs of musical synthesizers remain decades and many quality levels behind lets say a cheap enough second hand motif or so, with 64 or more voices. Regards, Theo -- View this message in context: http://www.nabble.com/Open-Source-DSP-Analog-Simulation-Synth-tp23487108p23526923.html Sent from the Music-DSP mailing list archive at Nabble.com. From theover at tiscali.nl Wed May 13 14:33:50 2009 From: theover at tiscali.nl (theover) Date: Wed May 13 14:34:00 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: <518fe7b20905131029k4f43c38ep4d436d9c3778771c@mail.gmail.com> References: <23487108.post@talk.nabble.com> <518fe7b20905120845x137058bawec897c0fbcad7839@mail.gmail.com> <23511475.post@talk.nabble.com> <3C22680E207841989DF0D8A9AC06FBC2@LazzariniPC> <23512139.post@talk.nabble.com> <518fe7b20905131029k4f43c38ep4d436d9c3778771c@mail.gmail.com> Message-ID: <23527073.post@talk.nabble.com> Charles Henry wrote: > > On Tue, May 12, 2009 at 5:55 PM, theover wrote: >> Long live a Open Source PCI-Express FPGA board with possibly some good >> DSP >> on it, too, but that isn't around, yet. > > Personally, I would really like a platform that *just* handles buffers > of samples through PCI-X. I'm aware there are some chips & FPGA > implementations for it, but it's a little remote to me still. > ... > Right, but preferable I'd want a good, guaranteed low latency link between the board and a strong computer, that's very important to break through the real time and interactive music barrier, maybe things turn in to muddy nonsense when everything is non-interacting, I observe. And also: what would a soundcard do, compared with software processing, like I was recently trying out freeverb3, an Open Source impulse based reverb and the Stanford STK software for (in my case) Physical Modeling based sounds, and then I think quite a heavy design is in place to complement the sort of bandwidth and SSE2 based processing going on, so a good FPGA, possibly with built in or external DSP would be cool, and not a redone soundblaster design, right? Greetings, Theo -- View this message in context: http://www.nabble.com/Open-Source-DSP-Analog-Simulation-Synth-tp23487108p23527073.html Sent from the Music-DSP mailing list archive at Nabble.com. From hybridalienrob at hotmail.com Wed May 13 14:59:10 2009 From: hybridalienrob at hotmail.com (Rob Belcham) Date: Wed May 13 14:59:34 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: <9b3e2dc20905130801o4dbeaebcrb6a2399a8bbb58d7@mail.gmail.com> References: <23487108.post@talk.nabble.com><518fe7b20905120845x137058bawec897c0fbcad7839@mail.gmail.com><23511475.post@talk.nabble.com><3C22680E207841989DF0D8A9AC06FBC2@LazzariniPC><4A0A83B6.8070605@saunalahti.fi> <9b3e2dc20905130801o4dbeaebcrb6a2399a8bbb58d7@mail.gmail.com> Message-ID: The blackfin 'Stamp' board is pretty pokey and has a good feature set, although no audio i/o. I think there are daughter boards you can get to expand it. There's a version of uCLinux (i.e open source tools & drivers) available for it and a pretty good blackfin community forum at www.blackfin.org. Digikey are selling them for $215. The blackfin is no good if you want to do floating point ops, but it's fine for integer / fractional 32 bit maths. http://www.analog.com/en/embedded-processing-dsp/blackfin/BF537-STAMP/processors/product.html In addition to the HW vs PC argument, i'd like to say there's no substitute for a 'real' synth with real knobs & buttons. i've yet to hear a va soft synth that's made me think i could ever conceive selling my Virus. Mac vs PC anyone ?) Rob -------------------------------------------------- From: "Stephen Sinclair" Sent: Wednesday, May 13, 2009 4:01 PM To: "A discussion list for music-related DSP" Subject: Re: [music-dsp] Open Source DSP Analog Simulation Synth > Just to interject into this conversation, while we're talking about > hardware... > > Can anyone recommend a good, inexpensive (< $200) and physically > *small* solution for doing embedded audio? Bonus points for: > > - analog inputs for reading sensors > (or if not, tty / i2c to talk to digital sensors) > > - compatibility with a GNU or otherwise free C compiler > > - output audio digitally to plug into digital mixer using something like > SPDIF > > - ethernet for communicating via Open Sound Control > > The reason is to embed audio synthesis into custom musical instruments. > > I've thought about trying the gumstix for this, does anyone have > experience with it? It looks like it could do it, but it's annoying > that it requires different attachments (i.e., more $$$) for almost > each feature I want. Also, I think ARM lacks floating-point support > which is a bit annoying for audio purposes. > > Another thought, would an FPGA be an interesting option for this? Why, > why not? > I think a "perfect" solution would be to add a DSP to an Arduino > perhaps, but that would require my own electronics design, which is > not my area of expertise. > > thanks, > > Steve > > > On Wed, May 13, 2009 at 4:24 AM, Vesa Norilo > wrote: >> >>> >>> when I started still works and produces audio. With a modern system, >>> provided >>> you are not trying to do something beyond the CPU power, there are no >>> lost >>> frames (dropouts) and there is good timing. I would not invest time and >>> effort >>> on a piece of hardware that will be obsolete next year. It's just not my >>> thing. >>> I'm very happy with the quality of what I get out of a PC. >> >> Hi Victor, >> >> I beg to re-differ :) >> >> With a DSP board you can get a latency far below anything you can dream >> of >> on a non-realtime OS. >> >> When you take it to a gig, it does not take a minute to boot. >> >> There are no drivers or interfaces to worry about. >> >> It will not be obsolete, ever, as it will continue to work exactly like >> it >> did barring a electrical/mechanical failure. Unlike PC software. Try and >> see >> how much fun it is to run 15 year old music software today. >> >> PCs have their place. They are great for sound design, hacking and >> composition and decent enough for mixing. Playing gigs or making >> records - >> you have to pry DSP chips from my cold, dead hands :) >> >> V >> -- >> 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 hybridalienrob at hotmail.com Wed May 13 15:05:50 2009 From: hybridalienrob at hotmail.com (Rob Belcham) Date: Wed May 13 15:06:11 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: References: <20090513153419.A507510ABA5@ws6-4.us4.outblaze.com> Message-ID: >> a minute??!! i wish!! with AVG or whatever anti-virus is happening, it >> takes *multiple* minutes for my XP to transition from That's just AVG. Used to drive me mad that on XP - it would constantly insist on updating itself on startup & seem to lock up the whole PC until it'd finished. In the end i upgraded to the latest free version & it's not quite so bad now. Rob From ebrombaugh1 at cox.net Wed May 13 15:23:57 2009 From: ebrombaugh1 at cox.net (Eric Brombaugh) Date: Wed May 13 15:24:21 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: References: <23487108.post@talk.nabble.com><518fe7b20905120845x137058bawec897c0fbcad7839@mail.gmail.com><23511475.post@talk.nabble.com><3C22680E207841989DF0D8A9AC06FBC2@LazzariniPC><4A0A83B6.8070605@saunalahti.fi> <9b3e2dc20905130801o4dbeaebcrb6a2399a8bbb58d7@mail.gmail.com> Message-ID: <4A0B1E4D.1060900@cox.net> Rob Belcham wrote: > The blackfin 'Stamp' board is pretty pokey and has a good feature set, > although no audio i/o. I think there are daughter boards you can get to > expand it. There's a version of uCLinux (i.e open source tools & > drivers) available for it and a pretty good blackfin community forum at > www.blackfin.org. Digikey are selling them for $215. The blackfin is no > good if you want to do floating point ops, but it's fine for integer / > fractional 32 bit maths. One platform I've been looking at seriously is the TI BeagleBoard. For $149 from Digi-Key you get an OMAP SoC (600MHz ARM processor, DSP co-processor, 3D graphics accelerator), 256MB DRAM, 256MB NAND Flash, DVI-D, raw LCD & S-Video output, two USB2.0 ports, SD Flash and stereo audio I/O. There are several flavors of full Linux running on this hardware today and heavy development underway to integrate the extra OMAP features. All software development can be done with open-source or free tools (the C compiler for the on-chip DSP is closed source but freely available and runs under x86 Linux) and it's even possible to do native development on the Beagle itself. Audio software from the OS community (ALSA, JACK, LADSPA, etc) is reputed to port without too much difficulty and a standardized DSP interface framework is also working. There's a 28-pin expansion connector with UART, SPI, I2C & GPIO that's accessible through the Linux kernel. Several hardware developers out there are already building daughter cards for it which allow DIY development. This could be the heart of a powerful soft-synth based entirely on open-source software. With suitable tuning it can boot to a useable state from SD flash in just a few seconds and be running powerful multiprocessing soft synths. Add some UI hardware (knobs, buttons, displays) via the expansion connector and it could be usable in live situations as well. Eric From jerry at novadsp.com Wed May 13 15:58:16 2009 From: jerry at novadsp.com (Jerry Evans) Date: Wed May 13 15:59:24 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: <23527073.post@talk.nabble.com> References: <23487108.post@talk.nabble.com> <518fe7b20905120845x137058bawec897c0fbcad7839@mail.gmail.com> <23511475.post@talk.nabble.com> <3C22680E207841989DF0D8A9AC06FBC2@LazzariniPC> <23512139.post@talk.nabble.com> <518fe7b20905131029k4f43c38ep4d436d9c3778771c@mail.gmail.com> <23527073.post@talk.nabble.com> Message-ID: <4A0B2658.1030202@NovaDSP.com> Greets. Having built comparable hardware I am utterly convinced that it is absolutely the wrong approach. You get murdered on productivity. price, and performance. We built a 24 bit 6 in 2 out processing engine with a TI DSP core and a USB 2 link to a PC. To keep the costs at rock bottom we (ahem) piggy-backed the IO onto a TI eval board. Nonetheless the hardware was still 100's of dollars as custom PCB etc absolutely critical for getting chips to work at all, let alone with decent noise performance etc. IIRC the one-off cost was > than a top spec PC of the era (single core P4 I'd guess). This cheery dismissal describes none of the agony of writing embedded C code for the TI core that had to be downloaded, flashed, debugged etc etc over a USB 2 bus that itself had to be programmed, debugged etc etc. After about 9 months the system would play nice with an Apple laptop but the multi-channel USB audio was never recognised by Windows boxes. Hardware? Aptly named. Even something 'simple' like replacing a chip became fantastically difficult. You are dealing with 200 pin packages which have to be soldered into place, with sub-millimeter intra-pin spacing. They are simply not made for human handling - robots do it all on a flow soldering line. Overheat the chip with your $300 tempco Weller, or short 2 pins, or lift a PCB track and it is back to square one. 2 days of regression testing leaves you no choice but to infer the 30us timing slew on some obscure pin is out of spec and implies a hardware fault. At the outset you could just about compare the raw power of the TI series with a single core PIII with SSE2, even then it was heading for apples and oranges territory . By the time the h/w was tottering into life the whole world had changed and you had multi-core SSE3 systems and double the RAM for *less* than the previous generation of processor. Today a quad core PC with 8GB of RAM is less than the price of said soldering iron. Plug in a sensible quality PCI soundboard (or 4) and you've got all the horsepower and flexibility you could ever want, at budget prices, with a reasonable and verifiable expectation of functionality. The problem with using a PC for 'real-time' audio is not the hardware - it is because we generally insist on loading up a gigantic stack of decidedly non-real-time software, be it Windows, 'NIX or something else. Wrong. Load up something that allows you to sync to a USB2 subframe (125us clocking) in 3 lines of code, gives you 8/16 sample buffering for audio and (preferably) gives you an API that mimics your favourite heavy-weight OS so you can use your standard development tools (the Microsoft C++ compiler in my case). Now you take your 'real-time' PC and connect it to your normal workstation and they talk to each other. Unlimited audio joy (both technical and artistic) results. If you decide you no longer wish to burn the 700 watts or so the Q660 and friends require you can swap it out for a dual core Atom board and carry on without having to make a single change to your development/production/performance environment. It may be slightly less capable, but not that much less. Bear in mind that FPGAs are just silicon - they are subject to exactly the same laws as DRAM or X86 processors. If you want to do powerful things with an FPGA you need lots of cells, and they are not nearly as cheap as the cells you buy in DRAM and X86 processor cores. Competition and economies of scale overwhelmingly favour consumer grade components for price and performance. Footnote: It is interesting to contrast the explosion of interest in (DIY) analog audio hardware with the collapse of interest in the same in the digital domain. It's a reflection of what has happened with classic cars - almost anything from the 50's and 60's can be kept going forever. Worst case you might have to do some machining or get a specialist to fix your carburettor. I'll be willing to bet my 60's Sprite will be running long after my 00's Audi is recycled AL. Ditto my little valve powered Laney amp. Digital electronics - which is all about creation and consumption and not maintenance. Sorry for the splurge ... ATB Jerry. > Right, but preferable I'd want a good, guaranteed low latency link between > the board and a strong computer, that's very important to break through the > real time and interactive music barrier, maybe things turn in to muddy > nonsense when everything is non-interacting, I observe. > > And also: what would a soundcard do, compared with software processing, like > I was recently trying out freeverb3, an Open Source impulse based reverb and > the Stanford STK software for (in my case) Physical Modeling based sounds, > and then I think quite a heavy design is in place to complement the sort of > bandwidth and SSE2 based processing going on, so a good FPGA, possibly with > built in or external DSP would be cool, and not a redone soundblaster > design, right? > > Greetings, > Theo > > From dpanseri at gmail.com Wed May 13 16:01:05 2009 From: dpanseri at gmail.com (David Panseri) Date: Wed May 13 16:01:22 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: <4A0B1E4D.1060900@cox.net> References: <23487108.post@talk.nabble.com> <518fe7b20905120845x137058bawec897c0fbcad7839@mail.gmail.com> <23511475.post@talk.nabble.com> <3C22680E207841989DF0D8A9AC06FBC2@LazzariniPC> <4A0A83B6.8070605@saunalahti.fi> <9b3e2dc20905130801o4dbeaebcrb6a2399a8bbb58d7@mail.gmail.com> <4A0B1E4D.1060900@cox.net> Message-ID: I've been keeping an eye on the beagleboard myself. Looks like a neat little board that can do a ton of cool stuff. Pretty cheap too. The fact that it has HDMI/DVI out presents some interesting interface options. -Dave On Wed, May 13, 2009 at 3:23 PM, Eric Brombaugh wrote: > Rob Belcham wrote: >> >> The blackfin 'Stamp' board is pretty pokey and has a good feature set, >> although no audio i/o. I think there are daughter boards you can get to >> expand it. There's a version of uCLinux (i.e open source tools & drivers) >> available for it and a pretty good blackfin community forum at >> www.blackfin.org. Digikey are selling them for $215. The blackfin is no good >> if you want to do floating point ops, but it's fine for integer / fractional >> 32 bit maths. > > One platform I've been looking at seriously is the TI BeagleBoard. For $149 > from Digi-Key you get an OMAP SoC (600MHz ARM processor, DSP co-processor, > 3D graphics accelerator), 256MB DRAM, 256MB NAND Flash, DVI-D, raw LCD & > S-Video output, two USB2.0 ports, SD Flash and stereo audio I/O. There are > several flavors of full Linux running on this hardware today and heavy > development underway to integrate the extra OMAP features. > > All software development can be done with open-source or free tools (the C > compiler for the on-chip DSP is closed source but freely available and runs > under x86 Linux) and it's even possible to do native development on the > Beagle itself. Audio software from the OS community (ALSA, JACK, LADSPA, > etc) is reputed to port without too much difficulty and a standardized DSP > interface framework is also working. > > There's a 28-pin expansion connector with UART, SPI, I2C & GPIO that's > accessible through the Linux kernel. Several hardware developers out there > are already building daughter cards for it which allow DIY development. > > This could be the heart of a powerful soft-synth based entirely on > open-source software. With suitable tuning it can boot to a useable state > from SD flash in just a few seconds and be running powerful multiprocessing > soft synths. Add some UI hardware (knobs, buttons, displays) via the > expansion connector and it could be usable in live situations as well. > > Eric > -- > 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 nostromo at arkaos.net Wed May 13 16:10:27 2009 From: nostromo at arkaos.net (M-.-n) Date: Wed May 13 16:10:48 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: <4A0B1E4D.1060900@cox.net> Message-ID: <7qb0v2$8bbepm@relay.skynet.be> I was looking at that one for a while too. But the eee 701 sort of kills it IMHO because with it's price going down, you get sort of more complete package for the same price. You still can install a unix kernel (actually you have more choice of the flavor). You'd miss the expansion port but gain a display on top and a floating point processor. Speaking of that makes me think of another puzzling question: is there any known usb controller providing good knobs with HID and not the laughable resolution of midi ? I'm trying to understand why it's so tough to find.. Regards, M. >One platform I've been looking at seriously is the TI BeagleBoard. For >$149 from Digi-Key you get an OMAP SoC (600MHz ARM processor, DSP co-processor, >3D graphics accelerator), 256MB DRAM, 256MB NAND Flash, DVI-D, raw LCD & >S-Video output, two USB2.0 ports, SD >Flash and stereo audio I/O. >There are several flavors of full Linux >running on this hardware today and heavy development underway to integrate >the extra OMAP features. From nostromo at arkaos.net Wed May 13 16:15:57 2009 From: nostromo at arkaos.net (M-.-n) Date: Wed May 13 16:17:01 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: <4A0B2658.1030202@NovaDSP.com> Message-ID: <7qb0v2$8bbhcj@relay.skynet.be> Hey Jerry, Can you explain a little bit more how this would work ? It's completely new territory for me and I'm quite curious. Any links in case you don't want to type it all ? Thanks Marc. [snip] The problem with using a PC for 'real-time' audio is not the hardware - it is because we generally insist on loading up a gigantic stack of decidedly non-real-time software, be it Windows, 'NIX or something else. Wrong. Load up something that allows you to sync to a USB2 subframe (125us clocking) in 3 lines of code, gives you 8/16 sample buffering for audio and (preferably) gives you an API that mimics your favourite heavy-weight OS so you can use your standard development tools (the Microsoft C++ compiler in my case). Now you take your 'real-time' PC and connect it to your normal workstation and they talk to each other. Unlimited audio joy (both technical and artistic) results. [/snip] From michael.gogins at gmail.com Wed May 13 16:30:44 2009 From: michael.gogins at gmail.com (Michael Gogins) Date: Wed May 13 16:31:01 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: <4A0B2658.1030202@NovaDSP.com> References: <23487108.post@talk.nabble.com> <518fe7b20905120845x137058bawec897c0fbcad7839@mail.gmail.com> <23511475.post@talk.nabble.com> <3C22680E207841989DF0D8A9AC06FBC2@LazzariniPC> <23512139.post@talk.nabble.com> <518fe7b20905131029k4f43c38ep4d436d9c3778771c@mail.gmail.com> <23527073.post@talk.nabble.com> <4A0B2658.1030202@NovaDSP.com> Message-ID: <898dd7270905131330v13cb9635m24d71f8c2022b4e3@mail.gmail.com> I was thinking of saying something about this, but you said it better. Regards, Mike On 5/13/09, Jerry Evans wrote: > Greets. > > Having built comparable hardware I am utterly convinced that it is > absolutely the wrong approach. You get murdered on productivity. price, > and performance. > > We built a 24 bit 6 in 2 out processing engine with a TI DSP core and a > USB 2 link to a PC. To keep the costs at rock bottom we (ahem) > piggy-backed the IO onto a TI eval board. Nonetheless the hardware was > still 100's of dollars as custom PCB etc absolutely critical for getting > chips to work at all, let alone with decent noise performance etc. IIRC > the one-off cost was > than a top spec PC of the era (single core P4 I'd > guess). > > This cheery dismissal describes none of the agony of writing embedded C > code for the TI core that had to be downloaded, flashed, debugged etc > etc over a USB 2 bus that itself had to be programmed, debugged etc etc. > After about 9 months the system would play nice with an Apple laptop but > the multi-channel USB audio was never recognised by Windows boxes. > > Hardware? Aptly named. Even something 'simple' like replacing a chip > became fantastically difficult. You are dealing with 200 pin packages > which have to be soldered into place, with sub-millimeter intra-pin > spacing. They are simply not made for human handling - robots do it all > on a flow soldering line. Overheat the chip with your $300 tempco > Weller, or short 2 pins, or lift a PCB track and it is back to square > one. 2 days of regression testing leaves you no choice but to infer the > 30us timing slew on some obscure pin is out of spec and implies a > hardware fault. > > At the outset you could just about compare the raw power of the TI > series with a single core PIII with SSE2, even then it was heading for > apples and oranges territory . By the time the h/w was tottering into > life the whole world had changed and you had multi-core SSE3 systems and > double the RAM for *less* than the previous generation of processor. > Today a quad core PC with 8GB of RAM is less than the price of said > soldering iron. > > Plug in a sensible quality PCI soundboard (or 4) and you've got all the > horsepower and flexibility you could ever want, at budget prices, with a > reasonable and verifiable expectation of functionality. > > The problem with using a PC for 'real-time' audio is not the hardware - > it is because we generally insist on loading up a gigantic stack of > decidedly non-real-time software, be it Windows, 'NIX or something else. > Wrong. Load up something that allows you to sync to a USB2 subframe > (125us clocking) in 3 lines of code, gives you 8/16 sample buffering for > audio and (preferably) gives you an API that mimics your favourite > heavy-weight OS so you can use your standard development tools (the > Microsoft C++ compiler in my case). Now you take your 'real-time' PC and > connect it to your normal workstation and they talk to each other. > Unlimited audio joy (both technical and artistic) results. > > If you decide you no longer wish to burn the 700 watts or so the Q660 > and friends require you can swap it out for a dual core Atom board and > carry on without having to make a single change to your > development/production/performance environment. It may be slightly less > capable, but not that much less. > > Bear in mind that FPGAs are just silicon - they are subject to exactly > the same laws as DRAM or X86 processors. If you want to do powerful > things with an FPGA you need lots of cells, and they are not nearly as > cheap as the cells you buy in DRAM and X86 processor cores. Competition > and economies of scale overwhelmingly favour consumer grade components > for price and performance. > > Footnote: It is interesting to contrast the explosion of interest in > (DIY) analog audio hardware with the collapse of interest in the same in > the digital domain. It's a reflection of what has happened with classic > cars - almost anything from the 50's and 60's can be kept going forever. > Worst case you might have to do some machining or get a specialist to > fix your carburettor. I'll be willing to bet my 60's Sprite will be > running long after my 00's Audi is recycled AL. Ditto my little valve > powered Laney amp. Digital electronics - which is all about creation and > consumption and not maintenance. > > Sorry for the splurge ... > > ATB > > Jerry. >> Right, but preferable I'd want a good, guaranteed low latency link between >> the board and a strong computer, that's very important to break through >> the >> real time and interactive music barrier, maybe things turn in to muddy >> nonsense when everything is non-interacting, I observe. >> >> And also: what would a soundcard do, compared with software processing, >> like >> I was recently trying out freeverb3, an Open Source impulse based reverb >> and >> the Stanford STK software for (in my case) Physical Modeling based sounds, >> and then I think quite a heavy design is in place to complement the sort >> of >> bandwidth and SSE2 based processing going on, so a good FPGA, possibly >> with >> built in or external DSP would be cool, and not a redone soundblaster >> design, right? >> >> Greetings, >> Theo >> >> > > > -- > 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 > -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com From ben at glw.com Wed May 13 17:45:19 2009 From: ben at glw.com (Ben Loftis) Date: Wed May 13 17:45:36 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: <20090513201713.43EB37E1DE4@music.columbia.edu> References: <20090513201713.43EB37E1DE4@music.columbia.edu> Message-ID: <4A0B3F6F.60501@glw.com> Speaking of low-latency "native" audio processing: At Harrison we have some "big iron" native audio processing technology. We are open to licensing if anyone is interested. These are production items, in use around the world, not vaporware. We have 2 different flavors available: System "A" is a linux desktop OS, using JACK for I/O, which communicates 64 channels of 32-bit audio to our Xrouter. Total roundtrip latency is 56 samples at 48kHz. This is extremely stable with full graphical desktop, recording software, etc. System "B" is a hard-realtime OS, providing 256 channels of 64-bit audio I/O. Roundtrip latency is under 10 samples, maybe significantly lower depending on the application. Both systems use our proprietary "Xrouter" hardware for I/O. Audio connection to the computer is via CAT5e. This is a large-scale solution, with 8+8 MADI ports ( 512x512 I/O ) in the basic setup. If anyone is interested, feel free to contact me. -Ben Loftis ben@harrisonconsoles.com Harrison Consoles http://www.harrisonconsoles.com From Victor.Lazzarini at nuim.ie Wed May 13 17:54:18 2009 From: Victor.Lazzarini at nuim.ie (victor) Date: Wed May 13 17:54:37 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth In-Reply-To: <4A0B3F6F.60501@glw.com> References: <20090513201713.43EB37E1DE4@music.columbia.edu> <4A0B3F6F.60501@glw.com> Message-ID: This sounds impressive, what is the OS? > > System "B" is a hard-realtime OS, providing 256 channels of 64-bit audio > I/O. Roundtrip latency is under 10 samples, maybe significantly lower > depending on the application. > > > > -- > 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 May 13 18:09:11 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Wed May 13 18:06:53 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth References: <23487108.post@talk.nabble.com><518fe7b20905120845x137058bawec897c0fbcad7839@mail.gmail.com><23511475.post@talk.nabble.com><3C22680E207841989DF0D8A9AC06FBC2@LazzariniPC><23512139.post@talk.nabble.com><518fe7b20905131029k4f43c38ep4d436d9c3778771c@mail.gmail.com><23527073.post@talk.nabble.com> <4A0B2658.1030202@NovaDSP.com> <898dd7270905131330v13cb9635m24d71f8c2022b4e3@mail.gmail.com> Message-ID: <006501c9d417$75596920$0201a8c0@mooncode> And I was wondering how to turn this back into the high-volume list it was when I first discovered music-dsp... Martin From rbj at audioimagination.com Wed May 13 23:53:35 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Wed May 13 23:55:03 2009 Subject: [music-dsp] Open Source DSP Analog Simulation Synth Message-ID: <20090514035335.38F009ECC3@ws6-2.us4.outblaze.com> > ----- Original Message ----- > From: theover > To: music-dsp@music.columbia.edu > Subject: Re: [music-dsp] Open Source DSP Analog Simulation Synth > Date: Wed, 13 May 2009 11:28:47 -0700 (PDT) > > > ... Analog synths of 5 decades ago can easily be better at many > of these issues than a nifty new fpga or dsp design when no care is taken. which means that we should take care. > Also, many sounds based on samples are based on assumptions about the > playboack equipment being used, and uses transforms which are seldom a > bijection (i.e. impossible to invert by external processing to the original, > intended sound). i guess a hard-limiter might be one of them non-bijective transformations. > > An important issue IMO is bandwidth limited oscillators (after my above > synth design and prototype had received some attention but little feedback I > was glad to read the latest kurzweils had 'bandwidth limited generators' i guess i had something to do with that. we called it "smooth" or "alias-suppressed" waveform generation. > even while of course I knew that is normal. A saw or triangle oscillator for > a 'normal' synth design which is well frequency band limited as to prevent > aliasing, well, i dunno how "normal" it is to do decent bandlimited waveform generation (that is about as bright and funky as the corresponding analog waveform generation had been), but the music-dsp archive here has a bunch of algs for that. for me, as long as interpolation is not an extra problem (which it would not be if you had the sample-playback down nicely), the simplest conceptual method is simply to have a bunch or wavetables for the same sawtooth (or whatever analog waveform) but bandlimited to different degrees (different number of harmonics in each wavetable) and sample and loop with that. you might need to do some inter-wavetable interpolation with that (meaning you'll have to have two wavetable oscillators going simultaneously for each voice), but you can be guaranteed have the harmonics good up to the top octave (or even better). and if you're sampling at 96 kHz, then the top octave really doesn't matter at all. this isn't at all how the PC3 synths do it, so i'm not revealing anything. > ... and most commonly used interpolations are > really very far from the sonic quality I like to monitor, granted on a > extensive monitoring system, but many modern sounds sound alike and annoying > also on a good notebook amplification, for instance, and all that seems most > of the time to be taken for granted. That's among the reasons many not so > much adding designs of musical synthesizers remain decades and many quality > levels behind lets say a cheap enough second hand motif or so, with 64 or > more voices. well, the new kurz keyboards sound good. they have some nice built-in samples and nice alg presets done by some really good "soundware" engineers (really musicians). their algorithmic synth waveform generators are better that the kurz keyboards previously released (so the VA1 is not in that set), they have some useful and nifty UI and 128 voices, but synthesis-wise they are not anything much new. still doin' it the same ol' trusted way they used to. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From raga.raga at gmx.de Thu May 14 06:38:32 2009 From: raga.raga at gmx.de (Jan Baumgart) Date: Thu May 14 06:38:49 2009 Subject: [music-dsp] time representation in the frequency domain Message-ID: <4A0BF4A8.70909@gmx.de> Hallo! I've got a mathematical question: When doing a fulltime fourier transform (only _one_ big "frame"), how is the time information encoded into the phase? When doing an inverse transform (or for example convolve with an dirac impulse) you get back exactly the same you put in in the first place. So the time information has got to be hidden somewhere in the frequency domain, doesn't it? When looking at a time domain signal from a fourier view, you can look at the frequency information as "encoded" as sine function components. Does the same apply for the time information encoded into the frequency domain? This seems quite mysterious to me...has there been anything published on this subject? cheers, jan baumgart. From didid at skynet.be Thu May 14 06:55:22 2009 From: didid at skynet.be (Didier Dambrin) Date: Thu May 14 06:55:54 2009 Subject: [music-dsp] time representation in the frequency domain In-Reply-To: <4A0BF4A8.70909@gmx.de> References: <4A0BF4A8.70909@gmx.de> Message-ID: <1A02B2A5A3454C5B926FE55EC60CA242@GOLAMD> There's no time information, it's the sum of the sines at their specific phases that combine back to the original signal. A sine that would start in the middle of your signal that you FFT, would already end up as several freqs in your FFT, depending on how smoothly it starts (if it starts abruptly, you'll get a click, and thus your FFT filled). > Hallo! > > I've got a mathematical question: > When doing a fulltime fourier transform (only _one_ big "frame"), how is > the time information encoded into the phase? > > When doing an inverse transform (or for example convolve with an dirac > impulse) you get back exactly the same you put in in the first place. So > the time information has got to be hidden somewhere in the frequency > domain, doesn't it? > > When looking at a time domain signal from a fourier view, you can look > at the frequency information as "encoded" as sine function components. > Does the same apply for the time information encoded into the frequency > domain? > > This seems quite mysterious to me...has there been anything published on > this subject? > > cheers, > jan baumgart. > > -- > 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.5.329 / Virus Database: 270.12.29/2114 - Release Date: 05/14/09 06:28:00 From bogac at bteaudio.com Thu May 14 07:20:24 2009 From: bogac at bteaudio.com (Bogac Topaktas) Date: Thu May 14 07:21:26 2009 Subject: [music-dsp] time representation in the frequency domain Message-ID: <1e2ff330$64321589$5fd72e31$@com> See the following tutorial paper on joint-domain time-frequency analysis: "Wigner Distribution Representation and Analysis of Audio Signals: An Illustrated Tutorial Review" Douglas Preis and Voula Chris Georgopoulos JAES Volume 47 Issue 12 pp. 1043-1053; December 1999 (available to AES members at http://www.aes.org/tutorials/ ) And the following resources also contain relevant information: "Scatter: A Software Tool for Visualizing, Transforming, and Performing Atomic Decompositions of Sound" http://mast.mat.ucsb.edu/docs/paper_36.pdf "Time-Frequency Analysis using Time-Order Representation and Wigner Distribution" http://www.iiit.net/techreports/2008_122.pdf -------- Original Message -------- > From: "Jan Baumgart" > Sent: Thursday, May 14, 2009 1:39 PM > To: music-dsp@music.columbia.edu > Subject: [music-dsp] time representation in the frequency domain > > Hallo! > > I've got a mathematical question: > When doing a fulltime fourier transform (only _one_ big "frame"), how is > the time information encoded into the phase? > > When doing an inverse transform (or for example convolve with an dirac > impulse) you get back exactly the same you put in in the first place. So > the time information has got to be hidden somewhere in the frequency > domain, doesn't it? > > When looking at a time domain signal from a fourier view, you can look > at the frequency information as "encoded" as sine function components. > Does the same apply for the time information encoded into the frequency > domain? > > This seems quite mysterious to me...has there been anything published on > this subject? > > cheers, > jan baumgart. > > -- > 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 tothl at inf.u-szeged.hu Thu May 14 07:34:46 2009 From: tothl at inf.u-szeged.hu (Laszlo Toth) Date: Thu May 14 07:35:01 2009 Subject: [music-dsp] time representation in the frequency domain In-Reply-To: <4A0BF4A8.70909@gmx.de> References: <4A0BF4A8.70909@gmx.de> Message-ID: On Thu, 14 May 2009, Jan Baumgart wrote: > the time information has got to be hidden somewhere in the frequency > domain, doesn't it? I don't really get what you mean by "time information", but I think the repliy is as you said: the phase. A basic property of the Fourier-transform is that its amplitude is shift-invariant, so by shifting your data in time, the resulting amplitude values will be the same, only the phase will change. Laszlo Toth Hungarian Academy of Sciences * Research Group on Artificial Intelligence * "Failure only begins e-mail: tothl@inf.u-szeged.hu * when you stop trying" http://www.inf.u-szeged.hu/~tothl * From rossb-lists at audiomulch.com Thu May 14 07:34:49 2009 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Thu May 14 07:35:24 2009 Subject: [music-dsp] time representation in the frequency domain References: <4A0BF4A8.70909@gmx.de> Message-ID: <04dc01c9d487$feaa31d0$0773a8c0@rossmacbook> Hi Jan A good question would be "time information of what?" I'm you're interested in the time of transient onsets you could investigate algorithms for improving onset localisation within a Fourier frame (sorry can't find a reference right now)... Ross. ----- Original Message ----- From: "Jan Baumgart" To: Sent: Thursday, May 14, 2009 8:38 PM Subject: [music-dsp] time representation in the frequency domain > Hallo! > > I've got a mathematical question: > When doing a fulltime fourier transform (only _one_ big "frame"), how is > the time information encoded into the phase? > > When doing an inverse transform (or for example convolve with an dirac > impulse) you get back exactly the same you put in in the first place. So > the time information has got to be hidden somewhere in the frequency > domain, doesn't it? > > When looking at a time domain signal from a fourier view, you can look at > the frequency information as "encoded" as sine function components. Does > the same apply for the time information encoded into the frequency domain? > > This seems quite mysterious to me...has there been anything published on > this subject? > > cheers, > jan baumgart. > > -- > 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 xue.wen at elec.qmul.ac.uk Thu May 14 07:49:05 2009 From: xue.wen at elec.qmul.ac.uk (Wen X) Date: Thu May 14 07:49:36 2009 Subject: [music-dsp] time representation in the frequency domain In-Reply-To: <4A0BF4A8.70909@gmx.de> References: <4A0BF4A8.70909@gmx.de> Message-ID: <1061352F5A464CA7985B0B51FFD75A6C@wenmac> In general time information are encoded in both amplitude and phase. Nonetheless, Oppenheim wrote a paper called "The importance of phase in signals", addressing that phase appears more important in locating events, and that you can get a lot from the phase only. It doesn't say HOW it is encoded there but points out it IS there. An easier-to-understand fact is that signals with the same phase spectrum are connected by zero-phase filters. These filters have symmetric impulse responses so more or less (can be very little though!) preserve locations. Wen X. -----Original Message----- From: music-dsp-bounces@music.columbia.edu [mailto:music-dsp-bounces@music.columbia.edu] On Behalf Of Jan Baumgart Sent: 14 May 2009 11:39 To: music-dsp@music.columbia.edu Subject: [music-dsp] time representation in the frequency domain Hallo! I've got a mathematical question: When doing a fulltime fourier transform (only _one_ big "frame"), how is the time information encoded into the phase? When doing an inverse transform (or for example convolve with an dirac impulse) you get back exactly the same you put in in the first place. So the time information has got to be hidden somewhere in the frequency domain, doesn't it? When looking at a time domain signal from a fourier view, you can look at the frequency information as "encoded" as sine function components. Does the same apply for the time information encoded into the frequency domain? This seems quite mysterious to me...has there been anything published on this subject? cheers, jan baumgart. -- 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 music-dsp at zenprobe.com Thu May 14 07:50:41 2009 From: music-dsp at zenprobe.com (Dylan Menzies) Date: Thu May 14 07:51:02 2009 Subject: [music-dsp] time representation in the frequency domain In-Reply-To: <04dc01c9d487$feaa31d0$0773a8c0@rossmacbook> References: <4A0BF4A8.70909@gmx.de> <04dc01c9d487$feaa31d0$0773a8c0@rossmacbook> Message-ID: Jan, You nearly answered this yourself I think, but the time isn't simply in a single phase of freq rep. A delta in time is represented in frequency by a infinitely wide spread of frequencies (or finite if sampled) with precise phase relationships. Mess with the phases and you have white noise. Dylan > ----- Original Message ----- From: "Jan Baumgart" > To: > Sent: Thursday, May 14, 2009 8:38 PM > Subject: [music-dsp] time representation in the frequency domain > > >> Hallo! >> >> I've got a mathematical question: >> When doing a fulltime fourier transform (only _one_ big "frame"), how is >> the time information encoded into the phase? >> >> When doing an inverse transform (or for example convolve with an dirac >> impulse) you get back exactly the same you put in in the first place. So >> the time information has got to be hidden somewhere in the frequency >> domain, doesn't it? >> >> When looking at a time domain signal from a fourier view, you can look at >> the frequency information as "encoded" as sine function components. Does >> the same apply for the time information encoded into the frequency domain? >> >> This seems quite mysterious to me...has there been anything published on >> this subject? >> >> cheers, >> jan baumgart. >> >> -- >> 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 xue.wen at elec.qmul.ac.uk Thu May 14 07:52:18 2009 From: xue.wen at elec.qmul.ac.uk (Wen X) Date: Thu May 14 07:52:34 2009 Subject: [music-dsp] time representation in the frequency domain In-Reply-To: <04dc01c9d487$feaa31d0$0773a8c0@rossmacbook> References: <4A0BF4A8.70909@gmx.de> <04dc01c9d487$feaa31d0$0773a8c0@rossmacbook> Message-ID: ;) Do you mean my paper? - "Acoustic onset detection using phase information," Int. Cong. Ac., Kyoto, 2004. -----Original Message----- From: music-dsp-bounces@music.columbia.edu [mailto:music-dsp-bounces@music.columbia.edu] On Behalf Of Ross Bencina Sent: 14 May 2009 12:35 To: music-dsp@music.columbia.edu Subject: Re: [music-dsp] time representation in the frequency domain Hi Jan A good question would be "time information of what?" I'm you're interested in the time of transient onsets you could investigate algorithms for improving onset localisation within a Fourier frame (sorry can't find a reference right now)... Ross. ----- Original Message ----- From: "Jan Baumgart" To: Sent: Thursday, May 14, 2009 8:38 PM Subject: [music-dsp] time representation in the frequency domain > Hallo! > > I've got a mathematical question: > When doing a fulltime fourier transform (only _one_ big "frame"), how is > the time information encoded into the phase? > > When doing an inverse transform (or for example convolve with an dirac > impulse) you get back exactly the same you put in in the first place. So > the time information has got to be hidden somewhere in the frequency > domain, doesn't it? > > When looking at a time domain signal from a fourier view, you can look at > the frequency information as "encoded" as sine function components. Does > the same apply for the time information encoded into the frequency domain? > > This seems quite mysterious to me...has there been anything published on > this subject? > > cheers, > jan baumgart. > > -- > 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 didid at skynet.be Thu May 14 08:09:27 2009 From: didid at skynet.be (Didier Dambrin) Date: Thu May 14 08:09:56 2009 Subject: [music-dsp] time representation in the frequency domain In-Reply-To: <1061352F5A464CA7985B0B51FFD75A6C@wenmac> References: <4A0BF4A8.70909@gmx.de> <1061352F5A464CA7985B0B51FFD75A6C@wenmac> Message-ID: Talking about phases, it's interesting how it's not so much absolute phases that seem to be important, but phases relative to neighbors, and how you can scramble audio by shifting phases at random, while a progressive shift through the whole spectrum isn't much audible. It's also amazing to see 2 signals that can be as high as 12dB apart in peaks, while they sound exactly the same because all of the phases were shifted by the same amount. I've made a little tool that "normalizes" (short bits of) audio higher than classic normalization, by shifting phases. In practice you get around 1 to 3 dB's out of most short signals. But I'm not sure if it really has a use. That is, you can feed it a kickdrum and get it louder for the same peak, but I'm not too sure if it makes a difference in a final mix. Would probably more efficient to play with phasing in a -mixer-, to shift phases until the sum peaks at its lowest. > In general time information are encoded in both amplitude and phase. > Nonetheless, Oppenheim wrote a paper called "The importance of phase in > signals", addressing that phase appears more important in locating events, > and that you can get a lot from the phase only. It doesn't say HOW it is > encoded there but points out it IS there. > > An easier-to-understand fact is that signals with the same phase spectrum > are connected by zero-phase filters. These filters have symmetric impulse > responses so more or less (can be very little though!) preserve locations. > > Wen X. > > -----Original Message----- > From: music-dsp-bounces@music.columbia.edu > [mailto:music-dsp-bounces@music.columbia.edu] On Behalf Of Jan Baumgart > Sent: 14 May 2009 11:39 > To: music-dsp@music.columbia.edu > Subject: [music-dsp] time representation in the frequency domain > > Hallo! > > I've got a mathematical question: > When doing a fulltime fourier transform (only _one_ big "frame"), how is > the time information encoded into the phase? > > When doing an inverse transform (or for example convolve with an dirac > impulse) you get back exactly the same you put in in the first place. So > the time information has got to be hidden somewhere in the frequency > domain, doesn't it? > > When looking at a time domain signal from a fourier view, you can look > at the frequency information as "encoded" as sine function components. > Does the same apply for the time information encoded into the frequency > domain? > > This seems quite mysterious to me...has there been anything published on > this subject? > > cheers, > jan baumgart. > > -- > 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 -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.329 / Virus Database: 270.12.29/2114 - Release Date: 05/14/09 06:28:00 From padawan12 at obiwannabe.co.uk Thu May 14 07:22:41 2009 From: padawan12 at obiwannabe.co.uk (Andy Farnell) Date: Thu May 14 08:21:18 2009 Subject: [music-dsp] time representation in the frequency domain In-Reply-To: References: <4A0BF4A8.70909@gmx.de> <1061352F5A464CA7985B0B51FFD75A6C@wenmac> Message-ID: <20090514122241.476d45ca.padawan12@obiwannabe.co.uk> That's an interesting application. On Thu, 14 May 2009 14:09:27 +0200 "Didier Dambrin" wrote: > It's also amazing to see 2 signals that can be as high as 12dB apart in > peaks, while they sound exactly the same because all of the phases were > shifted by the same amount. > I've made a little tool that "normalizes" (short bits of) audio higher than > classic normalization, by shifting phases. > In practice you get around 1 to 3 dB's out of most short signals. But I'm > not sure if it really has a use. It certainly has use, but it has a cost. By moving the phases you got the minimum dynamic variance (and so the maximum average amplitude) but you lost the attack transient. The kick drum seems a great example. Don't these 'super normalised' short hits sound "duller" with less "impact" than their unprocessed sources? My best guess for application domain is short vocal phrases. -- Use the source From neolit123 at gmail.com Thu May 14 11:15:52 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Thu May 14 12:29:27 2009 Subject: [music-dsp] time representation in the frequency domain References: <4A0BF4A8.70909@gmx.de> Message-ID: <007001c9d4a6$e49046d0$0201a8c0@LuboPC> Hello Jan, As you may know time should be considered linear in any system, unless we deal with strictly theoretical mathematics. The FFT works with time intervals (in which time is linear and soundwaves travels in linear time or at least we hear so ). It also works with amplitudes to construct the frequency / magnitude for this signal. I will not say that time is not "encoded" in phase or vice versa. But there are these simple relations: f (frequency) = 1 / T (time) omega (angular frequency) = 2 * PI * f phi (phase) = omega * T and in the case of FFT series - sin(omega * T), cos(omega * T) as our two subfunction types. It is suggested that any function (signal) can be expanded in terms of sin() and cos(), and since time is linear here we can work the above relations very easily. Or maybe I do not understand the nature of your question correctly? ;) Lubomir I. Ivanov http://www.tu-varna.bg ----- Original Message ----- From: "Jan Baumgart" To: Sent: Thursday, May 14, 2009 1:38 PM Subject: [music-dsp] time representation in the frequency domain > Hallo! > > I've got a mathematical question: > When doing a fulltime fourier transform (only _one_ big "frame"), how is > the time information encoded into the phase? > > When doing an inverse transform (or for example convolve with an dirac > impulse) you get back exactly the same you put in in the first place. So > the time information has got to be hidden somewhere in the frequency > domain, doesn't it? > > When looking at a time domain signal from a fourier view, you can look at > the frequency information as "encoded" as sine function components. Does > the same apply for the time information encoded into the frequency domain? > > This seems quite mysterious to me...has there been anything published on > this subject? > > cheers, > jan baumgart. > > -- > 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 raga.raga at gmx.de Thu May 14 13:33:53 2009 From: raga.raga at gmx.de (Jan Baumgart) Date: Thu May 14 13:34:18 2009 Subject: [music-dsp] time representation in the frequency domain In-Reply-To: <007001c9d4a6$e49046d0$0201a8c0@LuboPC> References: <4A0BF4A8.70909@gmx.de> <007001c9d4a6$e49046d0$0201a8c0@LuboPC> Message-ID: <4A0C5601.4030009@gmx.de> Sorry, if I didn't make myself clear. I'm no native english-speaker and sometimes mix up technical terms.. A FFT assumes that the signal is periodic/static. This means, that no change over time is involved. The only term referring to time is "phase", but it's merely describing a relationship between the frequency-components and not a change over time. To overcome this, one normally applies the FFT to very short (quasi-static) enveloped time-segments of the signal (so called frames) and (overlap-)adds them together after the inverse transform. This of course introduces artefacts and limits the resolution (time vs. frequency). However, practically it's possible to make one huge fourier transform of a _whole_ non-periodic signal. As I understand, the fourier paradigma isn't meant to be used this way, but it works! For example, in convolution. And it works without any artefacts or loss of any kind. As stated by others, "time" (to be honest, i'm not sure myself, what that _exactly_ means) in the frequency domain is to be found somewhere in the relationship of neighboring bins. BTW, my goal is to exploit this phenomena for experimental audio manipulations... Lubomir I. Ivanov wrote: > Hello Jan, > > As you may know time should be considered linear in any system, unless we > deal with strictly theoretical mathematics. > The FFT works with time intervals (in which time is linear and soundwaves > travels in linear time or at least we hear so ). It also works with > amplitudes to construct the frequency / magnitude for this signal. > > I will not say that time is not "encoded" in phase or vice versa. But there > are these simple relations: > > f (frequency) = 1 / T (time) > omega (angular frequency) = 2 * PI * f > phi (phase) = omega * T > > and in the case of FFT series - sin(omega * T), cos(omega * T) as our two > subfunction types. > It is suggested that any function (signal) can be expanded in terms of > sin() > and cos(), and since time is linear here we can work the above relations > very easily. > > Or maybe I do not understand the nature of your question correctly? ;) > > Lubomir I. Ivanov > http://www.tu-varna.bg > > ----- Original Message ----- From: "Jan Baumgart" > To: > Sent: Thursday, May 14, 2009 1:38 PM > Subject: [music-dsp] time representation in the frequency domain > > >> Hallo! >> >> I've got a mathematical question: >> When doing a fulltime fourier transform (only _one_ big "frame"), how is >> the time information encoded into the phase? >> >> When doing an inverse transform (or for example convolve with an dirac >> impulse) you get back exactly the same you put in in the first place. So >> the time information has got to be hidden somewhere in the frequency >> domain, doesn't it? >> >> When looking at a time domain signal from a fourier view, you can look at >> the frequency information as "encoded" as sine function components. Does >> the same apply for the time information encoded into the frequency >> domain? >> >> This seems quite mysterious to me...has there been anything published on >> this subject? >> >> cheers, >> jan baumgart. >> >> -- >> 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 mtonelli at anwida.com Thu May 14 14:15:00 2009 From: mtonelli at anwida.com (Massimiliano Tonelli) Date: Thu May 14 14:15:10 2009 Subject: [music-dsp] time representation in the frequency domain References: <4A0BF4A8.70909@gmx.de> <007001c9d4a6$e49046d0$0201a8c0@LuboPC> <4A0C5601.4030009@gmx.de> Message-ID: > However, practically it's possible to make one huge fourier transform of a > _whole_ non-periodic signal. > As I understand, the fourier paradigma isn't meant to be used this way, > but it works! To my understanding, but I might be wrong, by doing this you are implicitly considering the whole signal as just one period of its periodic extension. All the best Massimiliano From alantygel at gmail.com Thu May 14 14:47:35 2009 From: alantygel at gmail.com (Alan Tygel) Date: Thu May 14 14:47:51 2009 Subject: [music-dsp] time representation in the frequency domain In-Reply-To: References: <4A0BF4A8.70909@gmx.de> <007001c9d4a6$e49046d0$0201a8c0@LuboPC> <4A0C5601.4030009@gmx.de> Message-ID: <5ae548c20905141147t554e5101r82e69f1af5097cb8@mail.gmail.com> >> And it works without any artefacts or loss of any kind. Until you doesn't make any changes in your signal (in time or freq.), you can go from time to frequency (and back) without any loss. Problems starts when you do modifications on it. A discussion about Fourier Transform/Series can be found on Haykin's Signals and Systems. This can clarify your doubts about the signal being periodic or time limited. Cheers, Alan Tygel www.lps.ufrj.br/~alan On Thu, May 14, 2009 at 3:15 PM, Massimiliano Tonelli wrote: >> However, practically it's possible to make one huge fourier transform of a >> _whole_ non-periodic signal. >> As I understand, the fourier paradigma isn't meant to be used this way, >> but it works! > > To my understanding, but I might be wrong, by doing this ?you are implicitly > considering the whole signal as just one period of its periodic extension. > > All the best > Massimiliano > > -- > 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 Thu May 14 14:52:23 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Thu May 14 14:52:47 2009 Subject: [music-dsp] time representation in the frequency domain Message-ID: <20090514185223.6D0C654D8BE@ws6-9.us4.outblaze.com> > ----- Original Message ----- > From: "Massimiliano Tonelli" > To: "A discussion list for music-related DSP" > Subject: Re: [music-dsp] time representation in the frequency domain > Date: Thu, 14 May 2009 20:15:00 +0200 > > > > However, practically it's possible to make one huge fourier transform of a > > _whole_ non-periodic signal. > > As I understand, the fourier paradigm isn't meant to be used this way, but > > it works! > > To my understanding, but I might be wrong, by doing this you are implicitly > considering the whole signal as just one period of its periodic extension. that's a property of the Discrete Fourier Transform of which an FFT is an implementation of such. we should start getting more specific with our semantics. the "Fourier Transform" with no qualifiers is the continuous Fourier transform which transforms functions, not necessarily data as does the DFT. but whatever finite set of data that you pass to the DFT the DFT periodically extends that data. if we were to anthropomorphize a little, the DFT "assumes" that the data passed to it is one period of an infinite and periodic sequence of numbers. and the result is a single period from another periodic sequence with the same period as going in. with the Fourier Transform, discretely sampled in one domain means periodicity in the other domain. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From michael.gogins at gmail.com Thu May 14 15:05:00 2009 From: michael.gogins at gmail.com (Michael Gogins) Date: Thu May 14 15:05:11 2009 Subject: [music-dsp] time representation in the frequency domain In-Reply-To: References: <4A0BF4A8.70909@gmx.de> <007001c9d4a6$e49046d0$0201a8c0@LuboPC> <4A0C5601.4030009@gmx.de> Message-ID: <898dd7270905141205t71c9823dle985863a70850716@mail.gmail.com> Suppose that you record a click, a Dirac delta, at a specific time, with silence coming before and after. You then take the discrete Fourier transform of this time-domain signal. You end up with a frequency-domain signal in which the phases and amplitudes of the components completely encode the time of the click (within the limits of the irreducible time/frequency uncertainty relation derived by Gabor). The time information is scattered by the Fourier analysis into the relative phases and amplitudes of the various frequency components. "Time" has several meanings here. A periodic signal has no beginning or ending in time, so in that sense it has no "time." But the zero crossings or peaks of each component (which of course is a periodic sinusoidal signal) in the Fourier analysis move back and forth in "time" as its phase increases or decreases. The artifacts to which you refer must be understood with care. You can obtain a perfect reconstruction of a signal with overlapping short time Fourier transforms, if they implement a Gabor resynthesis, i.e. if the resynthesis windows are Guassian and if the STFT cells overlap the Gabor analysis cells. In that case, the inverse STFT is just a way of implementing the Gabor resynthesis, there will be no artifacts. You can't perfectly implement a Gabor analysis this way, but you can perfectly implement the Gabor resynthesis with the Gaussian windowed inverse STFT if you already have the Gabor analysis. So, the artifacts result either from approximating a Gabor analysis with a STFT analysis, and/or from analyzing a signal with one cell spacing and resynthesizing it with another cell spacing. In either case, the kernel of the resynthesis does not "fit" the Gabor cells, and so energy is smeared out, either in time or in frequency, and correspondingly scrunched up in frequency or time. This is often quite audible and annoying. Consequently, for musical applications, it often works better to use an analysis that either is tailored to the signal, or is overdetermined, and then to use oscillator bank resynthesis instead of an inverse transform. Strictly speaking some of the information that is heard in that case is faked by interpolation, but at least it sounds 'realistic' instead of 'artifactual.' Regards, Mike On 5/14/09, Massimiliano Tonelli wrote: >> However, practically it's possible to make one huge fourier transform of a >> >> _whole_ non-periodic signal. >> As I understand, the fourier paradigma isn't meant to be used this way, >> but it works! > > To my understanding, but I might be wrong, by doing this you are implicitly > considering the whole signal as just one period of its periodic extension. > > All the best > Massimiliano > > > -- > 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 > -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com From hsundt at notam02.no Thu May 14 15:16:51 2009 From: hsundt at notam02.no (hsundt@notam02.no) Date: Thu May 14 15:17:05 2009 Subject: [music-dsp] time representation in the frequency domain In-Reply-To: <4A0C5601.4030009@gmx.de> References: <4A0BF4A8.70909@gmx.de> <007001c9d4a6$e49046d0$0201a8c0@LuboPC> <4A0C5601.4030009@gmx.de> Message-ID: <50688.84.48.215.7.1242328611.squirrel@webmail.sysedata.no> I can recommend the program "Mammut" for experimenting with audio transformations based on a huge FFT. It is available for Mac, PC and Linux, both a runnable application (binary) and source code. You can find it here: http://archive.notam02.no/arkiv/doc/mammut/ Also, a paper explaining the techniques, by ?yvind Hammer and myself: "Musical applications of decomposition with global support" http://tinyurl.com/notam-mammut-pdf There is also another project called HyperMammut by Nasca Octavian Paul: http://sourceforge.net/projects/hypermammut Best regards, Henrik Sundt NOTAM http://www.notam02.no > "Jan Baumgart" wrote > .. > > BTW, my goal is to exploit this phenomena for experimental audio > manipulations... > .. From hybridalienrob at hotmail.com Thu May 14 15:26:44 2009 From: hybridalienrob at hotmail.com (Rob Belcham) Date: Thu May 14 15:27:32 2009 Subject: [music-dsp] time representation in the frequency domain In-Reply-To: References: <4A0BF4A8.70909@gmx.de> <007001c9d4a6$e49046d0$0201a8c0@LuboPC><4A0C5601.4030009@gmx.de> Message-ID: >> However, practically it's possible to make one huge fourier transform of >> a _whole_ non-periodic signal. >> As I understand, the fourier paradigma isn't meant to be used this way, >> but it works! > > To my understanding, but I might be wrong, by doing this you are > implicitly considering the whole signal as just one period of its periodic > extension. > Absolutely, but that's one hell of a complex periodic waveform is it not ? Certainly one who's phase relationship between frequencies doesn't remain static, so in that sense, there must be 'time' information encoded in the relationship between phase bins ? I came across this paper a while ago on the subject of decorrelation. The basic idea from what i remember is to filter a signal with an FIR who's IR is generated from a inverse FFT of a unity-gain, random-phase data set. The effect is apparently good at improving stereo imaging because the L&R signals no longer contain any common information and the Haas effect is greatly reduced, so the brain is more able to distinguish from the two sound sources. I'd be interested to hear what other people think of this technique, I haven't got round to trying this out properly yet & running some audio through it. Regards Rob From hybridalienrob at hotmail.com Thu May 14 15:31:50 2009 From: hybridalienrob at hotmail.com (Rob Belcham) Date: Thu May 14 15:32:16 2009 Subject: [music-dsp] time representation in the frequency domain In-Reply-To: References: <4A0BF4A8.70909@gmx.de><007001c9d4a6$e49046d0$0201a8c0@LuboPC><4A0C5601.4030009@gmx.de> Message-ID: Doh - here's the link http://www.dxarts.washington.edu/courses/567/08WIN/KendallDecorrelation_lr.pdf -------------------------------------------------- From: "Rob Belcham" Sent: Thursday, May 14, 2009 8:26 PM To: "A discussion list for music-related DSP" Subject: Re: [music-dsp] time representation in the frequency domain >>> However, practically it's possible to make one huge fourier transform of >>> a _whole_ non-periodic signal. >>> As I understand, the fourier paradigma isn't meant to be used this way, >>> but it works! >> >> To my understanding, but I might be wrong, by doing this you are >> implicitly considering the whole signal as just one period of its >> periodic extension. >> > > Absolutely, but that's one hell of a complex periodic waveform is it not ? > Certainly one who's phase relationship between frequencies doesn't remain > static, so in that sense, there must be 'time' information encoded in the > relationship between phase bins ? > > I came across this paper a while ago on the subject of decorrelation. The > basic idea from what i remember is to filter a signal with an FIR who's IR > is generated from a inverse FFT of a unity-gain, random-phase data set. > The effect is apparently good at improving stereo imaging because the L&R > signals no longer contain any common information and the Haas effect is > greatly reduced, so the brain is more able to distinguish from the two > sound sources. > > I'd be interested to hear what other people think of this technique, I > haven't got round to trying this out properly yet & running some audio > through it. > > Regards > Rob > -- > 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 tothl at inf.u-szeged.hu Thu May 14 17:00:57 2009 From: tothl at inf.u-szeged.hu (Laszlo Toth) Date: Thu May 14 17:01:10 2009 Subject: [music-dsp] time representation in the frequency domain In-Reply-To: <898dd7270905141205t71c9823dle985863a70850716@mail.gmail.com> References: <4A0BF4A8.70909@gmx.de> <007001c9d4a6$e49046d0$0201a8c0@LuboPC> <4A0C5601.4030009@gmx.de> <898dd7270905141205t71c9823dle985863a70850716@mail.gmail.com> Message-ID: On Thu, 14 May 2009, Michael Gogins wrote: > Suppose that you record a click, a Dirac delta, at a specific time, > with silence coming before and after. > You then take the discrete Fourier transform of this time-domain > signal. You end up with a frequency-domain signal in which the phases > and amplitudes of the components completely encode the time of the > click It's only the phases. The amplitudes are shift-invariant, so they are imdependent of the position of the impulse. Laszlo Toth Hungarian Academy of Sciences * Research Group on Artificial Intelligence * "Failure only begins e-mail: tothl@inf.u-szeged.hu * when you stop trying" http://www.inf.u-szeged.hu/~tothl * From neolit123 at gmail.com Thu May 14 23:40:16 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Thu May 14 23:41:44 2009 Subject: [music-dsp] time representation in the frequency domain References: <4A0BF4A8.70909@gmx.de> <007001c9d4a6$e49046d0$0201a8c0@LuboPC><4A0C5601.4030009@gmx.de> <50688.84.48.215.7.1242328611.squirrel@webmail.sysedata.no> Message-ID: <00e601c9d50e$ea5d20c0$0201a8c0@LuboPC> Henrik Sundt wrote: >I can recommend the program "Mammut" for experimenting with audio > transformations based on a huge FFT. It is available for Mac, PC and > Linux, both a runnable application (binary) and source code. > > You can find it here: > http://archive.notam02.no/arkiv/doc/mammut/ > Also, a paper explaining the techniques, by ?yvind Hammer and myself: > "Musical applications of decomposition with global support" > http://tinyurl.com/notam-mammut-pdf > There is also another project called HyperMammut by Nasca Octavian Paul: > http://sourceforge.net/projects/hypermammut I'm familliar with Nasca Octavian Paul's "PaulStretch" - probably on of the best hyper-stretch algorithms around. Congratulations on the on the program & paper. @ Jan - ^^^^ Is this is what you need ? If someone is intereseted in the analysis of nonlinear time series, here is a paper on the the Hilbert-Huang transform: http://www.physionet.org/events/hrv-2006/huang.pdf HHT opens a whole new perspective on signal anylisis and experiments. I must say though that the algorythms in the "Mammut" programs and ARSS pretty much prove the FFT not obsolete... Lubomir From richarddobson at blueyonder.co.uk Fri May 15 04:47:28 2009 From: richarddobson at blueyonder.co.uk (Richard Dobson) Date: Fri May 15 04:49:04 2009 Subject: [music-dsp] time representation in the frequency domain In-Reply-To: References: <4A0BF4A8.70909@gmx.de> <007001c9d4a6$e49046d0$0201a8c0@LuboPC> <4A0C5601.4030009@gmx.de> <898dd7270905141205t71c9823dle985863a70850716@mail.gmail.com> Message-ID: <4A0D2C20.7030905@blueyonder.co.uk> Laszlo Toth wrote: > On Thu, 14 May 2009, Michael Gogins wrote: > >> Suppose that you record a click, a Dirac delta, at a specific time, >> with silence coming before and after. >> You then take the discrete Fourier transform of this time-domain >> signal. You end up with a frequency-domain signal in which the phases >> and amplitudes of the components completely encode the time of the >> click > > It's only the phases. The amplitudes are shift-invariant, so they are > imdependent of the position of the impulse. > Perhaps the simplest way of looking at this is to see the time aspect as effectively encrypted into the FFT. All the information is there, and can be recovered exactly by an inverse FFT in the absence of any alteration; but ~discovering~ that information from the FFT output in a deterministic and meaningful way may be at least as hard as decrypting very large numbers composed of primes, without a key. Much more effort, probably, than simply doing the inverse FFT. Richard Dobson From o at iki.fi Fri May 15 05:27:45 2009 From: o at iki.fi (Olli Niemitalo) Date: Fri May 15 05:27:54 2009 Subject: [music-dsp] time representation in the frequency domain In-Reply-To: <4A0D2C20.7030905@blueyonder.co.uk> References: <4A0BF4A8.70909@gmx.de> <007001c9d4a6$e49046d0$0201a8c0@LuboPC> <4A0C5601.4030009@gmx.de> <898dd7270905141205t71c9823dle985863a70850716@mail.gmail.com> <4A0D2C20.7030905@blueyonder.co.uk> Message-ID: <1376b5730905150227i65ba9fc3i42b3800db3296679@mail.gmail.com> One example that demonstrates that phase will not always tell all is when you have a time-domain signal that is symmetrical around time zero. The phase in the frequency domain will be zero or 180 degrees for all frequencies. Imagine that you have a long recording of whatever audio, and then append to it a time-reversed copy of it. This will effectively move most of the information contained in the phase to the amplitude. On the other hand, if you have a time-domain signal where the energy at each frequency is sharply centered at no more than one point in time, then those time points will be well described by the group delay, which can be calculated from phase. -olli On Fri, May 15, 2009 at 11:47 AM, Richard Dobson wrote: > Laszlo Toth wrote: >> >> On Thu, 14 May 2009, Michael Gogins wrote: >> >>> Suppose that you record a click, a Dirac delta, at a specific time, >>> with silence coming before and after. >>> You then take the discrete Fourier transform of this time-domain >>> signal. You end up with a frequency-domain signal in which the phases >>> and amplitudes of the components completely encode the time of the >>> click >> >> It's only the phases. The amplitudes are shift-invariant, so they are >> imdependent of the position of the impulse. >> > > Perhaps the simplest way of looking at this is to see the time aspect as > effectively encrypted into the FFT. All the information is there, and can be > recovered exactly by an inverse FFT in the absence of any alteration; but > ~discovering~ that information from the FFT output in a deterministic and > meaningful way may be at least as hard as decrypting very large numbers > composed of primes, without a key. Much more effort, probably, than simply > doing the inverse FFT. > > > Richard Dobson > > -- > 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 tothl at inf.u-szeged.hu Fri May 15 05:49:56 2009 From: tothl at inf.u-szeged.hu (Laszlo Toth) Date: Fri May 15 05:50:07 2009 Subject: [music-dsp] time representation in the frequency domain In-Reply-To: <1376b5730905150227i65ba9fc3i42b3800db3296679@mail.gmail.com> References: <4A0BF4A8.70909@gmx.de> <007001c9d4a6$e49046d0$0201a8c0@LuboPC> <4A0C5601.4030009@gmx.de> <898dd7270905141205t71c9823dle985863a70850716@mail.gmail.com> <4A0D2C20.7030905@blueyonder.co.uk> <1376b5730905150227i65ba9fc3i42b3800db3296679@mail.gmail.com> Message-ID: On Fri, 15 May 2009, Olli Niemitalo wrote: > One example that demonstrates that phase will not always tell all is > when you have a time-domain signal that is symmetrical around time > zero. As I already said, the original question was simply not precisely formed. It talked about "time information" without defining what it would mean. I interpreted "time information" as the position of a signal (e.g., consider an impulse), and referred to the Fourier transform property that says that if the transform of h(t) is H(f), that the transform of h(t-T) is H(f)*e^-j2pifT. Which means that by shifting the signal the amplitudes won't change, so the information regarding T is coded only in the phase. You are talking about more complicated signal manipulations, like reversing and concatenating signals, where the amplutide may change as well. Again, as we don't exactly know what the original question was about, both our answers may be correct :) Laszlo Toth Hungarian Academy of Sciences * Research Group on Artificial Intelligence * "Failure only begins e-mail: tothl@inf.u-szeged.hu * when you stop trying" http://www.inf.u-szeged.hu/~tothl * From raga.raga at gmx.de Fri May 15 05:58:23 2009 From: raga.raga at gmx.de (Jan Baumgart) Date: Fri May 15 05:58:35 2009 Subject: [music-dsp] time representation in the frequency domain In-Reply-To: <00e601c9d50e$ea5d20c0$0201a8c0@LuboPC> References: <4A0BF4A8.70909@gmx.de> <007001c9d4a6$e49046d0$0201a8c0@LuboPC><4A0C5601.4030009@gmx.de> <50688.84.48.215.7.1242328611.squirrel@webmail.sysedata.no> <00e601c9d50e$ea5d20c0$0201a8c0@LuboPC> Message-ID: <4A0D3CBF.6000203@gmx.de> First of all, thank you all for your answers and perspectives. Seems like the music-dsp is coming back to life again :) I pretty much assumed, that there wouldn't be a straight-forward "decryption" algorithm. Maybe this is like looking for frequency information in the Amplitude of single Samples in the time domain.... I already took a look at Mammut some time ago, which is really an amazing app. Unfortunately, it only allows you to manipulate the "phase-spectrum" as a whole. Something like a selection for the bins affected would be nice. Well, the source code's there (thank you Henrik!!)... so maybe I will try some hacking there... Nasca Paul's Paulstretch sounds really good. I had a look at the code and the algorithm used seems to be quite simple: He's feeding a (huge) FFT with the input signal (sort of like a ring buffer, I suppose...not quite sure), applies a window-envelope, replaces the phases with random values (!) and takes the inverse transform. that's it! I've already started porting the fftw-lib to max/msp for large windows and non-realtime processing but it's not working yet... Will have a look at the papers mentioned and inform the list, if I come up with something useful or interesting... cheers and happy dsping! jan. Lubomir I. Ivanov wrote: > Henrik Sundt wrote: >> I can recommend the program "Mammut" for experimenting with audio >> transformations based on a huge FFT. It is available for Mac, PC and >> Linux, both a runnable application (binary) and source code. >> >> You can find it here: >> http://archive.notam02.no/arkiv/doc/mammut/ >> Also, a paper explaining the techniques, by ?yvind Hammer and myself: >> "Musical applications of decomposition with global support" >> http://tinyurl.com/notam-mammut-pdf >> There is also another project called HyperMammut by Nasca Octavian Paul: >> http://sourceforge.net/projects/hypermammut > > I'm familliar with Nasca Octavian Paul's "PaulStretch" - probably on of the > best hyper-stretch algorithms around. > Congratulations on the on the program & paper. > > @ Jan - ^^^^ Is this is what you need ? > > If someone is intereseted in the analysis of nonlinear time series, here is > a paper on the the Hilbert-Huang transform: > http://www.physionet.org/events/hrv-2006/huang.pdf > HHT opens a whole new perspective on signal anylisis and experiments. > I must say though that the algorythms in the "Mammut" programs and ARSS > pretty much prove the FFT not obsolete... > > Lubomir > > -- > 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 raga.raga at gmx.de Fri May 15 06:16:31 2009 From: raga.raga at gmx.de (Jan Baumgart) Date: Fri May 15 06:16:41 2009 Subject: [music-dsp] time representation in the frequency domain In-Reply-To: References: <4A0BF4A8.70909@gmx.de> <007001c9d4a6$e49046d0$0201a8c0@LuboPC> <4A0C5601.4030009@gmx.de> <898dd7270905141205t71c9823dle985863a70850716@mail.gmail.com> <4A0D2C20.7030905@blueyonder.co.uk> <1376b5730905150227i65ba9fc3i42b3800db3296679@mail.gmail.com> Message-ID: <4A0D40FF.7070105@gmx.de> I must admit, that while your answers came rushing in, I realized that I'm not sure, what I mean with "time information" myself... As you suggested, I had something in mind like "time offset". For example of a single sine burst (maybe this is an easier example than an impulse). This could be expressed as a single number (in seconds) relating to a specific frequency. But what if there are more than one bursts (of the same frequency) ? Well, I guess I'll just start to experiment by trial and error, when I've programmed an appropriate tool. I think the mathematics involved will exceed my skills by far... Laszlo Toth wrote: > On Fri, 15 May 2009, Olli Niemitalo wrote: > >> One example that demonstrates that phase will not always tell all is >> when you have a time-domain signal that is symmetrical around time >> zero. > > As I already said, the original question was simply not precisely formed. > It talked about "time information" without defining what it would mean. > I interpreted "time information" as the position of a signal (e.g., > consider an impulse), and referred to the Fourier transform property that > says that if the transform of h(t) is H(f), that the transform of h(t-T) > is H(f)*e^-j2pifT. Which means that by shifting the signal the amplitudes > won't change, so the information regarding T is coded only in the phase. > You are talking about more complicated signal manipulations, like > reversing and concatenating signals, where the amplutide may change as > well. Again, as we don't exactly know what the original question was > about, both our answers may be correct :) > > Laszlo Toth > Hungarian Academy of Sciences * > Research Group on Artificial Intelligence * "Failure only begins > e-mail: tothl@inf.u-szeged.hu * when you stop trying" > http://www.inf.u-szeged.hu/~tothl * > > -- > 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 tothl at inf.u-szeged.hu Fri May 15 06:30:09 2009 From: tothl at inf.u-szeged.hu (Laszlo Toth) Date: Fri May 15 06:31:48 2009 Subject: [music-dsp] time representation in the frequency domain In-Reply-To: <4A0D40FF.7070105@gmx.de> References: <4A0BF4A8.70909@gmx.de> <007001c9d4a6$e49046d0$0201a8c0@LuboPC> <4A0C5601.4030009@gmx.de> <898dd7270905141205t71c9823dle985863a70850716@mail.gmail.com> <4A0D2C20.7030905@blueyonder.co.uk> <1376b5730905150227i65ba9fc3i42b3800db3296679@mail.gmail.com> <4A0D40FF.7070105@gmx.de> Message-ID: On Fri, 15 May 2009, Jan Baumgart wrote: > As you suggested, I had something in mind like "time offset". That's why I thought that the shifting property of the Fourier transform may answer your question (at least partially). > For example of a single sine burst (maybe this is an easier example than > an impulse). An impulse is much easier, because its transform is simply a constant at every frequencies . Also, interpreting "time offset" is very intuitive in the case of an impulse. > But what if there are more than one bursts (of the same frequency)? Another important property of the Fourier transform is linearity, that is, the transform of the sum of two signals will be the sum of the individual transforms. Laszlo Toth Hungarian Academy of Sciences * Research Group on Artificial Intelligence * "Failure only begins e-mail: tothl@inf.u-szeged.hu * when you stop trying" http://www.inf.u-szeged.hu/~tothl * From douglas at music.columbia.edu Fri May 15 07:00:01 2009 From: douglas at music.columbia.edu (douglas repetto) Date: Fri May 15 07:00:07 2009 Subject: [music-dsp] [admin] music-dsp FAQ Message-ID: <20090515110001.4CD237FA8B4@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 douglas at music.columbia.edu Fri May 15 10:20:15 2009 From: douglas at music.columbia.edu (douglas repetto) Date: Fri May 15 10:20:48 2009 Subject: [music-dsp] time representation in the frequency domain In-Reply-To: <4A0D3CBF.6000203@gmx.de> References: <4A0BF4A8.70909@gmx.de> <007001c9d4a6$e49046d0$0201a8c0@LuboPC><4A0C5601.4030009@gmx.de> <50688.84.48.215.7.1242328611.squirrel@webmail.sysedata.no> <00e601c9d50e$ea5d20c0$0201a8c0@LuboPC> <4A0D3CBF.6000203@gmx.de> Message-ID: <4A0D7A1F.1050707@music.columbia.edu> Jan Baumgart wrote: > I already took a look at Mammut some time ago, which is really an > amazing app. Unfortunately, > it only allows you to manipulate the "phase-spectrum" as a whole. > Something like a selection > for the bins affected would be nice. Well, the source code's there > (thank you Henrik!!)... > so maybe I will try some hacking there... You might be interested in SPEAR, which uses MQ analysis and a sine bank for resynthesis: http://www.klingbeil.com/spear/ douglas -- ............................................... http://artbots.org .....douglas.....irving........................ http://dorkbot.org .......................... http://music.columbia.edu/cmc/music-dsp .......... repetto............. http://music.columbia.edu/organism ........................................ http://douglasrepetto.org From gsn10 at hotmail.com Fri May 15 12:18:00 2009 From: gsn10 at hotmail.com (Scott Nordlund) Date: Fri May 15 12:18:19 2009 Subject: [music-dsp] time representation in the frequency domain In-Reply-To: <4A0D40FF.7070105@gmx.de> References: <4A0BF4A8.70909@gmx.de> <007001c9d4a6$e49046d0$0201a8c0@LuboPC> <4A0C5601.4030009@gmx.de> <898dd7270905141205t71c9823dle985863a70850716@mail.gmail.com> <4A0D2C20.7030905@blueyonder.co.uk> <1376b5730905150227i65ba9fc3i42b3800db3296679@mail.gmail.com> <4A0D40FF.7070105@gmx.de> Message-ID: The funny thing is that a sine burst contains much more than just the frequency of the sinusoid, even if it's properly windowed. If these seemingly spurious components are removed, it becomes an infinite duration sine, not a burst. So the frequency portion of the FFT also contains information that you would ordinarily associate with "time". ---------------------------------------- > Date: Fri, 15 May 2009 12:16:31 +0200 > From: raga.raga@gmx.de > To: music-dsp@music.columbia.edu > Subject: Re: [music-dsp] time representation in the frequency domain > > I must admit, that while your answers came rushing in, I realized > that I'm not sure, what I mean with "time information" myself... > As you suggested, I had something in mind like "time offset". > For example of a single sine burst (maybe this is an easier example than > an impulse). This could be expressed as a single number (in seconds) > relating > to a specific frequency. > But what if there are more than one bursts (of the same frequency) ? > > Well, I guess I'll just start to experiment by trial and error, when > I've programmed > an appropriate tool. I think the mathematics involved will exceed my skills > by far... > > > Laszlo Toth wrote: >> On Fri, 15 May 2009, Olli Niemitalo wrote: >> >>> One example that demonstrates that phase will not always tell all is >>> when you have a time-domain signal that is symmetrical around time >>> zero. >> >> As I already said, the original question was simply not precisely formed. >> It talked about "time information" without defining what it would mean. >> I interpreted "time information" as the position of a signal (e.g., >> consider an impulse), and referred to the Fourier transform property that >> says that if the transform of h(t) is H(f), that the transform of h(t-T) >> is H(f)*e^-j2pifT. Which means that by shifting the signal the amplitudes >> won't change, so the information regarding T is coded only in the phase. >> You are talking about more complicated signal manipulations, like >> reversing and concatenating signals, where the amplutide may change as >> well. Again, as we don't exactly know what the original question was >> about, both our answers may be correct :) >> >> Laszlo Toth >> Hungarian Academy of Sciences * >> Research Group on Artificial Intelligence * "Failure only begins >> e-mail: tothl@inf.u-szeged.hu * when you stop trying" >> http://www.inf.u-szeged.hu/~tothl * >> >> -- >> 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 _________________________________________________________________ Hotmail? has a new way to see what's up with your friends. http://windowslive.com/Tutorial/Hotmail/WhatsNew?ocid=TXT_TAGLM_WL_HM_Tutorial_WhatsNew1_052009 From martin.eisenberg at udo.edu Sun May 17 15:18:02 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Sun May 17 15:15:43 2009 Subject: [music-dsp] Blurps and Chirps when changing filter parameters References: <108217.42179.qm@web58206.mail.re3.yahoo.com><002501c9ce72$d1fecc60$0201a8c0@mooncode><27C0FB3B66874FAF9C5CEE8D2EC90911@nibln01077><005d01c9cf37$3c40cb40$0201a8c0@mooncode><006401c9d009$682f8e80$0201a8c0@mooncode> <437852DE9038454CBF3CF4FAA959BECD@nibln01077> Message-ID: <000701c9d724$36c45200$0201a8c0@mooncode> From: "Vadim Zavalishin" > >> (again I don't know where this method was described first). > > > > I believe that would be their ref. 4 (Borin et al. 2000) which > > introduced the K-method. > I don't have access to that article, so unfortunately I cannot > check that. I found another paper on a similar subject where > one of the authors was the same in DAFX'04 proceedings > (p.113), which is again on a subject of eliminating delay-free > loops. Ah yes, it seems the main difference is more structure in the matrices in the newer paper. But it has occurred to me that you perhaps meant the method of discretizing each integrator in an analog structure by itself. Borin et al. 2000 doesn't allude to that, and I'd be interested in any references you know of. > Anyway, when I was referring to Serafini/Zamboni paper, the > main thing I meant was that you can apply the bilinear > transform directly to the differential equations, which > eliminates the delay-free loops implicitly. The BLT (trapezoidal rule) is an implicit integration scheme in contrast to explicit methods like backward Euler, so it actually preserves the analog model's instantaneous transmission and you end up with the need for a numerical solver -- or in the scalar linear case, the traditional structure-changing step of putting the transfer function back on a single fraction line after substituting for s. Martin From jos at ccrma.stanford.edu Sun May 17 17:18:18 2009 From: jos at ccrma.stanford.edu (Julius Smith) Date: Sun May 17 17:19:06 2009 Subject: [music-dsp] Blurps and Chirps when changing filter parameters In-Reply-To: <000701c9d724$36c45200$0201a8c0@mooncode> References: <108217.42179.qm@web58206.mail.re3.yahoo.com> <002501c9ce72$d1fecc60$0201a8c0@mooncode> <27C0FB3B66874FAF9C5CEE8D2EC90911@nibln01077> <005d01c9cf37$3c40cb40$0201a8c0@mooncode> <006401c9d009$682f8e80$0201a8c0@mooncode> <437852DE9038454CBF3CF4FAA959BECD@nibln01077> <000701c9d724$36c45200$0201a8c0@mooncode> Message-ID: <200905172118.n4HLIjJV009562@feta.cc.columbia.edu> At 12:18 PM 5/17/2009, Martin Eisenberg wrote: >.... But it has occurred to me that you >perhaps meant the method of discretizing each integrator in an >analog structure by itself. Borin et al. 2000 doesn't allude to >that, and I'd be interested in any references you know of. I believe this goes back at least to Hal Chamberlin (Music Applications of Microprocessors). My understanding of the "Chamberlin form" biquad is digitizing the 2nd-order state-variable analog filter by replacing each integrator by 1/(1-1/z) and then, to break the delay-free loop, moving the output of the first integrator to be after its delay (thus making that one (1/z)/(1-1/z)). A Google search on "chamberlin form filter" yields some representative info. According to the paper by Duane Wise, Zolzer attributes the Chamberlin form to Kingsbury. State-variable analog filters themselves go way back to the analog computer days (at least). - jos Julius O. Smith III Prof. of Music and Assoc. Prof. (by courtesy) of Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ From rbj at audioimagination.com Sun May 17 22:15:43 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sun May 17 22:16:01 2009 Subject: [music-dsp] Blurps and Chirps when changing filter parameters Message-ID: <20090518021543.778B85480D3@ws6-6.us4.outblaze.com> > ----- Original Message ----- > From: "Julius Smith" > To: "A discussion list for music-related DSP" > Subject: Re: [music-dsp] Blurps and Chirps when changing filter parameters > Date: Sun, 17 May 2009 14:18:18 -0700 > > > At 12:18 PM 5/17/2009, Martin Eisenberg wrote: > > .... But it has occurred to me that you > > perhaps meant the method of discretizing each integrator in an > > analog structure by itself. Borin et al. 2000 doesn't allude to > > that, and I'd be interested in any references you know of. > > I believe this goes back at least to Hal Chamberlin (Music Applications of > Microprocessors). My understanding of the "Chamberlin form" biquad is > digitizing the 2nd-order state-variable analog filter by replacing each > integrator by 1/(1-1/z) and then, to break the delay-free loop, moving the > output of the first integrator to be after its delay (thus making that one > (1/z)/(1-1/z)). > > A Google search on "chamberlin form filter" yields some representative info. > According to the paper by Duane Wise, Zolzer attributes the Chamberlin form > to Kingsbury. i didn't know that (i don't always read stuff carefully). that's interesting information. although the "Musical Apps..." book is gratifying, most of the theoretical content i knew came from somewhere else (like the linear congruence RN method) but the book showed exactly how to code a 6502 or BASIC program to do something. the one thing i had always previous thought was seminal was the Chamberlin State-Variable Filter. one reason was because of the derivation of the warping of the resonant frequency with z/(z-1) as the element instead of 1/s. Julius (or Duane, if you're listening in), if you've seen the Kingsbury paper (i wouldn't mind a reference), does he do the same thing regarding compensating the resonant frequency coefficient? > State-variable analog filters themselves go way back to the analog computer > days (at least). i think, almost by definition. Julius, one thing we may both have gotten to do in the 70's is dink around with an analog computer that was on a board and had little processing blocks (including non-linear things like exp or log-amps or multipliers as well as linear gain and filter blocks). in a sense, a patch-board Moog was something like that (but the analog computers that were donated to the EE department from the Air Force did not have little 4 octave monophonic keyboards with a portamento knob on it). -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From vadim.zavalishin at native-instruments.de Mon May 18 06:16:26 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Mon May 18 06:16:34 2009 Subject: [music-dsp] Blurps and Chirps when changing filter parameters In-Reply-To: <200905172118.n4HLIjJV009562@feta.cc.columbia.edu> References: <108217.42179.qm@web58206.mail.re3.yahoo.com><002501c9ce72$d1fecc60$0201a8c0@mooncode><27C0FB3B66874FAF9C5CEE8D2EC90911@nibln01077><005d01c9cf37$3c40cb40$0201a8c0@mooncode><006401c9d009$682f8e80$0201a8c0@mooncode><437852DE9038454CBF3CF4FAA959BECD@nibln01077><000701c9d724$36c45200$0201a8c0@mooncode> <200905172118.n4HLIjJV009562@feta.cc.columbia.edu> Message-ID: Julius Smith wrote: > I believe this goes back at least to Hal Chamberlin (Music Applications of > Microprocessors). My understanding of the "Chamberlin form" biquad is > digitizing the 2nd-order state-variable analog filter by replacing each > integrator by 1/(1-1/z) and then, to break the delay-free loop, moving the > output of the first integrator to be after its delay (thus making that one > (1/z)/(1-1/z)). If I'm correct guessing what the Chamberlin form is, then my intuitive understanding would be that it's simply using a sort-of Euler method approach to solving a set of differential equations: bp'=w*(x-lp-D*bp) lp'=w*bp However I don't know whether this was his specific approach in creating that form. Martin Eisenberg wrote: > The BLT (trapezoidal rule) is an implicit integration scheme in > contrast to explicit methods like backward Euler, so it actually I'm not sure what you mean by implicit here. If you use it to substitute for s, then yes, but you still can apply it explicitly, as Serafini/Zamboni do (or as it happens in integrator substitution). Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From rbj at audioimagination.com Mon May 18 10:21:17 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Mon May 18 10:21:33 2009 Subject: [music-dsp] Blurps and Chirps when changing filter parameters Message-ID: <20090518142117.BD0A89ECC1@ws6-2.us4.outblaze.com> > ----- Original Message ----- > From: "Vadim Zavalishin" > To: "A discussion list for music-related DSP" > Subject: Re: [music-dsp] Blurps and Chirps when changing filter parameters > Date: Mon, 18 May 2009 12:16:26 +0200 > > > Julius Smith wrote: > > I believe this goes back at least to Hal Chamberlin (Music Applications of > > Microprocessors). My understanding of the "Chamberlin form" biquad is > > digitizing the 2nd-order state-variable analog filter by replacing each > > integrator by 1/(1-1/z) and then, to break the delay-free loop, moving the > > output of the first integrator to be after its delay (thus making that one > > (1/z)/(1-1/z)). > > If I'm correct guessing what the Chamberlin form is, no need to guess. if you don't have the book (many of us do not), an explicit diagram of it is at http://www.earlevel.com/Digital%20Audio/StateVar.html . > then my intuitive understanding would be that it's simply using a sort-of > Euler method approach to solving a set of differential equations: > > bp'=w*(x-lp-D*bp) > lp'=w*bp > > However I don't know whether this was his specific approach in creating that > form. i think it was the concept of taking an analog state variable filter, substituting z/(z-1) in for 1/s, fixing that delay-free loop by moving a tap, and explicitly solving for the transfer function and noting that sin() function in the resonant frequency coefficient. i've met Hal, in fact worked under him for a year sorta recently (and got him to sign my old copy of the book). i think it is in the *time* (the 70's) that he developed this for musical application that was noteworthy. and that it is still a useful architecture. other than that, i don't think it's anything more special than that. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From vadim.zavalishin at native-instruments.de Mon May 18 10:35:45 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Mon May 18 10:35:57 2009 Subject: [music-dsp] Blurps and Chirps when changing filter parameters In-Reply-To: <20090518142117.BD0A89ECC1@ws6-2.us4.outblaze.com> References: <20090518142117.BD0A89ECC1@ws6-2.us4.outblaze.com> Message-ID: >> If I'm correct guessing what the Chamberlin form is, > > no need to guess. if you don't have the book (many of us do not), > an explicit diagram of it is at > http://www.earlevel.com/Digital%20Audio/StateVar.html . Thanks for the link. So my guess was correct :-) Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From martin.eisenberg at udo.edu Mon May 18 11:54:40 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Mon May 18 11:52:26 2009 Subject: [music-dsp] Blurps and Chirps when changing filter parameters References: <108217.42179.qm@web58206.mail.re3.yahoo.com><002501c9ce72$d1fecc60$0201a8c0@mooncode><27C0FB3B66874FAF9C5CEE8D2EC90911@nibln01077><005d01c9cf37$3c40cb40$0201a8c0@mooncode><006401c9d009$682f8e80$0201a8c0@mooncode><437852DE9038454CBF3CF4FAA959BECD@nibln01077><000701c9d724$36c45200$0201a8c0@mooncode><200905172118.n4HLIjJV009562@feta.cc.columbia.edu> Message-ID: <002101c9d7d0$f7b6ede0$0201a8c0@mooncode> From: "Vadim Zavalishin" > Martin Eisenberg wrote: > > The BLT (trapezoidal rule) is an implicit integration > > scheme in contrast to explicit methods like backward > > Euler, so it actually [restoring context] > > preserves the analog model's > > instantaneous transmission > I'm not sure what you mean by implicit here. It's numerical analysis jargon. An implicit ODE discretization scheme is one that uses the solution value at the latest timestep both in approximating the differential and in the right-hand side function. Example for y' = f(x,y,t): - Backward Euler (explicit) (y[n]-y[n-1])/T = f(x[n-1], y[n-1], (n-1)*T); - Forward Euler (implicit) (y[n]-y[n-1])/T = f(x[n], y[n], n*T). > If you use it to substitute for s, then yes, but you still can > apply it explicitly, as Serafini/Zamboni do (or as it happens > in integrator substitution). Which does leave one with the output implicitly defined, hence your application of Harma's feed-zero-and-update trick, no? That's what I was pointing out -- the BLT doesn't eliminate loops. Martin From martin.eisenberg at udo.edu Mon May 18 11:55:13 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Mon May 18 11:53:16 2009 Subject: [music-dsp] Name of delay-free loop technique Message-ID: <002401c9d7d1$0aee5ce0$0201a8c0@mooncode> In another thread we've been discussing the method of resolving a delay-free feedback connection of linear elements that first computes the value on the flowgraph loop from inputs, filter state values, and direct-path coefficients, and then updates all states using that (http://www.acoustics.hut.fi/~aqi/papers/icassp98.ps.gz). I think that technique could do with a crisp name. What do you folks think about "deferred state update"? Other takers? Martin From martin.eisenberg at udo.edu Mon May 18 11:57:03 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Mon May 18 11:54:46 2009 Subject: [music-dsp] Blurps and Chirps when changing filter parameters References: <108217.42179.qm@web58206.mail.re3.yahoo.com><002501c9ce72$d1fecc60$0201a8c0@mooncode><27C0FB3B66874FAF9C5CEE8D2EC90911@nibln01077><005d01c9cf37$3c40cb40$0201a8c0@mooncode><006401c9d009$682f8e80$0201a8c0@mooncode><437852DE9038454CBF3CF4FAA959BECD@nibln01077><000701c9d724$36c45200$0201a8c0@mooncode> <200905172118.n4HLIjJV009562@feta.cc.columbia.edu> Message-ID: <002c01c9d7d1$4ce543c0$0201a8c0@mooncode> From: "Julius Smith" > At 12:18 PM 5/17/2009, Martin Eisenberg wrote: > >discretizing each integrator in an analog structure by itself. > I believe this goes back at least to Hal Chamberlin (Music > Applications of Microprocessors). Thanks Julius! Martin From lukas at lukaweb.com Mon May 18 12:44:16 2009 From: lukas at lukaweb.com (Lukas Kaser) Date: Mon May 18 12:44:35 2009 Subject: [music-dsp] Which Signal Processing Device? Message-ID: <4a119060.139.2522.376729592@webmaildh4.aruba.it> Dear List, for a "very realtime" audio processing application we're looking for a suitable platform with the following specs: - freely programmable in C(++); ideally GNU C, minimum: development environment with C compiler - analog line in/out (at least 1 in and out) - possibility of realtime control, e.g. through usb, midi, osc... - !!! MAXIMUM TOTAL in-out-latency for audio signal below 2ms !!! Our favorite until now is the http://www.chameleon.synth.net/english/chameleon/. Can anyone suggest another DSP-device or PC/Mac which fulfills these requirements or tell us something about her/experience with the chameleon (availability/stability/development cycle...)? Thank you in advance!!! Yours Sincerely Lukas From jerry at novadsp.com Mon May 18 12:55:16 2009 From: jerry at novadsp.com (Jerry Evans) Date: Mon May 18 12:56:27 2009 Subject: [music-dsp] Which Signal Processing Device? In-Reply-To: <4a119060.139.2522.376729592@webmaildh4.aruba.it> References: <4a119060.139.2522.376729592@webmaildh4.aruba.it> Message-ID: <4A1192F4.9050504@NovaDSP.com> hmm. how much do you want to spend? and what do you want to do with it? 2ms is completely achievable on standard PC hardware with the right audio device(s) and OS. The chameleon already looks like legacy hardware to me ... ATB Jerry Lukas Kaser wrote: > Dear List, > > for a "very realtime" audio processing application we're > looking for a > suitable platform with the following specs: > > - freely programmable in C(++); ideally GNU C, minimum: > development environment with C compiler > - analog line in/out (at least 1 in and out) > - possibility of realtime control, e.g. through usb, midi, > osc... > - !!! MAXIMUM TOTAL in-out-latency for audio signal below > 2ms !!! > > Our favorite until now is the > http://www.chameleon.synth.net/english/chameleon/. > > Can anyone suggest another DSP-device or PC/Mac which > fulfills these requirements or tell us something about > her/experience with the chameleon > (availability/stability/development cycle...)? > > Thank you in advance!!! > > Yours Sincerely > > > > Lukas > > -- > 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 neolit123 at gmail.com Mon May 18 13:52:18 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Mon May 18 13:53:06 2009 Subject: [music-dsp] Name of delay-free loop technique References: <002401c9d7d1$0aee5ce0$0201a8c0@mooncode> Message-ID: <003f01c9d7e1$6a3c25f0$0201a8c0@LuboPC> > In another thread we've been discussing the method of resolving a > delay-free feedback connection of linear elements that first > computes the value on the flowgraph loop from inputs, filter > state values, and direct-path coefficients, and then updates all > states using that > (http://www.acoustics.hut.fi/~aqi/papers/icassp98.ps.gz). > > I think that technique could do with a crisp name. What do you > folks think about "deferred state update"? Other takers? > > > Martin Sounds good. Also - "post computational state update" ? from: "The method introduced in this paper separates the computation of the output of the filter y(n)and updating of the inner states of the filter. .... Once the current value of y(n)is found the inner states of P must be updated." Lubomir From music.maker at gte.net Mon May 18 14:16:49 2009 From: music.maker at gte.net (Scott Gravenhorst) Date: Mon May 18 14:17:19 2009 Subject: [music-dsp] Which Signal Processing Device? Message-ID: <200905181816.n4IIGnYO029685@linux7.lan> I know it's not C or C++, but consider the FPGA, it can be a very powerful and fast DSP device. >Lukas Kaser wrote: >> Dear List, >> >> for a "very realtime" audio processing application we're >> looking for a >> suitable platform with the following specs: >> >> - freely programmable in C(++); ideally GNU C, minimum: >> development environment with C compiler >> - analog line in/out (at least 1 in and out) >> - possibility of realtime control, e.g. through usb, midi, >> osc... >> - !!! MAXIMUM TOTAL in-out-latency for audio signal below >> 2ms !!! >> >> Our favorite until now is the >> http://www.chameleon.synth.net/english/chameleon/. >> >> Can anyone suggest another DSP-device or PC/Mac which >> fulfills these requirements or tell us something about >> her/experience with the chameleon >> (availability/stability/development cycle...)? >> >> Thank you in advance!!! >> >> Yours Sincerely >> >> >> >> Lukas >> >> -- >> 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 -- ScottG ________________________________________________________________________ -- Scott Gravenhorst -- FPGA MIDI Synthesizer Information: home1.gte.net/res0658s/FPGA_synth/ -- FatMan: home1.gte.net/res0658s/fatman/ -- NonFatMan: home1.gte.net/res0658s/electronics/ -- When the going gets tough, the tough use the command line. From martin.eisenberg at udo.edu Mon May 18 15:38:47 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Mon May 18 15:36:24 2009 Subject: [music-dsp] Name of delay-free loop technique References: <002401c9d7d1$0aee5ce0$0201a8c0@mooncode> <003f01c9d7e1$6a3c25f0$0201a8c0@LuboPC> Message-ID: <000901c9d7f0$46ee1220$0201a8c0@mooncode> From: "Lubomir I. Ivanov" > > (http://www.acoustics.hut.fi/~aqi/papers/icassp98.ps.gz). > > > > I think that technique could do with a crisp name. What do you > > folks think about "deferred state update"? Other takers? > Sounds good. > Also - "post computational state update" ? Thanks for playing :) That's already getting longer than I had envisioned though; and it's not really accurate either, as for instance with the DF2-transposed *all* computation happens in the update phase! Martin From martin.eisenberg at udo.edu Mon May 18 15:43:57 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Mon May 18 15:41:37 2009 Subject: [music-dsp] Name of delay-free loop technique References: <002401c9d7d1$0aee5ce0$0201a8c0@mooncode><003f01c9d7e1$6a3c25f0$0201a8c0@LuboPC> <000901c9d7f0$46ee1220$0201a8c0@mooncode> Message-ID: <000501c9d7f0$ff8997a0$0201a8c0@mooncode> ...all computation except the output solving of course. Martin From neolit123 at gmail.com Mon May 18 16:18:30 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Mon May 18 16:19:03 2009 Subject: [music-dsp] Name of delay-free loop technique References: <002401c9d7d1$0aee5ce0$0201a8c0@mooncode><003f01c9d7e1$6a3c25f0$0201a8c0@LuboPC> <000901c9d7f0$46ee1220$0201a8c0@mooncode> Message-ID: <00c701c9d7f5$d2950270$0201a8c0@LuboPC> > Thanks for playing :) That's already getting longer than I had > envisioned though; and it's not really accurate either, as for > instance with the DF2-transposed *all* computation happens in the > update phase! > > > Martin Hmm yes..:) "deferred state update" is ok. But a bit difficult to sum this method with a few words, while retaining sufficient descriptivity. Lubomir From earlevel at earlevel.com Mon May 18 17:44:14 2009 From: earlevel at earlevel.com (Nigel Redmon) Date: Mon May 18 17:44:35 2009 Subject: [music-dsp] Which Signal Processing Device? In-Reply-To: <4a119060.139.2522.376729592@webmaildh4.aruba.it> References: <4a119060.139.2522.376729592@webmaildh4.aruba.it> Message-ID: Seems a Mac mini would not be a bad choice--maybe with some MIDI knobs for control (if you're going to use a MIDI keyboard, lots of inexpensive choices with knobs and sliders built in). I'm sure there are cheaper PC choices, but Core Audio is pretty cool to work with, the development system is free (and GNU compilers). On May 18, 2009, at 9:44 AM, Lukas Kaser wrote: > - freely programmable in C(++); ideally GNU C, minimum: > development environment with C compiler > - analog line in/out (at least 1 in and out) > - possibility of realtime control, e.g. through usb, midi, > osc... > - !!! MAXIMUM TOTAL in-out-latency for audio signal below > 2ms !!! From theandersoncouncil at gmail.com Tue May 19 01:44:25 2009 From: theandersoncouncil at gmail.com (theandersoncouncil@gmail.com) Date: Tue May 19 01:44:46 2009 Subject: [music-dsp] Which Signal Processing Device? In-Reply-To: <4a119060.139.2522.376729592@webmaildh4.aruba.it> References: <4a119060.139.2522.376729592@webmaildh4.aruba.it> Message-ID: Line6 Tonecore? http://line6.com/tcddk/ cheers, -Brian On Mon, May 18, 2009 at 9:44 AM, Lukas Kaser wrote: > Dear List, > > for a "very realtime" audio processing application we're > looking for a > suitable platform with the following specs: > > - freely programmable in C(++); ideally GNU C, minimum: > development environment with C compiler > - analog line in/out (at least 1 in and out) > - possibility of realtime control, e.g. through usb, midi, > osc... > - !!! MAXIMUM TOTAL in-out-latency for audio signal below > 2ms !!! > > Our favorite until now is the > http://www.chameleon.synth.net/english/chameleon/. > > Can anyone suggest another DSP-device or PC/Mac which > fulfills these requirements or tell us something about > her/experience with the chameleon > (availability/stability/development cycle...)? > > Thank you in advance!!! > > Yours Sincerely > > > > Lukas > > -- > 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 nostromo at arkaos.net Tue May 19 04:50:47 2009 From: nostromo at arkaos.net (M-.-n) Date: Tue May 19 04:51:02 2009 Subject: [music-dsp] Which Signal Processing Device? In-Reply-To: Message-ID: <200905190850.n4J8orG6017578@jujube.cc.columbia.edu> I have one and last time I check there was a very very minimal support for C/C++. Actually when they shipped the product it was only ASM. The support of the product is kind of scary (one person doing it on his off work hours) so get ready to scratch your head on your own if you want to dive there. Conceptually it's a great idea tho. But it's very roughly 'packaged' -----Original Message----- From: music-dsp-bounces@music.columbia.edu [mailto:music-dsp-bounces@music.columbia.edu] On Behalf Of theandersoncouncil@gmail.com Sent: mardi 19 mai 2009 7:44 To: A discussion list for music-related DSP Subject: Re: [music-dsp] Which Signal Processing Device? Line6 Tonecore? http://line6.com/tcddk/ cheers, -Brian On Mon, May 18, 2009 at 9:44 AM, Lukas Kaser wrote: > Dear List, > > for a "very realtime" audio processing application we're looking for a > suitable platform with the following specs: > > - freely programmable in C(++); ideally GNU C, minimum: > development environment with C compiler > - analog line in/out (at least 1 in and out) > - possibility of realtime control, e.g. through usb, midi, osc... > - !!! MAXIMUM TOTAL in-out-latency for audio signal below 2ms !!! > > Our favorite until now is the > http://www.chameleon.synth.net/english/chameleon/. > > Can anyone suggest another DSP-device or PC/Mac which fulfills these > requirements or tell us something about her/experience with the > chameleon (availability/stability/development cycle...)? > > Thank you in advance!!! > > Yours Sincerely > > > > Lukas > > -- > 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 dan.stowell at elec.qmul.ac.uk Tue May 19 05:21:47 2009 From: dan.stowell at elec.qmul.ac.uk (Dan Stowell) Date: Tue May 19 05:22:05 2009 Subject: [music-dsp] Which Signal Processing Device? In-Reply-To: <4a119060.139.2522.376729592@webmaildh4.aruba.it> References: <4a119060.139.2522.376729592@webmaildh4.aruba.it> Message-ID: <4A127A2B.6030705@elec.qmul.ac.uk> Hi - According to this paper: http://lad.linuxaudio.org/events/2009_cdm/Friday/07_Grimm/07.pdf (full citation below) ...an Asus Eee PC running a realtime Linux kernel can achieve sub-2ms total latency, depending on the choice of sound card. I'm sure other PCs could achieve similar results with the same OS+soundcard. (BTW you don't specify what sample rate(s) you're working with...) Best Dan @inproceedings{Grimm:2009, Author = {Grimm, G. and Herzke, T. and Hohmann, V.}, Booktitle = {Linux Audio Conference (LAC2009)}, Date-Added = {2009-05-05 09:01:03 +0100}, Date-Modified = {2009-05-05 14:39:57 +0100}, Rating = {5}, Read = {Yes}, Title = {Application of Linux Audio in Hearing Aid Research}, Url = {http://lad.linuxaudio.org/events/2009_cdm/Friday/07_Grimm/07.pdf}, Year = {2009}, Abstract = {Development of algorithms for digital hearing aid processing includes many steps from the first algorithmic idea and implementation up to field tests with hearing impaired patients. Each of these steps has its own requirements towards the development environment. However, a common platform throughout the whole development process is desirable. This paper gives an overview of the application of Linux Audio in the hearing aid algorithm development process. The performance of portable hardware in terms of delay, battery runtime and processing power is investigated. }, } Lukas Kaser wrote: > Dear List, > > for a "very realtime" audio processing application we're > looking for a > suitable platform with the following specs: > > - freely programmable in C(++); ideally GNU C, minimum: > development environment with C compiler > - analog line in/out (at least 1 in and out) > - possibility of realtime control, e.g. through usb, midi, > osc... > - !!! MAXIMUM TOTAL in-out-latency for audio signal below > 2ms !!! > > Our favorite until now is the > http://www.chameleon.synth.net/english/chameleon/. > > Can anyone suggest another DSP-device or PC/Mac which > fulfills these requirements or tell us something about > her/experience with the chameleon > (availability/stability/development cycle...)? > > Thank you in advance!!! > > Yours Sincerely > > > > Lukas > > -- > 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 -- Dan Stowell Centre for Digital Music School of Electronic Engineering and Computer Science Queen Mary, University of London Mile End Road, London E1 4NS http://www.elec.qmul.ac.uk/department/staff/research/dans.htm http://www.mcld.co.uk/ From richarddobson at blueyonder.co.uk Tue May 19 05:21:12 2009 From: richarddobson at blueyonder.co.uk (Richard Dobson) Date: Tue May 19 05:22:50 2009 Subject: [music-dsp] Which Signal Processing Device? In-Reply-To: <200905190850.n4J8orG6017578@jujube.cc.columbia.edu> References: <200905190850.n4J8orG6017578@jujube.cc.columbia.edu> Message-ID: <4A127A08.7000707@blueyonder.co.uk> I suppose what you really needed is a revival of the largely defunct "Extended Csound" running on ADI Sharc chips (a standard implementation used two of them with a 6ch output daughter board, and of course copious MIDI support). That apart, neither C nor C++ fits the architecture of a modern DSP chip very well; to do so at all they will need extensions and stuff (e.g. for fixed-point arithmetic, data v program memory, etc). ADI supplied a version of GCC with their Sharc development kits - it sort of worked (I used it to get a basic phase vocoder running on an EZ-Kit at a low sample rate), but invariably, writing assembler gets much faster results (and is typically essential where memory is limited, as it usually is). A Mini-ITX PC with added MIDI + audio could be a pretty compact solution, albeit at a relatively low clock speed (but silent - no fan). But it is pretty much impossible for a product in the form of a generic DSP system for music to sustain itself long-term (if it is is the only product in the portfolio), as the number of users interested at that level is too low overall. I liked the look of the Chameleon very much, and if they had brought out a multi-channel model with at least two dsps I would have bought one. Richard Dobson M-.-n wrote: > I have one and last time I check there was a very very minimal support for > C/C++. Actually when they shipped the product it was only ASM. The support > of the product is kind of scary (one person doing it on his off work hours) > so get ready to scratch your head on your own if you want to dive there. > > Conceptually it's a great idea tho. But it's very roughly 'packaged' > > From vadim.zavalishin at native-instruments.de Tue May 19 07:10:47 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Tue May 19 07:11:03 2009 Subject: [music-dsp] Name of delay-free loop technique In-Reply-To: <002401c9d7d1$0aee5ce0$0201a8c0@mooncode> References: <002401c9d7d1$0aee5ce0$0201a8c0@mooncode> Message-ID: <56BDCC96E6B94AF5BC7DF68F893A63C1@nibln01077> > In another thread we've been discussing the method of resolving a > delay-free feedback connection of linear elements that first > computes the value on the flowgraph loop from inputs, filter > state values, and direct-path coefficients, and then updates all > states using that > (http://www.acoustics.hut.fi/~aqi/papers/icassp98.ps.gz). > > I think that technique could do with a crisp name. What do you > folks think about "deferred state update"? Other takers? For myself I was referring to this thing as simply "instant feedback". The transformation to an equivalent structure without instant feedback is then referred to as "resolving the instant feedback". Similarly, one can speak about "instantly instable" feedback loops, if they reach infinity within a single sample. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From lukas at lukaweb.com Tue May 19 09:57:16 2009 From: lukas at lukaweb.com (Lukas Kaser) Date: Tue May 19 09:57:44 2009 Subject: [music-dsp] Which Signal Processing Device? Message-ID: <4a12babc.398.2440.582189508@webmaildh6.aruba.it> Hello, thank you for your answers! We have still some questions open: - Did someone run a Linux-Solution with NO drop-outs? In the paper is mentioned that drop-outs has been reported. - Is someone experienced with the Chameleon and what would be an alternative DSP-device? - Which FPGA's run with 2ms max latency? How are the experiences here? Thank you for any further suggestions. Yours Sincerely Lukas Kaser ----- Original Message ----- Da : Dan Stowell A : A discussion list for music-related DSP Oggetto : Re: [music-dsp] Which Signal Processing Device? Data : Tue, 19 May 2009 10:21:47 +0100 > Hi - > > According to this paper: > http://lad.linuxaudio.org/events/2009_cdm/Friday/07_Grimm/07.pdf > (full citation below) > > ..an Asus Eee PC running a realtime Linux kernel can > achieve sub-2ms total latency, depending on the choice of > sound card. I'm sure other PCs could achieve similar > results with the same OS+soundcard. > > (BTW you don't specify what sample rate(s) you're working > with...) > > Best > Dan > > > > > @inproceedings{Grimm:2009, > Author = {Grimm, G. and Herzke, T. and Hohmann, V.}, > Booktitle = {Linux Audio Conference (LAC2009)}, > Date-Added = {2009-05-05 09:01:03 +0100}, > Date-Modified = {2009-05-05 14:39:57 +0100}, > Rating = {5}, > Read = {Yes}, > Title = {Application of Linux Audio in Hearing Aid > Research}, > Url = > {http://lad.linuxaudio.org/events/2009_cdm/Friday/07_Grimm > /07.pdf}, > Year = {2009}, > Abstract = {Development of algorithms for digital > hearing aid processing includes many steps from the first > algorithmic idea and implementation up to field tests > with hearing impaired patients. Each of these steps has > its own requirements towards the development environment. > However, a common platform throughout the whole > development process is desirable. This paper gives an > overview of the application of Linux Audio in the hearing > aid algorithm development process. The performance of > portable hardware in terms of delay, battery runtime and > processing power is investigated. }, > } > > > > Lukas Kaser wrote: > > Dear List, > > > > for a "very realtime" audio processing application we're > > looking for a > > suitable platform with the following specs: > > > > - freely programmable in C(++); ideally GNU C, minimum: > > development environment with C compiler > > - analog line in/out (at least 1 in and out) > > - possibility of realtime control, e.g. through usb, > > midi, osc... > > - !!! MAXIMUM TOTAL in-out-latency for audio signal > > below 2ms !!! > > > > Our favorite until now is the > > http://www.chameleon.synth.net/english/chameleon/. > > > > Can anyone suggest another DSP-device or PC/Mac which > > fulfills these requirements or tell us something about > > her/experience with the chameleon > > (availability/stability/development cycle...)? > > > > Thank you in advance!!! > > > > Yours Sincerely > > > > > > > > Lukas > > > > -- > > 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 > > > -- > Dan Stowell > Centre for Digital Music > School of Electronic Engineering and Computer Science > Queen Mary, University of London > Mile End Road, London E1 4NS > http://www.elec.qmul.ac.uk/department/staff/research/dans.htm > http://www.mcld.co.uk/ > -- > 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 andrew.capon at zen.co.uk Tue May 19 10:08:41 2009 From: andrew.capon at zen.co.uk (Andrew Capon) Date: Tue May 19 10:09:03 2009 Subject: [music-dsp] Which Signal Processing Device? In-Reply-To: <4a12babc.398.2440.582189508@webmaildh6.aruba.it> References: <4a12babc.398.2440.582189508@webmaildh6.aruba.it> Message-ID: <946DC404-6641-47C6-BB63-02B0DD35E9E9@zen.co.uk> Hi, I have a Chameleon sitting in a rack here, doesn't get used much though. For The Son Of Chameleon look here http://www.imx31synth.info/ Cheers Andy On 19 May 2009, at 14:57, Lukas Kaser wrote: > Hello, > > thank you for your answers! > > We have still some questions open: > - Did someone run a Linux-Solution with NO drop-outs? In the > paper is mentioned that drop-outs has been reported. > - Is someone experienced with the Chameleon and what would > be an alternative DSP-device? > - Which FPGA's run with 2ms max latency? How are the > experiences here? > > Thank you for any further suggestions. > > Yours Sincerely > > > Lukas Kaser > > > ----- Original Message ----- > Da : Dan Stowell > A : A discussion list for music-related DSP > > Oggetto : Re: [music-dsp] Which Signal Processing Device? > Data : Tue, 19 May 2009 10:21:47 +0100 > >> Hi - >> >> According to this paper: >> > http://lad.linuxaudio.org/events/2009_cdm/Friday/07_Grimm/07.pdf >> (full citation below) >> >> ..an Asus Eee PC running a realtime Linux kernel can >> achieve sub-2ms total latency, depending on the choice of >> sound card. I'm sure other PCs could achieve similar >> results with the same OS+soundcard. >> >> (BTW you don't specify what sample rate(s) you're working >> with...) >> >> Best >> Dan >> >> >> >> >> @inproceedings{Grimm:2009, >> Author = {Grimm, G. and Herzke, T. and Hohmann, V.}, >> Booktitle = {Linux Audio Conference (LAC2009)}, >> Date-Added = {2009-05-05 09:01:03 +0100}, >> Date-Modified = {2009-05-05 14:39:57 +0100}, >> Rating = {5}, >> Read = {Yes}, >> Title = {Application of Linux Audio in Hearing Aid >> Research}, >> Url = >> {http://lad.linuxaudio.org/events/2009_cdm/Friday/07_Grimm >> /07.pdf}, >> Year = {2009}, >> Abstract = {Development of algorithms for digital >> hearing aid processing includes many steps from the first >> algorithmic idea and implementation up to field tests >> with hearing impaired patients. Each of these steps has >> its own requirements towards the development environment. >> However, a common platform throughout the whole >> development process is desirable. This paper gives an >> overview of the application of Linux Audio in the hearing >> aid algorithm development process. The performance of >> portable hardware in terms of delay, battery runtime and >> processing power is investigated. }, >> } >> >> >> >> Lukas Kaser wrote: >>> Dear List, >>> >>> for a "very realtime" audio processing application we're >>> looking for a >>> suitable platform with the following specs: >>> >>> - freely programmable in C(++); ideally GNU C, minimum: >>> development environment with C compiler >>> - analog line in/out (at least 1 in and out) >>> - possibility of realtime control, e.g. through usb, >>> midi, osc... >>> - !!! MAXIMUM TOTAL in-out-latency for audio signal >>> below 2ms !!! >>> >>> Our favorite until now is the >>> http://www.chameleon.synth.net/english/chameleon/. >>> >>> Can anyone suggest another DSP-device or PC/Mac which >>> fulfills these requirements or tell us something about >>> her/experience with the chameleon >>> (availability/stability/development cycle...)? >>> >>> Thank you in advance!!! >>> >>> Yours Sincerely >>> >>> >>> >>> Lukas >>> >>> -- >>> 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 >> >> >> -- >> Dan Stowell >> Centre for Digital Music >> School of Electronic Engineering and Computer Science >> Queen Mary, University of London >> Mile End Road, London E1 4NS >> > http://www.elec.qmul.ac.uk/department/staff/research/dans.htm >> http://www.mcld.co.uk/ >> -- >> 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 May 19 13:20:53 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Tue May 19 13:18:36 2009 Subject: [music-dsp] Name of delay-free loop technique References: <002401c9d7d1$0aee5ce0$0201a8c0@mooncode> <56BDCC96E6B94AF5BC7DF68F893A63C1@nibln01077> Message-ID: <001201c9d8a6$2f916bc0$0201a8c0@mooncode> Vadim Zavalishin wrote: >> I think that technique could do with a crisp name. What do you >> folks think about "deferred state update"? Other takers? > > For myself I was referring to this thing as simply "instant > feedback". That *is* short but doesn't distinguish the condition from the treatment. I've thought of augmenting it to "preserving instantaneous feedback" -- alas, it still won't suggest the How. (FYI, "instantaneous" is the right word here -- it suggests short time to completion of a process or event, rather than short time elapsed between an event and its consequent which "instant" connotes.) Martin From andrew.capon at zen.co.uk Tue May 19 13:37:51 2009 From: andrew.capon at zen.co.uk (Andrew Capon) Date: Tue May 19 13:38:08 2009 Subject: [music-dsp] Which Signal Processing Device? In-Reply-To: <946DC404-6641-47C6-BB63-02B0DD35E9E9@zen.co.uk> References: <4a12babc.398.2440.582189508@webmaildh6.aruba.it> <946DC404-6641-47C6-BB63-02B0DD35E9E9@zen.co.uk> Message-ID: <1DD3AFBF-4967-4AE8-B41F-6725F6267B55@zen.co.uk> Also Symphony Soundbite is quite interesting because of the 8 audio ins. http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=SYMP_SOUNDBITE Andy On 19 May 2009, at 15:08, Andrew Capon wrote: > Hi, > > I have a Chameleon sitting in a rack here, doesn't get used much > though. > > For The Son Of Chameleon look here http://www.imx31synth.info/ > > Cheers > > Andy > > On 19 May 2009, at 14:57, Lukas Kaser wrote: > >> Hello, >> >> thank you for your answers! >> >> We have still some questions open: >> - Did someone run a Linux-Solution with NO drop-outs? In the >> paper is mentioned that drop-outs has been reported. >> - Is someone experienced with the Chameleon and what would >> be an alternative DSP-device? >> - Which FPGA's run with 2ms max latency? How are the >> experiences here? >> >> Thank you for any further suggestions. >> >> Yours Sincerely >> >> >> Lukas Kaser >> >> >> ----- Original Message ----- >> Da : Dan Stowell >> A : A discussion list for music-related DSP >> >> Oggetto : Re: [music-dsp] Which Signal Processing Device? >> Data : Tue, 19 May 2009 10:21:47 +0100 >> >>> Hi - >>> >>> According to this paper: >>> >> http://lad.linuxaudio.org/events/2009_cdm/Friday/07_Grimm/07.pdf >>> (full citation below) >>> >>> ..an Asus Eee PC running a realtime Linux kernel can >>> achieve sub-2ms total latency, depending on the choice of >>> sound card. I'm sure other PCs could achieve similar >>> results with the same OS+soundcard. >>> >>> (BTW you don't specify what sample rate(s) you're working >>> with...) >>> >>> Best >>> Dan >>> >>> >>> >>> >>> @inproceedings{Grimm:2009, >>> Author = {Grimm, G. and Herzke, T. and Hohmann, V.}, >>> Booktitle = {Linux Audio Conference (LAC2009)}, >>> Date-Added = {2009-05-05 09:01:03 +0100}, >>> Date-Modified = {2009-05-05 14:39:57 +0100}, >>> Rating = {5}, >>> Read = {Yes}, >>> Title = {Application of Linux Audio in Hearing Aid >>> Research}, >>> Url = >>> {http://lad.linuxaudio.org/events/2009_cdm/Friday/07_Grimm >>> /07.pdf}, >>> Year = {2009}, >>> Abstract = {Development of algorithms for digital >>> hearing aid processing includes many steps from the first >>> algorithmic idea and implementation up to field tests >>> with hearing impaired patients. Each of these steps has >>> its own requirements towards the development environment. >>> However, a common platform throughout the whole >>> development process is desirable. This paper gives an >>> overview of the application of Linux Audio in the hearing >>> aid algorithm development process. The performance of >>> portable hardware in terms of delay, battery runtime and >>> processing power is investigated. }, >>> } >>> >>> >>> >>> Lukas Kaser wrote: >>>> Dear List, >>>> >>>> for a "very realtime" audio processing application we're >>>> looking for a >>>> suitable platform with the following specs: >>>> >>>> - freely programmable in C(++); ideally GNU C, minimum: >>>> development environment with C compiler >>>> - analog line in/out (at least 1 in and out) >>>> - possibility of realtime control, e.g. through usb, >>>> midi, osc... >>>> - !!! MAXIMUM TOTAL in-out-latency for audio signal >>>> below 2ms !!! >>>> >>>> Our favorite until now is the >>>> http://www.chameleon.synth.net/english/chameleon/. >>>> >>>> Can anyone suggest another DSP-device or PC/Mac which >>>> fulfills these requirements or tell us something about >>>> her/experience with the chameleon >>>> (availability/stability/development cycle...)? >>>> >>>> Thank you in advance!!! >>>> >>>> Yours Sincerely >>>> >>>> >>>> >>>> Lukas >>>> >>>> -- >>>> 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 >>> >>> >>> -- Dan Stowell >>> Centre for Digital Music >>> School of Electronic Engineering and Computer Science >>> Queen Mary, University of London >>> Mile End Road, London E1 4NS >>> >> http://www.elec.qmul.ac.uk/department/staff/research/dans.htm >>> http://www.mcld.co.uk/ >>> -- >>> 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 linkshttp://music.columbia.edu/cmc/music-dsphttp://music.columbia.edu/mailman/listinfo/music-dsp From music.maker at gte.net Tue May 19 13:56:35 2009 From: music.maker at gte.net (Scott Gravenhorst) Date: Tue May 19 13:56:48 2009 Subject: [music-dsp] Which Signal Processing Device? Message-ID: <200905191756.n4JHuZIk013183@linux7.lan> A discussion list for music-related DSP wrote: >Hello, > >thank you for your answers! > >We have still some questions open: >- Did someone run a Linux-Solution with NO drop-outs? In the >paper is mentioned that drop-outs has been reported. >- Is someone experienced with the Chameleon and what would >be an alternative DSP-device? >- Which FPGA's run with 2ms max latency? How are the >experiences here? Because there is no operating system, an FPGA provides latency times which are highly consistent and entirely dependant on the design itself and the sample rate. If the design can compute an output in less than the sample time, then the latency will never be more than one sample time and without dropouts (assuming a well designed DSP system). High sample rates (easily up to 200KHz and more) are attainable using an FPGA and selected ADC/DAC hardware. The main disadvantage of an FPGA is that because it is RAM based, it must be "booted" at power up which can take a small number of seconds. The FPGA devices I use for DSP boot up in around 1 or 2 seconds from a user configurable Flash RAM. While all FPGAs are capable of DSP at some level, the newer bigger FPGA devices have built in dedicated hardware structures that support enhanced and faster DSP functionality. As I mentioned in an earlier response, an FPGA cannot be programmed in C or C++, rather a hardware description language such as VHDL or Verilog is used. I am a seasoned C programmer who has worked with hardware logic design and I took about 6 months to learn the basics of Verilog, mainly from free web-based educational resources. >Thank you for any further suggestions. > >Yours Sincerely > > >Lukas Kaser > > >----- Original Message ----- >Da : Dan Stowell >A : A discussion list for music-related DSP > >Oggetto : Re: [music-dsp] Which Signal Processing Device? >Data : Tue, 19 May 2009 10:21:47 +0100 > >> Hi - >> >> According to this paper: >> >http://lad.linuxaudio.org/events/2009_cdm/Friday/07_Grimm/07.pdf >> (full citation below) >> >> ..an Asus Eee PC running a realtime Linux kernel can >> achieve sub-2ms total latency, depending on the choice of >> sound card. I'm sure other PCs could achieve similar >> results with the same OS+soundcard. >> >> (BTW you don't specify what sample rate(s) you're working >> with...) >> >> Best >> Dan >> >> >> >> >> @inproceedings{Grimm:2009, >> Author = {Grimm, G. and Herzke, T. and Hohmann, V.}, >> Booktitle = {Linux Audio Conference (LAC2009)}, >> Date-Added = {2009-05-05 09:01:03 +0100}, >> Date-Modified = {2009-05-05 14:39:57 +0100}, >> Rating = {5}, >> Read = {Yes}, >> Title = {Application of Linux Audio in Hearing Aid >> Research}, >> Url = >> {http://lad.linuxaudio.org/events/2009_cdm/Friday/07_Grimm >> /07.pdf}, >> Year = {2009}, >> Abstract = {Development of algorithms for digital >> hearing aid processing includes many steps from the first >> algorithmic idea and implementation up to field tests >> with hearing impaired patients. Each of these steps has >> its own requirements towards the development environment. >> However, a common platform throughout the whole >> development process is desirable. This paper gives an >> overview of the application of Linux Audio in the hearing >> aid algorithm development process. The performance of >> portable hardware in terms of delay, battery runtime and >> processing power is investigated. }, >> } >> >> >> >> Lukas Kaser wrote: >> > Dear List, >> > >> > for a "very realtime" audio processing application we're >> > looking for a >> > suitable platform with the following specs: >> > >> > - freely programmable in C(++); ideally GNU C, minimum: >> > development environment with C compiler >> > - analog line in/out (at least 1 in and out) >> > - possibility of realtime control, e.g. through usb, >> > midi, osc... >> > - !!! MAXIMUM TOTAL in-out-latency for audio signal >> > below 2ms !!! >> > >> > Our favorite until now is the >> > http://www.chameleon.synth.net/english/chameleon/. >> > >> > Can anyone suggest another DSP-device or PC/Mac which >> > fulfills these requirements or tell us something about >> > her/experience with the chameleon >> > (availability/stability/development cycle...)? >> > >> > Thank you in advance!!! >> > >> > Yours Sincerely >> > >> > >> > >> > Lukas >> > >> > -- >> > 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 >> >> >> -- >> Dan Stowell >> Centre for Digital Music >> School of Electronic Engineering and Computer Science >> Queen Mary, University of London >> Mile End Road, London E1 4NS >> >http://www.elec.qmul.ac.uk/department/staff/research/dans.htm >> http://www.mcld.co.uk/ >> -- >> 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 > -- ScottG ________________________________________________________________________ -- Scott Gravenhorst -- FPGA MIDI Synthesizer Information: home1.gte.net/res0658s/FPGA_synth/ -- FatMan: home1.gte.net/res0658s/fatman/ -- NonFatMan: home1.gte.net/res0658s/electronics/ -- When the going gets tough, the tough use the command line. From andy at korgrd.com Tue May 19 14:04:50 2009 From: andy at korgrd.com (Andy Leary) Date: Tue May 19 14:05:04 2009 Subject: [music-dsp] Which Signal Processing Device? In-Reply-To: <20090519135801.4BD4B83A0E2@music.columbia.edu> References: <20090519135801.4BD4B83A0E2@music.columbia.edu> Message-ID: <0E1EA11F-FF27-45A2-8C75-C27A508AFF81@korgrd.com> > We have still some questions open: > - Did someone run a Linux-Solution with NO drop-outs? In the > paper is mentioned that drop-outs has been reported. At Korg, we used an Asus motherboard with a P4 running Linux and RTAI for the Korg Oasys keyboard. We get NO drop-outs and key down to audio out latency of under 4 ms. 48 kHz of course. So, it can be done and work very nicely. We used a custom soundcard, but you can do the same with other commercially available cards. http://korg.com/product.aspx?&pd=214 Development for that was a few years ago and the P4 we used was pretty weak but we were still able to squeek out 172 voices of high quality interpolated PCM voices with 4 pole resonant filters, modulation, etc. or almost 100 voices of really excellent sounding virtual analog. We put in several analog synths, clone-wheel organ, physical modeling and an FM synth. We sold a decent amount of these - more than I expected - even at the hefty price of $8000. As a DSP development platform, Linux and an x86 type processor isn't bad. The issue with Linux is the tools of course, but there are a few decent tools out there. I do some of my development under windows where I can use full featured debuggers and IDEs, then build for Linux for tuning realtime performance. Andy Leary andy@korgrd.com From Victor.Lazzarini at nuim.ie Tue May 19 15:07:31 2009 From: Victor.Lazzarini at nuim.ie (victor) Date: Tue May 19 15:07:56 2009 Subject: [music-dsp] Which Signal Processing Device? In-Reply-To: <0E1EA11F-FF27-45A2-8C75-C27A508AFF81@korgrd.com> References: <20090519135801.4BD4B83A0E2@music.columbia.edu> <0E1EA11F-FF27-45A2-8C75-C27A508AFF81@korgrd.com> Message-ID: It's interesting to hear your opinion on this. For me, on the other hand is Windows that does not give me enough tools, but that might be because I am more at home in a unix-like environment. Nice that one, that linux-based workstation by Korg. Victor > As a DSP development platform, Linux and an x86 type processor isn't bad. > The issue with Linux is the tools of course, but there are a few decent > tools out there. I do some of my development under windows where I can > use full featured debuggers and IDEs, then build for Linux for tuning > realtime performance. > > > Andy Leary > andy@korgrd.com > -- > 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 michael.gogins at gmail.com Tue May 19 15:31:01 2009 From: michael.gogins at gmail.com (Michael Gogins) Date: Tue May 19 15:31:20 2009 Subject: [music-dsp] Which Signal Processing Device? In-Reply-To: References: <20090519135801.4BD4B83A0E2@music.columbia.edu> <0E1EA11F-FF27-45A2-8C75-C27A508AFF81@korgrd.com> Message-ID: <898dd7270905191231q5402314es9e67f472bde92425@mail.gmail.com> I have some experience on Windows, Solaris, and Linux. Tool comparison across platform is complex, but to summarize, yes, it does depend on exactly what you are trying to do, which platform is better. No recent experience on OS X, sorry. My 2 cents: (0) The Intel compiler is best, then the Solaris compiler, then the GCC and Microsoft compilers are tied for last, GCC having caught up with Microsoft more or less. OpenMP with GCC is not really there yet. It's great in Intel. Don't know about Microsoft or Solaris -- I presume it is good in Solaris. But all of these compilers are actually pretty good now for straight ahead C or C++ code. OpenMP will I think gain rapidly in importance. (1) Solaris is the best development environment all round. Most things are just a bit better, and then there is DTrace. Also, SunStudio does profiling and memory debugging out of the box. This has saved my life professionally at times. But the SunStudio IDE is clunky (although it does lots). (2) Linux is next best all round. (3) Windows is next best after Linux. But... (4) The Microsoft debugger is the best, hands down, then the Solaris debugger, then the Linux debugger (gdb). Gdb, frankly, has issues, but of course there is always valgrind. (5) The Microsoft IDE is the best, hands down. This includes ease of making macros, ease of looking up documentaton, many wizards and templates, etc. (6) CodeBlocks is a tolerable if simpler-minded substitute for the Microsoft IDE. (7) Emacs is a tolerable substitute for the Microsoft IDE, and is of course more flexible if you want to spend your time playing with Emacs instead of writing code. (8) Eclipse is a tolerable substitue for the Microsoft IDE if you want to use makefiles. It has great stuff for code refactoring etc. Regards, Mike On 5/19/09, victor wrote: > It's interesting to hear your opinion on this. For me, on the other hand > is Windows that does not give me enough tools, but that might be because > I am more at home in a unix-like environment. > > Nice that one, that linux-based workstation by Korg. > > Victor > >> As a DSP development platform, Linux and an x86 type processor isn't bad. >> >> The issue with Linux is the tools of course, but there are a few decent >> tools out there. I do some of my development under windows where I can >> use full featured debuggers and IDEs, then build for Linux for tuning >> realtime performance. >> >> >> Andy Leary >> andy@korgrd.com >> -- >> 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 > -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com From Stefan at stenzel.com Tue May 19 15:32:13 2009 From: Stefan at stenzel.com (Stefan Stenzel) Date: Tue May 19 15:32:34 2009 Subject: [music-dsp] Which Signal Processing Device? In-Reply-To: <4a12babc.398.2440.582189508@webmaildh6.aruba.it> References: <4a12babc.398.2440.582189508@webmaildh6.aruba.it> Message-ID: <4A13093D.108@Stenzel.com> Lukas Kaser wrote: [...] > - Is someone experienced with the Chameleon and what would > be an alternative DSP-device? Maybe consider this one: http://line6.com/tcddk/ Or this: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=SYMP_SOUNDBITE I promise programming DSP in assembly is much more fun that coding in some boring high level language and dealing with operating system restrictions. Stefan From mike at psychonic.net Tue May 19 23:07:59 2009 From: mike at psychonic.net (Mike) Date: Tue May 19 23:03:29 2009 Subject: [music-dsp] DSP: Hard or Soft Message-ID: <4A13740F.4000005@psychonic.net> Regarding the recent post about hardware vs. software, I've done a lot of software and a little bit of hardware, and I had a considerably different experience. Though all of the ?hard? parts that were mention about hardware are true, they aren't necessarily any worse than some of the difficulties in software. It can be just as difficult to track down a software bug as a hardware one. The ease of developing a hardware system varies considerably with the complexity and support of the parts. Intermittent glitches can of course be very difficult to track down, though as systems get more highly integrated (e.g. with on-chip RAM and FLASH), this becomes less of an issue. A good reference design & development board & sample software can make the difference between a few hours and a few months, so check out the chip support carefully And of course it depends on what clock rate. 40 MHz seemed easy enough, but 500 MHz may not be. Some of this depends on what you consider expensive, e.g. in the U.S., you can get 5 prototype boards for around $135.00, a used stereo microscope for a few hundred, etc. A nice digital scope is almost a requirement, too, though, and that can cost up to a few thousand, though there are also some USB options that may work for some situations. Certainly a lot more expensive than free, and you have to buy the parts for your board (tens to hundreds of dollars), and some CPU's/DSP's need propriety compilers and JTAG pods, but it?s comparable to the cost of a nice computer and not tens of thousands or hundreds of thousands of dollars. Working with surface-mount components is tricky but not impossible IF you have the right equipment (mainly a microscope), and don't use the smallest parts (0603 components and .050" pin spacing are readily doable with no major pain). Though of course BGA's are essentially impossible for home assembly. A 10x Stereo microscope and a flux pen and a fine-tip iron (my 25-year old Weller works fine) help a lot with soldering, and Chip-Quik works well for removing larger chips and just use 2 soldering irons for 2-pin components (e.g. resistors, capacitors, etc). Changes and mistakes are of course much much much more difficult with electronics, you can't just change a parameter and recompile -- you may need to cut a trace and run a jumper wire or re-spin the board, and soldering up the second board takes about as long as doing the first board, much longer than copying a file. But with hardware, you?re also not at the mercy of the O/S (e.g. if VST or AudioUnits introduces a new version, the people I've talked to that do plugins tell me it takes them a year to re-do everything to get it working again, whereas e.g. a Kurzweil K2600 still turns on and make sounds now, 25 years later. Regarding USB etc. pain: This will depend a lot on how good of sample code you can get (e.g. with a development system), and there's other options, such as an all-in-one USB to serial chip (FTDI or Cygnal/Silicon Labs CP2101), or just use plain old RS-232. Another aspect to consider is that if you want specific features or functionality (e.g. bluetooth, zigbee, IR, FPGA's, touch-sensitive LCD, motor drivers, etc), and/or manufacture and sell it yourself, then the complete systems don?t really work. And if you want something that will still be available in a few months or years, a commercially available system will likely be discontinued and you may have to re-write things to work with new O/S's or hardware. Conversely, you can't make hardware available as a free download. Just my experience and thoughts, your mileage may very. -Mike Shonle From rossb-lists at audiomulch.com Tue May 19 23:33:37 2009 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Tue May 19 23:33:55 2009 Subject: [music-dsp] Which Signal Processing Device? References: <20090519135801.4BD4B83A0E2@music.columbia.edu><0E1EA11F-FF27-45A2-8C75-C27A508AFF81@korgrd.com> Message-ID: <00fa01c9d8fb$c38cdf30$0773a8c0@rossmacbook> Interesting thread... Victor Lazzarini wrote: > It's interesting to hear your opinion on this. For me, on the other hand > is Windows that does not give me enough tools, but that might be because > I am more at home in a unix-like environment. Hi Victor, I'd be interested to hear what Linux-only tools you're thinking of.. I've been very happy using MSVC++ for the last three years (and relatively unhappy using XCode on OSX) but havn't had much joy with performance tuning when evaluating VTune and am starting to wonder whether it's worth doing Linux builds just to leverage C++ profiling and tuning tools that aren't available on Windows... (I know about valgrind but I presume there are others). Ross. From valerianmusic at gmail.com Wed May 20 00:22:35 2009 From: valerianmusic at gmail.com (NickMtl) Date: Wed May 20 00:22:57 2009 Subject: [music-dsp] Which Signal Processing Device? In-Reply-To: <00fa01c9d8fb$c38cdf30$0773a8c0@rossmacbook> References: <20090519135801.4BD4B83A0E2@music.columbia.edu> <0E1EA11F-FF27-45A2-8C75-C27A508AFF81@korgrd.com> <00fa01c9d8fb$c38cdf30$0773a8c0@rossmacbook> Message-ID: "(and relatively unhappy using XCode on OSX)" Ross, do you care to elaborate on this? I'm starting to prefer Xcode over MSVC++ after using it almost exclusively for 8 months. Then again, I'm more into graphics development than audio/dsp, so I've probably only seen Xcode good side. Thanks, -- - Nick - From rossb-lists at audiomulch.com Wed May 20 01:39:00 2009 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Wed May 20 01:39:19 2009 Subject: [music-dsp] Which Signal Processing Device? References: <20090519135801.4BD4B83A0E2@music.columbia.edu><0E1EA11F-FF27-45A2-8C75-C27A508AFF81@korgrd.com><00fa01c9d8fb$c38cdf30$0773a8c0@rossmacbook> Message-ID: <01ce01c9d90d$480b9290$0773a8c0@rossmacbook> Hi Nick > "(and relatively unhappy using XCode on OSX)" > > Ross, do you care to elaborate on this? I'm starting to prefer Xcode > over MSVC++ after using it almost exclusively for 8 months. Then > again, I'm more into graphics development than audio/dsp, so I've > probably only seen Xcode good side. Some background: lately I've been mainly working on GUI code using the Qt framework in C++. This means that all my coding is in straight C++ (no IB or other wysiwyg stuff aside from Qt Designer). I use Scons to manage my builds. So the IDE is used only for editing and debugging, not for builds or project management although I have scripts which auto-update the file tree in my project files from the Scons dependency tree and I often do launch builds from the IDE. Because I'm developing cross-platform software I'm constantly flipping between MSVC and XCode. I've been doing this daily for a couple of years now. I do most of my development on a 13 inch macbook. I find that the screen layout in XCode is difficult to work with and is not as space efficient as MSVC. Usually I am working with 10 - 20 open C++ files at a time. One of the main problems for me is the lack of tabbed code windows (I know I could use the "organiser" but that's a separate window, and you have to be "organised" you can't just randomly open files and hit tabs to switch between them. The lack of docked sub views (find results, compiler output, stack trace, local variables etc etc) and the need to switch to different views for build/edit/debug is also an issue. Also the whole UI is very sluggish compared to MSVC on the same machine (loading source files, switching between source files). Then there is the debugger. I use Scons to manage my builds, and for some reason XCode debugging doesn't work quite right with externally built executables. The breakpoints don't load half the time. There are workarounds but it doesn't "just work". Michael already noted that the MSVC debugger is possibly the best out there.. so perhaps I am spoilt. And finally, the XCode search function is broken and when it works it is incredibly slow. I can search all 1778 files in my project using MSVC in under 5 seconds (actually i think under 1 second), XCode takes minutes _if_ it works at all, which often it doesn't (often it actually fails to find words when I can see them with my own eyes -- I've taken to using grep on the command line). When I have more time I'm going to investigate Eclipse/C++ and QtCreator for debugging on OSX and consider running MSVC in VMWare for editing and general development. If anyone has found a serious (GUI based) alternative to XCode for OSX I'd be interested to hear about it. Ross. =================================== AudioMulch 2.0 coming soon! http://www.audiomulch.com From nostromo at arkaos.net Wed May 20 02:36:48 2009 From: nostromo at arkaos.net (M-.-n) Date: Wed May 20 02:37:04 2009 Subject: [music-dsp] Which Signal Processing Device? In-Reply-To: <01ce01c9d90d$480b9290$0773a8c0@rossmacbook> Message-ID: <7qb0qm$a1ko2q@relay.skynet.be> >you can't just randomly open files and hit tabs to switch between them. You can't indeed but Ctrl+Alt+Left/Right go to previous/next document. It's a fairely good replacement of Ctrl+Tab under windows. After doing a project exclusively on Mac, I kind of think now a little more of Xcode, even if MSVC's IDE is still the best. Ross, if you are looking at cross-platform performance ehancing, you might want to dig "Instruments" on Mac which contains free tools for code profiling, memory leaks and so on. Should come at the same time as Xcode. Marc. From valerianmusic at gmail.com Wed May 20 02:57:10 2009 From: valerianmusic at gmail.com (NickMtl) Date: Wed May 20 02:57:23 2009 Subject: [music-dsp] Which Signal Processing Device? In-Reply-To: <01ce01c9d90d$480b9290$0773a8c0@rossmacbook> References: <20090519135801.4BD4B83A0E2@music.columbia.edu> <0E1EA11F-FF27-45A2-8C75-C27A508AFF81@korgrd.com> <00fa01c9d8fb$c38cdf30$0773a8c0@rossmacbook> <01ce01c9d90d$480b9290$0773a8c0@rossmacbook> Message-ID: Ross, Thanks for the info. I'm in the same boat (cross-platform c++ app with flashy UI), so I can relate to your comments. It's true that Xcode is optimized to work with it's own toolchain and a small set of external tools (Subversion, TextMate, etc.). I chose my cross-platform technology soup (C++, hand-tuned OpenGL and Boost templates instead of QT, Subversion instead of Git, etc.) based on what Xcode was good at. As a result, my C++ development is quite straightforward. > Some background: lately I've been mainly working on GUI code using the Qt > framework in C++. This means that all my coding is in straight C++ (no IB or > other wysiwyg stuff aside from Qt Designer). > ... Qt is pretty good, but since you're doing audio, it may be interesting for you to investigate the NUI toolkit (http://www.libnui.net/). It's already used by many audio vendors (MOTU, FXpansion, etc.) and will allow you to draw complex widgets without knowing the underlying OpenGL. I had already implemented my own toolkit when I learned about them, but I would definitely use them if I were starting again. I know it's too late for AudioMulch 2.0, but maybe in the future... Also, choosing ObjectiveC++ for the glue code made my life a lot easier since I can use NIB files for the main window and dialog panels. Xcode is optimized for rapid development of Objective-c code + XIB/NIB files. Doing otherwise is like using a Ferrari to do deliveries: it works but it's a fight. > I do most of my development on a 13 inch macbook. I find that the screen > layout in XCode is difficult to work with and is not as space efficient as > MSVC. > ... Same thing here. I get around this by using the "All in one" mode which enables a kind of "tabbed" view. XCode-->Preferences-->General-->Layout-->"All in One" Works great on my 13" white Macbook. There's a useful blogpost about reducing Xcode clutter here: http://meandmarkpublishing.blogspot.com/2007/06/reducing-xcodes-window-clutter.html > Then there is the debugger. I use Scons to manage my builds, and for some > reason XCode debugging doesn't work quite right with externally built > executables... For Xcode projects, the debugger is more than adequate, although just not in the same league as the MSVC++ debugger IMO. That doesn't help you, but I can only suggest that you use an Xcode project and build from there. Regards, >> Go AudioMulch! << -- - Nick - From dan.stowell at elec.qmul.ac.uk Wed May 20 03:30:39 2009 From: dan.stowell at elec.qmul.ac.uk (Dan Stowell) Date: Wed May 20 03:31:01 2009 Subject: OpenMP Re: [music-dsp] Which Signal Processing Device? In-Reply-To: <898dd7270905191231q5402314es9e67f472bde92425@mail.gmail.com> References: <20090519135801.4BD4B83A0E2@music.columbia.edu> <0E1EA11F-FF27-45A2-8C75-C27A508AFF81@korgrd.com> <898dd7270905191231q5402314es9e67f472bde92425@mail.gmail.com> Message-ID: <4A13B19F.3050803@elec.qmul.ac.uk> Hi - Would be grateful to hear more about the difference between the compilers regarding OpenMP. I've been dabbling with gcc+OpenMP, so I'm wondering what the differences are that you've found, versus intel compilers. Thanks Dan Michael Gogins wrote: > I have some experience on Windows, Solaris, and Linux. Tool comparison > across platform is complex, but to summarize, yes, it does depend on > exactly what you are trying to do, which platform is better. No recent > experience on OS X, sorry. My 2 cents: > > (0) The Intel compiler is best, then the Solaris compiler, then the > GCC and Microsoft compilers are tied for last, GCC having caught up > with Microsoft more or less. OpenMP with GCC is not really there yet. > It's great in Intel. Don't know about Microsoft or Solaris -- I > presume it is good in Solaris. But all of these compilers are actually > pretty good now for straight ahead C or C++ code. OpenMP will I think > gain rapidly in importance. > > (1) Solaris is the best development environment all round. Most things > are just a bit better, and then there is DTrace. Also, SunStudio does > profiling and memory debugging out of the box. This has saved my life > professionally at times. But the SunStudio IDE is clunky (although it > does lots). > > (2) Linux is next best all round. > > (3) Windows is next best after Linux. But... > > (4) The Microsoft debugger is the best, hands down, then the Solaris > debugger, then the Linux debugger (gdb). Gdb, frankly, has issues, but > of course there is always valgrind. > > (5) The Microsoft IDE is the best, hands down. This includes ease of > making macros, ease of looking up documentaton, many wizards and > templates, etc. > > (6) CodeBlocks is a tolerable if simpler-minded substitute for the > Microsoft IDE. > > (7) Emacs is a tolerable substitute for the Microsoft IDE, and is of > course more flexible if you want to spend your time playing with Emacs > instead of writing code. > > (8) Eclipse is a tolerable substitue for the Microsoft IDE if you want > to use makefiles. It has great stuff for code refactoring etc. > > Regards, > Mike > > > > > On 5/19/09, victor wrote: >> It's interesting to hear your opinion on this. For me, on the other hand >> is Windows that does not give me enough tools, but that might be because >> I am more at home in a unix-like environment. >> >> Nice that one, that linux-based workstation by Korg. >> >> Victor >> >>> As a DSP development platform, Linux and an x86 type processor isn't bad. >>> >>> The issue with Linux is the tools of course, but there are a few decent >>> tools out there. I do some of my development under windows where I can >>> use full featured debuggers and IDEs, then build for Linux for tuning >>> realtime performance. >>> >>> >>> Andy Leary >>> andy@korgrd.com -- Dan Stowell Centre for Digital Music Queen Mary, University of London Mile End Road, London E1 4NS http://www.elec.qmul.ac.uk/digitalmusic/people/dans.htm http://www.mcld.co.uk/ From cannam at all-day-breakfast.com Wed May 20 04:17:57 2009 From: cannam at all-day-breakfast.com (Chris Cannam) Date: Wed May 20 04:18:09 2009 Subject: [music-dsp] Which Signal Processing Device? In-Reply-To: <898dd7270905191231q5402314es9e67f472bde92425@mail.gmail.com> References: <20090519135801.4BD4B83A0E2@music.columbia.edu> <0E1EA11F-FF27-45A2-8C75-C27A508AFF81@korgrd.com> <898dd7270905191231q5402314es9e67f472bde92425@mail.gmail.com> Message-ID: <587e90db0905200117g59d467b5r39b1188a0ea5326b@mail.gmail.com> On Tue, May 19, 2009 at 8:31 PM, Michael Gogins wrote: > (0) The Intel compiler is best, then the Solaris compiler, then the > GCC and Microsoft compilers are tied for last, GCC having caught up > with Microsoft more or less. The Intel compiler produces comfortably the fastest code in my experience as well. I have tested the Sun Studio compiler on Linux quite recently and was disappointed to find its code (in my highly unscientific tests) a bit slower than that from GCC 4.3 on a 64-bit machine. My impression is that these days MSVC is last for everything except compile time. This is hearsay without any actual numbers though, and I don't have those to hand. As a mostly Emacs and command-line chap, I find Linux most pleasant but OS/X a satisfying alternative as a development platform (OS/X has Instruments, Shark and a few other nice tools; Linux has valgrind, sysprof etc; both suffer from gdb). Windows is a necessity rather than a pleasure. Ross mentioned Qt -- you should definitely take a look at Qt Creator, it's very promising. I would probably be using it myself by now, if it weren't for the fact that it just isn't Emacs. Chris From Victor.Lazzarini at nuim.ie Wed May 20 04:38:54 2009 From: Victor.Lazzarini at nuim.ie (victor) Date: Wed May 20 04:39:11 2009 Subject: [music-dsp] Which Signal Processing Device? In-Reply-To: <00fa01c9d8fb$c38cdf30$0773a8c0@rossmacbook> References: <20090519135801.4BD4B83A0E2@music.columbia.edu> <0E1EA11F-FF27-45A2-8C75-C27A508AFF81@korgrd.com> <00fa01c9d8fb$c38cdf30$0773a8c0@rossmacbook> Message-ID: Well, I am thinking here of emacs, valgrind, sysproof, and other stuff. I can't say I have had issues with gdb, I have not really compared it to anything else. I used to work with MSVC (4.0 and then 6.0), but then migrated to mingw and gcc on Windows as these resemble very slightly a unix-like environment. Of course, I am probably not in the same league as you for going into performance tuning etc. One thing is true, though, comparing OSs, I find the latest Windows (which I've only got in contact with because I changed my family computer) a disgrace for audio work, or at the very least, terribly awkward. OSX and Linux should dominate this area quite easily now. Regards Victor ----- Original Message ----- From: "Ross Bencina" To: "A discussion list for music-related DSP" Sent: Wednesday, May 20, 2009 4:33 AM Subject: Re: [music-dsp] Which Signal Processing Device? > Interesting thread... > > Victor Lazzarini wrote: >> It's interesting to hear your opinion on this. For me, on the other hand >> is Windows that does not give me enough tools, but that might be because >> I am more at home in a unix-like environment. > > Hi Victor, I'd be interested to hear what Linux-only tools you're thinking > of.. > > I've been very happy using MSVC++ for the last three years (and relatively > unhappy using XCode on OSX) but havn't had much joy with performance > tuning when evaluating VTune and am starting to wonder whether it's worth > doing Linux builds just to leverage C++ profiling and tuning tools that > aren't available on Windows... (I know about valgrind but I presume there > are others). > > Ross. > -- > 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 vadim.zavalishin at native-instruments.de Wed May 20 05:53:15 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Wed May 20 05:53:25 2009 Subject: [music-dsp] Name of delay-free loop technique In-Reply-To: <001201c9d8a6$2f916bc0$0201a8c0@mooncode> References: <002401c9d7d1$0aee5ce0$0201a8c0@mooncode><56BDCC96E6B94AF5BC7DF68F893A63C1@nibln01077> <001201c9d8a6$2f916bc0$0201a8c0@mooncode> Message-ID: >>> I think that technique could do with a crisp name. What do you >>> folks think about "deferred state update"? Other takers? >> >> For myself I was referring to this thing as simply "instant >> feedback". > > That *is* short but doesn't distinguish the condition from the > treatment. I've thought of augmenting it to "preserving > instantaneous feedback" -- alas, it still won't suggest the How. > > (FYI, "instantaneous" is the right word here -- it suggests short > time to completion of a process or event, rather than short time > elapsed between an event and its consequent which "instant" > connotes.) Well, my English is far from perfect, thanks for correcting me. In regards to distinguishing the condition from the treatment, I don't know if it's really necessary. At least ATM I don't know any other technique which would be an equally intuitive treatment of the problem (if you artificially add a unit delay into the loop, you don't really solve the problem, you rather eliminate it). I mean, if you do have "instantaneous feedback", then you cannot immediately (that is until solving the feedback equation) update the state anyway, as you don't know the new values. In that respect there is nothing to be artificially deferred. Therefore how about simply referring to it as an "instantaneous feedback", whereas *the* method maybe doesn't need any specific name, and is implicitly understood? What do you also think about "instantaneously unstable" (or is it instable?) term then? Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From michael.gogins at gmail.com Wed May 20 11:44:31 2009 From: michael.gogins at gmail.com (Michael Gogins) Date: Wed May 20 11:44:44 2009 Subject: [music-dsp] Which Signal Processing Device? In-Reply-To: <00fa01c9d8fb$c38cdf30$0773a8c0@rossmacbook> References: <20090519135801.4BD4B83A0E2@music.columbia.edu> <0E1EA11F-FF27-45A2-8C75-C27A508AFF81@korgrd.com> <00fa01c9d8fb$c38cdf30$0773a8c0@rossmacbook> Message-ID: <898dd7270905200844p5ebd8607o4b3ac02f7fe4e252@mail.gmail.com> Well, there is gprof. Works well enough. In my experience, obtaining high performance is mostly a matter of learning how to code, which in turn involves paying attention to what other people who obtain high performance are doing, and to what the language designers and library designers say. I look at other people's code. Numerical libraries, performance test code, DSP code. Also I don't necessarily "buy" common ideas of what is better or faster without testing them (e.g., that single frame computations are slower than block of frame computations, although it turns out that block of frame computations are indeed usually quite a bit faster). I end up putting accurate timers (the clock function is usually fine) into my code to time critical loops, then just try different things inside the loops. I have a C++ class that I can instantiate at the beginning of any function, and that will accurately time that function no matter through what path it returns. Regards, Mike On 5/19/09, Ross Bencina wrote: > Interesting thread... > > Victor Lazzarini wrote: >> It's interesting to hear your opinion on this. For me, on the other hand >> is Windows that does not give me enough tools, but that might be because >> I am more at home in a unix-like environment. > > Hi Victor, I'd be interested to hear what Linux-only tools you're thinking > of.. > > I've been very happy using MSVC++ for the last three years (and relatively > unhappy using XCode on OSX) but havn't had much joy with performance tuning > when evaluating VTune and am starting to wonder whether it's worth doing > Linux builds just to leverage C++ profiling and tuning tools that aren't > available on Windows... (I know about valgrind but I presume there are > others). > > Ross. > > -- > 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 > -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com From Diemo.Schwarz at ircam.fr Wed May 20 16:16:56 2009 From: Diemo.Schwarz at ircam.fr (Diemo Schwarz) Date: Wed May 20 16:14:34 2009 Subject: [music-dsp] time representation in the frequency domain In-Reply-To: <4A0D3CBF.6000203@gmx.de> References: <4A0BF4A8.70909@gmx.de> <007001c9d4a6$e49046d0$0201a8c0@LuboPC><4A0C5601.4030009@gmx.de> <50688.84.48.215.7.1242328611.squirrel@webmail.sysedata.no> <00e601c9d50e$ea5d20c0$0201a8c0@LuboPC> <4A0D3CBF.6000203@gmx.de> Message-ID: <4A146538.5070607@ircam.fr> Jan Baumgart wrote: > I've already started porting the fftw-lib to max/msp for large windows > and non-realtime processing but it's > not working yet... Arbitrary window sizes and arbitrary rate signal processing is already possible in Max/MSP by the FTM&Co. extensions at http://ftm.ircam.fr. (Check out the Gabor objects and tutorials...) ...Diemo -- Diemo Schwarz, PhD -- http://diemo.concatenative.net Real-Time Music Interaction Team -- http://imtr.ircam.fr IRCAM - Centre Pompidou -- 1, place Igor-Stravinsky, 75004 Paris, France Phone +33-1-4478-4879 -- Fax +33-1-4478-1540 From slehman2 at yahoo.com Thu May 21 00:02:01 2009 From: slehman2 at yahoo.com (Scott Lehman) Date: Thu May 21 00:02:18 2009 Subject: [music-dsp] Which Signal Processing Device? Message-ID: <112837.15345.qm@web55607.mail.re4.yahoo.com> --- On Tue, 5/19/09, Ross Bencina wrote: > I do most of my development on a 13 inch macbook. I find > that the screen layout in XCode is difficult to work with > and is not as space efficient as MSVC. Usually I am working > with 10 - 20 open C++ files at a time. One of the main > problems for me is the lack of tabbed code windows (I know I > could use the "organiser" but that's a separate window, and > you have to be "organised" you can't just randomly open > files and hit tabs to switch between them. The lack of Xcode certainly has deficiencies, but in addition to the cmd-option-up/down/left/right, you can also use ctrl-1 to activate the menu of files in an editor pane, ctrl-2 to activate the menu of methods in the current source file (doesn't work so well on C++), and ctrl-3 to activate the list of included headers. There's also the "Open Quickly" command (cmd-shift-d) that can be handy. Ctrl-tab will also move focus across open panes. I would like to see tabs as well, but after finding these commands, I can get by reasonably well without resorting to a mouse. Scott From thevinn at yahoo.com Fri May 22 18:14:27 2009 From: thevinn at yahoo.com (Vinnie) Date: Fri May 22 18:14:51 2009 Subject: [music-dsp] Revisiting C++ Filtering Classes Message-ID: <163625.32426.qm@web58204.mail.re3.yahoo.com> I'm back to working on the classes that I published: http://sourceforge.net/projects/dspfilterscpp/ Can someone enlighten me on the concept behind the math here? Specifically if a[2]==0 and x2==0 what is the rationale behind combining the existing coefficients? What is the use-case here? I'm trying to get rid of the loop over the stages but I don't understand how it works (I translated a Java implementation into C++): inline void CascadeFilter::SetAStage( CalcT x1, CalcT x2 ) { Stage *s=m_stagep; for( int i=m_nstage;i;i-- ) { if( s->a[1]==0 && s->a[2]==0 ) { s->a[1]=x1; s->a[2]=x2; s=0; break; } if( s->a[2]==0 && x2==0 ) { s->a[2]=-s->a[1]*x1; s->a[1]+=x1; s=0; break; } s++; } assert( s==0 ); } From martin.eisenberg at udo.edu Sat May 23 10:24:00 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Sat May 23 10:21:39 2009 Subject: [music-dsp] Revisiting C++ Filtering Classes References: <163625.32426.qm@web58204.mail.re3.yahoo.com> Message-ID: <002801c9dbb2$2385c240$0201a8c0@mooncode> Vinnie wrote: > Specifically if a[2]==0 and x2==0 what is the rationale behind > combining the existing coefficients? If I remember well you took that part from a standalone coefficient generator. There, one obviously wants to obtain the most compact equivalent form of any given higher-order filter. So if, for some design parameters, the denominators of two stages' transfer functions happen to come out as less than 2nd order then it's economical to combine them by multiplying the z-polynomials. Specifically, s->a[1] == s->a[2] == 0 means that stage s has no poles, so it can assume the poles of a subsequently-generated stage (whose creation caused the current call to SetAStage()). Similarly, if stage s->a[2] == x2 == 0 then each of s and the new stage has only one pole, so the product (1 - a[1]/z)*(1 - x1/z) fits in a single 2nd-order stage. The same thing, mutatis mutandis, happens with short transfer function numerators in SetBStage(). However, doing that is only possible when the filter will be fixed during operation. Since you want to allow parameter modulation in midstream, the compactification is unsuitable -- it disrupts the association of stage coefficients and state variables. Therefore, replace the code as follows: inline void CascadeFilter::SetAStage( int i, CalcT x1, CalcT x2 ) { m_stagep[i].a[1]=x1; m_stagep[i].a[2]=x2; } // in PoleFilter::Prepare() for( int i=0;i0 )" in Prepare() are spurious. That is not an error condition, and it's bound to break someone's derived class sooner or later. Make those lines just "else". Martin From thevinn at yahoo.com Sat May 23 10:47:22 2009 From: thevinn at yahoo.com (Vinnie) Date: Sat May 23 10:47:44 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes Message-ID: <848236.83749.qm@web58208.mail.re3.yahoo.com> > Date: Sat, 23 May 2009 16:24:00 +0200 > From: "Martin Eisenberg" > BTW, the tests "else if( c.imag()>0 )" in Prepare() are > spurious. That is not an error condition, and it's bound to break > someone's derived class sooner or later. Make those lines just > "else". Doing so causes the routine to fail. The assertion "assert( s==0 )" goes off in SetAStage (I'm using a 15-pole chebyshev type II high pass). I can only assume that Prepare() ignores poles and zeroes whose imaginary component is negative. Because when we try to add them to the cascade, it overflows the array. Perhaps the assumption in the PoleFilter is that poles and zeroes always come in pairs, i.e. (r,i) and (r,-i) for display purposes, but for computation it is only necessary to look at coordinates with non negative imaginary parts? From thevinn at yahoo.com Sat May 23 11:10:51 2009 From: thevinn at yahoo.com (Vinnie) Date: Sat May 23 11:11:01 2009 Subject: [music-dsp] Analog Filter Prototypes Message-ID: <805920.93843.qm@web58206.mail.re3.yahoo.com> > From: "Martin Eisenberg" > But it is mainly concerned with the *analog* system's topology, > which never enters in what Vinnie's doing because the code he > pilfered BLT's each s-root of an abstract prototype individually > and then assembles the results into a digital filter. So I guess > whether he can apply your presentation at his current level really > depends on his understanding of tunable analog filters. My understanding is growing, slowly but surely. Please tell me if I understand things correctly: The placement of poles and zeroes on the s-plane comprises the "analog prototype", while the bilinear transformation and resulting stage coefficients comprise the "digital filter realization"? From rossb-lists at audiomulch.com Sat May 23 12:55:10 2009 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Sat May 23 12:55:24 2009 Subject: [music-dsp] Analog Filter Prototypes References: <805920.93843.qm@web58206.mail.re3.yahoo.com> Message-ID: <064e01c9dbc7$3d1dd570$0a73a8c0@rossmacbook> Hi Vinnie At the risk of confusing you I'm going to test my understanding too.. > The placement of poles and zeroes on the s-plane comprises the "analog > prototype" I think the "analog prototype" usually refers to the analog transfer function (an equation usually written H(s)=something). Different types of filters (high pass, lowpass etc) have different transfer functions (equations) and hence provide different analog prototypes. I'll leave explaining exactly what the analog transfer function represents to someone else but you can get some info here: http://en.wikipedia.org/wiki/Transfer_function >From what I gather, you've been working with formulas for the locations of (s-plane) poles and zeros. The poles and zeros are the values for which the transfer function goes to infinity (poles) or to zero. The equations you're using for pole/zero locations have been derived from the analog transfer function. > while the bilinear transformation and resulting stage coefficients > comprise the "digital filter realization"? The BLT gets you from an s-plane transfer function to a z-plane transfer function (or equivalently for BLT from s-plane poles and zeros to z-plane poles and zeros which can then be turned into a z-plane transfer function). There are also other methods for getting from analog prototype to z-plane coefficients (such as impulse invariant method). Strictly speaking I don't think this digitization process is part of the "digital filter realization" >From what I've seen "digital filter realization" refers to the process of taking the simple z-plane transfer function and manipulating it to get coefficients for a specific implementation structure -- for example, series, or paralell biquads, lattice filters etc. Hopefully someone will correct me if I'm wrong... Ross. =================================== AudioMulch 2.0 coming soon! http://www.audiomulch.com From martin.eisenberg at udo.edu Sat May 23 13:57:26 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Sat May 23 13:55:01 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes References: <848236.83749.qm@web58208.mail.re3.yahoo.com> Message-ID: <000d01c9dbcf$f53d0560$0201a8c0@mooncode> Vinnie wrote: > Date: Sat, 23 May 2009 16:24:00 +0200 > From: "Martin Eisenberg" martin.eisenberg@udo.edu >> BTW, the tests "else if( c.imag()>0 )" in Prepare() are >> spurious. That is not an error condition, and it's bound to >> break someone's derived class sooner or later. Make those >> lines just "else". > > Doing so causes the routine to fail. The assertion "assert( > s==0 )" goes off in SetAStage (I'm using a 15-pole chebyshev > type II high pass). > > I can only assume that Prepare() ignores poles and zeroes > whose imaginary component is negative. Because when we try to > add them to the cascade, it overflows the array. > > Perhaps the assumption in the PoleFilter is that poles and > zeroes always come in pairs, i.e. (r,i) and (r,-i) for display > purposes, but for computation it is only necessary to look at > coordinates with non negative imaginary parts? Nonreal roots must indeed come in conjugate pairs for the coefficients to be real. The Set*Stage calls guarded by those "else if" amount to multiplying out each pair, (z - r)*(z - conj(r)). It didn't occur to me that the code would even compute the second member of such a pair, but I guess it has to if PoleFilter is to drive the enumeration the way it does now. So it seems your best options are: a) leave the tests in Prepare() alone and make it clear to subclass authors that the index passed to GetPole/Zero() ranges over both members of any complex root pairs. b) have Prepare() count only up to "stages" and let subclasses specify each stage as a unit (two Complex values which Prepare() combines with their conjugates if nonreal), rather than treating poles and zeros separately. Subclasses get to decide whether real roots are combined into 2nd-order sections or are turned into stages of their own. I think this raises no technical problem once the cleverness in Set*Stage is dropped, and it saves the currently wasted half of Prepare()'s computation. Martin From martin.eisenberg at udo.edu Sat May 23 14:22:54 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Sat May 23 14:20:41 2009 Subject: [music-dsp] Analog Filter Prototypes References: <805920.93843.qm@web58206.mail.re3.yahoo.com> Message-ID: <001501c9dbd3$8656fd00$0201a8c0@mooncode> Vinnie wrote: > The placement of poles and zeroes on the s-plane comprises the > "analog prototype", while the bilinear transformation and > resulting stage coefficients comprise the "digital filter > realization"? Yes, that's right. In analog filtering, a prototype filter has a critical frequency of unity and the final design is derived by scaling the s variable by the target frequency. When designing a digital filter, this scaling and the BLT may be introduced at various points (all leading to equivalent procedures, of course) -- so the connotation may be lost there, although "the" s-plane that the prototype lives in is still not necessarily the one corresponding to physical frequency. Martin From thevinn at yahoo.com Sat May 23 17:21:16 2009 From: thevinn at yahoo.com (Vinnie) Date: Sat May 23 17:21:28 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes Message-ID: <29303.42395.qm@web58202.mail.re3.yahoo.com> > From: "Martin Eisenberg" > If I remember well you took that part from a standalone > coefficient generator. There, one obviously wants to obtain > the most compact equivalent form of any given higher-order > filter. So if, for some design parameters, the denominators of two > stages' transfer functions happen to come out as less than 2nd > order then it's economical to combine them by multiplying the > z-polynomials. It took some time but I understand the cascade well enough to fix SetAStage() and SetBStage() so they execute in constant time. First of all the test for if( c.imag()>0 ) was essential because without it, too many stages try to get set. There is no one to one mapping of stages and pole indices. I stepped through construction of the cascade for a few different cases and the array does not get filled in an orderly, linear fashion. I wrote some code to shuffle the A portions and B portions of the stages independently to verify that the order and grouping of the A and B coefficients doesn't matter. Even with a shuffle, the filter's output was the same. Finally, I rewrote SetAStage() and SetBStage() to execute in constant time. The front of the cascade is used as a holding area for polynomials that are less than second order. If a stage is set with a full 2nd order polynomial, it is parked off at the end of the stage array. When the holding area reaches degree 2, it is shuffled off to the "full" portion of the stage array. m_nfulla is set to 0 every time the coefficients are reset. SetBStage() works in a similar fashion: inline void CascadeFilter::SetAStage( CalcT x1, CalcT x2 ) { if( x2!=0 ) { Stage *s=m_stagep+m_nstage-1-m_nfulla; assert( s->a[1]==0 && s->a[2]==0 ); s->a[1]=x1; s->a[2]=x2; m_nfulla++; } else { // combine Stage *s=m_stagep; s->a[2]=-s->a[1]*x1; s->a[1]+=x1; if( s->a[2]!=0 ) { int n=m_nstage-1-m_nfulla; if( n>0 ) { Stage *f=m_stagep+n; f->a[1]=s->a[1]; f->a[2]=s->a[2]; s->a[1]=0; s->a[2]=0; m_nfulla++; } } } } I am trying to further my understanding of digital filters by studying the transfer functions and looking at analog prototypes. I'm making progress in some of the books that were previously incomprehensible. The formula for the geometric mean of the passband worked very well, thanks. I am looking for information or references that will let me squeeze all pass, peaking eq, low shelf, and high shelf variations out of the existing filters. Perhaps through some type of transformation? I am trying to find literature that describes this process for N-order filters. Or am I searching for the wrong thing? After I get some more of the suggestions implemented I will post a new version. Thanks to everyone for helping this newb! From martin.eisenberg at udo.edu Sun May 24 15:23:44 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Sun May 24 15:21:31 2009 Subject: [music-dsp] Name of delay-free loop technique References: <002401c9d7d1$0aee5ce0$0201a8c0@mooncode><56BDCC96E6B94AF5BC7DF68F893A63C1@nibln01077><001201c9d8a6$2f916bc0$0201a8c0@mooncode> Message-ID: <001201c9dca5$332d6f60$0201a8c0@mooncode> Vadim Zavalishin wrote: >>>> I think that technique could do with a crisp name. What do >>>> you folks think about "deferred state update"? Other takers? >>> >>> For myself I was referring to this thing as simply "instant >>> feedback". >> >> That *is* short but doesn't distinguish the condition from the >> treatment. I've thought of augmenting it to "preserving >> instantaneous feedback" -- alas, it still won't suggest the >> How. > In regards to distinguishing the condition from the treatment, > I don't know if it's really necessary. I just meant that it is a desirable terminological property. Thanks though for pointing out that state update is only possible once the output is known whatever the procedure -- I overlooked that detail ;) My current favorite is "direct implementation" of instantaneity, as opposed to reconfiguring the graph. As you say, there aren't many alternatives to exclude. > What do you also think about "instantaneously unstable" (or is > it instable?) term then? Yes, unstable -- I think it's fitting. You could also say "immediately divergent", but I can't suggest other possible synonyms because I'm not sure what the condition's significance is in a systems context. Let's disregard the location of I/O taps and combine all the filters on the cycle into one filter L = L(z) for simpler discussion. Clearly, the direct-path coefficient k of L is also the first value of the open-loop IR, so if k = 1 then either L is the identity or L has power gain. On the other hand, we can force any lossy or nontrivial allpass filter into instantaneous instability by cascading an additional factor of just the right value. Anyway, there seems to be nothing physically special about that particular gain value in either case. For instance, if we close a loop with feedback gain g around an integrator, the overall analog transfer function is Ha(s) = 1/(s-g) so stability requires g < 0. BLT'ing the integrator with a scale parameter of c gives a digital pole at z = (c+g)/(c-g) and the loop gain is k = g/c, so divergence is immediate if g = 1/c. Now, this is positive by definition of c and hence makes Ha unstable, but the response is still defined for all time. *However* (and I just noticed this), positive g is outside the trapezoidal rule's so-called stability region which only comprises the left half s-plane! So it turns out I can put the canonic label on the phenomenon after all; it is numerical instability due to discretizing an ODE with eigenvalues outside the discretization scheme's (absolute) stability region. The BLT at least preserves stability, while any explicit scheme maps some stable ODEs into unstable recurrences as well. See http://en.wikipedia.org/wiki/Stiff_equation . Sorry if this is a bit stream-of-consciousness, I'm tipsy. Happy barbecue season everyone! Martin From neolit123 at gmail.com Sun May 24 15:36:16 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Sun May 24 15:37:09 2009 Subject: [music-dsp] DSP modeling of the Niveau filter Message-ID: <002401c9dca6$ec9e02b0$0201a8c0@LuboPC> Hello, I'm looking for a paper or a circuit showing exact characteristics (and potential) of the Niveau filter. as a standalone module: http://www.adt-audio.com/Audio_Modules/Mastering/W795_Niveau_Filter.html The filter can also be found in the Elysia compressors. Elysia mpressor manual: http://www.elysia.com/fileadmin/user_upload/Manuals/mpressor/Manual_mpressor_v1.1.pdf ^page 11, 21 - plots here It is essentially a standard "Tilt" equalizer: "...Dependent on the gain settings around a variable center frequency, the high frequencies are boosted whereas the low frequencies are attenuated (or vice versa)." I've already recreated it with two shelfs and some adjustments to try to match the data/plots found in the second document. But I wonder if there is something interesting/extra about the "Niveau" design in particular. Does anyone have additional information on the subject? Regards Lubomir I. Ivanov http://www.tu-varna.bg From rbj at audioimagination.com Sun May 24 22:43:29 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sun May 24 22:43:54 2009 Subject: [music-dsp] DSP modeling of the Niveau filter In-Reply-To: <002401c9dca6$ec9e02b0$0201a8c0@LuboPC> References: <002401c9dca6$ec9e02b0$0201a8c0@LuboPC> Message-ID: On May 24, 2009, at 3:36 PM, Lubomir I. Ivanov wrote: > Hello, > > I'm looking for a paper or a circuit showing exact characteristics > (and potential) of the Niveau filter. > > as a standalone module: > http://www.adt-audio.com/Audio_Modules/Mastering/ > W795_Niveau_Filter.html > > The filter can also be found in the Elysia compressors. Elysia > mpressor manual: > http://www.elysia.com/fileadmin/user_upload/Manuals/mpressor/ > Manual_mpressor_v1.1.pdf > ^page 11, 21 - plots here > > It is essentially a standard "Tilt" equalizer: > "...Dependent on the gain settings around a variable center > frequency, the high frequencies are boosted whereas the low > frequencies are attenuated (or vice versa)." > > I've already recreated it with two shelfs and some adjustments to > try to match the data/plots found in the second document. > But I wonder if there is something interesting/extra about the > "Niveau" design in particular. > Does anyone have additional information on the subject? i have to admit that i never before heard of this Niveau Filter. if it the standard "tilt" filter (does this have anything to do with the analog "Baxandall circuit"?), i think that the odd-symmetric shelf: s/g + 1/Q + 1/(s/g) (s - q)*(s - cong(q)) H(s) = --------------------- = (1/g^2) * ----------------------- g*s + 1/Q + 1/(g*s) (s - p)*(s - cong(p)) is what is most often meant. the analog prototype above is for normalized frequency so it has odd symmetry (log gain and log frequency) around omega=1. it has DC and high-frequency shelves of g^2 and 1/g^2 respectively. and it has roots (if Q>1/2) of poles: p = (1/g)*( -1(2Q) +/- j*sqrt(1-1/(4Q^2)) ) zeros: q = g*( -1(2Q) +/- j*sqrt(1-1/(4Q^2)) ) i think that is the standard tilt analog prototype. to most easily convert to digital, use the Bilinear transform, then substitute: 1 1 - z^-1 (normalized) s <-- ----------- * ---------- tan(w0/2) 1 + z^-1 and use these trig identities: sin(w0) 1 - cos(w0) tan(w0/2) = ------------- (tan(w0/2))^2 = ------------- 1 + cos(w0) 1 + cos(w0) where w0 ("omega_not") is the pivot angular frequency relative to the sampling rate (which is not in angular frequency). if you blast that out, you'll get the same as the shelving filters you see in the audio EQ cookbook, but with a gain adjustment so that at the shelf midpoint (at w0), the gain is 0 dB. anyway, no promises that this is your "Niveau". but it is a tilting filter and with only 2nd order, you don't have many degrees of freedom to play with. in fact, i would comfortably say that it *has* to fit this form *if* the tilt frequency response is odd symmetric in log-gain vs. log-frequency. you get to play with Q and g (and w0), and if symmetry is imposed, there is no other 2nd-order form. i think that's the case. From vadim.zavalishin at native-instruments.de Mon May 25 06:32:48 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Mon May 25 06:33:05 2009 Subject: [music-dsp] Analog Filter Prototypes In-Reply-To: <001501c9dbd3$8656fd00$0201a8c0@mooncode> References: <805920.93843.qm@web58206.mail.re3.yahoo.com> <001501c9dbd3$8656fd00$0201a8c0@mooncode> Message-ID: <3C3B70353E1F494197F9CC869C7F03B5@nibln01077> > Vinnie wrote: > >> The placement of poles and zeroes on the s-plane comprises the >> "analog prototype", while the bilinear transformation and >> resulting stage coefficients comprise the "digital filter >> realization"? > > Yes, that's right. In analog filtering, a prototype filter has a > critical frequency of unity and the final design is derived by > scaling the s variable by the target frequency. When designing a > digital filter, this scaling and the BLT may be introduced at > various points (all leading to equivalent procedures, of > course) -- so the connotation may be lost there, although "the" > s-plane that the prototype lives in is still not necessarily the > one corresponding to physical frequency. IMHO the topology of the analog prototype constitutes an equally important (or even more important) part. The s-plane representation (transfer function) basically describes only the static behavior of the system. However its the topological aspects which contain essential information about the time-variant behavior (the behavior in case of varying parameters). In that sense I'd rather understand the analog prototype as a block-diagram containing integrators (while the digital block-diagram contains unit delays). One can easily check the importance of the topological aspects by comparing the time-variant behavior of e.g. a 2nd order discrete-time direct form (I or II) against the one which has the preserved topology of the classical analog prototype (while there is of course a variation in the topology of the analog prototype as well). In that respect the bilinear transformation in its simplest understanding is a way to convert the transfer function from s- to z-plane. However, one can instead apply it to the differential equations or to the block-diagram, thereby preserving (to a large extent) the time-variant behavior of the system. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From vadim.zavalishin at native-instruments.de Mon May 25 07:12:04 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Mon May 25 07:12:10 2009 Subject: [music-dsp] Name of delay-free loop technique In-Reply-To: <001201c9dca5$332d6f60$0201a8c0@mooncode> References: <002401c9d7d1$0aee5ce0$0201a8c0@mooncode><56BDCC96E6B94AF5BC7DF68F893A63C1@nibln01077><001201c9d8a6$2f916bc0$0201a8c0@mooncode> <001201c9dca5$332d6f60$0201a8c0@mooncode> Message-ID: <86DBA60A6D954C829C23571C46248EFE@nibln01077> > I just meant that it is a desirable terminological property. > Thanks though for pointing out that state update is only possible > once the output is known whatever the procedure -- I overlooked > that detail ;) My current favorite is "direct implementation" of > instantaneity, as opposed to reconfiguring the graph. As you say, > there aren't many alternatives to exclude. That's my favorite as well. Anyway, I think both approaches are formally equivalent. > >> What do you also think about "instantaneously unstable" (or is >> it instable?) term then? > > ... > > For instance, if we close a loop with feedback gain g around an > integrator, the overall analog transfer function is Ha(s) = > 1/(s-g) so stability requires g < 0. BLT'ing the integrator with > a scale parameter of c gives a digital pole at z = (c+g)/(c-g) > and the loop gain is k = g/c, so divergence is immediate if g = > 1/c. Now, this is positive by definition of c and hence makes Ha > unstable, but the response is still defined for all time. > *However* (and I just noticed this), positive g is outside the > trapezoidal rule's so-called stability region which only > comprises the left half s-plane! > > ... > I think what I was referring to is slightly different. I do want to include unstable systems into the analysis (e.g. self-oscillating filters). However, there are unstable cases where the solution of the feedback equation produces a "wrong" result. In fact the solution of the feedback equation yields the stability point, but it's not guaranteed that this stability point is to be reached. This is what I referred to in my article as "non-zero impedance approach". I believe you could explicitly obtain the same result with the approach of the Harma's article you pointed me to, except instead of a unit delay running at a very high sampling rate in the feedback path you need to use a lowpass filter with a very high cutoff running at a very high sampling rate. I once did the same in the continuous time domain, obtaining similar results. Usually you don't run into this problem. However e.g. for the ladder filter model (which is a particular case of the structure in Fig.3 in my article) you run into this case at k<-1. Interestingly, this also corresponds to having more than one solution for the nonlinear case, for a typical shape of the nonlinearity (linear around zero, then clipping/saturating). So, while 1+gk is not zero, the straightforward solution of the feedback equation is wrong. Instead, the system reaches infinitely high level (unless there is saturation) within a single sample. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From martin.eisenberg at udo.edu Mon May 25 07:36:48 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Mon May 25 07:34:30 2009 Subject: [music-dsp] Analog Filter Prototypes References: <805920.93843.qm@web58206.mail.re3.yahoo.com><001501c9dbd3$8656fd00$0201a8c0@mooncode> <3C3B70353E1F494197F9CC869C7F03B5@nibln01077> Message-ID: <001101c9dd2d$1ddf2580$0201a8c0@mooncode> Vadim Zavalishin wrote: >> In analog filtering, a prototype filter has a critical frequency of >> unity and the final design is derived by scaling the s variable >> by the target frequency. > IMHO the topology of the analog prototype constitutes an > equally important (or even more important) part. I'll take your word for it regarding EE but I believe it's not what "prototype" suggests in the general DSP literature. Just google 'prototype iir design', or look at Orfanidis' EQ papers (although he tends to call the animal "equivalent analog filter" over "analog prototype filter"). > In that respect the bilinear transformation in its simplest > understanding is a way to convert the transfer function from > s- to z-plane. However, one can instead apply it to the > differential equations or to the block-diagram, thereby > preserving (to a large extent) the time-variant behavior of > the system. What influences transient behavior is not which representation of a system you transform but how freely you shuffle the symbols afterwards. Applying the BLT to the TF by substituting for s is exactly the same thing as replacing integrators in the block diagram. Likewise, putting the digital TF into single-fraction form is exactly the same as isolating the latest output on one side of the discretized ODE. On the other hand, leaving the TF as a multiple fraction can be construed to indicate the direct delay-free realization. Martin From vadim.zavalishin at native-instruments.de Mon May 25 07:42:06 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Mon May 25 07:42:15 2009 Subject: [music-dsp] Analog Filter Prototypes In-Reply-To: <001101c9dd2d$1ddf2580$0201a8c0@mooncode> References: <805920.93843.qm@web58206.mail.re3.yahoo.com><001501c9dbd3$8656fd00$0201a8c0@mooncode><3C3B70353E1F494197F9CC869C7F03B5@nibln01077> <001101c9dd2d$1ddf2580$0201a8c0@mooncode> Message-ID: <01D17B6387E64737A616AE5655CFC863@nibln01077> -> I'll take your word for it regarding EE but I believe it's not > what "prototype" suggests in the general DSP literature. Just > google 'prototype iir design', or look at Orfanidis' EQ papers > (although he tends to call the animal "equivalent analog filter" > over "analog prototype filter"). Yes, commonly one cares only about the transfer function. But if one is concerned about the topology as well, then the block-diagram becomes the prototype. Therefore, if one abstracts from the form and concentrates on the purpose, there is nothing uncommon in my usage of the word "prototype". I actually woudn't know about EE :-) > >> In that respect the bilinear transformation in its simplest >> understanding is a way to convert the transfer function from >> s- to z-plane. However, one can instead apply it to the >> differential equations or to the block-diagram, thereby >> preserving (to a large extent) the time-variant behavior of >> the system. > > What influences transient behavior is not which representation of > a system you transform but how freely you shuffle the symbols > afterwards. Applying the BLT to the TF by substituting for s is > exactly the same thing as replacing integrators in the block > diagram. Only in the respect to the transfer function. You lose all other information. There is no difference in the time-invariant case, but systems with the same transfer function will exhibit different time-variant behaviors. Even in the analog domain. Simplest example - putting a variable gain module before the integrator or afterwards. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From martin.eisenberg at udo.edu Mon May 25 08:47:29 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Mon May 25 08:45:04 2009 Subject: [music-dsp] DSP modeling of the Niveau filter References: <002401c9dca6$ec9e02b0$0201a8c0@LuboPC> Message-ID: <001701c9dd36$f9d925a0$0201a8c0@mooncode> Lubomir I. Ivanov wrote: >> I've already recreated it with two shelfs and some >> adjustments to try to match the data/plots found in the >> second document. Might it not be a single scaled 1st-order shelf, given that Elysia's filter becomes a 6dB/oct filter when one band gain goes to zero? Martin From martin.eisenberg at udo.edu Mon May 25 10:12:42 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Mon May 25 10:10:11 2009 Subject: [music-dsp] Analog Filter Prototypes References: <805920.93843.qm@web58206.mail.re3.yahoo.com><001501c9dbd3$8656fd00$0201a8c0@mooncode><3C3B70353E1F494197F9CC869C7F03B5@nibln01077><001101c9dd2d$1ddf2580$0201a8c0@mooncode> <01D17B6387E64737A616AE5655CFC863@nibln01077> Message-ID: <000f01c9dd42$e1de6bc0$0201a8c0@mooncode> Vadim Zavalishin wrote: >> What influences transient behavior is not which >> representation of a system you transform but how freely you >> shuffle the symbols afterwards. Applying the BLT to the TF by >> substituting for s is exactly the same thing as replacing >> integrators in the block diagram. > > Only in the respect to the transfer function. You lose all > other information. Again, only once you choose to view the immediate substitution result as a mathematical rather than typographical object and thus further manipulate it in ways that preserve the former but erase the latter. But lest I turn into a crank, I'll stop emphasizing the distinction now. Martin From vadim.zavalishin at native-instruments.de Mon May 25 10:43:14 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Mon May 25 10:43:29 2009 Subject: [music-dsp] Analog Filter Prototypes In-Reply-To: <000f01c9dd42$e1de6bc0$0201a8c0@mooncode> References: <805920.93843.qm@web58206.mail.re3.yahoo.com><001501c9dbd3$8656fd00$0201a8c0@mooncode><3C3B70353E1F494197F9CC869C7F03B5@nibln01077><001101c9dd2d$1ddf2580$0201a8c0@mooncode><01D17B6387E64737A616AE5655CFC863@nibln01077> <000f01c9dd42$e1de6bc0$0201a8c0@mooncode> Message-ID: <37DCC735399940C9B41AB50585FBA190@nibln01077> >>> What influences transient behavior is not which >>> representation of a system you transform but how freely you >>> shuffle the symbols afterwards. Applying the BLT to the TF by >>> substituting for s is exactly the same thing as replacing >>> integrators in the block diagram. >> >> Only in the respect to the transfer function. You lose all >> other information. > > Again, only once you choose to view the immediate substitution > result as a mathematical rather than typographical object and > thus further manipulate it in ways that preserve the former but > erase the latter. But lest I turn into a crank, I'll stop > emphasizing the distinction now. Well, frankly speaking I'd appreciate you giving a simple example. Because it seems to me there's a misunderstanding either on mine or on your side. As a reminder: the goal is to preserve the time-variant behavior of the system as much as possible (or reasonably close to that) during the transform. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From martin.eisenberg at udo.edu Mon May 25 10:54:37 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Mon May 25 10:52:16 2009 Subject: [music-dsp] Name of delay-free loop technique References: <002401c9d7d1$0aee5ce0$0201a8c0@mooncode><56BDCC96E6B94AF5BC7DF68F893A63C1@nibln01077><001201c9d8a6$2f916bc0$0201a8c0@mooncode><001201c9dca5$332d6f60$0201a8c0@mooncode> <86DBA60A6D954C829C23571C46248EFE@nibln01077> Message-ID: <001301c9dd48$bceb70a0$0201a8c0@mooncode> Vadim Zavalishin wrote: >> For instance, if we close a loop with feedback gain g around >> an integrator, the overall analog transfer function is Ha(s) = >> 1/(s-g) so stability requires g < 0. BLT'ing the integrator >> with a scale parameter of c gives a digital pole at z = >> (c+g)/(c-g) and the loop gain is k = g/c, so divergence is >> immediate if g = 1/c. Now, this is positive by definition of >> c and hence makes Ha unstable, but the response is still >> defined for all time. *However* (and I just noticed this), >> positive g is outside the trapezoidal rule's so-called >> stability region which only comprises the left half s-plane! > I think what I was referring to is slightly different. I do > want to include unstable systems into the analysis (e.g. > self-oscillating filters). Yes, and you run into the problem that numerical integrators are not designed for and make no guarantees of physical plausibility about truly unstable systems. That is what I realized. Now, saturated systems are another matter, but only if the scheme sees the whole system or at least a local linearization where growing modes won't persist. > However, there are unstable cases > where the solution of the feedback equation produces a "wrong" > result. In fact the solution of the feedback equation yields > the stability point, but it's not guaranteed that this > stability point is to be reached. This is what I referred to > in my article as "non-zero impedance approach". Otherwise known as solving equations by iteration. > I believe you > could explicitly obtain the same result with the approach of > the Harma's article you pointed me to, except instead of a > unit delay running at a very high sampling rate in the > feedback path you need to use a lowpass filter with a very > high cutoff running at a very high sampling rate. I don't understand -- there are no artificial delays in that work. > Usually you don't run into this problem. However e.g. for the > ladder filter model (which is a particular case of the > structure in Fig.3 in my article) you run into this case at > k<-1. Do I understand well that that's outside the usual regime, creating a dip instead of the resonance peak? > So, while 1+gk is not zero, the straightforward solution of > the feedback equation is wrong. Instead, the system reaches > infinitely high level (unless there is saturation) within a > single sample. What's the mechanism here if 1+gk is nonzero? Martin From vadim.zavalishin at native-instruments.de Mon May 25 11:34:16 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Mon May 25 11:34:33 2009 Subject: [music-dsp] Name of delay-free loop technique In-Reply-To: <001301c9dd48$bceb70a0$0201a8c0@mooncode> References: <002401c9d7d1$0aee5ce0$0201a8c0@mooncode><56BDCC96E6B94AF5BC7DF68F893A63C1@nibln01077><001201c9d8a6$2f916bc0$0201a8c0@mooncode><001201c9dca5$332d6f60$0201a8c0@mooncode><86DBA60A6D954C829C23571C46248EFE@nibln01077> <001301c9dd48$bceb70a0$0201a8c0@mooncode> Message-ID: > Yes, and you run into the problem that numerical integrators are > not designed for and make no guarantees of physical plausibility > about truly unstable systems. That is what I realized. Now, > saturated systems are another matter, but only if the scheme sees > the whole system or at least a local linearization where growing > modes won't persist. Yes, of course this was discussed with a purpose of further extrapolation to the nonlinear case. > >> However, there are unstable cases >> where the solution of the feedback equation produces a "wrong" >> result. In fact the solution of the feedback equation yields >> the stability point, but it's not guaranteed that this >> stability point is to be reached. This is what I referred to >> in my article as "non-zero impedance approach". > > Otherwise known as solving equations by iteration. I think the convergence conditions are different. E.g. let u[n]=x[n]+k*y[n] y[n]=g*u[n]+s be a system with delayless feedback. The stability point is y=(g*x+s)/(1-g*k) Using the non-zero impedance approach we conclude that the stability point is reached whenever 1-g*k > 0 (the intuitive way would be to check whether the output signal "wants" to go in the direction of the stability point). The simple iteration converges only if |g*k|<1 > >> I believe you >> could explicitly obtain the same result with the approach of >> the Harma's article you pointed me to, except instead of a >> unit delay running at a very high sampling rate in the >> feedback path you need to use a lowpass filter with a very >> high cutoff running at a very high sampling rate. > > I don't understand -- there are no artificial delays in that > work. On the second page in the third paragraph, where the author is talking about approximately free delay loop. I think that is basically equivalent to the simple iteration. > >> Usually you don't run into this problem. However e.g. for the >> ladder filter model (which is a particular case of the >> structure in Fig.3 in my article) you run into this case at >> k<-1. > > Do I understand well that that's outside the usual regime, > creating a dip instead of the resonance peak? That's right, it's kind of negative resonance. Although there's no real dip, IIRC. > >> So, while 1+gk is not zero, the straightforward solution of >> the feedback equation is wrong. Instead, the system reaches >> infinitely high level (unless there is saturation) within a >> single sample. > > What's the mechanism here if 1+gk is nonzero? > Usually you reach the stability point. Otherwise see my previous example (except that I switched the sign of k for convenience). Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From rbj at audioimagination.com Mon May 25 12:12:43 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Mon May 25 12:13:09 2009 Subject: [music-dsp] Analog Filter Prototypes In-Reply-To: <001501c9dbd3$8656fd00$0201a8c0@mooncode> References: <805920.93843.qm@web58206.mail.re3.yahoo.com> <001501c9dbd3$8656fd00$0201a8c0@mooncode> Message-ID: On May 23, 2009, at 2:22 PM, Martin Eisenberg wrote: > Vinnie wrote: > >> The placement of poles and zeroes on the s-plane along with a constant gain term >> comprises the >> "analog prototype", while the bilinear transformation and >> resulting stage coefficients comprise the "digital filter >> realization"? > > Yes, that's right. In analog filtering, a prototype filter has a > critical frequency of unity sometimes i call that "normalized s". > and the final design is derived by > scaling the s variable by the target frequency. When designing a > digital filter, this scaling and the BLT may be introduced at > various points (all leading to equivalent procedures, of > course) -- so the connotation may be lost there, although "the" > s-plane that the prototype lives in is still not necessarily the > one corresponding to physical frequency. i'm piping in late, but if your analog prototype has normalized s (as it should, where everything is happening at 2*pi*f = 1), then you can take care of the scaling *and* the BLT conversion to z in one fell swoop. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From neolit123 at gmail.com Mon May 25 12:13:07 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Mon May 25 12:14:47 2009 Subject: [music-dsp] DSP modeling of the Niveau filter References: <002401c9dca6$ec9e02b0$0201a8c0@LuboPC> Message-ID: <003301c9dd53$c7886a80$0201a8c0@LuboPC> Thank you for the detailed explanation, Robert. I will give the odd-symmetric a spin with some code later on. > (does this have anything to do with the analog "Baxandall circuit"?) The "Baxandall" and the "Tilt" aren't exactly the same circuits. But they definitively have similar applications. Both are fairly simple to construct too. Cost wise, (a guess) the impedance accommodation stage for both, may cost more than the actual filter stage. The "Baxandall" can be used for correction of the loudness contour (Fletcher-Munson), since it boost/cuts the high & low end at the same time, while the "Tilt" cuts one portion of the spectrum and boost the other. Interesting pricing on that "Niveau" module as well...It also includes an elliptic high-pass for the 'side' processing (M/S). Lubomir ----- Original Message ----- From: "robert bristow-johnson" To: "A discussion list for music-related DSP" Sent: Monday, May 25, 2009 5:43 AM Subject: Re: [music-dsp] DSP modeling of the Niveau filter > > On May 24, 2009, at 3:36 PM, Lubomir I. Ivanov wrote: > >> Hello, >> >> I'm looking for a paper or a circuit showing exact characteristics (and >> potential) of the Niveau filter. >> >> as a standalone module: >> http://www.adt-audio.com/Audio_Modules/Mastering/ W795_Niveau_Filter.html >> >> The filter can also be found in the Elysia compressors. Elysia mpressor >> manual: >> http://www.elysia.com/fileadmin/user_upload/Manuals/mpressor/ >> Manual_mpressor_v1.1.pdf >> ^page 11, 21 - plots here >> >> It is essentially a standard "Tilt" equalizer: >> "...Dependent on the gain settings around a variable center frequency, >> the high frequencies are boosted whereas the low frequencies are >> attenuated (or vice versa)." >> >> I've already recreated it with two shelfs and some adjustments to try to >> match the data/plots found in the second document. >> But I wonder if there is something interesting/extra about the "Niveau" >> design in particular. >> Does anyone have additional information on the subject? > > > i have to admit that i never before heard of this Niveau Filter. if it > the standard "tilt" filter (does this have anything to do with the analog > "Baxandall circuit"?), i think that the odd-symmetric shelf: > > s/g + 1/Q + 1/(s/g) (s - q)*(s - cong(q)) > H(s) = --------------------- = (1/g^2) * ----------------------- > g*s + 1/Q + 1/(g*s) (s - p)*(s - cong(p)) > > is what is most often meant. > > the analog prototype above is for normalized frequency so it has odd > symmetry (log gain and log frequency) around omega=1. > > it has DC and high-frequency shelves of g^2 and 1/g^2 respectively. and > it has roots (if Q>1/2) of > > poles: p = (1/g)*( -1(2Q) +/- j*sqrt(1-1/(4Q^2)) ) > > zeros: q = g*( -1(2Q) +/- j*sqrt(1-1/(4Q^2)) ) > > > i think that is the standard tilt analog prototype. to most easily > convert to digital, use the Bilinear transform, then substitute: > > 1 1 - z^-1 > (normalized) s <-- ----------- * ---------- > tan(w0/2) 1 + z^-1 > > and use these trig identities: > > sin(w0) 1 - cos(w0) > tan(w0/2) = ------------- (tan(w0/2))^2 = ------------- > 1 + cos(w0) 1 + cos(w0) > > > where w0 ("omega_not") is the pivot angular frequency relative to the > sampling rate (which is not in angular frequency). > > if you blast that out, you'll get the same as the shelving filters you > see in the audio EQ cookbook, but with a gain adjustment so that at the > shelf midpoint (at w0), the gain is 0 dB. > > anyway, no promises that this is your "Niveau". but it is a tilting > filter and with only 2nd order, you don't have many degrees of freedom to > play with. in fact, i would comfortably say that it *has* to fit this > form *if* the tilt frequency response is odd symmetric in log-gain vs. > log-frequency. you get to play with Q and g (and w0), and if symmetry is > imposed, there is no other 2nd-order form. i think that's the case. > > -- > 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 neolit123 at gmail.com Mon May 25 12:24:24 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Mon May 25 12:25:25 2009 Subject: [music-dsp] DSP modeling of the Niveau filter References: <002401c9dca6$ec9e02b0$0201a8c0@LuboPC> <001701c9dd36$f9d925a0$0201a8c0@mooncode> Message-ID: <003a01c9dd55$4bec3620$0201a8c0@LuboPC> >>> I've already recreated it with two shelfs and some >>> adjustments to try to match the data/plots found in the >>> second document. > > Might it not be a single scaled 1st-order shelf, given that > Elysia's filter becomes a 6dB/oct filter when one band gain goes > to zero? > > > Martin > I've just chained two shelfs for my previous test, mainly to check the sound of the instantaneous boosting and cutting. But yes, 1str order low/pass filter shoots in different direction. And its is probably in the lines of this. (just did some test and worked this one out...) ------------------------------------------ //======================= // tilt filter settings //======================= gain = 6; //range is -6 / +6 in dB amp = 6/log(2); // dB scale pi = 22/7; f0 = 500; // range is 20-20000 in Hz //conditition; factor '3' reduces the opposing range (below or above f0) //it is possible here to create a proportional gain reduction so that one of the ranges is reduced to zero //probabaly an exponent will do better. if (gain > 0) ? { g1 = -3*gain; g2 = gain; } : { g1 = -gain; g2 = 3*gain; }; //two separate gains low_gain = exp(g1/amp)-1; high_gain = exp(g2/amp)-1; //filter k = exp(-2*pi*f0/samplerate); a0 = 1-k; b1 = -k; //================ // per sample //================ // 'input' - input sample // 'lp_out' - low pass // 'output' - resulted sample lp_out = a0*input - b1*lp_out; output = input + low_gain*lp_out + high_gain*(input - lp_out); ------------------------------------------ Not the exact same behaviour as seen in their plots but similar: highboost: http://img509.imageshack.us/img509/9962/highboost.png lowboost: http://img509.imageshack.us/img509/4336/lowboost.png Probably will tweak it a bit more and post in the source code archive... Any suggestions are welcome of course. Lubomir From rbj at audioimagination.com Mon May 25 12:39:25 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Mon May 25 12:39:42 2009 Subject: [music-dsp] DSP modeling of the Niveau filter In-Reply-To: <003301c9dd53$c7886a80$0201a8c0@LuboPC> References: <002401c9dca6$ec9e02b0$0201a8c0@LuboPC> <003301c9dd53$c7886a80$0201a8c0@LuboPC> Message-ID: <9868CB14-BC16-425B-AF8C-47A41C67EED9@audioimagination.com> On May 25, 2009, at 12:13 PM, Lubomir I. Ivanov wrote: > Thank you for the detailed explanation, Robert. i just yanked it from the cookbook and took out the constant gain of "A" to put the shelf midpoint at 0 dB. > I will give the odd-symmetric a spin with some code later on. > >> (does this have anything to do with the analog "Baxandall circuit"?) > > The "Baxandall" and the "Tilt" aren't exactly the same circuits. > But they definitively have similar applications. > Both are fairly simple to construct too. do you have a schematic of the "Tilt" filter? if it's simple, can you draw it here (with ASCII art) or point to a page that shows it? > Cost wise, (a guess) the impedance accommodation stage for both, > may cost more than the actual filter stage. > The "Baxandall" can be used for correction of the loudness contour > (Fletcher-Munson), since it boost/cuts the high & low end at the > same time, > while the "Tilt" cuts one portion of the spectrum and boost the other. well, if you're doing this with 2nd-order filters, there is a limited number of independent ways of doing it. and if differences of merely human definitions of parameters are accounted for, that limited number might be 1. > Interesting pricing on that "Niveau" module as well...It also > includes an elliptic high-pass for the 'side' processing (M/S). i'm generally skeptical about using anything elliptical in any audio application. i thought this book by Grover and Deller, "Digital Signal Processing and the Microcontroller" (poorly titled) said it best (regarding the phase linearity of elliptical filters): "Drunk fly on cross-country skis in tornado". -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From neolit123 at gmail.com Mon May 25 12:58:50 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Mon May 25 12:59:52 2009 Subject: [music-dsp] DSP modeling of the Niveau filter References: <002401c9dca6$ec9e02b0$0201a8c0@LuboPC><003301c9dd53$c7886a80$0201a8c0@LuboPC> <9868CB14-BC16-425B-AF8C-47A41C67EED9@audioimagination.com> Message-ID: <000801c9dd5a$1ad79160$0201a8c0@LuboPC> From: "robert bristow-johnson" > do you have a schematic of the "Tilt" filter? if it's simple, can you > draw it here (with ASCII art) or point to a page that shows it? There is a good example at "headwize": http://www.headwize.com/projects/equal_prj.htm Note that the given curcuit is supposed to provide the "mirrored tilt" (in regard of magnitude) there are also "wien bridge"- resonant, tube, "baxandall" etc. > i thought this book by Grover and Deller, "Digital Signal Processing and > the Microcontroller" (poorly titled) said it best (regarding the phase > linearity of elliptical filters): "Drunk fly on cross-country skis in > tornado". I guess this comparison tries to summarize the charismatic transfer function of the Elliptic ;)) Lubomir From rbj at audioimagination.com Tue May 26 01:51:32 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Tue May 26 01:51:56 2009 Subject: [music-dsp] DSP modeling of the Niveau filter In-Reply-To: <000801c9dd5a$1ad79160$0201a8c0@LuboPC> References: <002401c9dca6$ec9e02b0$0201a8c0@LuboPC><003301c9dd53$c7886a80$0201a8c0@LuboPC> <9868CB14-BC16-425B-AF8C-47A41C67EED9@audioimagination.com> <000801c9dd5a$1ad79160$0201a8c0@LuboPC> Message-ID: <30CBE174-4729-4A33-87C5-E49E0835BB6C@audioimagination.com> On May 25, 2009, at 12:58 PM, Lubomir I. Ivanov wrote: > From: "robert bristow-johnson" > >> do you have a schematic of the "Tilt" filter? if it's simple, >> can you draw it here (with ASCII art) or point to a page that >> shows it? > > There is a good example at "headwize": > http://www.headwize.com/projects/equal_prj.htm > Note that the given curcuit is supposed to provide the "mirrored > tilt" (in regard of magnitude) > there are also "wien bridge"- resonant, tube, "baxandall" etc. Lubomir, this is very good. I've never seen this nice collection of analog history. i sorta wish there were H(s) transfer functions (because i'm lazy), but perhaps i can just figure it out. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From vadim.zavalishin at native-instruments.de Tue May 26 06:31:20 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Tue May 26 06:31:33 2009 Subject: [music-dsp] Name of delay-free loop technique In-Reply-To: <86DBA60A6D954C829C23571C46248EFE@nibln01077> References: <002401c9d7d1$0aee5ce0$0201a8c0@mooncode><56BDCC96E6B94AF5BC7DF68F893A63C1@nibln01077><001201c9d8a6$2f916bc0$0201a8c0@mooncode><001201c9dca5$332d6f60$0201a8c0@mooncode> <86DBA60A6D954C829C23571C46248EFE@nibln01077> Message-ID: <029244E7BAD549C78B29E3DAB113FC06@nibln01077> > This is what I referred to in my article as "non-zero impedance approach". > I believe you could explicitly obtain the same result with the approach of > the Harma's article you pointed me to, except instead of a unit delay > running at a very high sampling rate in the feedback path you need to use > a lowpass filter with a very high cutoff running at a very high sampling > rate. I once did the same in the continuous time domain, obtaining similar > results. Correction: you should rather do it in the continuous time domain. So the main part of the discrete-time structure is frozen in time, while the delayless feedback is considered to be continuous-time. Now insert a lowpass filter into the feedback. Let f be the filter cutoff. Let the feedback run over the time period deltaT. Now let f approach infinity and deltaT approach zero, where f is approaching infinity "faster" than deltaT is approaching zero, so that their product is approaching infinity. If such system is unstable, then I'd say that the delayless feedback is "instantly unstable" and the value reaches infinity "within a single sample". Otherwise the delayless feedback converges to the point of stability within the same sample and you can simply solve the feedback equation. Notably, while for the ladder filter the instantly unstable case occurs in a rather exotic negative resonance case k<-1, for a state-variable filter you get it for very strong resonances (1/Q<-2). This information is sometimes important when nonlinearities are introduced. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From avanzini at dei.unipd.it Thu May 28 04:16:46 2009 From: avanzini at dei.unipd.it (federico avanzini) Date: Thu May 28 04:17:06 2009 Subject: [music-dsp] PhD fellowships for foreign candidates in Padova Message-ID: <4A1E486E.8080400@dei.unipd.it> [Apologies for cross-postings] The University of Padova, through the funding of the Fondazione Cassa di Risparmio di Padova e Rovigo, offers 15 research fellowships for foreign candidates to Doctoral Schools/International Courses. These include the Doctoral School in Information Engineering, with a research line in Sound and Music Computing. During the 3-year doctoral programme, successful candidates will be offered full board and lodging. Deadline for applications: September 3, 2009 Call for applications, instructions, and documentation: http://www.unipd.it/en/doctorates/grants.htm PhD school in Information Engineering: http://www.dei.unipd.it/phd Contact for projects in Sound and Music Computing: Federico Avanzini ---------------------------------------- Federico Avanzini, PhD Sound and Music Computing Group Dep. of Information Engineering University of Padova Via Ognissanti 72 I-35129 Padova - ITALY Skype: federico.avanzini Tel: +39 049 827 7856 Fax: +39 049 827 7826 http://smc.dei.unipd.it http://www.dei.unipd.it/~avanzini ---------------------------------------- From moore at sevenwoodsaudio.com Thu May 28 15:43:06 2009 From: moore at sevenwoodsaudio.com (Christopher Moore) Date: Thu May 28 16:33:02 2009 Subject: [music-dsp] Tilt tone control (Niveau filter?) and other related issues Message-ID: <4A1EE94A.1000602@sevenwoodsaudio.com> I think you are talking about a tone control found on older Quad hifi preamps: they called it a tilt control. There is an analog schematic in JJ Linsley-Hood's hardback tome on audio circuits. It is quite simple and it works. But I question the utility of a tilt circuit. Various sources of frequency response errors don't seem to include cases where the whole spectrum is tilted upward or downward. This tilt function is more like an integrator or differentiator. I think Baxandall tone controls are ultimately more useful for home audio use. Why would you want to have the bass cut while you were attempting to give a bit of lift to the treble? For a more complex and probably useful tone control, see the Hood book for the "Clapham Junction" circuit and curves. Other ideas for tone controls can be found in my (Christopher Moore, Seven Woods Audio, www.sevenwoodsaudio.com, Consulting and Articles, AN-12). In AN-12 you can learn how to use a feedforward/feedback architecture to yield shelving EQ and 2nd order boost/cut peaking and notch filters. You achieve symmetric boost and cut curves and can build virtually any EQ on this framework -- graphic, parametric, and shelves. BTW, I once tried to derive a digital implementation and came up against the dreaded "delay-free loop" problem. How to derive the symbolic transfer function of an analog circuit: An endorsement of TINA: TINA (DesignSoft, Budapest), is a multi-faceted SPICE program that will accept as input a schematic and will deduce and present the complex s domain transfer function in polynomial form. It's a very easy way to get transfer functions of analog domain circuits. Chris Moore From neolit123 at gmail.com Fri May 29 06:17:41 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Fri May 29 06:19:15 2009 Subject: [music-dsp] Tilt tone control (Niveau filter?) and other relatedissues References: <4A1EE94A.1000602@sevenwoodsaudio.com> Message-ID: <001901c9e046$c9bfe9e0$0201a8c0@LuboPC> Hello Chris, From: "Christopher Moore" >I think you are talking about a tone control found on older Quad hifi >preamps: they called it a tilt control. There is an analog schematic in JJ >Linsley-Hood's hardback tome on audio circuits. It is quite simple and it >works. > > But I question the utility of a tilt circuit. Various sources of frequency > response errors don't seem to include cases where the whole spectrum is > tilted upward or downward. This tilt function is more like an integrator > or differentiator. I think Baxandall tone controls are ultimately more > useful for home audio use. Why would you want to have the bass cut while > you were attempting to give a bit of lift to the treble? It started to appear in more recent modern audio tools, as a mastering solution. A well known mastering compressor has the "tilt" module included. Its very useful for drastic tonal changes in the lines of "sound sculpting". But I would prefer two separate shelf bass/treble controls for the home stereo system. > For a more complex and probably useful tone control, see the Hood book for > the "Clapham Junction" circuit and curves. > > Other ideas for tone controls can be found in my (Christopher Moore, Seven > Woods Audio, www.sevenwoodsaudio.com, Consulting and Articles, AN-12). In > AN-12 you can learn how to use a feedforward/feedback architecture to > yield shelving EQ and 2nd order boost/cut peaking and notch filters. You > achieve symmetric boost and cut curves and can build virtually any EQ on > this framework -- graphic, parametric, and shelves. BTW, I once tried to > derive a digital implementation and came up against the dreaded > "delay-free loop" problem. I have seen some of your articles before - they look very useful. Lubomir From thevinn at yahoo.com Fri May 29 07:46:31 2009 From: thevinn at yahoo.com (Vinnie) Date: Fri May 29 07:46:58 2009 Subject: [music-dsp] Peaking Filter Transformation Message-ID: <343181.79453.qm@web58205.mail.re3.yahoo.com> Given low pass, high pass, or band pass filter realized as a cascade of second order stage coefficients, is it possible to modify the coefficients (and only the coefficients) in such a way so as to produce a shelving or peaking filter using the following formula: peaking_output = original_input + scale * filter_output Where peaking_output is the output of the new filter, filter_output is the output of the low pass, high pass, or band pass filter upon which the new filter is based, original_input is the current unmodified input sample, and scale=::pow(10.,boostDb/20.)-1 ? From neolit123 at gmail.com Fri May 29 08:36:59 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Fri May 29 08:37:48 2009 Subject: [music-dsp] Peaking Filter Transformation References: <343181.79453.qm@web58205.mail.re3.yahoo.com> Message-ID: <003801c9e05a$2dd6cc60$0201a8c0@LuboPC> Well, using the formula only will result: if (filter_output = lp) [peaking_output] would be a lowshelf if (filter_output = hp) [peaking_output] would be a highshelf if (filter_output = bp) [peaking_output] would be a peak/notch If you modify the coefficients of a IIR filter (for example calculate peak from lowpass), then you will also have to change the way the recursive output is calculated. So if you change the coefficients, where "filter_output" is now a peak/notch filter then the formula would be only: peaking_output = scale*filter_output; and "scale" will act like an output gain. Lubomir ----- Original Message ----- From: "Vinnie" To: Sent: Friday, May 29, 2009 2:46 PM Subject: [music-dsp] Peaking Filter Transformation > > Given low pass, high pass, or band pass filter realized as a cascade of > second order stage coefficients, is it possible to modify the coefficients > (and only the coefficients) in such a way so as to produce a shelving or > peaking filter using the following formula: > > peaking_output = original_input + scale * filter_output > > Where peaking_output is the output of the new filter, filter_output is the > output of the low pass, high pass, or band pass filter upon which the new > filter is based, original_input is the current unmodified input sample, > and scale=::pow(10.,boostDb/20.)-1 > > ? > > -- > 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 neolit123 at gmail.com Fri May 29 09:01:33 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Fri May 29 09:02:25 2009 Subject: [music-dsp] DSP with JesuSonic Message-ID: <005001c9e05d$9f4a0b20$0201a8c0@LuboPC> For those who are starting out in DSP. You may want to check JesuSonic by Cockos (Justin Frankel (Winamp) and company) Its currently only available with the Reaper DAW, but I believe it is soon to be released officially as a standalone VST effect (which then can be loaded in any VST host). http://www.reaper.fm/ Jesusonic: "...JS is a scripting language which is compiled on the fly and allows you to modify and/or generate audio and MIDI, as well as draw custom vector based UI and analysis displays. JS effects are simple text files, which when loaded in REAPER become full featured plug-ins. You can try loading existing JS effects and since they are distributed in source form, you can also edit existing effects to suit your needs (we recommend if editing an existing effect you save it as something with a new name--if you do not you may lose your changes when upgrading REAPER). " Guide: http://www.reaper.fm/sdk/js/js.php Tutorials by Michael Gruhn: http://www.cockos.com/wiki/index.php/1st_Ever_Jesusonic_Tutorial Example code: //----------------------------- desc:Sine-Wave-Generator //----------------------------- @sample spl0 = .125 * sin(2*$pi*440*t); t += 1 / srate ; spl1 = spl0 ; //---------------------------- Everything is double precision. It has build in editor and realtime debugging. You are writing everything in pseudo code, so it is very easy to port to other languages. Lubomir From rbj at audioimagination.com Fri May 29 16:10:55 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Fri May 29 16:11:12 2009 Subject: [music-dsp] Peaking Filter Transformation Message-ID: <20090529161055.10723@web010.roc2.bluetie.com> -----Original Message----- From: "Lubomir I. Ivanov" [neolit123@gmail.com] Date: 05/29/2009 08:37 To: "A discussion list for music-related DSP" ; Subject: Re: [music-dsp] Peaking Filter Transformation > Well, using the formula only will result: > if (filter_output = lp) > [peaking_output] would be a lowshelf > if (filter_output = hp) > [peaking_output] would be a highshelf > if (filter_output = bp) > [peaking_output] would be a peak/notch it is true that adding the output of a 2nd-order BPF to a wire from the input will get you the same peak/notch filter that everybody other than Orfanidis gets (within a variance of definition of the meaning of bandwidth, if the bandwidth of the BPF is taken to be the bandwidth of the peak/notch filter, the boost and cut are not symmetrical). while that is the case, there are different ways of getting the 2nd-order shelves. you can do the above to get a lowshelf or highshelf, but if the LPF or HPF are the basic 2nd-order, adding them to a wire will get you different shelves than those depicted in the Audio EQ Cookbook. that's fine and good, if that is what you want, but shelves constructed this way will have an asymmetrical deep notch (it's from phase cancellation) somewhere around the shelf slope. i've been told by someone i can't remember that this traditional shelf was s'posed to be "more musical". i dunno why that would be but, being 53 and nearly deaf, i might very well miss it. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From martin.eisenberg at udo.edu Sun May 31 14:11:42 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Sun May 31 14:09:37 2009 Subject: [music-dsp] Name of delay-free loop technique References: <002401c9d7d1$0aee5ce0$0201a8c0@mooncode><56BDCC96E6B94AF5BC7DF68F893A63C1@nibln01077><001201c9d8a6$2f916bc0$0201a8c0@mooncode><001201c9dca5$332d6f60$0201a8c0@mooncode><86DBA60A6D954C829C23571C46248EFE@nibln01077> <029244E7BAD549C78B29E3DAB113FC06@nibln01077> Message-ID: <000a01c9e21b$441cc3e0$0201a8c0@mooncode> Vadim Zavalishin wrote: >>> However, there are unstable cases where the solution >>> of the feedback equation produces a "wrong" result. Because the analytic continuation implicit in algebraic manipulation is then inappropriate -- I see it now. Thank you! > Now insert a lowpass filter into the feedback. Let f be the > filter cutoff. Let the feedback run over the time period deltaT. > Now let f approach infinity and deltaT approach zero, where > f is approaching infinity "faster" than deltaT is approaching > zero, so that their product is approaching infinity. While this description differs somewhat from that in your article, you still end up looking for the final value of a step response, no? This double-limit business would thus seem overcomplicated. Martin