From douglas at roar.music.columbia.edu Sat Jan 1 00:00:01 2005 From: douglas at roar.music.columbia.edu (douglas repetto) Date: Sun Jan 21 12:10:59 2007 Subject: [music-dsp] [admin] music-dsp FAQ Message-ID: <200501010500.j01501UW031863@roar.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://shoko.calarts.edu/musicdsp/musicdspFAQ.html also of interest to new and not-so-new list members: the music-dsp list archives http://shoko.calarts.edu/musicdsp/musicdsparchives.html the music-dsp source code archive http://www.musicdsp.org music-dsp books and reviews http://shoko.calarts.edu/musicdsp/dspbooks.html all this and more at: http://shoko.calarts.edu/musicdsp hotdawg! douglas (this is an automated message sent out on the 1st and 15th of each month) From david.fee at qub.ac.uk Sun Jan 2 10:40:19 2005 From: david.fee at qub.ac.uk (David Fee) Date: Sun Jan 21 12:11:00 2007 Subject: [music-dsp] Implementing kurtosis maximization for dereverberation Message-ID: <41D815E3.2090900@qub.ac.uk> Hi I'm wondering if anyone has come across a paper "Speech dereverberation via maximum-kurtosis subband adaptive filtering" ICASSP 2001, Gillespie, Malvar and Florencio. I've been able to get the technique to give good results without splitting the signal into subbands. However, I haven't been able to get the subband approach to work successfully. The paper recommends using Modulated Complex Lapped Transforms (MCLT). I've been using Modulated Lapped Transform (purely real) as outlined in Malvar's book but with no real success. Would anybody have any ideas on this or be prepared to discuss it? Thanks David Fee -- David Fee Innovative Audio Systems Group Sonic Arts Research Centre Queen's University, Belfast Tel. (mob) +44 (0)7729 883433 Tel. (office) +44 (0)28 9027 4761 Email david.fee@qub.ac.uk From tsquank at yahoo.com Sun Jan 2 20:35:05 2005 From: tsquank at yahoo.com (Darren Gibbs) Date: Sun Jan 21 12:11:00 2007 Subject: [music-dsp] Fixed Point FFT question Message-ID: Hello, I've been searching for info about doing real FFTs on fixed point processors and found a post from r b-j in April 2000: > i have _definitely_ found an advantage of using such an algorithm over > zero > padding the imaginary parts of the input and performing an N point > complex > FFT. i don't recall how Numerical Recipes sets it up but i have set > it up > where the even indexed real samples go into the real parts and the odd > indexed samples go into the imaginary parts, an N/2 point complex FFT > is > done, and the result of that (which does not have the symmetry it > would if > the input had zero imag part) is untangled to get the result you want. > even though the N/2 point complex FFT needs N/4 twiddle factors (the > sine > function is sampled N/8 equally spaced samples from theta=0 to > theta=pi/2), > you still need the the other N/4 twiddles (sample the same quarter > cycle > sine N/4 times) to get the required N/2 twiddles for an N point FFT. > the > other N/4 twiddles are used in the "untangling" part of the algorithm. I found on the net a chunk of (PXA255) XScale/ARM assembler code that does a "split radix" complex FFT. I'm not wise in the ways of FFT algorithms, but I don't think I need a complex FFT for my situation. Could someone spare a few sentences to describe in high-level terms the difference between a complex and real FFT and appropriate contexts for using one over the other. I've found piles of articles on DFT v.s. FFT, and incredibly over-my-head detailed info on implementing various algorithms, but I don't fully understand this distinction. If I correctly understand the quote above, it's possible to use the complex FFT function to perform a real FFT, thus saving many cycles. Could someone hand hold me a little bit as to how this untangling works? Do I need to modify the complex FFT algorithm itself, or just massage the output somehow? thanks for any advice, darren From rbj at surfglobal.net Sun Jan 2 23:42:07 2005 From: rbj at surfglobal.net (robert bristow-johnson) Date: Sun Jan 21 12:11:00 2007 Subject: [music-dsp] Fixed Point FFT question In-Reply-To: Message-ID: on 01/02/2005 20:35, Darren Gibbs at tsquank@yahoo.com wrote: > Hello, > > I've been searching for info about doing real FFTs on fixed point > processors and found a post from r b-j in April 2000: > >> i have _definitely_ found an advantage of using such an algorithm over zero >> padding the imaginary parts of the input and performing an N point complex >> FFT. i don't recall how Numerical Recipes sets it up but i have set it up >> where the even indexed real samples go into the real parts and the odd >> indexed samples go into the imaginary parts, an N/2 point complex FFT is >> done, and the result of that (which does not have the symmetry it would if >> the input had zero imag part) is untangled to get the result you want. >> even though the N/2 point complex FFT needs N/4 twiddle factors (the sine >> function is sampled N/8 equally spaced samples from theta=0 to theta=pi/2), >> you still need the the other N/4 twiddles (sample the same quarter cycle >> sine N/4 times) to get the required N/2 twiddles for an N point FFT. the >> other N/4 twiddles are used in the "untangling" part of the algorithm. > > I found on the net a chunk of (PXA255) XScale/ARM assembler code that > does a "split radix" complex FFT. I'm not wise in the ways of FFT > algorithms, but I don't think I need a complex FFT for my situation. > Could someone spare a few sentences to describe in high-level terms the > difference between a complex and real FFT and appropriate contexts for > using one over the other. I've found piles of articles on DFT v.s. > FFT, and incredibly over-my-head detailed info on implementing various > algorithms, but I don't fully understand this distinction. the FFT is a "fast" way of performing the DFT. it is sorta like comparing some slick "Quick sort" algorithm to the bonehead "Bubble sort". they both do the same thing, but one might do it more efficiently. > If I correctly understand the quote above, it's possible to use the > complex FFT function to perform a real FFT, thus saving many cycles. yes. it saves computation over simply zeroing the imaginary part and performing the regular old N point FFT. you put all the even indexed samples in the real part of the N/2 input points, all of the odd indexed samples in the imaginary part those N/2 input points, ... > Could someone hand hold me a little bit as to how this untangling > works? Do I need to modify the complex FFT algorithm itself, ... run a normal N/2 point FFT, and ... > or just massage the output somehow? ... diddle with (massage) the the result. oh geez, if i knew the post you mention, i might have had some math in it. lessee, you have N samples of real input data: u[n] 0 <= n < N you conceptually split it into two N/2 sized blocks of real data: u_e[n] = u[2*n] 0 <= n < N/2 u_o[n] = u[2*n+1] construct N/2 points of complex input data: x[n] = u_e[n] + j*u_o[n] 0 <= n < N/2 run a N/2 point complex DFT on that and get: X[k] = U_e[k] + j*U_o[k] 0 <= k < N/2 Because the input to this DFT was not real, the conjugate symmetry is not valid (unless of course all of the odd samples of u[n] are zero). X[N/2 - k] = conj{ X[k] } if and only if Im{ x[n] } = 0 But we use that symmetry for U_e[k] and U_o[k] since they are DFTs of purely real input. The goal is the N point DFT of u[n] which is: N-1 U[k] = sum{ u[n] * exp(-j*2*pi*n*k/N) } n=0 which, if N is even, can be split into two summations: N/2-1 U[k] = sum{ u[2*n] * exp(-j*2*pi*(2*n)*k/N) } n=0 N/2-1 + sum{ u[2*n+1] * exp(-j*2*pi*(2*n+1)*k/N) } n=0 N/2-1 = sum{ u_e[n] * exp(-j*2*pi*n*k/(N/2)) } n=0 N/2-1 + exp(-j*2*pi*k/N) * sum{ u_o[n] * exp(-j*2*pi*n*k/(N/2)) } n=0 = U_e[k] + exp(-j*2*pi*k/N) * U_o[k] So if we can untangle U_e[k] and U_o[k] (both real and imaginary parts) from X[k] = U_e[k] + j*U_o[k] then we can plug those U_e[k] and U_o[k] into U[k] = U_e[k] + exp(-j*2*pi*k/N) * U_o[k] then we have the result you are looking for. It is okay that U_e[k] and U_o[k] are defined for only N/2 points because U[k], being the DFT of a real input, is conjugate symmetric. U[N - k] = conj{ U[k] } because Im{ u[n] } = 0 Also, because Im{ u_e[n] } = Im{ u_o[n] } = 0 U_e[N/2 - k] = conj{ U_e[k] } U_o[N/2 - k] = conj{ U_o[k] } We use this fact to extract U_e[k] and U_o[k] out of X[k] 2*Re{ U_e[k] } = Re{ X[k] + X[N/2-k] } 2*Im{ U_e[k] } = Im{ X[k] - X[N/2-k] } 2*Re{ U_o[k] } = Im{ X[k] + X[N/2-k] } -2*Im{ U_o[k] } = Re{ X[k] - X[N/2-k] } (keep the periodicity of the DFT in mind when you think about X[N/2-0].) So U[k] = U_e[k] + exp(-j*2*pi*k/N) * U_o[k] = 0.5 * ( Re{ X[k] + X[N/2-k] } + j*Im{ X[k] - X[N/2-k] } ) + 0.5 * exp(-j*2*pi*k/N) * ( Im{ X[k] + X[N/2-k] } - j*Re{ X[k] - X[N/2-k] } ) I skipped a couple of steps getting the last two equations, but just use that conjugate symmetry and slug it out. > thanks for any advice, clear as mud? -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From rbj at surfglobal.net Sun Jan 2 23:45:20 2005 From: rbj at surfglobal.net (robert bristow-johnson) Date: Sun Jan 21 12:11:00 2007 Subject: [music-dsp] Fixed Point FFT question In-Reply-To: Message-ID: i made a mental note about the subject line and then forgot it. i would *not* recommend any of this for Fixed-point FFT unless you gotta lotta bits (32 bit words with 64 bit accumulators). the roundoff noise of the FFT (as opposed to the straight forward slow DFT) is a bitch. definitely not good for 16 bit words. but if you're doing double precision float, this works very well. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From tsquank at yahoo.com Mon Jan 3 15:22:49 2005 From: tsquank at yahoo.com (Darren Gibbs) Date: Sun Jan 21 12:11:00 2007 Subject: [music-dsp] Fixed Point FFT question In-Reply-To: References: Message-ID: <3D0CEABD-5DC5-11D9-8B3A-000D93C2E232@yahoo.com> On Jan 2, 2005, at 8:42 PM, robert bristow-johnson wrote: >> Could someone spare a few sentences to describe in high-level terms >> the >> difference between a complex and real FFT and appropriate contexts for >> using one over the other. I've found piles of articles on DFT v.s. >> FFT, and incredibly over-my-head detailed info on implementing various >> algorithms, but I don't fully understand this distinction. > > the FFT is a "fast" way of performing the DFT. it is sorta like > comparing > some slick "Quick sort" algorithm to the bonehead "Bubble sort". they > both > do the same thing, but one might do it more efficiently. Yes, the DFT v.s. FFT I get... but the real v.s. complex I'm less clear about. > oh geez, if i knew the post you mention, i might have had some math in > it. nope... just the possibility teaser I quoted... :-) > lessee, you have N samples of real input data: > > u[n] 0 <= n < N > > you conceptually split it into two N/2 sized blocks of real data: > > u_e[n] = u[2*n] > 0 <= n < N/2 > u_o[n] = u[2*n+1] [lots of cool looking equations that make me really really wish I'd taken more math in college clipped] > clear as mud? Well, conceptually I was able to follow you, but not deep enough to implement it in code... I reckon I'm gonna to have to admit a certain level of defeat, for the time being treat the FFT as a slightly translucent black box, and find someone to implement the low-level magic for me. > i would *not* recommend any of this for Fixed-point FFT unless you > gotta > lotta bits (32 bit words with 64 bit accumulators). the roundoff > noise of > the FFT (as opposed to the straight forward slow DFT) is a bitch. Hmmm.... If I've correctly understood certain bits of the articles I've been perusing, a real FFT requires 1/2 the space/time to perform. In general, is it more clever to use the complex FFT in the way you've described, or to implement a real FFT as a separate algorithm? The ARM CPU I'm targeting is 32-bit, but does FP in software emulation which is what got me on the trail of a fixed point solution. I haven't been able to find an explanation I could grok that describes the algorithmic difference between a real v.s. complex FFT. Thanks! darren From paulwebb at rocketmail.com Mon Jan 3 16:34:33 2005 From: paulwebb at rocketmail.com (paul webb) Date: Sun Jan 21 12:11:00 2007 Subject: [music-dsp] filtered grains in granular synthesis In-Reply-To: <3D0CEABD-5DC5-11D9-8B3A-000D93C2E232@yahoo.com> Message-ID: <20050103213433.69717.qmail@web51410.mail.yahoo.com> hello, I am coding myself a granular synthesis engine and am now adding possibility to have grains that can have individual filters. Knowing when the grain has finished is easy when it has no filter, its just its duration, but what techniques do people use to decide to stop the grain audio when it has a filter. For example if it has a IIR filter the grain envelope may be down to zero but the tap of the filter can still be supplying audio. I am making a few techniques such as *just stopping everything when grain envelope finishes *letting the filter carry on for X ammount of time then stopping *having a short decay envelope acting on the filter after grain finishes *trying to test when the filter is outputing zeros some of the above is sounding fine but anyone have any other suggestions / techniques I can try ? cheers, paul ===== .................................................................................... http://www.fexia.com http://www.robotsoftware.co.uk http://www.nicetoanimals.org ..................................................................................... __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From kaleja at estarcion.com Mon Jan 3 18:18:02 2005 From: kaleja at estarcion.com (Russell Borogove) Date: Sun Jan 21 12:11:00 2007 Subject: [music-dsp] Re: filtered grains in granular synthesis Message-ID: <20050103231802.GA87323@regency.estarcion.com> On Mon, Jan 03, 2005 at 01:34:33PM -0800, paul webb wrote: > I am making a few techniques such as > *just stopping everything when grain envelope finishes > *letting the filter carry on for X ammount of time > then stopping > *having a short decay envelope acting on the filter > after grain finishes > *trying to test when the filter is outputing zeros > > some of the above is sounding fine but anyone have > any other suggestions / techniques I can try ? * simplest solution, but it will affect the sound somewhat: filter the signal *before* putting it through the envelope - when the envelope hits zero, the filtered signal is zero. * If you have a high resonance setting on the filter, drop the resonance very low when the grain envelope goes to 0, then let the filter ring for X amount of time - lowering the resonance will shorten the ring time. -Borogove From paulwebb at rocketmail.com Mon Jan 3 19:36:49 2005 From: paulwebb at rocketmail.com (paul webb) Date: Sun Jan 21 12:11:00 2007 Subject: [music-dsp] Re: filtered grains in granular synthesis In-Reply-To: <20050103231802.GA87323@regency.estarcion.com> Message-ID: <20050104003649.64132.qmail@web51401.mail.yahoo.com> hello, thanks. I'll give them a go. paul --- Russell Borogove wrote: > On Mon, Jan 03, 2005 at 01:34:33PM -0800, paul webb > wrote: > > I am making a few techniques such as > > *just stopping everything when grain envelope > finishes > > *letting the filter carry on for X ammount of time > > then stopping > > *having a short decay envelope acting on the > filter > > after grain finishes > > *trying to test when the filter is outputing zeros > > > > some of the above is sounding fine but anyone have > > any other suggestions / techniques I can try ? > > * simplest solution, but it will affect the sound > somewhat: > filter the signal *before* putting it through the > envelope - > when the envelope hits zero, the filtered signal is > zero. > > * If you have a high resonance setting on the > filter, drop the > resonance very low when the grain envelope goes to > 0, then let > the filter ring for X amount of time - lowering the > resonance > will shorten the ring time. > > -Borogove > -- > dupswapdrop -- the music-dsp mailing list and > website: > subscription info, FAQ, source code archive, list > archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > ===== .................................................................................... http://www.fexia.com http://www.robotsoftware.co.uk http://www.nicetoanimals.org ..................................................................................... __________________________________ Do you Yahoo!? Send holiday email and support a worthy cause. Do good. http://celebrity.mail.yahoo.com From earlevel at earlevel.com Mon Jan 3 21:03:04 2005 From: earlevel at earlevel.com (Nigel Redmon) Date: Sun Jan 21 12:11:00 2007 Subject: [music-dsp] Fixed Point FFT question In-Reply-To: <3D0CEABD-5DC5-11D9-8B3A-000D93C2E232@yahoo.com> References: <3D0CEABD-5DC5-11D9-8B3A-000D93C2E232@yahoo.com> Message-ID: On Jan 3, 2005, at 12:22 PM, Darren Gibbs wrote: > Yes, the DFT v.s. FFT I get... but the real v.s. complex I'm less > clear about. The DFT/FFT inherently uses complex values as its input and output. So, if you start with real data, you have to convert them to complex (0.95 converts to 0.95 + 0i)--you end up with a whole lot of wasted zero multiplies and generating a redundant set of (mirrored) harmonics. Fortunately, there's an easy way to rearrange your real input values and plug them into the transform (even samples in the real part, odd in the complex), do the transform, then do a similar complex to real conversion. That's a rough explanation, but I think that's all you need to know--a real FFT makes more efficient use of the algorithm when you have real data. From Dogstoyevsky at gmx.net Tue Jan 4 05:34:24 2005 From: Dogstoyevsky at gmx.net (Fido Dogstoyevsky) Date: Sun Jan 21 12:11:00 2007 Subject: [music-dsp] Fixed Point FFT question Message-ID: <24441.1104834864@www48.gmx.net> rbj wrote: > i would *not* recommend any of this for Fixed-point FFT unless you gotta > lotta bits (32 bit words with 64 bit accumulators). the roundoff noise of > the FFT (as opposed to the straight forward slow DFT) is a bitch. > definitely not good for 16 bit words. > but if you're doing double precision float, this works very well. It works well for 24 bits as well. I used the Motorola Block Floating Point FFT and it improved the S/N. Robert, do you think a Block Floating Point FFT could work reasonable with 16 bit words? best Fido -- +++ GMX - die erste Adresse für Mail, Message, More +++ 1 GB Mailbox bereits in GMX FreeMail http://www.gmx.net/de/go/mail From Dogstoyevsky at gmx.net Tue Jan 4 05:55:18 2005 From: Dogstoyevsky at gmx.net (Fido Dogstoyevsky) Date: Sun Jan 21 12:11:00 2007 Subject: [music-dsp] [OT] Stupid C Question Message-ID: <17027.1104836118@www43.gmx.net> Laurent de Soras [Ohm Force] wrote: > double (*a) [2] = malloc (n * sizeof (a [0])); Sorry to flog a dead horse, but houldn't this be more like: double * a[2] = { NULL, NULL }; a[0] = malloc ( 2 * n * sizeof(double) ); a[1] = a + n; /* This is important, isn't it? */ /* do stuff */ printf("%f", a[0][x]); printf("%f", a[1][y]); free( a[0] ); Best Fido -- +++ GMX - die erste Adresse für Mail, Message, More +++ 1 GB Mailbox bereits in GMX FreeMail http://www.gmx.net/de/go/mail From yaakov_s at rad.com Tue Jan 4 09:20:52 2005 From: yaakov_s at rad.com (Yaakov Stein) Date: Sun Jan 21 12:11:00 2007 Subject: [music-dsp] Fixed Point FFT question Message-ID: <27A0F290348F8E45AEF79889DDE65A52038DBA1C@exrad2.ad.rad.co.il> > rbj wrote: > > i would *not* recommend any of this for Fixed-point FFT unless you > > gotta lotta bits (32 bit words with 64 bit accumulators). The radix-2 FFT, as conventionally implemented, requires reduction of 1 bit of accuracy per stage for worst-case safe behavior (i.e. predivision by N). Thus only very small FFTs are benign. If you are willing to risk the occasional overflow (assuming that you are using saturation arithmetic) you can get away with 1/2 bit per stage (i.e. predivision by sqrt(N)). This can be done without risk by scaling per alternate stage (which doesn't cost more in MIPS if you have a shifter). Even better is conditional scaling per stage; and there are more careful ways to perform the rouding that give further improvements. Finally, in theory number theoretical transforms (NTT) can be used to eliminate all loss of precision. At the expense of significantly lower performance on conventional architectures and much harder coding. Jonathan (Y) Stein From signalzerodb at yahoo.co.uk Tue Jan 4 11:56:15 2005 From: signalzerodb at yahoo.co.uk (Dave Gamble) Date: Sun Jan 21 12:11:01 2007 Subject: [music-dsp] Fixed Point FFT question In-Reply-To: <24441.1104834864@www48.gmx.net> References: <24441.1104834864@www48.gmx.net> Message-ID: <8C0207C2-5E71-11D9-B8B8-000A958903DE@yahoo.co.uk> On 4 Jan 2005, at 10:34, Fido Dogstoyevsky wrote: > rbj wrote: >> i would *not* recommend any of this for Fixed-point FFT unless you >> gotta >> lotta bits (32 bit words with 64 bit accumulators). the roundoff >> noise of >> the FFT (as opposed to the straight forward slow DFT) is a bitch. > >> definitely not good for 16 bit words. > >> but if you're doing double precision float, this works very well. > > It works well for 24 bits as well. I used the Motorola Block Floating > Point > FFT and it improved the S/N. > > Robert, do you think a Block Floating Point FFT could work reasonable > with > 16 bit words? > Iirc, Knuth2 (seminumerical algorithms), the section on multiplying polynomials using FFTs has an indepth discussion of precisely what the roundoff requirements are for FFTs. Dave. From signalzerodb at yahoo.co.uk Tue Jan 4 12:03:50 2005 From: signalzerodb at yahoo.co.uk (Dave Gamble) Date: Sun Jan 21 12:11:01 2007 Subject: [music-dsp] [OT] Stupid C Question In-Reply-To: References: Message-ID: <9B5BA8EA-5E72-11D9-B8B8-000A958903DE@yahoo.co.uk> > > In the hands of experts each of these languages allows for the creation > of beauty. > > In the hands of novices, they are all disasters waiting to happen. > > You have two choices: > > master the tools appropriate to the task, create new ones, and > get work done. > > or > bitch and moan about some perceived mismatch between a given > tool and your idealized perception of some out dated design metaphor > (which is still somewhat useful on occasion) that for some reason has > been elevated to religion in the minds of some. > I agree completely. However, I very much like the idea of telling people that 'this sounds better, because it was written in C, not C++'. 'Oh yeah, the virtual functions in C++ degrade the signal quality, so by using 100% pure C, we get better sound quality'. It's like all the hi-fi discussions, about what type of material your pcb/cables/connectors/speaker cone/coffee mug should be made from to get the best signal quality. 99% of the time, these discussions are complete nonsense, but they don't half entertain me. So, what advertising memes can we come up with for various languages and DSP? "Oh, I never use C# for programming - the 'sharp' element of it means that it actually runs at a slightly faster samplerate internally, so it pitches all your audio up slightly." "JAVA is very quick for development, yes, but since Sun wanted to make it so portable, they had to default to using the lowest-common-denominator for connectivity." "Oh, C is great, but try writing an auto-tune for Dminor with it!" There may well be a small prize for the best suggestion! :) Dave. From emanuel.landeholm at telia.com Tue Jan 4 12:18:53 2005 From: emanuel.landeholm at telia.com (Emanuel Landeholm) Date: Sun Jan 21 12:11:01 2007 Subject: [music-dsp] [OT] Stupid C Question In-Reply-To: <9B5BA8EA-5E72-11D9-B8B8-000A958903DE@yahoo.co.uk> References: <9B5BA8EA-5E72-11D9-B8B8-000A958903DE@yahoo.co.uk> Message-ID: <41DACFFD.5030404@telia.com> > "Oh, I never use C# for programming - the 'sharp' element of it means > that it actually runs at a slightly faster samplerate internally, so it > pitches all your audio up slightly." That's fucking funny.. From paulwebb at rocketmail.com Tue Jan 4 13:01:03 2005 From: paulwebb at rocketmail.com (paul webb) Date: Sun Jan 21 12:11:01 2007 Subject: [music-dsp] [OT] Stupid C Question In-Reply-To: <41DACFFD.5030404@telia.com> Message-ID: <20050104180103.56163.qmail@web51406.mail.yahoo.com> I never use C/C++/Csharp for music because C is like see and this is audio stuff. if you are C'ing you are doing visuals. oh and never use Lisp for speech processing --- Emanuel Landeholm wrote: > > "Oh, I never use C# for programming - the 'sharp' > element of it means > > that it actually runs at a slightly faster > samplerate internally, so it > > pitches all your audio up slightly." > > That's fucking funny.. > -- > dupswapdrop -- the music-dsp mailing list and > website: > subscription info, FAQ, source code archive, list > archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > ===== .................................................................................... http://www.fexia.com http://www.robotsoftware.co.uk http://www.nicetoanimals.org ..................................................................................... __________________________________ Do you Yahoo!? Dress up your holiday email, Hollywood style. Learn more. http://celebrity.mail.yahoo.com From paulwebb at rocketmail.com Tue Jan 4 13:01:03 2005 From: paulwebb at rocketmail.com (paul webb) Date: Sun Jan 21 12:11:01 2007 Subject: [music-dsp] [OT] Stupid C Question In-Reply-To: <41DACFFD.5030404@telia.com> Message-ID: <20050104180103.56163.qmail@web51406.mail.yahoo.com> I never use C/C++/Csharp for music because C is like see and this is audio stuff. if you are C'ing you are doing visuals. oh and never use Lisp for speech processing --- Emanuel Landeholm wrote: > > "Oh, I never use C# for programming - the 'sharp' > element of it means > > that it actually runs at a slightly faster > samplerate internally, so it > > pitches all your audio up slightly." > > That's fucking funny.. > -- > dupswapdrop -- the music-dsp mailing list and > website: > subscription info, FAQ, source code archive, list > archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > ===== .................................................................................... http://www.fexia.com http://www.robotsoftware.co.uk http://www.nicetoanimals.org ..................................................................................... __________________________________ Do you Yahoo!? Dress up your holiday email, Hollywood style. Learn more. http://celebrity.mail.yahoo.com From joshscholar at yahoo.com Tue Jan 4 16:21:38 2005 From: joshscholar at yahoo.com (Joshua Scholar) Date: Sun Jan 21 12:11:01 2007 Subject: [music-dsp] [OT] Stupid C Question References: <20050104180103.56163.qmail@web51406.mail.yahoo.com> Message-ID: <001901c4f2a3$617316e0$bde22641@antssoftware.com> I never program in C because major keys are so boring. Joshua Scholar ----- Original Message ----- From: "paul webb" To: "a list for musical digital signal processing" ; "a list for musical digital signal processing" Sent: Tuesday, January 04, 2005 10:01 AM Subject: Re: [music-dsp] [OT] Stupid C Question > I never use C/C++/Csharp for music because C is like > see and this is audio stuff. if you are C'ing you are > doing visuals. > > > oh and never use Lisp for speech processing > > > > > > > --- Emanuel Landeholm > wrote: > > > > "Oh, I never use C# for programming - the 'sharp' > > element of it means > > > that it actually runs at a slightly faster > > samplerate internally, so it > > > pitches all your audio up slightly." > > > > That's fucking funny.. > > -- > > dupswapdrop -- the music-dsp mailing list and > > website: > > subscription info, FAQ, source code archive, list > > archive, book reviews, dsp links > > http://shoko.calarts.edu/musicdsp > > http://ceait.calarts.edu/mailman/listinfo/music-dsp > > > > ===== > ............................................................................ ........ > http://www.fexia.com > http://www.robotsoftware.co.uk > http://www.nicetoanimals.org > ............................................................................ ......... > > > > __________________________________ > Do you Yahoo!? > Dress up your holiday email, Hollywood style. Learn more. > http://celebrity.mail.yahoo.com > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp From paranoiaspoisondoor at gmail.com Tue Jan 4 16:39:52 2005 From: paranoiaspoisondoor at gmail.com (Keith Handy) Date: Sun Jan 21 12:11:01 2007 Subject: [music-dsp] [OT] Stupid C Question In-Reply-To: <001901c4f2a3$617316e0$bde22641@antssoftware.com> References: <20050104180103.56163.qmail@web51406.mail.yahoo.com> <001901c4f2a3$617316e0$bde22641@antssoftware.com> Message-ID: <79a2ad4105010413395f52751f@mail.gmail.com> One thing I'd like to point out is that C is for cookie; that's good enough for me. As you might know, C is for cookie; that's good enough for me. Like I mentioned earlier, C is for cookie; that's good enough for me. And of course, cookie, cookie, cookie starts with C. -Keith On Tue, 4 Jan 2005 13:21:38 -0800, Joshua Scholar wrote: > I never program in C because major keys are so boring. > > Joshua Scholar > > ----- Original Message ----- > From: "paul webb" > To: "a list for musical digital signal processing" > ; "a list for musical digital signal > processing" > Sent: Tuesday, January 04, 2005 10:01 AM > Subject: Re: [music-dsp] [OT] Stupid C Question > > > I never use C/C++/Csharp for music because C is like > > see and this is audio stuff. if you are C'ing you are > > doing visuals. > > > > > > oh and never use Lisp for speech processing > > > > > > > > > > > > > > --- Emanuel Landeholm > > wrote: > > > > > > "Oh, I never use C# for programming - the 'sharp' > > > element of it means > > > > that it actually runs at a slightly faster > > > samplerate internally, so it > > > > pitches all your audio up slightly." > > > > > > That's fucking funny.. > > > -- > > > dupswapdrop -- the music-dsp mailing list and > > > website: > > > subscription info, FAQ, source code archive, list > > > archive, book reviews, dsp links > > > http://shoko.calarts.edu/musicdsp > > > http://ceait.calarts.edu/mailman/listinfo/music-dsp > > > > > > > ===== > > > ............................................................................ > ........ > > http://www.fexia.com > > http://www.robotsoftware.co.uk > > http://www.nicetoanimals.org > > > ............................................................................ > ......... > > > > > > > > __________________________________ > > Do you Yahoo!? > > Dress up your holiday email, Hollywood style. Learn more. > > http://celebrity.mail.yahoo.com > > -- > > dupswapdrop -- the music-dsp mailing list and website: > > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > > http://shoko.calarts.edu/musicdsp > > http://ceait.calarts.edu/mailman/listinfo/music-dsp > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > -- -Keith From tony at mtx-media.com Tue Jan 4 16:54:28 2005 From: tony at mtx-media.com (Tony Scharf) Date: Sun Jan 21 12:11:01 2007 Subject: [music-dsp] [OT] Stupid C Question In-Reply-To: <79a2ad4105010413395f52751f@mail.gmail.com> References: <20050104180103.56163.qmail@web51406.mail.yahoo.com> <001901c4f2a3$617316e0$bde22641@antssoftware.com> <79a2ad4105010413395f52751f@mail.gmail.com> Message-ID: <41DB1094.4070206@mtx-media.com> Keith Handy said on 1/4/2005 3:39 PM: > One thing I'd like to point out is that C is for cookie; that's good > enough for me. As you might know, C is for cookie; that's good enough > for me. Like I mentioned earlier, C is for cookie; that's good enough > for me. And of course, cookie, cookie, cookie starts with C. > > -Keith cause what we really need on sessame street, is a C++ monster Tony From rbj at surfglobal.net Tue Jan 4 17:43:02 2005 From: rbj at surfglobal.net (robert bristow-johnson) Date: Sun Jan 21 12:11:02 2007 Subject: [music-dsp] Fixed Point FFT question In-Reply-To: <24441.1104834864@www48.gmx.net> Message-ID: on 01/04/2005 05:34, Fido Dogstoyevsky at Dogstoyevsky@gmx.net wrote: > rbj wrote: >> i would *not* recommend any of this for Fixed-point FFT unless you gotta >> lotta bits (32 bit words with 64 bit accumulators). the roundoff noise of >> the FFT (as opposed to the straight forward slow DFT) is a bitch. > >> definitely not good for 16 bit words. > >> but if you're doing double precision float, this works very well. > > It works well for 24 bits as well. I used the Motorola Block Floating Point > FFT and it improved the S/N. it should. i could never find a good copy of a block floating point 56K program that efficiently uses that S bit. so i took the regular FFT benchmark and modified it. this is so old that i'll give it away (probably no one uses the 56K series anymore). it's at the bottom. you'll have to unwrap some of the lines that wrapped. could you compare it to the one you got? > Robert, do you think a Block Floating Point FFT could work reasonable with > 16 bit words? it'll be 48 dB more noisy than 24 bit block floating-point. one other problem is that the DFT coefficients (a.k.a. "twiddle factors") are also quantized and the result of that imprecision of the coefficients is that (very low level) spurious bleeding of one bin into an unrelated bin will happen. try it i guess. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." page 255 opt cex,mex lstcol 8,8,10,13,13 ; ; copyright (C) 1994 by Robert Bristow-Johnson ; tel: 802/865-4525 ; e-mail: ; ; ; ; This subroutine is identical to the Motorola benchmark fftr2a ; except that scaling is optimized using block floating point. ; This requires a DSP56002, DSP56004, DSP56007 or DSP56001A. ; Some FFT passes have the divide by 2 scaling mode set (depending ; on the result of the S bit in the CCR). This insures ; against, overflow for any signal. N must be a power of 2. ; ; To be completely safe, the input should be scaled so that ; the magnitude of every real or imaginary part does not ; exceed 0.31066 ($27C3B5) . ; ; ; N-1 ; X[n] = 1/M SUM{ x[k]*exp(-j*2*PI*n*k/N) } ; k=0 ; ; where ; x[k] = input in normal order ; X[n] = output in bit reverse order ; ; N = 2^p ; ; M = 2^q (q = integer, number of passes that ; right shifting was necessary. ; 0 <= q <= p ) ; ; ; input: r1 -> data; x:(r1) is real part, y:(r1) is imag part ; r2 -> coefficients; x:(r2) is cos, y:(r2) is sin ; n1 = log2(number of points) = p ; r4 = block floating point exponent input (perhaps initialized to 0) ; ; output: r4 = block floating point exponent output ; = q + input r4 ; ; uses: a, b, x0, x1, y0, y1, mr, ccr ; r1, r2, r3, r4, r5, r6 ; n1, n2, n3, n4, n5, n6 ; m1, m2, m3, m4, m5, m6 ; x:-1,m5 ;2 init A and B address modifiers move m5,m6 ;1 for linear addressing move m5,m4 ;1 move m5,m1 ;1 move m5,m2 ;1 move #<0,m3 ;1 init C address modifier ; for bit-reversed addressing andi #$7F,ccr ;1 clear sticky bit ; ; Do FFT passes with triple nested DO loop. ; do n1,end_pass ;3 move x:-1,m5 move m5,m2 clr a #delta_table,r5 move #<2,n5 move #<1,a1 do n1,_shift asl a (r5)+n5 _shift lsr a #<-1.0,x0 ;-cos move a,n5 ;N/2 move p:(r5)+,x1 ;-cosdel move p:(r5)+,y1 ;-sindel mpyr -x0,x1,a #<0.0,y0 ;-sin do n5,_sincos_loop mpy -x0,y1,b a,x0 macr -y0,x1,b a,x:(r2) ; b = new sin mpy -x0,x1,a b,y0 macr y0,y1,a b,y:(r2)+ ; a = new cos _sincos_loop rts twopi equ 6.28318530717959 delta_table dc -@cos(twopi/1.0) dc -@sin(twopi/1.0) dc -@cos(twopi/2.0) dc -@sin(twopi/2.0) dc -@cos(twopi/4.0) dc -@sin(twopi/4.0) dc -@cos(twopi/8.0) dc -@sin(twopi/8.0) dc -@cos(twopi/16.0) dc -@sin(twopi/16.0) dc -@cos(twopi/32.0) dc -@sin(twopi/32.0) dc -@cos(twopi/64.0) dc -@sin(twopi/64.0) dc -@cos(twopi/128.0) dc -@sin(twopi/128.0) dc -@cos(twopi/256.0) dc -@sin(twopi/256.0) dc -@cos(twopi/512.0) dc -@sin(twopi/512.0) dc -@cos(twopi/1024.0) dc -@sin(twopi/1024.0) dc -@cos(twopi/2048.0) dc -@sin(twopi/2048.0) dc -@cos(twopi/4096.0) dc -@sin(twopi/4096.0) dc -@cos(twopi/8192.0) dc -@sin(twopi/8192.0) dc -@cos(twopi/16384.0) dc -@sin(twopi/16384.0) dc -@cos(twopi/32768.0) dc -@sin(twopi/32768.0) END From aclark at danvillesignal.com Tue Jan 4 18:21:46 2005 From: aclark at danvillesignal.com (Al Clark) Date: Sun Jan 21 12:11:02 2007 Subject: [music-dsp] Fixed Point FFT question In-Reply-To: References: <24441.1104834864@www48.gmx.net> Message-ID: <6.1.0.6.0.20050104171841.02700420@localhost> I prefer fixed point for many algorithms such as FIR and IIR filters, but FFTs are much easier with floating point. This is where a DSP like the SHARC works well since you have native floating point and fixed point capability. Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.com At 04:43 PM 1/4/2005, you wrote: >on 01/04/2005 05:34, Fido Dogstoyevsky at Dogstoyevsky@gmx.net wrote: > > > rbj wrote: > >> i would *not* recommend any of this for Fixed-point FFT unless you gotta > >> lotta bits (32 bit words with 64 bit accumulators). the roundoff noise of > >> the FFT (as opposed to the straight forward slow DFT) is a bitch. > > > >> definitely not good for 16 bit words. > > > >> but if you're doing double precision float, this works very well. > > > > It works well for 24 bits as well. I used the Motorola Block Floating Point > > FFT and it improved the S/N. > >it should. i could never find a good copy of a block floating point 56K >program that efficiently uses that S bit. so i took the regular FFT >benchmark and modified it. this is so old that i'll give it away (probably >no one uses the 56K series anymore). it's at the bottom. you'll have to >unwrap some of the lines that wrapped. could you compare it to the one you >got? > > > Robert, do you think a Block Floating Point FFT could work reasonable with > > 16 bit words? > >it'll be 48 dB more noisy than 24 bit block floating-point. one other >problem is that the DFT coefficients (a.k.a. "twiddle factors") are also >quantized and the result of that imprecision of the coefficients is that >(very low level) spurious bleeding of one bin into an unrelated bin will >happen. > >try it i guess. > > >-- > >r b-j rbj@audioimagination.com > >"Imagination is more important than knowledge." > > > > > > > page 255 > opt cex,mex > lstcol 8,8,10,13,13 > > >; >; copyright (C) 1994 by Robert Bristow-Johnson >; tel: 802/865-4525 >; e-mail: >; >; >; >; This subroutine is identical to the Motorola benchmark fftr2a >; except that scaling is optimized using block floating point. >; This requires a DSP56002, DSP56004, DSP56007 or DSP56001A. >; Some FFT passes have the divide by 2 scaling mode set (depending >; on the result of the S bit in the CCR). This insures >; against, overflow for any signal. N must be a power of 2. >; >; To be completely safe, the input should be scaled so that >; the magnitude of every real or imaginary part does not >; exceed 0.31066 ($27C3B5) . >; >; >; N-1 >; X[n] = 1/M SUM{ x[k]*exp(-j*2*PI*n*k/N) } >; k=0 >; >; where >; x[k] = input in normal order >; X[n] = output in bit reverse order >; >; N = 2^p >; >; M = 2^q (q = integer, number of passes that >; right shifting was necessary. >; 0 <= q <= p ) >; >; >; input: r1 -> data; x:(r1) is real part, y:(r1) is imag part >; r2 -> coefficients; x:(r2) is cos, y:(r2) is sin >; n1 = log2(number of points) = p >; r4 = block floating point exponent input (perhaps >initialized to 0) >; >; output: r4 = block floating point exponent output >; = q + input r4 >; >; uses: a, b, x0, x1, y0, y1, mr, ccr >; r1, r2, r3, r4, r5, r6 >; n1, n2, n3, n4, n5, n6 >; m1, m2, m3, m4, m5, m6 >; x:; x:; >; Leaves mr in no scaling mode. >; >; Requires 78 words of internal p: memory >; and p*( 3*N + 20 ) + 8*N + 15 instruction cycles. >; >; To execute optimally, the fft routine sould be in >; internal p: space. >; >; > > org x:$0 >data ds $1 >coef ds $1 > > > org p:$40 >fft > move r1,x: clr a #<1,n4 ;1 init >groups per pass > move n4,a1 ;1 > do n1,_shift ;3 > lsl a ;p >_shift > lsr a r2,x: lsr a a1,n5 ;1 init bfy >per group > move a1,n3 ;1 init C >pointer offset > move #>-1,m5 ;2 init A >and B address modifiers > move m5,m6 ;1 for >linear addressing > move m5,m4 ;1 > move m5,m1 ;1 > move m5,m2 ;1 > move #<0,m3 ;1 init C >address modifier > ; for >bit-reversed addressing > andi #$7F,ccr ;1 clear >sticky bit > >; >; Do FFT passes with triple nested DO loop. >; > do n1,end_pass ;3 > > move x:input pointer > move r5,r1 ;p init A >output pointer > lua (r5)+n5,r6 ;p init B >input pointer > move x:input pointer > lua (r6)-,r2 ;2p init B >output pointer > move n5,n6 ;p init >pointer offsets > move n5,n1 ;p > move n5,n2 ;p > > jset #7,sr,scale_down ;2p test >scaling bit > > andi #$F3,mr ;p reset >scaling to normal scaling mode > do n4,_end_grp1 ;3p > move x:(r6),x1 y:(r3),y0 ;N-1 lookup >-sine and > ; >-cosine values > move x:(r2),a y:(r5),b ;N-1 preload >b and > ; >update C pointer > move x:(r3)+n3,x0 ;N-1 > > do n5,_end_bfy1 ;3(N-1) > mac x1,y0,b y:(r6)+,y1 ;pN/2 > macr -x0,y1,b a,x:(r2)+ y:(r5),a ;pN/2 > subl b,a x:(r5),b b,y:(r1) ;pN/2 > mac -x1,x0,b x:(r5)+,a a,y:(r2) ;pN/2 > macr -y1,y0,b x:(r6),x1 ;pN/2 > subl b,a b,x:(r1)+ y:(r5),b ;pN/2 >_end_bfy1 > move a,x:(r2)+n2 y:(r6)+n6,y1 ;N-1 update >A and B pointers > move x:(r5)+n5,x1 y:(r1)+n1,y1 ;N-1 >_end_grp1 > jmp >scale_down > move (r4)+ ;p increment >block exponent > ; each time >we scale down > andi #$7F,ccr ;p clear >sticky bit > ori #$04,mr ;p set >scaling mode to divide by 2 > do n4,_end_grp2 ;3p > move x:(r6),x1 y:(r3),y0 ;N-1 lookup >-sine and > ; >-cosine values > move x:(r2),a y:(r5),b ;N-1 preload >b and > ; >update C pointer > asl a x:(r3)+n3,x0 ;N-1 double >a to compensate > ; for >div by 2 scaling > do n5,_end_bfy2 ;3(N-1) > mac x1,y0,b y:(r6)+,y1 ;pN/2 > macr -x0,y1,b a,x:(r2)+ y:(r5),a ;pN/2 > subl b,a x:(r5),b b,y:(r1) ;pN/2 > mac -x1,x0,b x:(r5)+,a a,y:(r2) ;pN/2 > macr -y1,y0,b x:(r6),x1 ;pN/2 > subl b,a b,x:(r1)+ y:(r5),b ;pN/2 >_end_bfy2 > move a,x:(r2)+n2 y:(r6)+n6,y1 ;N-1 update >A and B pointers > move x:(r5)+n5,x1 y:(r1)+n1,y1 ;N-1 >_end_grp2 > >pass_common > move n5,b1 ;p divide >bfy per group by 2 > lsr b n4,a ;p multiply >groups per pass by 2 > lsl a b1,n5 ;p > move a1,n4 ;p >end_pass > andi #$F3,mr ;1 reset >scaling to normal scaling mode > rts ;2 > > >; >;pi equ 3.141592654 >;freq equ 2.0*pi/@cvf(points) >; >; org x:coef >;count set 0 >; dup points/2 >; dc -@cos(@cvf(count)*freq) >;count set count+1 >; endm >; >; org y:coef >;count set 0 >; dup points/2 >; dc -@sin(@cvf(count)*freq) >;count set count+1 >; endm >; >; endm ;end of sincos macro >; > > > >sincos > andi #$F3,mr > move #>-1,m5 > move m5,m2 > clr a #delta_table,r5 > move #<2,n5 > move #<1,a1 > do n1,_shift > asl a (r5)+n5 >_shift > lsr a #<-1.0,x0 ;-cos > move a,n5 ;N/2 > move p:(r5)+,x1 ;-cosdel > move p:(r5)+,y1 ;-sindel > mpyr -x0,x1,a #<0.0,y0 ;-sin > > do n5,_sincos_loop > mpy -x0,y1,b a,x0 > macr -y0,x1,b a,x:(r2) ; b = new >sin > mpy -x0,x1,a b,y0 > macr y0,y1,a b,y:(r2)+ ; a = new >cos >_sincos_loop > rts > >twopi equ 6.28318530717959 > >delta_table > dc -@cos(twopi/1.0) > dc -@sin(twopi/1.0) > dc -@cos(twopi/2.0) > dc -@sin(twopi/2.0) > dc -@cos(twopi/4.0) > dc -@sin(twopi/4.0) > dc -@cos(twopi/8.0) > dc -@sin(twopi/8.0) > dc -@cos(twopi/16.0) > dc -@sin(twopi/16.0) > dc -@cos(twopi/32.0) > dc -@sin(twopi/32.0) > dc -@cos(twopi/64.0) > dc -@sin(twopi/64.0) > dc -@cos(twopi/128.0) > dc -@sin(twopi/128.0) > dc -@cos(twopi/256.0) > dc -@sin(twopi/256.0) > dc -@cos(twopi/512.0) > dc -@sin(twopi/512.0) > dc -@cos(twopi/1024.0) > dc -@sin(twopi/1024.0) > dc -@cos(twopi/2048.0) > dc -@sin(twopi/2048.0) > dc -@cos(twopi/4096.0) > dc -@sin(twopi/4096.0) > dc -@cos(twopi/8192.0) > dc -@sin(twopi/8192.0) > dc -@cos(twopi/16384.0) > dc -@sin(twopi/16384.0) > dc -@cos(twopi/32768.0) > dc -@sin(twopi/32768.0) > > END > >-- >dupswapdrop -- the music-dsp mailing list and website: >subscription info, FAQ, source code archive, list archive, book reviews, >dsp links >http://shoko.calarts.edu/musicdsp >http://ceait.calarts.edu/mailman/listinfo/music-dsp From joshscholar at yahoo.com Tue Jan 4 21:11:09 2005 From: joshscholar at yahoo.com (Joshua Scholar) Date: Sun Jan 21 12:11:02 2007 Subject: [music-dsp] Fixed Point FFT question References: <27A0F290348F8E45AEF79889DDE65A52038DBA1C@exrad2.ad.rad.co.il> Message-ID: <005201c4f2cb$d3bc4370$bde22641@antssoftware.com> ----- Original Message ----- >From: "Yaakov Stein" >To: "a list for musical digital signal processing" >Sent: Tuesday, January 04, 2005 6:20 AM >Subject: RE: [music-dsp] Fixed Point FFT question > > > ... > >Finally, in theory number theoretical transforms (NTT) can >be used to eliminate all loss of precision. >At the expense of significantly lower performance >on conventional architectures and much harder coding. > >Jonathan (Y) Stein >-- And note that all your number base must be big enough to represent the results of a convolution as a integers, so if the signal is 16 bits and the filter function is 16 bits then the calculations must be done in a base that's at least 32 bits. Joshua Scholar From allan at wholecheese.com Tue Jan 4 22:28:20 2005 From: allan at wholecheese.com (Allan Hoeltje) Date: Sun Jan 21 12:11:02 2007 Subject: [music-dsp] Stupid DSP Question Message-ID: Please forgive me in advance if this is a dumb question. I want to write an Audio Unit for my Macintosh that implements an effect that I usually run on an Eventide DSP7000. So that means I am learning about FIR and IIR filters. (I had calculus a long time ago in college, shortly after Newton publish his paper on the topic.) So, I understand that one needs to find coefficients to implement FIR and IIR filters that respond to a specific frequency and bandwidth. However, what does one do if they want a filter that has a Q and cutoff frequency that varies in real-time, like those used in audio effect processors? Do I need to continuously calculate the coefficients in real time to accommodate the variable Q and cutoff frequency? It seems that this could get very expensive for any filter with an order above 2! How is this problem generally solved? -Allan From erikd-music-dsp at mega-nerd.com Tue Jan 4 23:29:08 2005 From: erikd-music-dsp at mega-nerd.com (Erik de Castro Lopo) Date: Sun Jan 21 12:11:02 2007 Subject: [music-dsp] Stupid DSP Question In-Reply-To: References: Message-ID: <20050105152908.7b98b6ae.erikd-music-dsp@mega-nerd.com> On Tue, 04 Jan 2005 19:28:20 -0800 Allan Hoeltje wrote: > So, I understand that one needs to find coefficients to implement FIR and > IIR filters that respond to a specific frequency and bandwidth. OK. > However, > what does one do if they want a filter that has a Q and cutoff frequency > that varies in real-time, like those used in audio effect processors? Do I > need to continuously calculate the coefficients in real time to accommodate > the variable Q and cutoff frequency? Yes. > It seems that this could get very > expensive for any filter with an order above 2! For audio filtering, IIR filter orders rarely get above say 10. An order 10 filter can be implemented as a cascade of five 2nd order sections. A second order section can be fully specified by two parameters (cutoff and Q for lowpass and highpass, center and Q for bandpass etc). See the Robert Bristow-Johnson formulas for more: http://www.harmony-central.com/Computer/Programming/Audio-EQ-Cookbook.txt You can then precalculate the parameters you want for the ranges you want, store them in a table and interpolate between the table values. This is all quite doable in realtime with almost no CPU load on modern CPUs. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo nospam@mega-nerd.com (Yes it's valid) +-----------------------------------------------------------+ "I have long argued that the entertainment industry doesn't want people to have computers. Computers give users too much capability, too much flexibility, too much freedom. The entertainment industry wants users to sit back and consume things. They are trying to turn a computer into an Internet Entertainment Platform, along the lines of a television or VCR. This bill is a large step in that direction." -- Bruce Schneier From dan at bacterie.wanadoo.co.uk Tue Jan 4 23:37:49 2005 From: dan at bacterie.wanadoo.co.uk (Dan Evans) Date: Sun Jan 21 12:11:02 2007 Subject: [music-dsp] Stupid DSP Question References: Message-ID: <000201c4f2e1$22e409f0$ae7786d9@euclid> I'm fairly new to this all myself, but have been able to implement several types of real-time filter. First off, FIR filters are not really suitable for use in real-time, since to get a decent frequency response requires a large number of taps (which I believe would mean several hundred samples latency?). IIR filters have the benefit that they only use a few coefficients, along with the previous input and output samples, I'm still a little hazy on z transforms and poles and zeroes and things (slowly getting there!) but this means that recursive filters can feasibly work in real-time, and be tweaked in real time. There's a variety of code on the music-dsp website with a variety of different filter types. I basically used these to create simple VST filter plugins, without really understanding much about how they work. As long as you're confident enough in your programming language, you should be able to implement filters without really understanding how it all works. Of course, it can't hurt to learn filter design in detail, and I'm sure you're interested enough to want to know how they work. But in the meantime, I say get hacking away at the music-dsp examples and you'll figure out the detailed workings as you go along. Personally, I would look into State Variable Filters. I'm not sure if they're technically classed as IIRs, or something different altogether, the algorithm isn't the standard IIR direct form I or II, and I think I've read that it simulates the components of an analog filter in some way, perhaps someone could fill us in on the workings of the SVF as compared to IIR filters? Anyway, the SVF sounds excellent, is easy to code, and is designed so that the coefficients are closely related to the cutoff and resonance parameters, and outputs LP, BP, N and HP -filtered signals simultaneously. One disadvantage with the SVF is that it is only stable up to 1/3 of the nyquist frequency (or 1/6 of the sample rate) but it's simple enough to oversample by three; oversampling twice would probably be enough for most purposes. As for updating the coefficients, if cutoff and resonance are controlled only by GUI controls (ie. knobs or sliders and not LFOs) you only need to update the coefficients if the cutoff or resonance are altered (not sure about AU, but in VST this means calling a function to set the coefficients based on cutoff and/or resonance whenever setParameter is called [ie. when the user changes the parameters]). As for LFOs and other modulations of that type, you probably don't want or need to be setting the coefficients once per sample. I think I did this once with a simple LFO->Filter plugin and it worked okay, but it's needlessly expensive for the CPU and would probably fall apart if I tried to use it as part of a synth for example... I suppose Nyquist theorem would suggest that your control rate should be at least twice the highest frequency of the LFO/modulation source, but this might be hard to determine for harmonic-rich waveforms? Exactly how to manage the control signals is something I've not really gotten around to looking into properly yet... perhaps someone could explain how this is done for my benefit and for the benefit of the original poster? Hope that's been of some help... If you're a DSP boffin and you notice I've got something completely wrong, please correct me, it's the only way I'll learn lol. Dan ----- Original Message ----- From: "Allan Hoeltje" To: "dsp list" Sent: Wednesday, January 05, 2005 3:28 AM Subject: [music-dsp] Stupid DSP Question > Please forgive me in advance if this is a dumb question. I want to write > an > Audio Unit for my Macintosh that implements an effect that I usually run > on > an Eventide DSP7000. So that means I am learning about FIR and IIR > filters. > (I had calculus a long time ago in college, shortly after Newton publish > his > paper on the topic.) > > So, I understand that one needs to find coefficients to implement FIR and > IIR filters that respond to a specific frequency and bandwidth. However, > what does one do if they want a filter that has a Q and cutoff frequency > that varies in real-time, like those used in audio effect processors? Do > I > need to continuously calculate the coefficients in real time to > accommodate > the variable Q and cutoff frequency? It seems that this could get very > expensive for any filter with an order above 2! > > How is this problem generally solved? > > -Allan > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > From dan at bacterie.wanadoo.co.uk Tue Jan 4 23:50:25 2005 From: dan at bacterie.wanadoo.co.uk (Dan Evans) Date: Sun Jan 21 12:11:02 2007 Subject: [music-dsp] Stupid DSP Question References: <20050105152908.7b98b6ae.erikd-music-dsp@mega-nerd.com> Message-ID: <000701c4f2e2$12a1c9a0$ae7786d9@euclid> > You can then precalculate the parameters you want for the ranges you want, > store them in a table and interpolate between the table values. This is > all > quite doable in realtime with almost no CPU load on modern CPUs. you mean interpolate between coefficients? Hmm, I wasn't aware that this worked; I tried interpolating between coefficients for the Formant Filter on the music-dsp archive, and things got unstable at certain points, and didn't seem to morph properly between the vowels that were stable... Then again, no-one seems to know quite how those coefficients were obtained; I'm guessing it might work with more straightforward filter coefficients? In the end I used the RBJ filters for my formant filter and interpolated between frequency, bandwidth and amplitude values, calculating the coefficients over and over again - if I can instead store the coefficient values in a table and interpolate between them, like you suggested, I could save a lot of calculations. Dan From erikd-music-dsp at mega-nerd.com Wed Jan 5 01:22:17 2005 From: erikd-music-dsp at mega-nerd.com (Erik de Castro Lopo) Date: Sun Jan 21 12:11:02 2007 Subject: [music-dsp] Stupid DSP Question In-Reply-To: <000701c4f2e2$12a1c9a0$ae7786d9@euclid> References: <20050105152908.7b98b6ae.erikd-music-dsp@mega-nerd.com> <000701c4f2e2$12a1c9a0$ae7786d9@euclid> Message-ID: <20050105172217.3ac23152.erikd-music-dsp@mega-nerd.com> On Wed, 5 Jan 2005 04:50:25 -0000 "Dan Evans" wrote: > you mean interpolate between coefficients? Hmm, I wasn't aware that this > worked; It can work but you need to be careful. > I tried interpolating between coefficients for the Formant Filter on > the music-dsp archive, and things got unstable at certain points, and didn't > seem to morph properly between the vowels that were stable... Then again, > no-one seems to know quite how those coefficients were obtained; I'm > guessing it might work with more straightforward filter coefficients? In the > end I used the RBJ filters for my formant filter and interpolated between > frequency, bandwidth and amplitude values, That works much better. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo nospam@mega-nerd.com (Yes it's valid) +-----------------------------------------------------------+ "One World, one Web, one Browser." - Microsoft promotion "Ein Volk, ein Reich, ein Fuhrer." - Adolf Hitler -- +-----------------------------------------------------------+ Erik de Castro Lopo nospam@mega-nerd.com (Yes it's valid) +-----------------------------------------------------------+ "The beauty of religious mania is that it has the power to explain everything. Once God (or Satan) is accepted as the first cause of everything which happens in the mortal world, nothing is left to chance...logic can be happily tossed out the window." - Stephen King From signalzerodb at yahoo.co.uk Wed Jan 5 05:13:19 2005 From: signalzerodb at yahoo.co.uk (Dave Gamble) Date: Sun Jan 21 12:11:02 2007 Subject: [music-dsp] DSP Lies, Damn lies, and marketing! :) In-Reply-To: <20050104180103.56163.qmail@web51406.mail.yahoo.com> References: <20050104180103.56163.qmail@web51406.mail.yahoo.com> Message-ID: <6C33B764-5F02-11D9-B8B8-000A958903DE@yahoo.co.uk> Hey, > oh and never use Lisp for speech processing > :) Anyone got any good lies concerning fixed point / floating point processing? :)) One processor over another? One type of digital interconnect over another? Anyone else seen those crystals which you mount atop your amplifier? :) I've heard some good stuff in the past, but nothing springs to mind right now... :) What's everyone's favourite myth/marketing lie? :) [For BOFH readers, anything that switches a DSP-style *DUMMY MODE ON* ;) ] Cheers, Dave. From d.sbragion at infotecna.it Wed Jan 5 07:43:17 2005 From: d.sbragion at infotecna.it (Denis Sbragion) Date: Sun Jan 21 12:11:02 2007 Subject: [music-dsp] OT: DSP Lies, Damn lies, and marketing! :) In-Reply-To: <6C33B764-5F02-11D9-B8B8-000A958903DE@yahoo.co.uk> References: <20050104180103.56163.qmail@web51406.mail.yahoo.com> <20050104180103.56163.qmail@web51406.mail.yahoo.com> Message-ID: <5.1.0.14.1.20050105133558.02f6de68@pop3.infotecna.lcl> Hello Dave, At 10.13 05/01/2005 +0000, you wrote: >What's everyone's favourite myth/marketing lie? :) Myth: "The difference is clearly audible, you should be deaf to not hear it, but you need an ultra high-end hi-fi system which cost at least 10,000$, at least 20 years of High-End systems listening experience and a couple of truly golden ears to hear it." Marketing: "High-end audio is an industry based on abuse, greed and arrogance. It takes advantage of people who love music. Don't glorify this business." -- Mark Levinson Unfortunately this last one isn't a lie, but explain pretty well what's marketing coupled with myth... Bye, -- Denis Sbragion InfoTecna Tel: +39 0362 805396, Fax: +39 0362 805404 URL: http://www.infotecna.it From kouhia at nic.funet.fi Wed Jan 5 09:45:01 2005 From: kouhia at nic.funet.fi (Juhana Sadeharju) Date: Sun Jan 21 12:11:02 2007 Subject: [music-dsp] Re: Anyone know how to implement NTM crossovers? Message-ID: >From: "Ulrich Brueggemann" > >Appended quick and dirty code of NT filters. [ ... ] >Neville-Thiele Lowpass: > >for i := 1 to nr_of_points-1 do >begin > >f := FFT.FreqOfLine(i,sampletime); > > db := (1-0.25*power(f/fglow,2*k)) >/(1-0.5*power(f/fglow,2*k)+power(f/fglow,4*k)); Is this code useful at all in implementation of NTM crossovers? If the reason for the low quality of responses is the lack of information, then here goes: ftp://ftp.funet.fi/pub/sci/audio/devel/dsp/ The file "crossovers.tar.gz" contains two papers. The Linkwitz-Riley filter paper from Journal of AES (www.aes.org) Jan/Feb 1976, and the Thiele paper from JAES Sep 2000. Note that the papers deals with crossovers for speaker design, and that most of us want crossovers for audio signal splitting only. That is, the unnecessary fine adjustments related to the speaker cone positions and orientations may be skipped. How about three-band crossovers? I remember these were discussed here earlier at nearly practical level, but I cannot now verify if the music-dsp code archive or any other open source software has them. Anyone? BTW, has anyone yet implemented Antti's Moog filter precisely and is willing to submit it to the music-dsp code archive? Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software From yaakov_s at rad.com Wed Jan 5 10:52:44 2005 From: yaakov_s at rad.com (Yaakov Stein) Date: Sun Jan 21 12:11:02 2007 Subject: [music-dsp] Fixed Point FFT question Message-ID: <27A0F290348F8E45AEF79889DDE65A52038DBC46@exrad2.ad.rad.co.il> > And note that all your number base must be big enough to > represent the results of a convolution as a integers, so if > the signal is 16 bits and the filter function is 16 bits then > the calculations must be done in a base that's at least 32 bits. That's always the case, not some unusual requirement for NTTs. If you have a 16 bit processor that can't multiply two registers and produce a 32 bit answer, then I suggest confining yourself to problems that only use addition (but even that needs one more bit) and to forget about DSP. Y(J)S From allan at wholecheese.com Wed Jan 5 11:18:55 2005 From: allan at wholecheese.com (Allan Hoeltje) Date: Sun Jan 21 12:11:02 2007 Subject: [music-dsp] Stupid DSP Question In-Reply-To: <20050105152908.7b98b6ae.erikd-music-dsp@mega-nerd.com> Message-ID: Eric, Thank you for the tips and the harmony-central link. Looks like a lot of usable code there. Now its time to hack up a few AUs! -Allan "Erik de Castro Lopo" wrote on 1/4/05 8:29 PM: > > For audio filtering, IIR filter orders rarely get above say 10. An order > 10 filter can be implemented as a cascade of five 2nd order sections. A > second order section can be fully specified by two parameters (cutoff > and Q for lowpass and highpass, center and Q for bandpass etc). See the > Robert Bristow-Johnson formulas for more: > > http://www.harmony-central.com/Computer/Programming/Audio-EQ-Cookbook.txt > > You can then precalculate the parameters you want for the ranges you want, > store them in a table and interpolate between the table values. This is all > quite doable in realtime with almost no CPU load on modern CPUs. > > Erik From jdmiller at mail.arc.nasa.gov Wed Jan 5 13:01:04 2005 From: jdmiller at mail.arc.nasa.gov (Joel Miller) Date: Sun Jan 21 12:11:02 2007 Subject: [music-dsp] SLAB 3D-sound (part II) Message-ID: <6.1.2.0.2.20050105094017.02754008@mail.arc.nasa.gov> First, thanks for the feedback... Second, based on feedback I decided to redesign the website - it should now be much easier to tell what SLAB is and what it does... Quick description: "SLAB is a real-time virtual acoustic environment rendering system available from the Spatial Auditory Displays Lab at NASA Ames Research Center. SLAB performs spatial 3D-sound processing allowing the arbitrary placement of sound sources in auditory space. SLAB can be downloaded free for non-commercial use." http://human-factors.arc.nasa.gov/SLAB/ Regards, --joel From joshscholar at yahoo.com Wed Jan 5 16:12:18 2005 From: joshscholar at yahoo.com (Joshua Scholar) Date: Sun Jan 21 12:11:02 2007 Subject: [music-dsp] Fixed Point FFT question References: <27A0F290348F8E45AEF79889DDE65A52038DBC46@exrad2.ad.rad.co.il> Message-ID: <001101c4f36b$3e2ccc30$aae22641@antssoftware.com> Not quite. If you use floating or fixed point arithmetic, then you can divide your initial values down and don't need as many places... 5 * 5 = 25 but 5/10 *5/10 = 25/100 25 requires 5 bits to represent and .25 requires 2 bits after the binary point. Joshua Scholar ----- Original Message ----- From: "Yaakov Stein" To: "a list for musical digital signal processing" Sent: Wednesday, January 05, 2005 7:52 AM Subject: RE: [music-dsp] Fixed Point FFT question > And note that all your number base must be big enough to > represent the results of a convolution as a integers, so if > the signal is 16 bits and the filter function is 16 bits then > the calculations must be done in a base that's at least 32 bits. That's always the case, not some unusual requirement for NTTs. If you have a 16 bit processor that can't multiply two registers and produce a 32 bit answer, then I suggest confining yourself to problems that only use addition (but even that needs one more bit) and to forget about DSP. Y(J)S -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://shoko.calarts.edu/musicdsp http://ceait.calarts.edu/mailman/listinfo/music-dsp From martin.eisenberg at udo.edu Wed Jan 5 18:07:29 2005 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Sun Jan 21 12:11:02 2007 Subject: [music-dsp] Re: filtered grains in granular synthesis References: <20050103231802.GA87323@regency.estarcion.com> Message-ID: <001501c4f37b$5bf498a0$1e0d060a@mooncode> From: "Russell Borogove" > On Mon, Jan 03, 2005 at 01:34:33PM -0800, paul webb wrote: > > > I am making a few techniques such as > > *just stopping everything when grain envelope finishes > > *letting the filter carry on for X ammount of time > > then stopping > > *having a short decay envelope acting on the filter > > after grain finishes > > *trying to test when the filter is outputing zeros > > > > some of the above is sounding fine but anyone have > > any other suggestions / techniques I can try ? > > * simplest solution, but it will affect the sound somewhat: > filter the signal *before* putting it through the envelope - > when the envelope hits zero, the filtered signal is zero. You could even split the envelope before the final decay, at a peak, or similar and apply the first part, then filter, then the second part. That would preserve initial transient behavior. Martin From leechun at leechun.freeserve.co.uk Wed Jan 5 19:17:39 2005 From: leechun at leechun.freeserve.co.uk (chun lee) Date: Sun Jan 21 12:11:02 2007 Subject: [music-dsp] [OT] OpenLab London - call for artists Message-ID: OpenLab London This is our official announcement of the OpenLab project, we finally made it! OpenLab is a collaborative organization open to artists who make use of and support the free/open source software movement. Openlab exists to organize performances and events, with the intention of allowing participants to meet,share and exchange ideas face to face. http://www.pawfal.org/openlab/ This is an open call to audio/visual artists in the London (UK) area who would like to join in, help with events or ideally, perform their work. Events would take the form of musical performances, visual projection, and possibly installation work suitable for a club setting. If you want a piece of the action, add your name to the OpenLab people page on the wiki: http://www.pawfal.org/openlab/index.php?page=OpenlabPeople and join the mailing list: email majordomo@pawfal.org with the body of the message containing "subscribe openlab" Many thanks, Dave Griffiths (http://www.pawfal.org/nebogeo/) Chun Lee (http://www.sonicvariable.com/) From brianw at sounds.wa.com Wed Jan 5 19:43:05 2005 From: brianw at sounds.wa.com (Brian Willoughby) Date: Sun Jan 21 12:11:02 2007 Subject: [music-dsp] Fixed Point FFT question In-Reply-To: <001101c4f36b$3e2ccc30$aae22641@antssoftware.com> References: <27A0F290348F8E45AEF79889DDE65A52038DBC46@exrad2.ad.rad.co.il> <001101c4f36b$3e2ccc30$aae22641@antssoftware.com> Message-ID: <200501060043.j060hO210138@mortem.sounds.wa.com> Using floating point, scaling has no effect on the bit depth required. All floating point numbers are adjusted to keep as many significant bits as possible. In other words, floating point numbers are constantly being auto-scaled, so there can be no advantage to pre-scaling them manually. With fixed point, you might be able to avoid needing a larger bit depth result, if you have some intelligently computed normalizing scalar, but for many signals you would introduce a great deal of quantization noise in order to avoid overflow. Better to find a way to have higher precision in the results, using a greater bit depth. [ Not quite. If you use floating or fixed point arithmetic, then you can [ divide your initial values down and don't need as many places... [ [ 5 * 5 = 25 but [ [ 5/10 *5/10 = 25/100 [ [ 25 requires 5 bits to represent and .25 requires 2 bits after the binary [ point. [ [ Joshua Scholar Your example does not hold true for arbitrary input signals. The only reason that .25 requires fewer bits is because it is a nice power-of-two. If you start with 32 instead of 5, then it gets really bad using your scaling. 32 requires only 1 bit (ok, 5 bits if you must use fixed point), but dividing by 10 as you suggest would result in a value that takes an infinite number of bits to describe precisely. In other words, there will always be a loss of precision when dividing 32 by 10 in a binary number system. If you had 16 bits after the fixed decimal point, or even 32 bits, there would still be additional bits dropped beyond that. To put this another way, given an arbitrary signal on input, scaling by 10, or any other constant, will not always reduce the number of bits required to represent the value. At least not without introducing quantization noise and lack of precision. Remember, 16-bit fixed point has approximately 90 dB of dynamic range, and quantization noise is at best 96 dB down (below a full-scale signal). But while a 16-bit float has an incredibly higher dynamic range (more dB than the range of the human ear), the quantization noise is at best only about 70 dB below the signal. What's worse, the noise is correlated with the signal, so the increased dynamic range only allows you to get to a higher quantization noise floor as the signal gets louder. Using 32-bit float increases performance to the level of 24-bit fixed, but you still want 64-bit float results to avoid having the noise floor rise with any intermediate values that are higher level. One key thing to remember with FFT is that intermediate computation values, as well as the pre-computed values, vary wildly in range. It takes deep bit depths in either float or fixed point to handle that kind of range without introducing quantization noise. Brian Willoughby Sound Consulting ----- Original Message ----- If you have a 16 bit processor that can't multiply two registers and produce a 32 bit answer, then I suggest confining yourself to problems that only use addition (but even that needs one more bit) and to forget about DSP. Y(J)S From bobm.dsp at gmail.com Wed Jan 5 23:07:31 2005 From: bobm.dsp at gmail.com (Bob M) Date: Sun Jan 21 12:11:02 2007 Subject: [music-dsp] Re: Group Delay for FFT Convolution In-Reply-To: References: Message-ID: Just in case others are curious, I stumbled upon the answer to my question.. When using Fast (FFT) Convolution, the group delay is the same as when using time-domain FIR convolution for the same set of filter taps. That is, the group delay for an odd number N taps is (N-1)/2. The pitfall I had in my implementation of FFT convolution turned out to be related to amplitude. When overlapping and adding, I forgot to multiply the overlapped samples by 1/2. Bob On Wed, 29 Dec 2004 10:35:44 -0800, Bob M wrote: > I'm having trouble understanding what the delay (in samples) is when > sending input through a filter which is implemented using fast (FFT) > convolution. > > I understand that an FIR filter of an odd number N taps will have its > output delayed by (N-1)/2 samples. > > Is the delay the same for the same N filter coefficients when using > FFT convolution instead of FIR convolution? I would think the size of > each block of input needs to be taken into account, but I'm having > difficulty understanding how. > > Thanks for any help! I'm trying to sync up the output of a filter with > the original input. It's working well when using an FIR filter (with > (N-1)/2 delay), but it seems to be out of sync when using FFT > convolution with the same filter taps. > > Thanks, > Bob > From uli.brueggemann at freenet.de Thu Jan 6 02:46:34 2005 From: uli.brueggemann at freenet.de (Ulrich Brueggemann) Date: Sun Jan 21 12:11:02 2007 Subject: [music-dsp] Re: Group Delay for FFT Convolution References: Message-ID: <002401c4f3c3$d92bdfc0$32b9a8c0@BrueggemannNB> Hi Bob, I'm a little bit wondering. I used FFT convolution code according to the dspguide book chapter 18 for a while (www.dspguide.com) . There is no multiplication by 1/2. And it works well. IMO it is a good starting point. Uli ----- Original Message ----- From: "Bob M" To: Sent: Thursday, January 06, 2005 4:07 AM Subject: [music-dsp] Re: Group Delay for FFT Convolution > Just in case others are curious, I stumbled upon the answer to my > question.. > > When using Fast (FFT) Convolution, the group delay is the same as when > using time-domain FIR convolution for the same set of filter taps. > That is, the group delay for an odd number N taps is (N-1)/2. > > The pitfall I had in my implementation of FFT convolution turned out > to be related to amplitude. When overlapping and adding, I forgot to > multiply the overlapped samples by 1/2. > > Bob > > On Wed, 29 Dec 2004 10:35:44 -0800, Bob M wrote: >> I'm having trouble understanding what the delay (in samples) is when >> sending input through a filter which is implemented using fast (FFT) >> convolution. >> >> I understand that an FIR filter of an odd number N taps will have its >> output delayed by (N-1)/2 samples. >> >> Is the delay the same for the same N filter coefficients when using >> FFT convolution instead of FIR convolution? I would think the size of >> each block of input needs to be taken into account, but I'm having >> difficulty understanding how. >> >> Thanks for any help! I'm trying to sync up the output of a filter with >> the original input. It's working well when using an FIR filter (with >> (N-1)/2 delay), but it seems to be out of sync when using FFT >> convolution with the same filter taps. >> >> Thanks, >> Bob >> > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > > From bobm.dsp at gmail.com Thu Jan 6 10:20:14 2005 From: bobm.dsp at gmail.com (Bob M) Date: Sun Jan 21 12:11:03 2007 Subject: [music-dsp] Re: Group Delay for FFT Convolution In-Reply-To: <002401c4f3c3$d92bdfc0$32b9a8c0@BrueggemannNB> References: <002401c4f3c3$d92bdfc0$32b9a8c0@BrueggemannNB> Message-ID: Hi Ulrich, Thanks for the tip. Just to play devil's advocate, are you sure the amplitude is not being doubled by that FFT convolution code? I'd be curious what happens if you try generating a single sine tone of a known frequency and magnitude, and then bandpass it using that FFT convolution code. My guess is that its magnitude might be doubled. I wouldn't have picked up on it (because the audio coming out of the filter itself sounded fine), if not for the fact that the application that this is integrated into is very sensitive to errors in amplitude. It was only when I generated a single tone and tested it, as above, that I saw the change in magnitude resulting from the FFT convolution code. Regards, Bob On Thu, 6 Jan 2005 07:46:34 -0000, Ulrich Brueggemann wrote: > Hi Bob, > > I'm a little bit wondering. I used FFT convolution code according to the > dspguide book chapter 18 for a while (www.dspguide.com) . There is no > multiplication by 1/2. And it works well. IMO it is a good starting point. > > Uli > > ----- Original Message ----- > From: "Bob M" > To: > Sent: Thursday, January 06, 2005 4:07 AM > Subject: [music-dsp] Re: Group Delay for FFT Convolution > > > Just in case others are curious, I stumbled upon the answer to my > > question.. > > > > When using Fast (FFT) Convolution, the group delay is the same as when > > using time-domain FIR convolution for the same set of filter taps. > > That is, the group delay for an odd number N taps is (N-1)/2. > > > > The pitfall I had in my implementation of FFT convolution turned out > > to be related to amplitude. When overlapping and adding, I forgot to > > multiply the overlapped samples by 1/2. > > > > Bob > > > > On Wed, 29 Dec 2004 10:35:44 -0800, Bob M wrote: > >> I'm having trouble understanding what the delay (in samples) is when > >> sending input through a filter which is implemented using fast (FFT) > >> convolution. > >> > >> I understand that an FIR filter of an odd number N taps will have its > >> output delayed by (N-1)/2 samples. > >> > >> Is the delay the same for the same N filter coefficients when using > >> FFT convolution instead of FIR convolution? I would think the size of > >> each block of input needs to be taken into account, but I'm having > >> difficulty understanding how. > >> > >> Thanks for any help! I'm trying to sync up the output of a filter with > >> the original input. It's working well when using an FIR filter (with > >> (N-1)/2 delay), but it seems to be out of sync when using FFT > >> convolution with the same filter taps. > >> > >> Thanks, > >> Bob > >> > > -- > > dupswapdrop -- the music-dsp mailing list and website: > > subscription info, FAQ, source code archive, list archive, book reviews, > > dsp links > > http://shoko.calarts.edu/musicdsp > > http://ceait.calarts.edu/mailman/listinfo/music-dsp > > > > > > From uli.brueggemann at freenet.de Thu Jan 6 10:57:02 2005 From: uli.brueggemann at freenet.de (Ulrich Brueggemann) Date: Sun Jan 21 12:11:03 2007 Subject: [music-dsp] Re: Group Delay for FFT Convolution References: <002401c4f3c3$d92bdfc0$32b9a8c0@BrueggemannNB> Message-ID: <000401c4f408$615ac1b0$32b9a8c0@BrueggemannNB> Hi Bob, I'm not sure of course. But you can simply try it. It is not a big point to implement the dspguide FFT convolution (you can download the complete book for free, also the examples). Then you can test with your application and data. I'm interested in the result :-) Remark: I started with dspguide but today I work with MtxVec for Delphi (it uses the Intel DSP library) and that's absolute fine for my purposes. All the best Uli ----- Original Message ----- From: "Bob M" To: Sent: Thursday, January 06, 2005 3:20 PM Subject: Re: [music-dsp] Re: Group Delay for FFT Convolution > Hi Ulrich, > > Thanks for the tip. Just to play devil's advocate, are you sure the > amplitude is not being doubled by that FFT convolution code? > > I'd be curious what happens if you try generating a single sine tone > of a known frequency and magnitude, and then bandpass it using that > FFT convolution code. My guess is that its magnitude might be doubled. > > I wouldn't have picked up on it (because the audio coming out of the > filter itself sounded fine), if not for the fact that the application > that this is integrated into is very sensitive to errors in amplitude. > It was only when I generated a single tone and tested it, as above, > that I saw the change in magnitude resulting from the FFT convolution > code. > > Regards, > Bob > > On Thu, 6 Jan 2005 07:46:34 -0000, Ulrich Brueggemann > wrote: >> Hi Bob, >> >> I'm a little bit wondering. I used FFT convolution code according to the >> dspguide book chapter 18 for a while (www.dspguide.com) . There is no >> multiplication by 1/2. And it works well. IMO it is a good starting >> point. >> >> Uli >> >> ----- Original Message ----- >> From: "Bob M" >> To: >> Sent: Thursday, January 06, 2005 4:07 AM >> Subject: [music-dsp] Re: Group Delay for FFT Convolution >> >> > Just in case others are curious, I stumbled upon the answer to my >> > question.. >> > >> > When using Fast (FFT) Convolution, the group delay is the same as when >> > using time-domain FIR convolution for the same set of filter taps. >> > That is, the group delay for an odd number N taps is (N-1)/2. >> > >> > The pitfall I had in my implementation of FFT convolution turned out >> > to be related to amplitude. When overlapping and adding, I forgot to >> > multiply the overlapped samples by 1/2. >> > >> > Bob >> > >> > On Wed, 29 Dec 2004 10:35:44 -0800, Bob M wrote: >> >> I'm having trouble understanding what the delay (in samples) is when >> >> sending input through a filter which is implemented using fast (FFT) >> >> convolution. >> >> >> >> I understand that an FIR filter of an odd number N taps will have its >> >> output delayed by (N-1)/2 samples. >> >> >> >> Is the delay the same for the same N filter coefficients when using >> >> FFT convolution instead of FIR convolution? I would think the size of >> >> each block of input needs to be taken into account, but I'm having >> >> difficulty understanding how. >> >> >> >> Thanks for any help! I'm trying to sync up the output of a filter with >> >> the original input. It's working well when using an FIR filter (with >> >> (N-1)/2 delay), but it seems to be out of sync when using FFT >> >> convolution with the same filter taps. >> >> >> >> Thanks, >> >> Bob >> >> >> > -- >> > dupswapdrop -- the music-dsp mailing list and website: >> > subscription info, FAQ, source code archive, list archive, book >> > reviews, >> > dsp links >> > http://shoko.calarts.edu/musicdsp >> > http://ceait.calarts.edu/mailman/listinfo/music-dsp >> > >> > >> >> > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > > From richarddobson at blueyonder.co.uk Thu Jan 6 12:21:27 2005 From: richarddobson at blueyonder.co.uk (Richard Dobson) Date: Sun Jan 21 12:11:03 2007 Subject: [music-dsp] musical tests for a compressor? In-Reply-To: <6.1.2.0.2.20050105094017.02754008@mail.arc.nasa.gov> References: <6.1.2.0.2.20050105094017.02754008@mail.arc.nasa.gov> Message-ID: <41DD7397.6050609@blueyonder.co.uk> Hello all, Happy New year! I am at the advanced stage of writing a compressor plugin, and have of course a battery of test soundfiles to verify behaviour (e.g. to inspect the generated compression envelope), and to observe behaviour of various commercial examples, both "budget" and "high-end". I suspect my plugin is more commensurate with the budget ones than the high-end ones (not being paid enough for the latter anyway!). Anyway, the compressor is unquestioningly compressing, and seems indeed to compare pretty well with various commercial examples (but then I would say that...). My problem is this: coming from a predominantly classical background, I am accustomed to a wide dynamic range and have myself made very little use of compressors, so my ears are relatively innocent of the ways such things are used in other idioms, where compression is used (sometimes notoriously!) more heavily. What are the most important appropriate musical sources such as a reviewer might use when testing a plugin? I have some drum loops which compress easily enough; and I can but assume that the effect is the sort of thing those-who-compress-drum-loops want. I really do not have golden ears when it comes to drum loops! I recall seeing a reference to bass guitar licks and am already hunting down some examples. Suggestions of other (or better) canonical sounds would be much appreciated. Since I am implementing a simple switch between "soft knee" and "hard knee", some suggestions of a musical test that can reasonably easily discriminate one from the other would also be welcome. Most subtle of all, probably, is tests to distinguish between rms, averaging and peak modes. As a rule of thumb, what would people expect to use for what types of musical source? Can such things be reasonably discriminated aurally, or does it in the end all come down to the output level? Richard Dobson From rbj at surfglobal.net Thu Jan 6 12:51:50 2005 From: rbj at surfglobal.net (robert bristow-johnson) Date: Sun Jan 21 12:11:03 2007 Subject: [music-dsp] Fixed Point FFT question In-Reply-To: <3D0CEABD-5DC5-11D9-8B3A-000D93C2E232@yahoo.com> Message-ID: on 01/03/2005 15:22, Darren Gibbs at tsquank@yahoo.com wrote: >> clear as mud? > > Well, conceptually I was able to follow you, but not deep enough to > implement it in code... here's a rebroadcast of the math with some expansion. the last equation is what you implement to make an N/2 point complex FFT do the job of an N point real input FFT. you have N samples of real input data: u[n] 0 <= n < N you conceptually split it into two N/2 sized blocks of real data: u_e[n] = u[2*n] 0 <= n < N/2 u_o[n] = u[2*n+1] construct N/2 points of complex input data: x[n] = u_e[n] + j*u_o[n] 0 <= n < N/2 run a N/2 point complex DFT on that and get: X[k] = U_e[k] + j*U_o[k] 0 <= k < N/2 Because the input to this DFT was not real, the conjugate symmetry is not valid (unless of course all of the odd samples of u[n] are zero). X[N/2 - k] = conj{ X[k] } if and only if Im{ x[n] } = 0 But we use that symmetry for U_e[k] and U_o[k] since they are DFTs of purely real input. The goal is the N point DFT of u[n] which is: N-1 U[k] = sum{ u[n] * exp(-j*2*pi*n*k/N) } n=0 which, if N is even, can be split into two summations: N/2-1 U[k] = sum{ u[2*n] * exp(-j*2*pi*(2*n)*k/N) } n=0 N/2-1 + sum{ u[2*n+1] * exp(-j*2*pi*(2*n+1)*k/N) } n=0 N/2-1 = sum{ u_e[n] * exp(-j*2*pi*n*k/(N/2)) } n=0 N/2-1 + exp(-j*2*pi*k/N) * sum{ u_o[n] * exp(-j*2*pi*n*k/(N/2)) } n=0 = U_e[k] + exp(-j*2*pi*k/N) * U_o[k] So if we can untangle U_e[k] and U_o[k] (both real and imaginary parts) from X[k] = U_e[k] + j*U_o[k] then we can plug those U_e[k] and U_o[k] into U[k] = U_e[k] + exp(-j*2*pi*k/N) * U_o[k] then we have the result you are looking for. It is okay that U_e[k] and U_o[k] are defined for only N/2 points because U[k], being the DFT of a real input, is conjugate symmetric. U[N - k] = conj{ U[k] } because Im{ u[n] } = 0 Also, because Im{ u_e[n] } = Im{ u_o[n] } = 0 U_e[N/2 - k] = conj{ U_e[k] } U_o[N/2 - k] = conj{ U_o[k] } X[N/2 - k] = U_e[N/2 - k] + j*U_o[N/2 - k] = conj{ U_e[k] } + j*conj{ U_o[k] } X[k] + X[N/2-k] = U_e[k] + conj{ U_e[k] } + j*(U_o[k] + conj{ U_o[k] }) = 2*Re{ U_e[k] } + 2*j*Re{ U_o[k] } X[k] - X[N/2-k] = U_e[k] - conj{ U_e[k] } + j*(U_o[k] - conj{ U_o[k] }) = 2*j*Im{ U_e[k] } - 2*Im{ U_o[k] } We use this fact to extract U_e[k] and U_o[k] out of X[k] 2*Re{ U_e[k] } = Re{ X[k] + X[N/2-k] } 2*Im{ U_e[k] } = Im{ X[k] - X[N/2-k] } 2*Re{ U_o[k] } = Im{ X[k] + X[N/2-k] } -2*Im{ U_o[k] } = Re{ X[k] - X[N/2-k] } (keep the periodicity of the DFT in mind when you think about X[N/2-0].) So U[k] = U_e[k] + exp(-j*2*pi*k/N) * U_o[k] = (X[k] + conj{X[N/2-k]})/2 + exp(-j*2*pi*k/N) * (X[k] - conj{X[N/2-k]})/(2*j) = 0.5 * ( Re{ X[k] + X[N/2-k] } + j*Im{ X[k] - X[N/2-k] } ) + 0.5 * exp(-j*2*pi*k/N) * ( Im{ X[k] + X[N/2-k] } - j*Re{ X[k] - X[N/2-k] } ) = 0.5 * ( Re{ X[k] + X[N/2-k] } + j*Im{ X[k] - X[N/2-k] } ) + 0.5 * ( cos(2*pi*k/N) - j*sin(2*pi*k/N) ) * ( Im{ X[k] + X[N/2-k] } - j*Re{ X[k] - X[N/2-k] } ) = 0.5 * ( Re{ X[k] + X[N/2-k] } + j*Im{ X[k] - X[N/2-k] } ) + 0.5 * ( cos(2*pi*k/N)*Im{ X[k] + X[N/2-k] } - sin(2*pi*k/N)*Re{ X[k] - X[N/2-k] } - j*sin(2*pi*k/N)*Im{ X[k] + X[N/2-k] } - j*cos(2*pi*k/N)*Re{ X[k] - X[N/2-k] } ) = 0.5 * ( Re{ X[k] + X[N/2-k] } + cos(2*pi*k/N)*Im{ X[k] + X[N/2-k] } - sin(2*pi*k/N)*Re{ X[k] - X[N/2-k] } ) + j*0.5 * ( Im{ X[k] - X[N/2-k] } - sin(2*pi*k/N)*Im{ X[k] + X[N/2-k] } - cos(2*pi*k/N)*Re{ X[k] - X[N/2-k] } ) From jchandjr at bellsouth.net Thu Jan 6 13:23:36 2005 From: jchandjr at bellsouth.net (James Chandler Jr) Date: Sun Jan 21 12:11:03 2007 Subject: [music-dsp] musical tests for a compressor? References: <6.1.2.0.2.20050105094017.02754008@mail.arc.nasa.gov> <41DD7397.6050609@blueyonder.co.uk> Message-ID: <048b01c4f41c$d6674410$6401a8c0@JamesCompaq3080> Hi Richard I'm not an expert, but here are some listening torture-tests-- 1. Heavily compress a two-fisted piano track, which is punctuated with low aggressive bass notes and mid/high chordal piano tinkling. Under heavy compression, its gonna pump like crazy on about any compressor (though a multi-band compressor might hide the pumping better). But subtlties of the envelope detectors can make a difference on how obnoxious-sounding the pumping will be. Also listen for intermodulation distortion. A good envelope filter will keep the bass notes from making nasty IM distortion on the right-hand chords. A poor envelope filter will allow bad IM distortion, and even psycho-acoustic clicks and pops (IOW, the audio is technically 'clean', but quick envelope changes put sudden edges on the audio waveform, which are perceived as clicks and pops). 2. Heavily compress an electric bass and listen for assorted undesirable nasty artifacts. 3. Heavily compress a bass+drum mix, and listen how the electric bass, kick, and snare ducks the hihats and cymbals. There will always be some ducking, but a multi-stage envelope can help minimize the obnoxious ducking. ===== Also test tones-- You could make up sine-wave 'step' test tones. Perhaps the amplitude is -20 dB for several seconds, then jumps to 0 dB for several seconds. Repeat the step jumps, with progressively shorter step duration. You can compress the test tone to an output file, then examine it "zoomed out" with an audio editor, to see how your envelope detector is performing. Several test tone files can be useful. Perhaps one step test tone file at 10 KHz, and other files at 1 KHz, 100 Hz, maybe even 40 Hz. Zooming in on heavily compressed low-freq step test tones can be useful to visualize what kind of transient waveform distortions are being imposed by your compressor. Its a good way to find/solve gremlins that might be trashing heavily-compressed bass instruments. JJCJR From s.eversmeier at gmx.de Thu Jan 6 13:53:14 2005 From: s.eversmeier at gmx.de (Sascha Eversmeier) Date: Sun Jan 21 12:11:03 2007 Subject: [music-dsp] Re: musical tests for a compressor? (Richard Dobson) References: <20050106175205.605AF18A5383@music.calarts.edu> Message-ID: <41DD891A.3D418361@gmx.de> Hi Richard, > I am at the advanced stage of writing a compressor plugin Welcome aboard ;) > My problem is this: coming from a predominantly classical background, I am > accustomed to a wide dynamic range and have myself made very little use of > compressors, so my ears are relatively innocent of the ways such things are used > in other idioms, where compression is used (sometimes notoriously!) more heavily. This is good. Really good. > What are the most important appropriate musical sources such as a reviewer might > use when testing a plugin? I have some drum loops which compress easily enough; > and I can but assume that the effect is the sort of thing > those-who-compress-drum-loops want. I really do not have golden ears when it > comes to drum loops! I recall seeing a reference to bass guitar licks and am > already hunting down some examples. Suggestions of other (or better) canonical > sounds would be much appreciated. My opinion is: forget artificial sounds. Go for real-world signals. If your unit is already performing 'right', take the best and finest signals possible. Is surely easier to locate artifacts here than with alien noise, plings, boings and electric zaps (getting pathetic now...). When I'm testing stuff, I take recordings from my personal surroundings, from people I know, take recordings from which I know I've done my best and listened to them a million times over. It doesn't harm if you have an emotional relationship towards your signals. I think the contrary is true. For example, I go for female voices, piano recordings, percussions. Plus, I've done some choir recordings performed in churches that turned out to be very helpful for compressor tests. Of course, such signals should be totally un-compressed... make your own, then you know they are 'clean' ;) Pianos are brilliant for testing. If recorded well, the release phase says a lot, especially when you're experimenting with different release-type curves and program-dependent release time circuits. Acoustic guitars are good, too (e.g. various portions of room information). Percussions are essential for playing around with the attack shape and the first msecs. Take tablas, for instance. I personally find that 'drum loops' suck, especially those that pretend to sound 'real' but consist of nothing but samples (again: who says they aren't already compressed? Even if they initially sound 'okay', it could easily be that someone's clamped the peaks). I better rely on takes that I've made in the past. If you've done such yourself, you 'know' more easily how it 'should' sound (especially when having stood beneath the kit and the ears were doing 'natural compression'... :D). 'How is that snare supposed to sound?'... 'man this is NOT my floor tom... what's up with that???'... > Since I am implementing a simple switch between "soft knee" and "hard knee", > some suggestions of a musical test that can reasonably easily discriminate one > from the other would also be welcome. Experience is the key. You can't give such on to the end user. Better figure out yourself what your beast is capable of. This can take very very long. But that's the game. According to'knee', my opinion is that the more complex the source, the more easily different knees can be heard. Again, the human ear is the best measuring instrument, especially on vocal takes, narrators and 'everyday sound'. For example, make some takes with a pair of mics in your flat or a hallway: record a minute with someone (or you) walking in the distance, coming closer, going away. Other test: record 30secs of an alarm clock (the old mechanical ones with that big 'ears'...), just let it tick in a room and place a mic in the diffuse field. > Most subtle of all, probably, is tests to distinguish between rms, averaging and > peak modes. As a rule of thumb, what would people expect to use for what types > of musical source? Can such things be reasonably discriminated aurally, or does > it in the end all come down to the output level? There are nearly as many averaging modes as there are compressor units... in the end, it all comes down to 'taste' and 'signature sound'. Do yourself a favour and build something unique. There's already too much 'academic' devices in the world. Here as well: experience is the key. If you concentrate long enough on the topic, you may come up with something really strange where all the rms-window-function-peak-response-something people would rather shoot you. But that means nothing if that thing's definitely having balls and making people sweat. My two eurocents, Sascha From r_obert at hotmail.com Thu Jan 6 19:31:35 2005 From: r_obert at hotmail.com (robert) Date: Sun Jan 21 12:11:03 2007 Subject: [music-dsp] Re: Group Delay for FFT Convolution In-Reply-To: Message-ID: I was wondering Bob. Thanks for the followup. Robert > -----Original Message----- > From: music-dsp-bounces@ceait.calarts.edu [mailto:music-dsp- > bounces@ceait.calarts.edu] On Behalf Of Bob M > Sent: Wednesday, January 05, 2005 10:08 PM > To: music-dsp@ceait.calarts.edu > Subject: [music-dsp] Re: Group Delay for FFT Convolution > > Just in case others are curious, I stumbled upon the answer to my > question.. > > When using Fast (FFT) Convolution, the group delay is the same as when > using time-domain FIR convolution for the same set of filter taps. > That is, the group delay for an odd number N taps is (N-1)/2. > > The pitfall I had in my implementation of FFT convolution turned out > to be related to amplitude. When overlapping and adding, I forgot to > multiply the overlapped samples by 1/2. > > Bob > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.6.8 - Release Date: 1/3/2005 From lanceboyle at cwazy.co.uk Thu Jan 6 23:54:44 2005 From: lanceboyle at cwazy.co.uk (Lance Boyle) Date: Sun Jan 21 12:11:03 2007 Subject: [music-dsp] musical tests for a compressor? In-Reply-To: <048b01c4f41c$d6674410$6401a8c0@JamesCompaq3080> References: <6.1.2.0.2.20050105094017.02754008@mail.arc.nasa.gov> <41DD7397.6050609@blueyonder.co.uk> <048b01c4f41c$d6674410$6401a8c0@JamesCompaq3080> Message-ID: <3F5F147D-6068-11D9-A6D5-003065F93FF0@cwazy.co.uk> On Jan 6, 2005, at 11:23 AM, James Chandler Jr wrote: > nvelope filter will keep the bass notes from making nasty IM > distortion on the right-hand chords. A poor envelope filter will allow > bad IM distortion, and even psycho-acoustic clicks and pops (IOW, the > audio is technically 'clean', but quick envelope changes put sudden > edges on the audio waveform, which are perceived as clicks and pops). > This is almost certainly aliasing distortion, don't you think? Lance From warder at dlc.fi Fri Jan 7 00:06:55 2005 From: warder at dlc.fi (Vesa Norilo) Date: Sun Jan 21 12:11:03 2007 Subject: [music-dsp] musical tests for a compressor? In-Reply-To: <3F5F147D-6068-11D9-A6D5-003065F93FF0@cwazy.co.uk> References: <6.1.2.0.2.20050105094017.02754008@mail.arc.nasa.gov> <41DD7397.6050609@blueyonder.co.uk> <048b01c4f41c$d6674410$6401a8c0@JamesCompaq3080> <3F5F147D-6068-11D9-A6D5-003065F93FF0@cwazy.co.uk> Message-ID: <41DE18EF.2000007@dlc.fi> Lance Boyle wrote: > > On Jan 6, 2005, at 11:23 AM, James Chandler Jr wrote: > >> nvelope filter will keep the bass notes from making nasty IM >> distortion on the right-hand chords. A poor envelope filter will >> allow bad IM distortion, and even psycho-acoustic clicks and pops >> (IOW, the audio is technically 'clean', but quick envelope changes >> put sudden edges on the audio waveform, which are perceived as clicks >> and pops). >> > This is almost certainly aliasing distortion, don't you think? > No, in fact I think it's mostly amplitude modulation inharmonicity. Unless of course it is pushing your signal out of the acceptable frequency band. Overrall, the compressor problem is (in my opinion) trying to avoid introducing audio rate amplitude modulation while still making the compressor react fast enough. Bandlimiting the amplitude envelope to say 10Hz would surely remove most of compressor artifacts, but also make it way too slow to react to transients. Vesa From jchandjr at bellsouth.net Fri Jan 7 00:15:10 2005 From: jchandjr at bellsouth.net (James Chandler Jr) Date: Sun Jan 21 12:11:03 2007 Subject: [music-dsp] musical tests for a compressor? References: <6.1.2.0.2.20050105094017.02754008@mail.arc.nasa.gov><41DD7397.6050609@blueyonder.co.uk><048b01c4f41c$d6674410$6401a8c0@JamesCompaq3080> <3F5F147D-6068-11D9-A6D5-003065F93FF0@cwazy.co.uk> Message-ID: <069001c4f477$dc94a070$6401a8c0@JamesCompaq3080> Hi Lance Good idea. It could be aliasing distortion in a digital plugin, hadn't thought of that. But I first encountered compressor psychoacoustic pops with analog compressors in the 1970's, debugged with stepped sine tones visualized with a memory oscilloscope. It wasn't aliasing in that case. A sharp enough discontinuity on a smooth waveform just sounds like a pop. It is particularly annoying in non-lookahead hard limiters. JCJR ----- Original Message ----- From: "Lance Boyle" To: "a list for musical digital signal processing" Sent: Thursday, January 06, 2005 11:54 PM Subject: Re: [music-dsp] musical tests for a compressor? > > On Jan 6, 2005, at 11:23 AM, James Chandler Jr wrote: > >> nvelope filter will keep the bass notes from making nasty IM distortion on >> the right-hand chords. A poor envelope filter will allow bad IM distortion, >> and even psycho-acoustic clicks and pops (IOW, the audio is technically >> 'clean', but quick envelope changes put sudden edges on the audio waveform, >> which are perceived as clicks and pops). >> > This is almost certainly aliasing distortion, don't you think? > > Lance > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, > source code archive, list archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > From citizenchunk at gmail.com Fri Jan 7 02:42:58 2005 From: citizenchunk at gmail.com (Citizen Chunk) Date: Sun Jan 21 12:11:03 2007 Subject: [music-dsp] musical tests for a compressor? In-Reply-To: <048b01c4f41c$d6674410$6401a8c0@JamesCompaq3080> References: <6.1.2.0.2.20050105094017.02754008@mail.arc.nasa.gov> <41DD7397.6050609@blueyonder.co.uk> <048b01c4f41c$d6674410$6401a8c0@JamesCompaq3080> Message-ID: On Thu, 6 Jan 2005 13:23:36 -0500, James Chandler Jr wrote: > I'm not an expert, but ... oh come on now, James! you are an expert, and you know it! ;) seriously--listen to what he says. this guy knows compressors. btw, sometimes, if you feel fairly confident in your project, it might be more useful to release an alpha/beta to get the opinion of John Q. Public. you might want to try www.kvraudio.com. they can get pretty rowdy at times, but most of their criticism is constructive. i'd love to put your comp through its paces--if you'll let me. ;) == chunk From signalzerodb at yahoo.co.uk Fri Jan 7 07:29:58 2005 From: signalzerodb at yahoo.co.uk (Dave Gamble) Date: Sun Jan 21 12:11:03 2007 Subject: [music-dsp] musical tests for a compressor? In-Reply-To: <069001c4f477$dc94a070$6401a8c0@JamesCompaq3080> References: <6.1.2.0.2.20050105094017.02754008@mail.arc.nasa.gov><41DD7397.6050609@blueyonder.co.uk><048b01c4f41c$d6674410$6401a8c0@JamesCompaq3080> <3F5F147D-6068-11D9-A6D5-003065F93FF0@cwazy.co.uk> <069001c4f477$dc94a070$6401a8c0@JamesCompaq3080> Message-ID: On 7 Jan 2005, at 05:15, James Chandler Jr wrote: > Hi Lance > > Good idea. It could be aliasing distortion in a digital plugin, hadn't > thought of that. > > But I first encountered compressor psychoacoustic pops with analog > compressors in the 1970's, debugged with stepped sine tones visualized > with a memory oscilloscope. It wasn't aliasing in that case. > No indeed. In any kind of VCA type mechanism, you are literally ring modulating the signal with the VCA envelope. Sharp jumps in VCA envelope will cause wide frequency spreads (in the fourier-analysis of ringmod sense) in your output. You do get pops from analogue compressors - it's part of the sound, and I for one like it. Mostly, one finds that compressors popping is a result of heavy compression combined with slow attacks, when the explanation is simply that you are increasing the distance (on attacky transients) between the peak and the body. (As anyone will know who's figured out how to use a compressor as an expander!) You turn the makeup gain up, and you have a huge spike at the start of your compressed signal. > A sharp enough discontinuity on a smooth waveform just sounds like a > pop. It is particularly annoying in non-lookahead hard limiters. Agreed. Of course, without proper attention, ring modulation implemented digitally causes aliasing. With a sufficiently sharp discontinuity, the VCA output from a digital compressor will sound different to the VCA output from an analogue compressor (when no care has been taken to prevent the aliasing). However, we are talking about very exceptional circumstances to get such a discontinuity, and a very short burst of the aliasing noise! The audible effect would be a slight change in timbre of the 'thwack' at the start of the hit. I have found that digital compressors tend to offer shorter attack times than analogue compressors, and this also results in spikier VCA envelopes, which means (often) that the default settings give a very clicky sound. Dave. From warder at dlc.fi Fri Jan 7 09:06:53 2005 From: warder at dlc.fi (Vesa Norilo) Date: Sun Jan 21 12:11:03 2007 Subject: [music-dsp] musical tests for a compressor? In-Reply-To: References: <6.1.2.0.2.20050105094017.02754008@mail.arc.nasa.gov> <41DD7397.6050609@blueyonder.co.uk> <048b01c4f41c$d6674410$6401a8c0@JamesCompaq3080> Message-ID: <41DE977D.90702@dlc.fi> >btw, sometimes, if you feel fairly confident in your project, it might >be more useful to release an alpha/beta to get the opinion of John Q. >Public. you might want to try www.kvraudio.com. they can get pretty >rowdy at times, but most of their criticism is constructive. i'd love >to put your comp through its paces--if you'll let me. ;) > > Try mine if you'd care to: http://cmt.siba.fi/soundsleeve/audio/vst/MDC.zip - for Win32/VST Vesa From jchandjr at bellsouth.net Fri Jan 7 12:11:36 2005 From: jchandjr at bellsouth.net (James Chandler Jr) Date: Sun Jan 21 12:11:03 2007 Subject: [music-dsp] musical tests for a compressor? References: <6.1.2.0.2.20050105094017.02754008@mail.arc.nasa.gov><41DD7397.6050609@blueyonder.co.uk><048b01c4f41c$d6674410$6401a8c0@JamesCompaq3080><3F5F147D-6068-11D9-A6D5-003065F93FF0@cwazy.co.uk><069001c4f477$dc94a070$6401a8c0@JamesCompaq3080> Message-ID: <071301c4f4db$f1da0970$6401a8c0@JamesCompaq3080> > I have found that digital compressors tend to offer shorter attack times than > analogue compressors, and this also results in spikier VCA envelopes, which > means (often) that the default settings give a very clicky sound. Hi Dave There was at least one expensive analog lookahead peak limiter, but can't recall the name right now. Saw one at a mastering studio years ago. It had a delay unit built-in, to accomplish the lookahead in real-time. One might wire together a digital delay rackmount and a good analog compressor to kludge a lookahead analog compressor (cheaper than buying a Waves L2 (GRIN)). Feed Digital Delay output into the Compressor input, and feed the un-delayed signal into the side chain. Back when I was obsessed hardware hacking compressors, a guy gave me a PAIA cheap hard limiter designed by Craig Anderton. It was based on a NE570 compander chip. The PAIA limiter was just barely modified from a Signetics Appnote circuit. I torture-tested it with a Baldwin grand piano, sitting there with headphones and oscilloscope off to the side. Ah the good old days (GRIN). The gadget might have been useful for light limiting, assuming you like a series of clicks better than you like a section of overload distortion (GRIN). But it was generally too clicky to be practical. These clicks are better described as very brief 'ticks'. This thing had a practically instant Attack (source of the clicks), and a medium Release. Increasing the smoothing cap value to increase the Release, didn't cure the clicking. Longer Release just slowed the click rate, and longer Release made awful pumping. The comparator envelope design had no way to decrease the attack time (and had real good current drive). No way to improve it short of replacing the entire envelope circuit. Sorry for the tedious reminiscenses, but I think that's why we don't see many analog compressors with minimum attack time lower than a couple of milliseconds. Without that min attack time, it just sounds bad. Most non-lookahead analog hard-limiters, have a few millisecond attack time, and use a soft-clipper to clamp transient peaks that leak thru while the envelope is charging. This seems inelegant and heavy-handed. But in practice, brief transient soft-clipping will sound much better than those obnoxious clicks. Another interesting observation toying with the PAIA limiter-- Since it was punctuating each over-threshold peak with a click, it was easy to notice that even a sustained piano chord would give a 'random' series of clicks. Occasionally the sustained chord notes reinforce each other and go way over threshold, repeatedly triggering the envelope generator as the chord decays. JCJR From kouhia at nic.funet.fi Mon Jan 10 08:33:26 2005 From: kouhia at nic.funet.fi (Juhana Sadeharju) Date: Sun Jan 21 12:11:03 2007 Subject: [music-dsp] Re: Implementing kurtosis maximization for dereverberation Message-ID: >From: David Fee > >I'm wondering if anyone has come across a paper "Speech dereverberation >via maximum-kurtosis subband adaptive filtering" ICASSP 2001, Gillespie, >Malvar and Florencio. Maybe the topic is not best suited for this list, music-dsp. But I have earlier wondered how the multisensor signal extraction methods would work for the vocal extraction in stereo music. I picked up the paper. We could write a couple of general tools to the music-dsp code archive -- like the MCLT bandsplitting and the adaptive filter. The paper is available at ftp://ftp.funet.fi/pub/sci/audio/devel/dsp/ >The paper recommends using >Modulated Complex Lapped Transforms (MCLT). I've been using Modulated >Lapped Transform (purely real) as outlined in Malvar's book but with no >real success. Why they use the complex valued transform if the real valued would do fine? Does real valued MLT loose the information? Perhaps that information is relevant. Are the lapped transform required? Would any lossless transform do fine? Like Portnoff's phase vocoder having complex valued band splitting. Could you make your source code available for closer examination? Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software From mbartkow at et.put.poznan.pl Tue Jan 11 02:47:18 2005 From: mbartkow at et.put.poznan.pl (Maciej Bartkowiak) Date: Sun Jan 21 12:11:03 2007 Subject: [music-dsp] Re: Implementing kurtosis maximization fordereverberation References: Message-ID: <022601c4f7b1$c6c77910$f81dfe96@cpo.multimedia.edu.pl> ----- Original Message ----- From: "Juhana Sadeharju" To: Sent: Monday, January 10, 2005 2:33 PM Subject: [music-dsp] Re: Implementing kurtosis maximization fordereverberation > >The paper recommends using > >Modulated Complex Lapped Transforms (MCLT). I've been using Modulated > >Lapped Transform (purely real) as outlined in Malvar's book but with no > >real success. > > Why they use the complex valued transform if the real valued would > do fine? Does real valued MLT loose the information? Perhaps > that information is relevant. The problem with real MLT is that it usually realizes a critically subsampled filterbank, i.e. a filterbank with a significant amount of aliasing between neighboring bands. This aliasing is supposed to be cancelled during the synthesis process, provided the subbands are not modified significantly. To some extend it works well in applications like compression, with only moderate distortion introduced in the form of quantization noise (that is wideband and therefore aliased anyway). However, if you introduce different attenuation to subbands, there is no chance for the aliasing components to cancel each other. A complex MLT is an overcomplete representation that allows to introduce different weights to the neighboring subbands/coefficients. > Are the lapped transform required? Would any lossless transform do > fine? Like Portnoff's phase vocoder having complex valued band > splitting. a lapped transform has several advantages over processing on the basis of disjoint blocks: - there are no discontinuities between blocks after your manipulation in the data, so no blocking artifacts (clicks) - a windowing function may be applied to smooth out the ends of the block of data in order to control the spectral leakage without losing information (due to overlaping windows, output samples are reconstructed from at least two blocks of transform) MB --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.823 / Virus Database: 561 - Release Date: 2004-12-27 From joshscholar at yahoo.com Tue Jan 11 02:59:35 2005 From: joshscholar at yahoo.com (Joshua Scholar) Date: Sun Jan 21 12:11:03 2007 Subject: [music-dsp] Re: Implementing kurtosis maximizationfordereverberation References: <022601c4f7b1$c6c77910$f81dfe96@cpo.multimedia.edu.pl> Message-ID: <003201c4f7b3$7ec3bbe0$92e22641@antssoftware.com> BTW I was working on a critically sample filterbank design with minimal aliasing between bands (the aliasing was limited to the nearest bands) and which also allowed some sort of control over how much aliasing there is... Of course the less aliasing, the more processing you have to do and the more levels of overlaps there are. I recently came up with a way of simplifying the processing to an exteme extent... Anyway as soon as I'm finished putting together the lossless/near-lossed sound compression codec I've been working on perhaps I'll throw together a demonstration of the filterbank. But perhaps I've just reinvented MLT or some such, I've never heard of those. One wierdness with my transform, I never got it to reconstruct all the way up to nyquest and I had to cheat to get it to work all the way down to DC. Is their any similar wierdnesses to MLT filterbanks? Joshua Scholar ----- Original Message ----- From: "Maciej Bartkowiak" To: Sent: Monday, January 10, 2005 11:47 PM Subject: Re: [music-dsp] Re: Implementing kurtosis maximizationfordereverberation > ----- Original Message ----- > From: "Juhana Sadeharju" > To: > Sent: Monday, January 10, 2005 2:33 PM > Subject: [music-dsp] Re: Implementing kurtosis maximization fordereverberation > > > > >The paper recommends using > > >Modulated Complex Lapped Transforms (MCLT). I've been using Modulated > > >Lapped Transform (purely real) as outlined in Malvar's book but with no > > >real success. > > > > Why they use the complex valued transform if the real valued would > > do fine? Does real valued MLT loose the information? Perhaps > > that information is relevant. > > The problem with real MLT is that it usually realizes a critically subsampled filterbank, > i.e. a filterbank with a significant amount of aliasing between neighboring bands. > This aliasing is supposed to be cancelled during the synthesis process, provided > the subbands are not modified significantly. To some extend it works well in applications > like compression, with only moderate distortion introduced in the form of quantization > noise (that is wideband and therefore aliased anyway). However, if you introduce different > attenuation to subbands, there is no chance for the aliasing components to cancel each other. > > A complex MLT is an overcomplete representation that allows to introduce different weights > to the neighboring subbands/coefficients. > > > Are the lapped transform required? Would any lossless transform do > > fine? Like Portnoff's phase vocoder having complex valued band > > splitting. > > a lapped transform has several advantages over processing on the basis of disjoint blocks: > - there are no discontinuities between blocks after your manipulation in the data, so no blocking > artifacts (clicks) > - a windowing function may be applied to smooth out the ends of the block of data in order to > control the spectral leakage without losing information (due to overlaping windows, output samples > are reconstructed from at least two blocks of transform) > > MB > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.823 / Virus Database: 561 - Release Date: 2004-12-27 > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp From david.fee at qub.ac.uk Tue Jan 11 07:23:51 2005 From: david.fee at qub.ac.uk (David Fee) Date: Sun Jan 21 12:11:03 2007 Subject: [music-dsp] Re: Implementing kurtosis maximization fordereverberation In-Reply-To: <022601c4f7b1$c6c77910$f81dfe96@cpo.multimedia.edu.pl> References: <022601c4f7b1$c6c77910$f81dfe96@cpo.multimedia.edu.pl> Message-ID: <41E3C557.1000508@qub.ac.uk> Hi I've noticed the large amount of aliasing is a big problem with MLT. I'm wondering if this is, therefore, not suitable for the implementation of the apative filter as suggested in the Gillespie paper (http://research.microsoft.com/~malvar/papers/icassp01makurt.pdf) and perhaps I should be using the complex version instead (MCLT) The other question is how to implement the update function. As far as I understand, the output of the inverse transform will produce a new block. I'm calculating an update vector by iterating through this block and performing an MLT on this vector. I then multiply my adaptive filters by the corresponding update value. Of course, it doesn't work, but as suggested that could be because of the real nature of the transform. If anyone's interested, I can mail the code for further discussion. Regards David Fee Maciej Bartkowiak wrote: >----- Original Message ----- >From: "Juhana Sadeharju" >To: >Sent: Monday, January 10, 2005 2:33 PM >Subject: [music-dsp] Re: Implementing kurtosis maximization fordereverberation > > > > >>>The paper recommends using >>>Modulated Complex Lapped Transforms (MCLT). I've been using Modulated >>>Lapped Transform (purely real) as outlined in Malvar's book but with no >>>real success. >>> >>> >>Why they use the complex valued transform if the real valued would >>do fine? Does real valued MLT loose the information? Perhaps >>that information is relevant. >> >> > >The problem with real MLT is that it usually realizes a critically subsampled filterbank, >i.e. a filterbank with a significant amount of aliasing between neighboring bands. >This aliasing is supposed to be cancelled during the synthesis process, provided >the subbands are not modified significantly. To some extend it works well in applications >like compression, with only moderate distortion introduced in the form of quantization >noise (that is wideband and therefore aliased anyway). However, if you introduce different >attenuation to subbands, there is no chance for the aliasing components to cancel each other. > >A complex MLT is an overcomplete representation that allows to introduce different weights >to the neighboring subbands/coefficients. > > > >>Are the lapped transform required? Would any lossless transform do >>fine? Like Portnoff's phase vocoder having complex valued band >>splitting. >> >> > >a lapped transform has several advantages over processing on the basis of disjoint blocks: >- there are no discontinuities between blocks after your manipulation in the data, so no blocking >artifacts (clicks) >- a windowing function may be applied to smooth out the ends of the block of data in order to >control the spectral leakage without losing information (due to overlaping windows, output samples >are reconstructed from at least two blocks of transform) > >MB > > >--- >Outgoing mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.823 / Virus Database: 561 - Release Date: 2004-12-27 >-- >dupswapdrop -- the music-dsp mailing list and website: >subscription info, FAQ, source code archive, list archive, book reviews, dsp links >http://shoko.calarts.edu/musicdsp >http://ceait.calarts.edu/mailman/listinfo/music-dsp > > > -- David Fee Innovative Audio Systems Group Sonic Arts Research Centre Queen's University, Belfast Tel. (mob) +44 (0)7729 883433 Tel. (office) +44 (0)28 9027 4761 Email david.fee@qub.ac.uk From contact at sciss.de Tue Jan 11 15:00:46 2005 From: contact at sciss.de (contact@sciss.de) Date: Sun Jan 21 12:11:03 2007 Subject: [music-dsp] Announce: FScape 0.65 Message-ID: ahoi everyone, my audio rendering software fscape has migrated to sourceforge and has become an open source project. download the current version 0.65 at http://sourceforge.net/projects/fscape/ changes to version 0.61 : removed all platform specific code, this version finally runs on mac os x, win xp and linux (the latter not tested) and supports WAVE sound file format. now with easy to use installer, a few more online help files and a few more modules, many bugfixes and minor improvements. enjoy! best, -sciss- From postmaster at emotu.it Tue Jan 11 16:07:16 2005 From: postmaster at emotu.it (eMOTU) Date: Sun Jan 21 12:11:04 2007 Subject: [music-dsp] VSTGUI question - moving bitmaps Message-ID: <41E44004.3090306@emotu.it> Hi, I need to draw two simple loop markers over a progress bar. When the user presses a button these markers have to move. I wrote a simple class like this /*****************************************************/ class LoopMarker : public CView { public: LoopMarker (const CRect& size, long bmpID) : CView (size) { hMarker = new CBitmap (bmpID); } virtual void draw (CDrawContext* context) { hMarker->drawTransparent (context, size); } protected: CBitmap* hMarker; }; /*******************************************************/ Then I add the 2 bmp with frame->addView(marker). But every time I have to move them I need to delete and recreate. Is there a more elegant way? thanx Carlo From dgm at baykitty.com Tue Jan 11 19:18:54 2005 From: dgm at baykitty.com (don) Date: Sun Jan 21 12:11:04 2007 Subject: [music-dsp] fft and phase Message-ID: <007001c4f83c$5044f840$0401a8c0@liuxing> Doing an FFT on very low frequencies, I am having a problem accurately deriving phase. I cannot supply an integer number of cycles to the FFT at the frequency of interest and as a result the phase is not being resolved correctly. Is there another way to get accurate phase information, even if it means that frequency amplitude information is wasted? ? Don ? From oberfeld at uni-mainz.de Wed Jan 12 05:02:36 2005 From: oberfeld at uni-mainz.de (oberfeld) Date: Sun Jan 21 12:11:04 2007 Subject: [music-dsp] Generation of bandpassed-filtered Gaussian noise Message-ID: <41E4F5BC.40900@uni-mainz.de> Dear list, could anyone hint me to suitable methods for generating bandpassed-filtered Gaussian random noise, e.g. with frequencies only between 900 and 1100 Hz? I need this for a classroom demonstration in psychoacoustics (loudness summation). The problem I see is the following: most filters also 'distort' phase, so which kind of filter (FFT-based?) could one use so that the phases remain *random*? If someone would be willing to share some MATLAB code, this would save me a lot of time... Best wishes Daniel From adry at gmx.at Wed Jan 12 05:07:22 2005 From: adry at gmx.at (=?ISO-8859-1?Q?=22Adriano_Br=FCstle=22?=) Date: Sun Jan 21 12:11:04 2007 Subject: [music-dsp] IIR filter 6th order problem Message-ID: <16358.1105524442@www12.gmx.net> Hi, I'm using the Motorola EVM56k and I want to programm a IIR lowpass filter 6th order in direct form. I want to do it with three filter stages 2nd order. One filter stage i have already implemented. The coefficients (a0,a1,a2,b1,b2 from each filter stage) are stored in a ring buffer with six slots. The past input values (en(n-1) and en(n-2) for each filter stage) and the past output values (sn(n-1) and sn(n-2) for each filter stage) are stored in a ring buffer with each 6 slots. Now I don't know how I have to read/write the en and sn values. Maybee it helps you if i post the sourcecode of one filter stage. r0 points to the coefficients stored in a 6 slot ring buffer. r4 points to the past values of en of each filter stage stored in a six slot ring buffer. r5 points to the past values of sn of each filter stage stored in a six slot ring buffer. move x:(r0)+,x0 mpy x0,y1,a x:(r0)+,x0 y:(r4)+,y0 mac x0,y0,a x:(r0)+,x0 y:(r4),y0 mac x0,y0,a x:(r0)+,x0 y:(r5)+,y0 mac -x0,y0,a x:(r0)+,x0 y:(r5),y0 macr -x0,y0,a y1,y:(r4)+ asl a move a,y:(r5)+ When i have 3 of these filter stages the past values of sn and en always overwrite each other in the ring buffer. Please help me. Greetings from Austria Adriano B. -- +++ GMX - die erste Adresse für Mail, Message, More +++ 1 GB Mailbox bereits in GMX FreeMail http://www.gmx.net/de/go/mail From signalzerodb at yahoo.co.uk Wed Jan 12 06:08:06 2005 From: signalzerodb at yahoo.co.uk (Dave Gamble) Date: Sun Jan 21 12:11:04 2007 Subject: [music-dsp] Generation of bandpassed-filtered Gaussian noise In-Reply-To: <41E4F5BC.40900@uni-mainz.de> References: <41E4F5BC.40900@uni-mainz.de> Message-ID: <3C459902-648A-11D9-9AFE-000A958903DE@yahoo.co.uk> Hey, > could anyone hint me to suitable methods for generating > bandpassed-filtered Gaussian random noise, e.g. with frequencies only > between 900 and 1100 Hz? I need this for a classroom demonstration in > psychoacoustics (loudness summation). The problem I see is the > following: most filters also 'distort' phase, so which kind of filter > (FFT-based?) could one use so that the phases remain *random*? > Applying a linear phase process to a random signal is still a random signal. Filtering noise won't make the phase any less random. Dave. From kouhia at nic.funet.fi Wed Jan 12 11:59:04 2005 From: kouhia at nic.funet.fi (Juhana Sadeharju) Date: Sun Jan 21 12:11:04 2007 Subject: [music-dsp] Re: Implementing kurtosis maximization for dereverberation Message-ID: >From: "Maciej Bartkowiak" > >there are no discontinuities between blocks after your manipulation >in the data, so no blocking artifacts (clicks) In Portnoff's phase vocoder the FFT window must move almost from sample to sample for smoothness. How lapped transform window should move? Some of the overlapping seems to be built-in to the lapped transform. And due the built-in overlapping the same length transforms cannot be compared directly. Is it so? I will pick up Malvar's original papers soon. [ Joshua Scholar ] >But perhaps I've just reinvented MLT or some such, I've never heard of >those. IEEE would do a cultural act if it would make one of its survey journal or magazine as "open access". Proceedings of IEEE, perhaps. However, Proc. of IEEE has (or had) non-survey papers as well. Such open access journal/magazine should have only surveys. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software From kaleja at estarcion.com Wed Jan 12 12:20:35 2005 From: kaleja at estarcion.com (Russell Borogove) Date: Sun Jan 21 12:11:05 2007 Subject: [music-dsp] Generation of bandpassed-filtered Gaussian noise References: <41E4F5BC.40900@uni-mainz.de> Message-ID: <001401c4f8cb$0891a9f0$0601000a@jaseroque> > could anyone hint me to suitable methods for generating > bandpassed-filtered Gaussian random noise, e.g. with frequencies only > between 900 and 1100 Hz? I need this for a classroom demonstration in > psychoacoustics (loudness summation). The problem I see is the > following: most filters also 'distort' phase, so which kind of filter > (FFT-based?) could one use so that the phases remain *random*? Random phases biased by particular frequency-dependent values should still be random, shouldn't they? -Borogove From giancarlo.vercellesi at dsi.unimi.it Wed Jan 12 12:33:26 2005 From: giancarlo.vercellesi at dsi.unimi.it (Giancarlo Vercellesi) Date: Sun Jan 21 12:11:05 2007 Subject: [music-dsp] musical tests for a compressor? References: <6.1.2.0.2.20050105094017.02754008@mail.arc.nasa.gov> <41DD7397.6050609@blueyonder.co.uk> Message-ID: <005f01c4f8cc$ddf16c60$9e9f959f@lim.dico.unimi.it> You can find and free download WAV files to test your codec from http://www.tnt.uni-hannover.de/project/mpeg/audio/sqam/ They are some audio files belong to SQAM (Sound Quality Assessment Material) CDDA, used by MPEG to test their own algorithms. Then, you can find more information about objective and subjective measurements of perceived audio quality on ITU recommendations BS.1387 (objective), BS.1116 and BS.1284 (subjective) - www.itu.int/ITU-R/ Regards Giancarlo Vercellesi From signalzerodb at yahoo.co.uk Wed Jan 12 12:50:41 2005 From: signalzerodb at yahoo.co.uk (Dave Gamble) Date: Sun Jan 21 12:11:05 2007 Subject: [music-dsp] Generation of bandpassed-filtered Gaussian noise In-Reply-To: <001401c4f8cb$0891a9f0$0601000a@jaseroque> References: <41E4F5BC.40900@uni-mainz.de> <001401c4f8cb$0891a9f0$0601000a@jaseroque> Message-ID: <79F6C9E3-64C2-11D9-B272-000A958903DE@yahoo.co.uk> On 12 Jan 2005, at 17:20, Russell Borogove wrote: >> could anyone hint me to suitable methods for generating >> bandpassed-filtered Gaussian random noise, e.g. with frequencies only >> between 900 and 1100 Hz? I need this for a classroom demonstration in >> psychoacoustics (loudness summation). The problem I see is the >> following: most filters also 'distort' phase, so which kind of filter >> (FFT-based?) could one use so that the phases remain *random*? > > Random phases biased by particular frequency-dependent values > should still be random, shouldn't they? The way I see it, it's either that, or they turn into Choral music... :-/ Dave. __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com From douglas at music.columbia.edu Wed Jan 12 13:09:43 2005 From: douglas at music.columbia.edu (douglas irving repetto) Date: Sun Jan 21 12:11:05 2007 Subject: [music-dsp] fft and phase In-Reply-To: <007001c4f83c$5044f840$0401a8c0@liuxing> References: <007001c4f83c$5044f840$0401a8c0@liuxing> Message-ID: is there a reason why you can't just increase your fft size? ideally you want to scale your fft size to fit the lowest frequency of interest. you'll lose time resolution, but that's a built-in trade off with the fft. douglas >Doing an FFT on very low frequencies, I am having a problem accurately >deriving phase. >I cannot supply an integer number of cycles to the FFT at the frequency of >interest and as a result the phase is not being resolved correctly. Is there >another way to get accurate phase information, even if it means that >frequency amplitude information is wasted? > >Don -- ............................................... http://artbots.org .....douglas.....irving........................ http://dorkbot.org ................................ http://ceait.calarts.edu/musicdsp .......... repetto............. http://music.columbia.edu/organism ............................... http://music.columbia.edu/~douglas From dgm at baykitty.com Wed Jan 12 15:49:58 2005 From: dgm at baykitty.com (don) Date: Sun Jan 21 12:11:05 2007 Subject: [music-dsp] fft and phase In-Reply-To: Message-ID: <009a01c4f8e8$4a5608f0$0401a8c0@liuxing> I realize that. Unfortunately, the application (which I cannot discuss) only allows me so much time. Does anyone know away to get phase information with a full cycle at the target frequency? I am using an FFT but I may be able to change that. Don -----Original Message----- From: music-dsp-bounces@ceait.calarts.edu [mailto:music-dsp-bounces@ceait.calarts.edu] On Behalf Of douglas irving repetto Sent: Wednesday, January 12, 2005 10:10 AM To: a list for musical digital signal processing Subject: Re: [music-dsp] fft and phase is there a reason why you can't just increase your fft size? ideally you want to scale your fft size to fit the lowest frequency of interest. you'll lose time resolution, but that's a built-in trade off with the fft. douglas >Doing an FFT on very low frequencies, I am having a problem accurately >deriving phase. >I cannot supply an integer number of cycles to the FFT at the frequency of >interest and as a result the phase is not being resolved correctly. Is there >another way to get accurate phase information, even if it means that >frequency amplitude information is wasted? > >Don -- ............................................... http://artbots.org .....douglas.....irving........................ http://dorkbot.org ................................ http://ceait.calarts.edu/musicdsp .......... repetto............. http://music.columbia.edu/organism ............................... http://music.columbia.edu/~douglas -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://shoko.calarts.edu/musicdsp http://ceait.calarts.edu/mailman/listinfo/music-dsp From jeffmcc at ihug.co.nz Wed Jan 12 20:32:17 2005 From: jeffmcc at ihug.co.nz (Jeff McClintock) Date: Sun Jan 21 12:11:05 2007 Subject: [music-dsp] Upsampling my Mod-Wheel In-Reply-To: <20050106001813.79847189F618@music.calarts.edu> References: <20050106001813.79847189F618@music.calarts.edu> Message-ID: <41E5CFA1.90906@ihug.co.nz> Hi All, I've written a soft synth. One thing it does is apply MIDI controllers to audio. I have to smooth these controllers, i.e. upsample them to audio rate. Untill now I've been doing so with a crude ramping technique, but now I want to upsample 'properly'. My textbook says I should pad out the samples with zeros, then filter at half the original sample rate. The mod-wheel samples arrive at 126 Hz, and I set the filter cuttoff to 50 Hz (just under half). I did so (using the biquad low-pass from the Music DSP archives) but the result is terrible, as an experiment I tried just duplicating the samples instead before filtering, it looks much better .... http://www.synthedit.com/smoothing.gif What am I doing wrong?, how is a filter meant to smooth those jagged impulses? have a made a simple coding error, or is sample-duplication better?, I'm sure I read somewhere sample-duplication was theoreticaly wrong, have I mis-understood the proceedure?. Any enlightenment much appreciated. Cheers, Jeff From cournape at enst.fr Wed Jan 12 22:07:38 2005 From: cournape at enst.fr (David Cournapeau) Date: Sun Jan 21 12:11:05 2007 Subject: [music-dsp] Upsampling my Mod-Wheel In-Reply-To: <41E5CFA1.90906@ihug.co.nz> References: <20050106001813.79847189F618@music.calarts.edu> <41E5CFA1.90906@ihug.co.nz> Message-ID: <41E5E5FA.20906@enst.fr> Jeff McClintock wrote: > Hi All, > > I've written a soft synth. One thing it does is apply MIDI > controllers to audio. I have to smooth these controllers, i.e. > upsample them to audio rate. Untill now I've been doing so with a > crude ramping technique, but now I want to upsample 'properly'. > My textbook says I should pad out the samples with zeros, then > filter at half the original sample rate. The mod-wheel samples arrive > at 126 Hz, and I set the filter cuttoff to 50 Hz (just under half). > I did so (using the biquad low-pass from the Music DSP archives) but > the result is terrible, as an experiment I tried just duplicating the > samples instead before filtering, it looks much better .... I think one problem may come from this step, that is using biquad filter: AFAIK, their purpose is not really to be used for resampling. > > http://www.synthedit.com/smoothing.gif > > What am I doing wrong?, how is a filter meant to smooth those jagged > impulses? have a made a simple coding error, or is sample-duplication > better?, I'm sure I read somewhere sample-duplication was theoreticaly > wrong It is not "wrong", it is an approximation (the most crude one, even linear interpolation is better). With 0 insertion and filtering, you try to achieve a "perfect" upsampling; by repeating the same samples, you are interpolating, in a crude way. See http://perso.enst.fr/~cournape/upsampling.jpg for a comparison with a sine ( If you can read matlab scripts, the script used to do the figure is here: http://perso.enst.fr/~cournape/upsampling.m) David From paranoiaspoisondoor at gmail.com Wed Jan 12 22:36:13 2005 From: paranoiaspoisondoor at gmail.com (Keith Handy) Date: Sun Jan 21 12:11:05 2007 Subject: [music-dsp] Upsampling my Mod-Wheel In-Reply-To: <41E5E5FA.20906@enst.fr> References: <20050106001813.79847189F618@music.calarts.edu> <41E5CFA1.90906@ihug.co.nz> <41E5E5FA.20906@enst.fr> Message-ID: <79a2ad410501121936b76fea2@mail.gmail.com> I've never used the "padding with zeros" thing ... I'm not a DSP guru so I don't even understand that method, but I could venture a guess that it's not going to work if your samples are not evenly spaced apart. For something like a controller wheel, which is meant to produce an arbitrary curve rather than any kind of periodic tones, I would suggest looking up code for splines. On Thu, 13 Jan 2005 12:07:38 +0900, David Cournapeau wrote: > Jeff McClintock wrote: > > > Hi All, > > > > I've written a soft synth. One thing it does is apply MIDI > > controllers to audio. I have to smooth these controllers, i.e. > > upsample them to audio rate. Untill now I've been doing so with a > > crude ramping technique, but now I want to upsample 'properly'. > > My textbook says I should pad out the samples with zeros, then > > filter at half the original sample rate. The mod-wheel samples arrive > > at 126 Hz, and I set the filter cuttoff to 50 Hz (just under half). > > I did so (using the biquad low-pass from the Music DSP archives) but > > the result is terrible, as an experiment I tried just duplicating the > > samples instead before filtering, it looks much better .... > > I think one problem may come from this step, that is using biquad > filter: AFAIK, their purpose is not really to be used for resampling. > > > > > http://www.synthedit.com/smoothing.gif > > > > What am I doing wrong?, how is a filter meant to smooth those jagged > > impulses? have a made a simple coding error, or is sample-duplication > > better?, I'm sure I read somewhere sample-duplication was theoreticaly > > wrong > > It is not "wrong", it is an approximation (the most crude one, even > linear interpolation is better). With 0 insertion and filtering, you try > to achieve a "perfect" upsampling; by repeating the same samples, you > are interpolating, in a crude way. > > See http://perso.enst.fr/~cournape/upsampling.jpg for a comparison with > a sine > ( If you can read matlab scripts, the script used to do the figure is > here: http://perso.enst.fr/~cournape/upsampling.m) > > David > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > -- -Keith From jeffmcc at ihug.co.nz Wed Jan 12 23:07:54 2005 From: jeffmcc at ihug.co.nz (Jeff McClintock) Date: Sun Jan 21 12:11:05 2007 Subject: [music-dsp] Upsampling my Mod-Wheel In-Reply-To: <20050113033641.C2E0B18E06F8@music.calarts.edu> References: <20050113033641.C2E0B18E06F8@music.calarts.edu> Message-ID: <41E5F41A.8070901@ihug.co.nz> http://www.synthedit.com/smoothing.gif >but I could venture a guess that it's not going to work if your samples are not evenly spaced apart. Ah, That makes sense, the samples are 'clumped' in twos (don't know why, My Keyboard sent them that way). Even a good reconstruction filter would give me a 'wavey' result. I also noticed a 'missing' sample near the peak caused a big dip in the result. Also makes sense, even though it's not the result i wanted. I guess zero-padding works best with perfectly regular samples. Cheers, Jeff From: Keith Handy Subject: Re: [music-dsp] Upsampling my Mod-Wheel To: a list for musical digital signal processing Message-ID: <79a2ad410501121936b76fea2@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII I've never used the "padding with zeros" thing ... I'm not a DSP guru so I don't even understand that method, but I could venture a guess that it's not going to work if your samples are not evenly spaced apart. For something like a controller wheel, which is meant to produce an arbitrary curve rather than any kind of periodic tones, I would suggest looking up code for splines. From jchandjr at bellsouth.net Wed Jan 12 23:05:30 2005 From: jchandjr at bellsouth.net (James Chandler Jr) Date: Sun Jan 21 12:11:05 2007 Subject: [music-dsp] Upsampling my Mod-Wheel References: <20050106001813.79847189F618@music.calarts.edu><41E5CFA1.90906@ihug.co.nz> <41E5E5FA.20906@enst.fr> <79a2ad410501121936b76fea2@mail.gmail.com> Message-ID: <00ac01c4f925$1f6b7a20$6401a8c0@JamesCompaq3080> I've never written a softsynth, but perhaps linear interpolation upsampling is about as good as its gonna get? Am just thinking that any kind of lopass upsampling will 'delay in time' the original control values a bit, and could at least slightly mess with the exact amplitude of the control values? Often the exact value or time of a MIDI controller is not critical, and anything 'in the ballpark' will do. But occasionally if a user enters a controller value of 67 at time 004:2:128 (or whatever), he needs this EXACT value at this EXACT time. In that case, either linear interpolation or spline interpolation might be the optimum methods to guarantee exact results? If a softsynth already has a log or other nonlinear response built-in to its controller response, wouldn't linear interpolation be the proper method? A curvey interpolation (like spline) would seem counterproductive? JCJR From jchandjr at bellsouth.net Wed Jan 12 23:09:39 2005 From: jchandjr at bellsouth.net (James Chandler Jr) Date: Sun Jan 21 12:11:05 2007 Subject: [music-dsp] Upsampling my Mod-Wheel References: <20050106001813.79847189F618@music.calarts.edu><41E5CFA1.90906@ihug.co.nz> <41E5E5FA.20906@enst.fr> <79a2ad410501121936b76fea2@mail.gmail.com> Message-ID: <00cb01c4f925$b41ef390$6401a8c0@JamesCompaq3080> I've never written a softsynth, but perhaps linear interpolation upsampling is about as good as its gonna get? Am just thinking that any kind of lopass upsampling will 'delay in time' the original control values a bit, and could at least slightly mess with the exact amplitude of the control values? Often the exact value or time of a MIDI controller is not critical, and anything 'in the ballpark' will do. But occasionally if a user enters a controller value of 67 at time 004:2:128 (or whatever), he needs this EXACT value at this EXACT time. In that case, either linear interpolation or spline interpolation might be the optimum methods to guarantee exact results? If a softsynth already has a log or other nonlinear response built-in to its controller response, wouldn't linear interpolation be the proper method? A curvey interpolation (like spline) could be counterproductive? JCJR From paranoiaspoisondoor at gmail.com Thu Jan 13 00:23:30 2005 From: paranoiaspoisondoor at gmail.com (Keith Handy) Date: Sun Jan 21 12:11:05 2007 Subject: [music-dsp] Upsampling my Mod-Wheel In-Reply-To: <00cb01c4f925$b41ef390$6401a8c0@JamesCompaq3080> References: <20050106001813.79847189F618@music.calarts.edu> <41E5CFA1.90906@ihug.co.nz> <41E5E5FA.20906@enst.fr> <79a2ad410501121936b76fea2@mail.gmail.com> <00cb01c4f925$b41ef390$6401a8c0@JamesCompaq3080> Message-ID: <79a2ad4105011221233cf7a14f@mail.gmail.com> If it's real time, then even linear interpolation is impossible without a delay, right? On Wed, 12 Jan 2005 23:09:39 -0500, James Chandler Jr wrote: > I've never written a softsynth, but perhaps linear interpolation upsampling is > about as good as its gonna get? > > Am just thinking that any kind of lopass upsampling will 'delay in time' the > original control values a bit, and could at least slightly mess with the exact > amplitude of the control values? > > Often the exact value or time of a MIDI controller is not critical, and anything > 'in the ballpark' will do. But occasionally if a user enters a controller value > of 67 at time 004:2:128 (or whatever), he needs this EXACT value at this EXACT > time. > > In that case, either linear interpolation or spline interpolation might be the > optimum methods to guarantee exact results? > > If a softsynth already has a log or other nonlinear response built-in to its > controller response, wouldn't linear interpolation be the proper method? A > curvey interpolation (like spline) could be counterproductive? > > JCJR > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > -- -Keith From warder at dlc.fi Thu Jan 13 00:34:50 2005 From: warder at dlc.fi (Vesa Norilo) Date: Sun Jan 21 12:11:05 2007 Subject: [music-dsp] Upsampling my Mod-Wheel In-Reply-To: <00cb01c4f925$b41ef390$6401a8c0@JamesCompaq3080> References: <20050106001813.79847189F618@music.calarts.edu><41E5CFA1.90906@ihug.co.nz> <41E5E5FA.20906@enst.fr> <79a2ad410501121936b76fea2@mail.gmail.com> <00cb01c4f925$b41ef390$6401a8c0@JamesCompaq3080> Message-ID: <41E6087A.1020704@dlc.fi> > > > If a softsynth already has a log or other nonlinear response built-in > to its > controller response, wouldn't linear interpolation be the proper > method? A > curvey interpolation (like spline) could be counterproductive? I would imagine that since he is probably working with sub-audio rate control signals (<20Hz) and his signal is not critically sampled (126Hz) linear interpolation will do just fine. I think in control signals the waveform shape is much more important than anything that happens in the frequency domain. And I doubt very much your ear can tell whether your vibrato amplitude (or similiar parameter) was linearily interpolated or something fancier. What the ear probably can hear is untreated signal, because zipper noise is a particularily nasty thing due to discontinuities. However, I think linear interpolation will dispose of them quite effectively. Splines would do that even for derivatives (?) Vesa From jchandjr at bellsouth.net Thu Jan 13 01:26:26 2005 From: jchandjr at bellsouth.net (James Chandler Jr) Date: Sun Jan 21 12:11:05 2007 Subject: [music-dsp] Upsampling my Mod-Wheel References: <20050106001813.79847189F618@music.calarts.edu><41E5CFA1.90906@ihug.co.nz> <41E5E5FA.20906@enst.fr><79a2ad410501121936b76fea2@mail.gmail.com><00cb01c4f925$b41ef390$6401a8c0@JamesCompaq3080> <79a2ad4105011221233cf7a14f@mail.gmail.com> Message-ID: <011201c4f938$cf968710$6401a8c0@JamesCompaq3080> ----- Original Message ----- From: "Keith Handy" To: "a list for musical digital signal processing" Sent: Thursday, January 13, 2005 12:23 AM Subject: Re: [music-dsp] Upsampling my Mod-Wheel > If it's real time, then even linear interpolation is impossible > without a delay, right? Hi Keith An excellent question, way above my pay grade (GRIN). Hosting DXi (the only softsynth hosting I have experience with), I dump all the midi events that will time-fit in the 'next buffer' to the DXi, and then tell the DXi to render that buffer. The lookahead time from the DXi's perspective, would be the buffer size? If using small buffers for low latency, that would mean very little lookahead time. The time position of the controller in the target audio buffer could affect the interpolation. Controller timestamps near the end of a render buffer, would give the softsynth a better opportunity to smoothly ramp up to the next controller value? But a controller near the beginning of a target render buffer would have to be ramped-up quicker, because the new controller value is more of a 'surprise'? The previous buffer rendering didn't know that a new controller value was about to be received in the next buffer render! Ramping forward seems problematic or even impossible (for realtime), because the softsynth has no way to know what controllers are in the future, beyond the end of the current render buffer, not yet known to the softsynth? Perhaps the density of received controllers would be something that the softsynth would consider? If controllers are pretty close-spaced, one might assume that controller events are part of a gesture (mod wheel gesture or whatever)? But sparse controllers may be better handled as 'step events'? Fer example, a few hi-end keyboard controllers can send continuous-value sustain pedal events, but most keyboards only send 'on' and 'off' sustain pedal controllers. Would it be counter-productive to interpolate very sparse sustain pedal events? Since I know nothing about writing softsynths, looks like a thorny problem for 'realtime' softsynth plugins which don't have access to the entire score before doing a render operation. I'll never find time to write a softsynth, but it would be interesting to see opinions on how it is best handled. JCJR From paranoiaspoisondoor at gmail.com Thu Jan 13 02:06:40 2005 From: paranoiaspoisondoor at gmail.com (Keith Handy) Date: Sun Jan 21 12:11:05 2007 Subject: [music-dsp] midi to wav rendering, was Upsampling my Mod-Wheel In-Reply-To: <41E6087A.1020704@dlc.fi> References: <20050106001813.79847189F618@music.calarts.edu> <41E5CFA1.90906@ihug.co.nz> <41E5E5FA.20906@enst.fr> <79a2ad410501121936b76fea2@mail.gmail.com> <00cb01c4f925$b41ef390$6401a8c0@JamesCompaq3080> <41E6087A.1020704@dlc.fi> Message-ID: <79a2ad41050112230624e288e@mail.gmail.com> See, me being me, if it was something for non-realtime, like rendering from a midi file to a wav file, then I would spline all the control values just to be anal. Which reminds me of a question that I've had that might not be too ridiculously off-topic for this forum: does anyone know of any good software for non-realtime rendering from midi files to wavs, using soundfonts/samples/softsynths? I know of at least one (WAVmaker) for Windows, but I'd like to not become dependent on something proprietary. I've looked over the stuff on Dave Phillip's site (linux-sound.org) too, but don't see many entries with the word "render" in them. On Thu, 13 Jan 2005 07:34:50 +0200, Vesa Norilo wrote: > > > > > > > If a softsynth already has a log or other nonlinear response built-in > > to its > > controller response, wouldn't linear interpolation be the proper > > method? A > > curvey interpolation (like spline) could be counterproductive? > > > I would imagine that since he is probably working with sub-audio rate > control signals (<20Hz) and his signal is not critically sampled (126Hz) > linear interpolation will do just fine. I think in control signals the > waveform shape is much more important than anything that happens in the > frequency domain. And I doubt very much your ear can tell whether your > vibrato amplitude (or similiar parameter) was linearily interpolated or > something fancier. What the ear probably can hear is untreated signal, > because zipper noise is a particularily nasty thing due to > discontinuities. However, I think linear interpolation will dispose of > them quite effectively. Splines would do that even for derivatives (?) > > Vesa > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > -- -Keith From erikd-music-dsp at mega-nerd.com Thu Jan 13 02:19:27 2005 From: erikd-music-dsp at mega-nerd.com (Erik de Castro Lopo) Date: Sun Jan 21 12:11:06 2007 Subject: [music-dsp] midi to wav rendering, was Upsampling my Mod-Wheel In-Reply-To: <79a2ad41050112230624e288e@mail.gmail.com> References: <20050106001813.79847189F618@music.calarts.edu> <41E5CFA1.90906@ihug.co.nz> <41E5E5FA.20906@enst.fr> <79a2ad410501121936b76fea2@mail.gmail.com> <00cb01c4f925$b41ef390$6401a8c0@JamesCompaq3080> <41E6087A.1020704@dlc.fi> <79a2ad41050112230624e288e@mail.gmail.com> Message-ID: <20050113181927.00079294.erikd-music-dsp@mega-nerd.com> On Thu, 13 Jan 2005 02:06:40 -0500 Keith Handy wrote: > Which reminds me of a question that I've had that might not be too > ridiculously off-topic for this forum: does anyone know of any good > software for non-realtime rendering from midi files to wavs, using > soundfonts/samples/softsynths? I know of at least one (WAVmaker) for > Windows, but I'd like to not become dependent on something > proprietary. I've looked over the stuff on Dave Phillip's site > (linux-sound.org) too, but don't see many entries with the word > "render" in them. I'm pretty sure TiMidity does this. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo nospam@mega-nerd.com (Yes it's valid) +-----------------------------------------------------------+ C++ is a siren song. It *looks* like a HLL in which you ought to be able to write an application, but it really isn't." -- Alain Picard (comp.lang.lisp) From mbartkow at et.put.poznan.pl Thu Jan 13 03:31:05 2005 From: mbartkow at et.put.poznan.pl (Maciej Bartkowiak) Date: Sun Jan 21 12:11:06 2007 Subject: [music-dsp] Upsampling my Mod-Wheel References: <20050106001813.79847189F618@music.calarts.edu><41E5CFA1.90906@ihug.co.nz><41E5E5FA.20906@enst.fr><79a2ad410501121936b76fea2@mail.gmail.com><00cb01c4f925$b41ef390$6401a8c0@JamesCompaq3080><79a2ad4105011221233cf7a14f@mail.gmail.com> <011201c4f938$cf968710$6401a8c0@JamesCompaq3080> Message-ID: <006401c4f94a$3a01d030$f81dfe96@cpo.multimedia.edu.pl> > Ramping forward seems problematic or even impossible (for realtime), because the > softsynth has no way to know what controllers are in the future, beyond the end > of the current render buffer, not yet known to the softsynth? [...] > > Since I know nothing about writing softsynths, looks like a thorny problem for > 'realtime' softsynth plugins which don't have access to the entire score before > doing a render operation. I'll never find time to write a softsynth, but it > would be interesting to see opinions on how it is best handled. contemporary high-end virtual analogue synths (like Access Virus B/C) do smooth their controllers in realtime. My guess is they employ some prediction scheme for the upcoming events. I would use a low-order adaptive predictor, LPC perhaps? MB From mbartkow at et.put.poznan.pl Thu Jan 13 03:37:56 2005 From: mbartkow at et.put.poznan.pl (Maciej Bartkowiak) Date: Sun Jan 21 12:11:06 2007 Subject: [music-dsp] Re: Implementing kurtosismaximization fordereverberation References: <022601c4f7b1$c6c77910$f81dfe96@cpo.multimedia.edu.pl> <41E3C557.1000508@qub.ac.uk> Message-ID: <007001c4f94b$2e6ff890$f81dfe96@cpo.multimedia.edu.pl> From: "David Fee" To: "a list for musical digital signal processing" Sent: Tuesday, January 11, 2005 1:23 PM Subject: Re: [music-dsp] Re: Implementing kurtosismaximization fordereverberation > I've noticed the large amount of aliasing is a big problem with MLT. > I'm wondering if this is, therefore, not suitable for the implementation > of the apative filter as suggested in the Gillespie paper > (http://research.microsoft.com/~malvar/papers/icassp01makurt.pdf) and > perhaps I should be using the complex version instead (MCLT) I guess so. See the original Malvar paper on MCLT: http://citeseer.ist.psu.edu/malvar99modulated.html MB From mbartkow at et.put.poznan.pl Thu Jan 13 03:45:49 2005 From: mbartkow at et.put.poznan.pl (Maciej Bartkowiak) Date: Sun Jan 21 12:11:06 2007 Subject: [music-dsp] Re: Implementing kurtosis maximization fordereverberation References: Message-ID: <007e01c4f94c$4863d770$f81dfe96@cpo.multimedia.edu.pl> From: "Juhana Sadeharju" > In Portnoff's phase vocoder the FFT window must move almost from > sample to sample for smoothness. How lapped transform window should > move? Some of the overlapping seems to be built-in to the lapped > transform. And due the built-in overlapping the same length transforms > cannot be compared directly. Is it so? I am not sure, what are the exact constraints. For TDAC MLT it is ubiquitous to use a 50% overlap (that is how MPEG L3 works), but I have seen different approaches. > IEEE would do a cultural act if it would make one of its survey > journal or magazine as "open access". Proceedings of IEEE, perhaps. > However, Proc. of IEEE has (or had) non-survey papers as well. Such > open access journal/magazine should have only surveys. IEEE offers a DVD-ROM with all publications of the SP Society up to 2001. They have put a tremendous work to scan, archive and index all the papers. I wholeheartly recommend it. And there is a lot of papers available at http://citeseer.ist.psu.edu/ with an excellent search engine. MB From kaleja at estarcion.com Wed Jan 12 23:17:11 2005 From: kaleja at estarcion.com (Russell Borogove) Date: Sun Jan 21 12:11:06 2007 Subject: [music-dsp] Upsampling my Mod-Wheel References: <20050106001813.79847189F618@music.calarts.edu> <41E5CFA1.90906@ihug.co.nz> Message-ID: <002a01c4f989$5ae09540$0601000a@jaseroque> > My textbook says I should pad out the samples with zeros, then filter > at half the original sample rate. The mod-wheel samples arrive at 126 > Hz, and I set the filter cuttoff to 50 Hz (just under half). > I did so (using the biquad low-pass from the Music DSP archives) but > the result is terrible, as an experiment I tried just duplicating the > samples instead before filtering, it looks much better .... > > http://www.synthedit.com/smoothing.gif > > What am I doing wrong? A single biquad lowpass filter cuts off at 12dB/octave, so components above 50Hz are still present, just attenuated. Sample-duplication followed by lowpass is better for this application. From kouhia at nic.funet.fi Thu Jan 13 11:32:30 2005 From: kouhia at nic.funet.fi (Juhana Sadeharju) Date: Sun Jan 21 12:11:06 2007 Subject: [music-dsp] Antti's Moog filter available Message-ID: Hello. Antti's Moog filter is available as Csound opcode here: http://www.kunstmusik.com/udo/ I hope it is tuned as good as Antti's own implementation. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software From earlevel at earlevel.com Thu Jan 13 12:11:37 2005 From: earlevel at earlevel.com (Nigel Redmon) Date: Sun Jan 21 12:11:06 2007 Subject: [music-dsp] Upsampling my Mod-Wheel In-Reply-To: <41E5CFA1.90906@ihug.co.nz> References: <20050106001813.79847189F618@music.calarts.edu> <41E5CFA1.90906@ihug.co.nz> Message-ID: <2F08E01F-6586-11D9-8D26-000A959AF1E4@earlevel.com> You don't have steep enough filter to upsample that way. But it doesn't matter--you just want to hold the last value for the filter (same as sample duplication). That is, just just write your control value to a variable (single sample delay) when it changes--it doesn't even have to be at a set rate--and use that as the input to your filter. Adjust the frequency cutoff of the filter to give you the smoothing you need. On Jan 12, 2005, at 5:32 PM, Jeff McClintock wrote: > Hi All, > > I've written a soft synth. One thing it does is apply MIDI > controllers to audio. I have to smooth these controllers, i.e. > upsample them to audio rate. Untill now I've been doing so with a > crude ramping technique, but now I want to upsample 'properly'. > My textbook says I should pad out the samples with zeros, then > filter at half the original sample rate. The mod-wheel samples arrive > at 126 Hz, and I set the filter cuttoff to 50 Hz (just under half). > I did so (using the biquad low-pass from the Music DSP archives) but > the result is terrible, as an experiment I tried just duplicating the > samples instead before filtering, it looks much better .... > > http://www.synthedit.com/smoothing.gif > > What am I doing wrong?, how is a filter meant to smooth those jagged > impulses? have a made a simple coding error, or is sample-duplication > better?, I'm sure I read somewhere sample-duplication was theoreticaly > wrong, have I mis-understood the proceedure?. > > Any enlightenment much appreciated. > > Cheers, > Jeff From bulent_biyikoglu at yahoo.com Thu Jan 13 12:36:58 2005 From: bulent_biyikoglu at yahoo.com (Bulent Biyikoglu) Date: Sun Jan 21 12:11:06 2007 Subject: [music-dsp] aligning loop start addresses in asm code (VC++/wintel) Message-ID: <20050113173658.18863.qmail@web54507.mail.yahoo.com> Hi all, I read in a couple of places that when writing inline assembly code, aliging the loop start addresses to processor cache size (32/64 bytes) makes the code faster. Has any body tried that and gained performance improvements? I tried the ALIGN directive with VC++, however VC++ doesn't allow values greater than 16 for this directive. I know that P3 cache line size is 32 bytes, and for P4 that is 64 bytes I guess, so to get the best performance I guess it would be great to be able to align the loop start address at 32/64 bytes boundaries, has anybody achieved to do this? Thanks, Bulent __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com From A.S.Basi at warwick.ac.uk Thu Jan 13 13:08:30 2005 From: A.S.Basi at warwick.ac.uk (Amarpreet Basi) Date: Sun Jan 21 12:11:06 2007 Subject: [music-dsp] Root Mean Square Normalisation Message-ID: This was my understanding on how to do it. (But of course didn't work, hence my post)... Segment the signal sample into blocks, so that we have N blocks per second (in my configuration I have N=100). Then for every block, compute the root mean square of the samples in that block (so each block will be a measure of instantaneous RMS power). Next step: for every K blocks, compute the average. Finally of all the averages computed, pick the maximum. This value should be a near enough estimate of the sustained RMS power for the entire signal. Now all that remains to be done is to apply the gain to the signal (I think). This part, which should be trivial, is giving me some bother. My implementation of the above algorithm seems to be correct; when I compare the RMS values recorded by SoundForge with my own app, they are about 1-5% different. Do I take the ratio of the highest peak in the signal to the sustained RMS power and apply this to the entire signal? For whatever reason, the resulting signal is never nothing like what happens in SoundForge when you apply RMS Normalisation with the saturate-on-clipping option. In SoundForge, the signal is just very loud whilst in mine it distorts and produces a horrible noise in the speakers. Anything obvious that I am doing wrong? Also, what is the difference between hard-limiting, soft-limiting and saturation? From lists at wildgooses.com Thu Jan 13 18:59:23 2005 From: lists at wildgooses.com (Ed Wildgoose) Date: Sun Jan 21 12:11:06 2007 Subject: [music-dsp] Anyone know how to implement NTM crossovers? In-Reply-To: <000901c4edc3$2385e680$65b9a8c0@BrueggemannNB> References: <41D2CC8B.90003@wildgooses.com> <000901c4edc3$2385e680$65b9a8c0@BrueggemannNB> Message-ID: <41E70B5B.9080009@wildgooses.com> > up to now I had problems to send a message, maybe this time it works. > > Appended quick and dirty code of NT filters. So the question is: where did you get this code from...? From lanceboyle at cwazy.co.uk Thu Jan 13 20:42:53 2005 From: lanceboyle at cwazy.co.uk (Lance Boyle) Date: Sun Jan 21 12:11:06 2007 Subject: [music-dsp] Availibility of Head Trackers In-Reply-To: References: Message-ID: <9BABEEE2-65CD-11D9-AFBD-003065F93FF0@cwazy.co.uk> Does anyone know of what is available in head-tracking hardware and what is involved with interfacing to software, e.g. via USB, RS-232, or MIDI? I've found the Polhemus products but am wondering what might be available for gamers or in 3D mice that I don't know about. I need only head azimuth angle, but any other data that is provided by a device is easily ignored. My first preference is to do this on Mac OS X, but I won't shoot myself in the foot over it. Any thoughts? Jerry From lanceboyle at cwazy.co.uk Thu Jan 13 20:56:31 2005 From: lanceboyle at cwazy.co.uk (Lance Boyle) Date: Sun Jan 21 12:11:06 2007 Subject: [music-dsp] Announce: FScape 0.65 In-Reply-To: References: Message-ID: <82CE3458-65CF-11D9-AFBD-003065F93FF0@cwazy.co.uk> Wow--this looks way cool. I haven't actually used it yet but it looks like it has lots of capability. Jerry On Jan 11, 2005, at 1:00 PM, contact@sciss.de wrote: > ahoi everyone, > > my audio rendering software fscape has migrated to sourceforge and has > become an open source project. download the current version 0.65 at > > http://sourceforge.net/projects/fscape/ > > changes to version 0.61 : removed all platform specific code, this > version > finally runs on mac os x, win xp and linux (the latter not tested) and > supports WAVE sound file format. now with easy to use installer, a few > more online help files and a few more modules, many bugfixes and minor > improvements. > > enjoy! > > best, -sciss- From arcane at arcanemethods.com Thu Jan 13 21:09:06 2005 From: arcane at arcanemethods.com (Bob Cain) Date: Sun Jan 21 12:11:06 2007 Subject: [music-dsp] Announce: FScape 0.65 In-Reply-To: <82CE3458-65CF-11D9-AFBD-003065F93FF0@cwazy.co.uk> References: <82CE3458-65CF-11D9-AFBD-003065F93FF0@cwazy.co.uk> Message-ID: <41E729C2.9020105@arcanemethods.com> Lance Boyle wrote: > Wow--this looks way cool. I haven't actually used it yet but it looks > like it has lots of capability. Is there a way to find out anything about it without downloading and installing it. Bob -- "Things should be described as simply as possible, but no simpler." A. Einstein From tkreger at bigpond.net.au Thu Jan 13 22:13:49 2005 From: tkreger at bigpond.net.au (Tim Kreger) Date: Sun Jan 21 12:11:06 2007 Subject: [music-dsp] Availibility of Head Trackers In-Reply-To: <9BABEEE2-65CD-11D9-AFBD-003065F93FF0@cwazy.co.uk> References: <9BABEEE2-65CD-11D9-AFBD-003065F93FF0@cwazy.co.uk> Message-ID: <6.2.0.14.0.20050114140742.01e88a30@mail-hub.bigpond.net.au> Intersense makes a USB head tracker (InterTrax2) with Yaw/Pitch/Roll. Its not that cheap (1000 US) but is pretty easy to set up and use with games etc. Works on the three major platforms (OSx, Linux, Windows). Its probably cheaper the Polhemus but couldn't say for sure. www.isense.com Hope this helps Tim At 12:42 PM 14/01/2005, you wrote: >Does anyone know of what is available in head-tracking hardware and what >is involved with interfacing to software, e.g. via USB, RS-232, or MIDI? >I've found the Polhemus products but am wondering what might be available >for gamers or in 3D mice that I don't know about. I need only head azimuth >angle, but any other data that is provided by a device is easily ignored. >My first preference is to do this on Mac OS X, but I won't shoot myself in >the foot over it. > >Any thoughts? > >Jerry > >-- >dupswapdrop -- the music-dsp mailing list and website: subscription info, >FAQ, source code archive, list archive, book reviews, dsp links >http://shoko.calarts.edu/musicdsp >http://ceait.calarts.edu/mailman/listinfo/music-dsp From d.piccoli at murdoch.edu.au Fri Jan 14 01:33:36 2005 From: d.piccoli at murdoch.edu.au (Daniel Piccoli) Date: Sun Jan 21 12:11:06 2007 Subject: [music-dsp] Pitch shifting a piano note In-Reply-To: <20041229223204.0B6DE186D390@music.calarts.edu> References: <20041229223204.0B6DE186D390@music.calarts.edu> Message-ID: <1105684416.10020.10.camel@powerride> Hi all, I'm relatively new to DSP and have the following question. In order to create a soundfont of a piano, what are the limitations in recording one piano note (say middle C), and then pitch shifting to other frequencies as required. I understand that when using time domain methods (sample rate changes) the length of the note will change. If a short time fourier transform (STFT) is used, couldn't the spectral peaks (fundamental and harmonics) be shifted to their appropriate positions for each note and the inverse transform can be calculated to get the original sound. An inverse STFT can then be performed to get the shifted sound. I also acknowledge a piano has slightly different harmonic proportions depending on what pitch the note is being played. Is this due to the body of the piano, favouring resonance with particular frequencies? If so, can a FIR filter be implemented to allow for the frequency response of the piano itself (If this is known). I know there are a few questions here. Thanks in advance for any answers. From warder at dlc.fi Fri Jan 14 01:56:12 2005 From: warder at dlc.fi (Vesa Norilo) Date: Sun Jan 21 12:11:06 2007 Subject: [music-dsp] Pitch shifting a piano note In-Reply-To: <1105684416.10020.10.camel@powerride> References: <20041229223204.0B6DE186D390@music.calarts.edu> <1105684416.10020.10.camel@powerride> Message-ID: <41E76D0C.406@dlc.fi> >I understand that when using time domain methods (sample rate changes) >the length of the note will change. If a short time fourier transform >(STFT) is used, couldn't the spectral peaks (fundamental and harmonics) >be shifted to their appropriate positions for each note and the inverse >transform can be calculated to get the original sound. An inverse STFT >can then be performed to get the shifted sound. > > Not so trivially. The harmonics in the signal are not bound to align with your FFT frequency bins. Phase vocoder analysis / resynthesis is a refined technique for this. http://www.dspdimension.com/html/pshiftstft.html >I also acknowledge a piano has slightly different harmonic proportions >depending on what pitch the note is being played. Is this due to the >body of the piano, favouring resonance with particular frequencies? If >so, can a FIR filter be implemented to allow for the frequency response >of the piano itself (If this is known). > > In short, yes. You would probably be looking at the impulse response of the piano as a system, sans the string you are playing (but with all the other strings). If you just want to retain formants (frequency response) of the piano as you shift samples, read up on formants in pitch shifting. If you will want to model piano as a system, you might want to forget samples altogether. If you are willing to go for it, you could look at the known techniques of extracting piano body response from an acoustical recording. I am not sure whether you would get a satisfying impulse response by hitting the piano body with an impulse hammer, you would probably need several responses from across the sound board to be convincing. Coupling this with piano samples would seem bad design to me, in that case you might want to build a bank of waveguide string models. And forget real time playback :) Vesa From erikd-music-dsp at mega-nerd.com Fri Jan 14 02:11:47 2005 From: erikd-music-dsp at mega-nerd.com (Erik de Castro Lopo) Date: Sun Jan 21 12:11:06 2007 Subject: [music-dsp] Pitch shifting a piano note In-Reply-To: <1105684416.10020.10.camel@powerride> References: <20041229223204.0B6DE186D390@music.calarts.edu> <1105684416.10020.10.camel@powerride> Message-ID: <20050114181147.423889bb.erikd-music-dsp@mega-nerd.com> On Fri, 14 Jan 2005 14:33:36 +0800 Daniel Piccoli wrote: > I understand that when using time domain methods (sample rate changes) > the length of the note will change. Yes. This method works reasonably well for a pitch shift of about +/- half an octave. > If a short time fourier transform > (STFT) is used, couldn't the spectral peaks (fundamental and harmonics) > be shifted to their appropriate positions for each note and the inverse > transform can be calculated to get the original sound. An inverse STFT > can then be performed to get the shifted sound. Its about 1000000 times harder than you might think. Even a single piano node is amazingly complex. Even the best highly secret algorithms would do a relatively poor job on a piano note unless the pitch shift was small (say 1/2 and octave). > I also acknowledge a piano has slightly different harmonic proportions > depending on what pitch the note is being played. Is this due to the > body of the piano, favouring resonance with particular frequencies? If > so, can a FIR filter be implemented to allow for the frequency response > of the piano itself (If this is known). If you are only varying playback speed to do the pitch shifting and not pitch shifting too far, this won't be necessary. If you arr pitch shifting too far, a filter will be insufficient to correct the sound. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo nospam@mega-nerd.com (Yes it's valid) +-----------------------------------------------------------+ "C++ is a language strongly optimized for liars and people who go by guesswork and ignorance." -- Erik Naggum From uli.brueggemann at freenet.de Fri Jan 14 02:41:04 2005 From: uli.brueggemann at freenet.de (Ulrich Brueggemann) Date: Sun Jan 21 12:11:06 2007 Subject: [music-dsp] Root Mean Square Normalisation References: Message-ID: <002c01c4fa0c$67918c80$32b9a8c0@BrueggemannNB> I don't know if I fully understand your problem. But you do the RMS in blocks. IMO you should calculate the RMS with a moving windows of size N over all sampled data. See dspguide chapter 2 from www.dspguide.com Uli ----- Original Message ----- From: "Amarpreet Basi" To: Sent: Thursday, January 13, 2005 6:08 PM Subject: [music-dsp] Root Mean Square Normalisation This was my understanding on how to do it. (But of course didn't work, hence my post)... Segment the signal sample into blocks, so that we have N blocks per second (in my configuration I have N=100). Then for every block, compute the root mean square of the samples in that block (so each block will be a measure of instantaneous RMS power). Next step: for every K blocks, compute the average. Finally of all the averages computed, pick the maximum. This value should be a near enough estimate of the sustained RMS power for the entire signal. Now all that remains to be done is to apply the gain to the signal (I think). This part, which should be trivial, is giving me some bother. My implementation of the above algorithm seems to be correct; when I compare the RMS values recorded by SoundForge with my own app, they are about 1-5% different. Do I take the ratio of the highest peak in the signal to the sustained RMS power and apply this to the entire signal? For whatever reason, the resulting signal is never nothing like what happens in SoundForge when you apply RMS Normalisation with the saturate-on-clipping option. In SoundForge, the signal is just very loud whilst in mine it distorts and produces a horrible noise in the speakers. Anything obvious that I am doing wrong? Also, what is the difference between hard-limiting, soft-limiting and saturation? -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://shoko.calarts.edu/musicdsp http://ceait.calarts.edu/mailman/listinfo/music-dsp From kouhia at nic.funet.fi Fri Jan 14 11:59:24 2005 From: kouhia at nic.funet.fi (Juhana Sadeharju) Date: Sun Jan 21 12:11:07 2007 Subject: [music-dsp] Re: Implementing kurtosis maximization for dereverberation Message-ID: >From: "Maciej Bartkowiak" > >> IEEE would do a cultural act if it would make one of its survey >> journal or magazine as "open access". Proceedings of IEEE, perhaps. >> However, Proc. of IEEE has (or had) non-survey papers as well. Such >> open access journal/magazine should have only surveys. > >IEEE offers a DVD-ROM with all publications of the SP Society up to 2001. >They have put a tremendous work to scan, archive and index all the papers. >I wholeheartly recommend it. Sure they do have, but it costs. IEEE papers have been available for purchase all of the time. Of course, as long as people (and IEEE owners) don't make any difference between $$$$ and "open access", the advantages of "open access" cannot be seen. Very sad. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software From kouhia at nic.funet.fi Fri Jan 14 12:20:07 2005 From: kouhia at nic.funet.fi (Juhana Sadeharju) Date: Sun Jan 21 12:11:07 2007 Subject: [music-dsp] Re: Announce: FScape 0.65 Message-ID: >From: contact@sciss.de > >my audio rendering software fscape has migrated to sourceforge and has >become an open source project. download the current version 0.65 at >http://sourceforge.net/projects/fscape/ Where are the source codes? The jar file has plenty of class files which looks like binary. What are those pack files? If sources are there how to extract the files? (E.g., I don't want run executable-only izpack included in the jar archive for unpacking the source codes, for security reasons.) If anyone has already extracted the source code files, please upload to ftp://ftp.funet.fi/incoming/audio/ as zip or jar archive. I really wonder why not make all this more simpler. Packs inside jar seems to be overly complicated. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software From mbartkow at et.put.poznan.pl Fri Jan 14 12:41:34 2005 From: mbartkow at et.put.poznan.pl (Maciej Bartkowiak) Date: Sun Jan 21 12:11:07 2007 Subject: [music-dsp] Re: Implementing kurtosis maximization fordereverberation References: Message-ID: <026e01c4fa60$4ac5d4e0$f81dfe96@cpo.multimedia.edu.pl> > Sure they do have, but it costs. IEEE papers have been available > for purchase all of the time. > > Of course, as long as people (and IEEE owners) don't make > any difference between $$$$ and "open access", the advantages > of "open access" cannot be seen. Very sad. It took a year of hard work to collect, scan and index all the publications. Why those people should not be paid? afaik, IEEE is not strictly a non-profit organization. Among other activities they offer financial support for students and scientific activities like conference sponsorship. If they offered a free access to their proceedings, nobody would pay for the printed versions. How would they collect the money to cover the editorial expenses, printing etc? Do you really work for free? I agree, it's wonderful when some institutions offer a public access of their output, however I don't think it's allright to blame those who don't MB From allan at wholecheese.com Fri Jan 14 15:06:50 2005 From: allan at wholecheese.com (Allan Hoeltje) Date: Sun Jan 21 12:11:07 2007 Subject: [music-dsp] Re: Announce: FScape 0.65 In-Reply-To: Message-ID: If you run the Install-FScape-0.65.jar file the installation will prompt you to install the developer source code in addition to the application binary. -Allan "Juhana Sadeharju" wrote on 1/14/05 9:20 AM: >> From: contact@sciss.de >> >> my audio rendering software fscape has migrated to sourceforge and has >> become an open source project. download the current version 0.65 at >> http://sourceforge.net/projects/fscape/ > > Where are the source codes? > The jar file has plenty of class files which looks like binary. > > What are those pack files? If sources are there how to extract > the files? (E.g., I don't want run executable-only izpack > included in the jar archive for unpacking the source codes, > for security reasons.) > > If anyone has already extracted the source code files, please > upload to > ftp://ftp.funet.fi/incoming/audio/ > as zip or jar archive. > > I really wonder why not make all this more simpler. Packs inside > jar seems to be overly complicated. > > Juhana From citizenchunk at gmail.com Fri Jan 14 18:16:17 2005 From: citizenchunk at gmail.com (Citizen Chunk) Date: Sun Jan 21 12:11:07 2007 Subject: [music-dsp] Root Mean Square Normalisation In-Reply-To: <002c01c4fa0c$67918c80$32b9a8c0@BrueggemannNB> References: <002c01c4fa0c$67918c80$32b9a8c0@BrueggemannNB> Message-ID: the reason that you are getting distortion is because you are clipping the output level. as you may know, the RMS is the AVERAGE POWER, and usually lies about 10-20dB below the peak value in musical signals. therefore, if you are normallizing RMS values, you are overshooting 0dB by about 10-20dB. (clipping produces nasty harmonic distortion--that's a recipe for horrible sound.) now, if you were to follow the normallizer with a peak limiter or saturator, it would help to prevent (or lessen) the distortion. a saturator is basically a waveshaper (an input-to-output transform) that gracefully eases the output signal up to a certain threshold, so as not to just clip it. a limiter (hard or soft refers to the linearity of the "knee") does this dynamically, applying gradual gain changes to level that exceed the threshold. also... you haven't mentioned anything about your RMS window size. this will affect everything. == chunk On Fri, 14 Jan 2005 07:41:04 -0000, Ulrich Brueggemann wrote: > I don't know if I fully understand your problem. > But you do the RMS in blocks. > IMO you should calculate the RMS with a moving windows of size N over all > sampled data. > See dspguide chapter 2 from www.dspguide.com > > Uli > ----- Original Message ----- > From: "Amarpreet Basi" > To: > Sent: Thursday, January 13, 2005 6:08 PM > Subject: [music-dsp] Root Mean Square Normalisation > > This was my understanding on how to do it. (But of course didn't work, hence > my post)... > > Segment the signal sample into blocks, so that we have N blocks per second > (in my configuration I have N=100). > > Then for every block, compute the root mean square of the samples in that > block (so each block will be a measure of instantaneous RMS power). > > Next step: for every K blocks, compute the average. > > Finally of all the averages computed, pick the maximum. This value should be > a near enough estimate of the sustained RMS power for the entire signal. > > Now all that remains to be done is to apply the gain to the signal (I > think). This part, which should be trivial, is giving me some bother. My > implementation of the above algorithm seems to be correct; when I compare > the RMS values recorded by SoundForge with my own app, they are about 1-5% > different. > > Do I take the ratio of the highest peak in the signal to the sustained RMS > power and apply this to the entire signal? For whatever reason, the > resulting signal is never nothing like what happens in SoundForge when you > apply RMS Normalisation with the saturate-on-clipping option. In SoundForge, > the signal is just very loud whilst in mine it distorts and produces a > horrible noise in the speakers. Anything obvious that I am doing wrong? > > Also, what is the difference between hard-limiting, soft-limiting and > saturation? > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp > links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > From glenn at greenoak.com Fri Jan 14 20:41:34 2005 From: glenn at greenoak.com (Glenn Olander) Date: Sun Jan 21 12:11:07 2007 Subject: [music-dsp] [OT] Spectrasonics - Help Wanted In-Reply-To: <20050114231641.9B77C18F203E@music.calarts.edu> Message-ID: <96F375E6-6696-11D9-B291-000A95B93E1A@greenoak.com> This is an invitation to any music-dsp'ers who will be at NAMM. At Spectrasonics, we're looking for developers to help with writing virtual instrument plugins. So if you're from the southern california area and have plugin writing experience, stop by the Spectrasonics booth and ask for me. Or, just drop me an email if you're interested. Actually, even if you're not interested, be sure to stop by the booth to say hi :-). Thanks. Glenn Olander glenn@greenoak.com Spectrasonics http://www.spectrasonics.net From lanceboyle at cwazy.co.uk Fri Jan 14 23:36:49 2005 From: lanceboyle at cwazy.co.uk (Lance Boyle) Date: Sun Jan 21 12:11:07 2007 Subject: [music-dsp] Announce: FScape 0.65 In-Reply-To: <41E729C2.9020105@arcanemethods.com> References: <82CE3458-65CF-11D9-AFBD-003065F93FF0@cwazy.co.uk> <41E729C2.9020105@arcanemethods.com> Message-ID: <124C0AB8-66AF-11D9-AFBD-003065F93FF0@cwazy.co.uk> On Jan 13, 2005, at 7:09 PM, Bob Cain wrote: > > Lance Boyle wrote: >> Wow--this looks way cool. I haven't actually used it yet but it looks >> like it has lots of capability. > > Is there a way to find out anything about it without downloading and > installing it. > > > Bob > -- The documentation is slim to none (the author doesn't pretend otherwise). FWIW, there is an unistaller included. I think he says it's Java. Jerry From douglas at roar.music.columbia.edu Sat Jan 15 00:00:01 2005 From: douglas at roar.music.columbia.edu (douglas repetto) Date: Sun Jan 21 12:11:07 2007 Subject: [music-dsp] [admin] music-dsp FAQ Message-ID: <200501150500.j0F501VJ020839@roar.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://shoko.calarts.edu/musicdsp/musicdspFAQ.html also of interest to new and not-so-new list members: the music-dsp list archives http://shoko.calarts.edu/musicdsp/musicdsparchives.html the music-dsp source code archive http://www.musicdsp.org music-dsp books and reviews http://shoko.calarts.edu/musicdsp/dspbooks.html all this and more at: http://shoko.calarts.edu/musicdsp hotdawg! douglas (this is an automated message sent out on the 1st and 15th of each month) From d.piccoli at murdoch.edu.au Sat Jan 15 02:12:23 2005 From: d.piccoli at murdoch.edu.au (Daniel Piccoli) Date: Sun Jan 21 12:11:07 2007 Subject: [music-dsp] Re: Pitch shifting of a piano note In-Reply-To: <20050114231642.5E3E718F2040@music.calarts.edu> References: <20050114231642.5E3E718F2040@music.calarts.edu> Message-ID: <1105773142.9951.24.camel@powerride> Thanks for the replies. >Not so trivially. The harmonics in the signal are not bound to align >with your FFT frequency bins. What if I used something like a bounded Q transforms to align the notes of the western scale to the frequency bins? >If you will want to model piano as a system, you might want to >forget samples altogether. Good suggestion, but my particular application revolves around samples. One of the goals is for the computer to recognise a monophonic sound as coming from a piano (instrument classification) given only one example of a piano note, and the impulse response of the piano as a system. Does this seem feasible? >Its about 1000000 times harder than you might think. Even a single >piano >node is amazingly complex. Even the best highly secret algorithms >would >do a relatively poor job on a piano note unless the pitch shift was >small (say 1/2 and octave). Does this mean that a piano cant be modelled on one sample note and the impulse response of the piano body? Even if the piano body had a perfectly flat frequency response from 20-20000Hz, would each note still sound substantially different. If so, what are the important elements for a human recognising a stream of piano notes? Bregman notes these harmonic peaks as one factor. On the use of an STFT and filtering for pitch shifting: >If you are only varying playback speed to do the pitch shifting and >not pitch shifting too far, this won't be necessary. If you arr >pitch shifting too far, a filter will be insufficient to correct >the sound. My idea was to move away from adjusting playback speed/sample rate, and just to shift the peaks in the STFT to the required note. Even if the western scale isn't perfectly aligned with the frequency bins, you could use an algorithm to find the peaks and use something like cubic maximisation it approximate the frequency. I've read that resynthesizing spectral peaks has a high perceptual fidelity with the original sound although it doesn't have a good mean squared error. Does it seem possible to maintain a high perceptual fidelity after pitch shifting using the STFT? Thanks for your responses, Dan From warder at dlc.fi Sat Jan 15 02:34:15 2005 From: warder at dlc.fi (Vesa Norilo) Date: Sun Jan 21 12:11:07 2007 Subject: [music-dsp] Re: Pitch shifting of a piano note In-Reply-To: <1105773142.9951.24.camel@powerride> References: <20050114231642.5E3E718F2040@music.calarts.edu> <1105773142.9951.24.camel@powerride> Message-ID: <41E8C777.9060701@dlc.fi> >What if I used something like a bounded Q transforms to align the notes >of the western scale to the frequency bins? > > The harmonics would still not necessarily fall on your bins. >Good suggestion, but my particular application revolves around samples. >One of the goals is for the computer to recognise a monophonic sound as >coming from a piano (instrument classification) given only one example >of a piano note, and the impulse response of the piano as a system. Does >this seem feasible? > > I see. I had thought you wanted to synthesize piano, but this is essentially analysis, right? I don't think it is possible to recognize bass notes based on middle notes or high notes or vice versa. There is probably just too much difference in most parameters. From a number of profiles I guess it might be possible. You would probably need to analyze both spectral distribution and envelope. Both are quite tricky because piano tuning affects the decay shape considerably. In addition, there's severe inharmonicity in the low register and stretched harmonic series all over the place. >Does this mean that a piano cant be modelled on one sample note and the >impulse response of the piano body? Even if the piano body had a >perfectly flat frequency response from 20-20000Hz, would each note still >sound substantially different. If so, what are the important elements >for a human recognising a stream of piano notes? Bregman notes these >harmonic peaks as one factor. > > If you look at the piano mechanism, there is typically three different sets of strings. The bass strings that are usually 'braided' (to increase mass without increasing tension which leads to horrible inharmonicity with thick tense strings) the middle strings and the high strings without dampers. In addition, in my yamaha the number of strings per voice goes from 1 to 2 to 3, quite independant of the string type. So there are six types of strings in the machine... plus, the size of the hammer remains relatively constant while strings get smaller, leading to the proportion being different all over the range. >My idea was to move away from adjusting playback speed/sample rate, and >just to shift the peaks in the STFT to the required note. Even if the >western scale isn't perfectly aligned with the frequency bins, you could >use an algorithm to find the peaks and use something like cubic >maximisation it approximate the frequency. I've read that resynthesizing >spectral peaks has a high perceptual fidelity with the original sound >although it doesn't have a good mean squared error. Does it seem >possible to maintain a high perceptual fidelity after pitch shifting >using the STFT? > > The phase vocoder technique I mentioned earlier can sound very good if formant corrected but there is always some frequency clustering (single source frequency looks like a cluster of frequencies in the synthesized version) which leads to some beating. So are you in fact aiming for perceptual fidelity or good measurement algorithm (computer recognizing that a note was played by a piano sounds to me like the focus is not on human perception). Vesa From jchandjr at bellsouth.net Sat Jan 15 12:43:25 2005 From: jchandjr at bellsouth.net (James Chandler Jr) Date: Sun Jan 21 12:11:07 2007 Subject: [music-dsp] Re: Pitch shifting of a piano note References: <20050114231642.5E3E718F2040@music.calarts.edu> <1105773142.9951.24.camel@powerride> Message-ID: <00e401c4fb29$b76818a0$6401a8c0@JamesCompaq3080> Perhaps a few template piano notes from different keyboard zones could be used for autocorrelation comparison or harmonics comparison. Am not smart enough to know. However, the inharmonicity (even in the mid and hi notes) makes piano an almost insurmountable challenge to convincingly emulate with Additive synthesis, unless the Additive engine is fancy enough to offer elaborate pitch envelopes for each harmonic. One of the most telling ear cues of piano, IMO, is the hammer noise thunk. Convincing hammer noise thunk seems difficult to impossible with vanilla Additive synthesis. Additively synthesizing the very top notes of a piano should be very simple, because there are only a few harmonics in the audible range. But years ago when I tried additively synthesizing it, there was no combination of those few harmonics that didn't sound like a hi beep rather than a piano note. If a computer instrument ID algorithm is looking for piano hammer thunks, how difficult would it be for the algorithm to tell the difference between a piano hammer vs a mid-range percussion instrument (fer example bongo)? I'm not wise enough to be a nay-sayer, but the ear can ID as 'piano' a Bosendorfer 9' grand, a cheap spinet, or even a cheezy Ensoniq Mirage 8 bit factory piano sample. Even if the piano is mixed with a full band of instruments and played back on a noisy third-generation cassette tape dub (or low-bit-rate MP3). There is so much variability in the spectra of all these things the ear can immediately ID as 'piano', it seems that a computer ID algorithm would need to be very intelligent? (DUH) JCJR From paranoiaspoisondoor at gmail.com Sat Jan 15 13:29:58 2005 From: paranoiaspoisondoor at gmail.com (Keith Handy) Date: Sun Jan 21 12:11:07 2007 Subject: [music-dsp] Re: Pitch shifting of a piano note In-Reply-To: <00e401c4fb29$b76818a0$6401a8c0@JamesCompaq3080> References: <20050114231642.5E3E718F2040@music.calarts.edu> <1105773142.9951.24.camel@powerride> <00e401c4fb29$b76818a0$6401a8c0@JamesCompaq3080> Message-ID: <79a2ad41050115102964edca1e@mail.gmail.com> Something else that makes it complicated is that the notes on a piano all affect one another; the fact that a note is playing means its string is undampened, which means it will sympathetically resonate with any other notes that are playing. And of course if the sustain pedal is down, *all* the strings will sympathetically resonate. -Keith From rbj at audioimagination.com Sat Jan 15 13:49:16 2005 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sun Jan 21 12:11:07 2007 Subject: [music-dsp] Re: Pitch shifting of a piano note In-Reply-To: <79a2ad41050115102964edca1e@mail.gmail.com> Message-ID: on 01/15/2005 13:29, Keith Handy at paranoiaspoisondoor@gmail.com wrote: > Something else that makes it complicated is that the notes on a piano > all affect one another; the fact that a note is playing means its > string is undampened, which means it will sympathetically resonate > with any other notes that are playing. And of course if the sustain > pedal is down, *all* the strings will sympathetically resonate. personally, folks, i've always thought that pitch shifting a single piano note was pretty easy with time-domain techniques. whether you do autocorrelation or AMDF, first detect where good places to splice and then do shifting and splicing to time-scale the note, then do resampling to change the pitch (with the added effect of bringing the length back to the original length). of course pitch shifting it very far (a few semitones) will make for a pretty funky sounding piano note, but that is a different story. also, if you want to do additive synthesis analysis, check out the Wavetable Synthesis 101 paper at harmony-central.com. as long as you can do decent pitch detection (or period detection), that analysis will get you harmonic amplitudes and phases spot on. a change in the phase (w.r.t. time) indicates that the frequency of the overtone is deviating from its harmonic value. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From joshscholar at yahoo.com Sat Jan 15 18:26:10 2005 From: joshscholar at yahoo.com (Joshua Scholar) Date: Sun Jan 21 12:11:07 2007 Subject: [music-dsp] Re: Pitch shifting of a piano note References: Message-ID: <009201c4fb59$9a5158a0$0de22641@antssoftware.com> After all the old method of hand looping samples is just a manual version of a time domain technique. > personally, folks, i've always thought that pitch shifting a single piano > note was pretty easy with time-domain techniques. whether you do > autocorrelation or AMDF, first detect where good places to splice and then > do shifting and splicing to time-scale the note, then do resampling to > change the pitch (with the added effect of bringing the length back to the > original length). of course pitch shifting it very far (a few semitones) > will make for a pretty funky sounding piano note, but that is a different > story. > > also, if you want to do additive synthesis analysis, check out the Wavetable > Synthesis 101 paper at harmony-central.com. as long as you can do decent > pitch detection (or period detection), that analysis will get you harmonic > amplitudes and phases spot on. a change in the phase (w.r.t. time) > indicates that the frequency of the overtone is deviating from its harmonic > value. > > -- > > r b-j rbj@audioimagination.com \ From richarddobson at blueyonder.co.uk Sat Jan 15 19:31:59 2005 From: richarddobson at blueyonder.co.uk (Richard Dobson) Date: Sun Jan 21 12:11:07 2007 Subject: [music-dsp] Re: Pitch shifting of a piano note In-Reply-To: <009201c4fb59$9a5158a0$0de22641@antssoftware.com> References: <009201c4fb59$9a5158a0$0de22641@antssoftware.com> Message-ID: <41E9B5FF.8010807@blueyonder.co.uk> CLassic peak-tracking tools such as SNDAN can prove very effective for single pitched tones (what they were designed for, after all). These will track/extract the time-varying frequency of each partial, and it is then possible to perform very high-quality time-scaling and/or pitch shifting using oscillator-bank additive resynthesis. More modern systems employ a stochastic+sinusoidal model for even greater fidelity, and tools such as Loris define "bandwidth-enhanced partials" too. SNDAN and its kin offer a facility to timescale only the ptiched part of the sound, leaving the initial attack transient unscaled. A special problem with the acoustic piano is the present of impact noise (key mecahnism) as well as the sound of the string; on the high notes this noise can be louder than that of the string tone, with audiences effectively discarding that sound when they listen. But render such notes without the noise and it will immediately sound "artificial". The SMS tools use the stochastic/sinusoidal model and thus offer independent control of the noise and tone aspects. Richard Dobson Joshua Scholar wrote: > > After all the old method of hand looping samples is just a manual version of > a time domain technique. > > >>personally, folks, i've always thought that pitch shifting a single piano >>note was pretty easy with time-domain techniques. whether you do >>autocorrelation or AMDF, first detect where good places to splice and then >>do shifting and splicing to time-scale the note, then do resampling to >>change the pitch (with the added effect of bringing the length back to the >>original length). of course pitch shifting it very far (a few semitones) >>will make for a pretty funky sounding piano note, but that is a different >>story. >> >>also, if you want to do additive synthesis analysis, check out the > > Wavetable > >>Synthesis 101 paper at harmony-central.com. as long as you can do decent >>pitch detection (or period detection), that analysis will get you harmonic >>amplitudes and phases spot on. a change in the phase (w.r.t. time) >>indicates that the frequency of the overtone is deviating from its > > harmonic > >>value. >> >>-- >> >>r b-j rbj@audioimagination.com > > \ > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > > From jtpigdon at students.latrobe.edu.au Sun Jan 16 20:05:16 2005 From: jtpigdon at students.latrobe.edu.au (Joel Pigdon) Date: Sun Jan 21 12:11:07 2007 Subject: [music-dsp] Re: availability of head trackers In-Reply-To: <20050116003244.16BA318FA85B@music.calarts.edu> References: <20050116003244.16BA318FA85B@music.calarts.edu> Message-ID: I believe there is a product called the gyromouse which acts just like a usb mouse except that it uses MEMS accelerometers to sense acceleration. These can be pulled apart and mounted in any orientation and will be significantly cheaper than any of the hard core VR suppliers, check out kevin mellots homebrew VR website for more info http://www.geocities.com/mellott124/index.htm he has got detailed build instructions there somewhere. Also analog devices make the accellerometers themselves, they are pretty easy to interface to but will require some microprocessor glue to the computer good luck Joel Pigdon From iain at idcl.co.uk Mon Jan 17 04:12:23 2005 From: iain at idcl.co.uk (Iain) Date: Sun Jan 21 12:11:07 2007 Subject: [music-dsp] [repeat???] Fundamental Frequence of long period waves In-Reply-To: Message-ID: <20050117091225.4F87AE4408@cmlapp02.csee.securepod.com> [I'm sorry if this ends up coming through several times. I've had 3 goes now at sending this and I've not seen it appear in the list. This time I am modifying a reply to an existing (unrelated) message! If anyone can suggest why these messages are disappearing, I would be greatfull!] I'm about to do a project which will require me to track the base frequency of a low frequency periodic wave (0.5 - 4 Hz). I need to know the absolute frequency of the fundamental with reasonable accuracy even whilst it is changing within a single period. To put this in perspective, the application is to measure the cadence of a repetitive action of an exerciser. So suppose the chap is cycling and the sensor is attached to the thigh. He is doing 60rpm and then pushes harder. I'd like to know he is at 65 Hz after half a cycle. The item measured is (in effect) the displacement of the limb so may not be clean in all cases. I *suspect* a phase locked loop may be the answer here, but that's a bit of a guess. Any ideas? Iain From ravikiranc at gmail.com Mon Jan 17 07:09:17 2005 From: ravikiranc at gmail.com (Ravi Kiran) Date: Sun Jan 21 12:11:08 2007 Subject: [music-dsp] Antti's Moog filter available In-Reply-To: References: Message-ID: <77e7371505011704097d075520@mail.gmail.com> Dear Juhana, I want to implement a low pass resonant digital filter with two poles (the one specified in DLS 2.1). The filter is characterised by the cut off frequency and resonance. The link you gave specifies that one can implement a filter with the above parameters. However, I dont understand what these opcodes are. Can you tell me where exactly can I find C code for the filter implementation in CSound with the above parameters? Thanks a lot!! Regards Ravi Kiran On Thu, 13 Jan 2005 18:32:30 +0200, Juhana Sadeharju wrote: > > Hello. Antti's Moog filter is available as Csound opcode here: > http://www.kunstmusik.com/udo/ > > I hope it is tuned as good as Antti's own implementation. > > Juhana > -- > http://music.columbia.edu/mailman/listinfo/linux-graphics-dev > for developers of open source graphics software > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > From howard.m.cornell.iii at lmco.com Mon Jan 17 12:59:04 2005 From: howard.m.cornell.iii at lmco.com (Cornell III, Howard M) Date: Sun Jan 21 12:11:08 2007 Subject: [music-dsp] [repeat???] Fundamental Frequence of long period waves Message-ID: <140F0E67720B194BB90FE31F40D67044033FD3AD@emss02m19.us.lmco.com> If the frequency changes relatively slowly (compared to the sample rate), you can keep track of PHASE instead. You can maintain a moving average of phase, which relates to instantaneous frequency. -----Original Message----- From: music-dsp-bounces@shoko.calarts.edu [mailto:music-dsp-bounces@shoko.calarts.edu] On Behalf Of Iain Sent: Monday, January 17, 2005 3:12 AM To: 'a list for musical digital signal processing' Subject: [music-dsp] [repeat???] Fundamental Frequence of long period waves [I'm sorry if this ends up coming through several times. I've had 3 goes now at sending this and I've not seen it appear in the list. This time I am modifying a reply to an existing (unrelated) message! If anyone can suggest why these messages are disappearing, I would be greatfull!] I'm about to do a project which will require me to track the base frequency of a low frequency periodic wave (0.5 - 4 Hz). I need to know the absolute frequency of the fundamental with reasonable accuracy even whilst it is changing within a single period. To put this in perspective, the application is to measure the cadence of a repetitive action of an exerciser. So suppose the chap is cycling and the sensor is attached to the thigh. He is doing 60rpm and then pushes harder. I'd like to know he is at 65 Hz after half a cycle. The item measured is (in effect) the displacement of the limb so may not be clean in all cases. I *suspect* a phase locked loop may be the answer here, but that's a bit of a guess. Any ideas? Iain -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://shoko.calarts.edu/musicdsp http://ceait.calarts.edu/mailman/listinfo/music-dsp From kaleja at estarcion.com Mon Jan 17 17:18:49 2005 From: kaleja at estarcion.com (Russell Borogove) Date: Sun Jan 21 12:11:08 2007 Subject: [music-dsp] [repeat???] Fundamental Frequence of long period waves References: <140F0E67720B194BB90FE31F40D67044033FD3AD@emss02m19.us.lmco.com> Message-ID: <000e01c4fce2$862d2310$0601000a@jaseroque> > I need to know the absolute frequency of the fundamental with reasonable > accuracy even whilst it is changing within a single period. > > To put this in perspective, the application is to measure the cadence of > a repetitive action of an exerciser. So suppose the chap is cycling and > the sensor is attached to the thigh. He is doing 60rpm and then pushes > harder. I'd like to know he is at 65 Hz after half a cycle. > > The item measured is (in effect) the displacement of the limb so may not > be clean in all cases. > > Any ideas? Pick a few spots in the cycle where motion is most likely to be smooth and count crossings of those points. The more points you pick, the less of a cycle he needs to go through before you can revise your estimate, but the less accuracy you'll have. From cshare01 at qub.ac.uk Tue Jan 18 06:33:47 2005 From: cshare01 at qub.ac.uk (Chris Share) Date: Sun Jan 21 12:11:08 2007 Subject: [music-dsp] New To List: Question About Melodyne Message-ID: <41ECF41B.6040501@qub.ac.uk> Hi, I'm new to the musid-dsp list. I'm interested in the algorithms that Celemony's Melodyne is using. Does anyone have any idea about what approach they're using? Cheers, Chris From signalzerodb at yahoo.co.uk Tue Jan 18 06:55:05 2005 From: signalzerodb at yahoo.co.uk (Dave Gamble) Date: Sun Jan 21 12:11:08 2007 Subject: [music-dsp] New To List: Question About Melodyne + pitchtracking questions! In-Reply-To: <41ECF41B.6040501@qub.ac.uk> References: <41ECF41B.6040501@qub.ac.uk> Message-ID: On 18 Jan 2005, at 11:33, Chris Share wrote: > Hi, > > I'm new to the musid-dsp list. > > I'm interested in the algorithms that Celemony's Melodyne is using. > > Does anyone have any idea about what approach they're using? > I asked them a while ago, and got the impression that it was some very proprietary, hand-calibrated stuff. My impression was that they use noise gates and a sidechain-type system to identify the envelopes, plus some very clever pitch tracking. The signal identification stuff was Very impressive (even to cynical old me!). Monophonic, of course, but it'd be rude to ask for polyphonic pitch tracking. Their pitch-modification is good, but not brilliant (there was no difficulty in hearing aliasing+grain on shifts of a few tones). Of course, the pitch tracking that they use gives them a lot of info on how to pitch-shift, so given that they have the fundamental, they can just measure the harmonics, then change the fundamental to where it should be, and because they know exactly where they've come from, and exactly where they've gone to, they can calculate the phase offset, and run that through to recalculate the rest of the signal without gaps/pops. I've been meaning to post to ask about pitch tracking for a while; there are some real clever techniques out there. I've seen lots of stuff; LPC (and looking at pole locations), zero crossings, AMDF, ADSDF (and the almost identical technique used in the autotune), all sorts of bizarre inventions based on band-pass filters (usually in guitar tuner patents), MPS, and some Sprenger wavelet magic (well... heard of)! ;) But what really works? I implemented some autocorrelation based tricks, and it's nothing special- really. Had a play with MPS, not much to write home about, and it's still stuck with being an FFT-based approach, so you still end up trying to interpolate across bins to estimate the peak. Zero-crossing-based methods are fraught with a million problems. :-/ LPC is hard enough to get to work well in the first place, nevermind analysing the pole locations! The wavelet based techniques, I just don't know anything about (although I assume something cool like a chirp-z transform is used, and a mother wavelet which is suspiciously band-pass-like!) Does anyone have any methods that they'd like to show off? :) Atb, Dave. From douglas at music.columbia.edu Tue Jan 18 13:24:20 2005 From: douglas at music.columbia.edu (douglas irving repetto) Date: Sun Jan 21 12:11:08 2007 Subject: [music-dsp] Fwd: Audio Software Developer Message-ID: >From: agreen@ambitgroup.com.au >Reply-To: agreen@ambitgroup.com.au >To: music-dsp-owner@shoko.calarts.edu >Subject: Audio Software Developer >Date: Thu, 3 Jun 2004 12:12:42 +1000 >Sender: mailman-bounces@shoko.calarts.edu >Status: > >Douglas, >I'm writng this from Sydney Australia and I am in the recruitment industry >looking for a Audio Software Developer. >I found your website through various searching I have done. >I have listed the skills I require and I was wondering, through your >network, if you knew anyone with the following skills. >If so please forward my contact details to them adn I would be happy to >discuss the role further with them. >I hope you can help, thanks alot >I'm looking for an experienced software developer to join the Pro > >Products > >> team, developing cutting edge user interfaces enabling > >> audio system controls for the lake contour and other next generation pro > >> audio products. > >> They'll need > >> 4yrs of C/C++ professional exp > >> In depth knowledge of Windows API > >> DirectX / OpenGL (graphic intensive programming) > >> Solid Object Oriented design skills. > > > >regards, > >Andrew Green >Senior Account Manager > >Ambit Engineering >Level 17, 15 Blue St >North Sydney NSW 2060 >Telephone +61 2 9409 4814 >Mobile: 0422 869 589 > >agreen@ambitgroup.com.au > >www.ambitgroup.com.au > >The right talent......now! > > > > > > >The information contained in this e-mail is confidential. It is only >intended for the recipient/s named above. > >If this message is not addressed to you, or if you are not responsible for >the delivery of this message to the addressee, you may not download, copy or >forward this message to any other person. If you do not immediately delete >this message you may be liable for a breach of confidentiality. We would be >grateful if you would notify us of your receipt and deletion of this >message. >It is your responsibility to maintain an up to date virus detection system >and to scan this message and any attachment to it for computer viruses or >other defects. If you download a file attached to this message, you do so at >your own risk. In no circumstances does Ambit Pty Ltd accept liability for >any loss or damage (including any indirect or consequential losses) which >may result, directly or indirectly, from your receipt of this message or any >attachment to it. >All publicly available privacy related forms, policies and procedures are >found on www.ambit.com.au, including the contact details of the Privacy >Officer. We will assume that you have made yourself aware of the contents of >the above web page. -- ............................................... http://artbots.org .....douglas.....irving........................ http://dorkbot.org ................................ http://ceait.calarts.edu/musicdsp .......... repetto............. http://music.columbia.edu/organism ............................... http://music.columbia.edu/~douglas From robin-lists at robinbowes.com Tue Jan 18 17:01:00 2005 From: robin-lists at robinbowes.com (Robin Bowes) Date: Sun Jan 21 12:11:08 2007 Subject: [music-dsp] Crossover in digital domain? Message-ID: <41ED871C.3070802@robinbowes.com> Hi, I'm playing around with my bi-amping audio system [1] and an idea popped into my head: instead of feeding the same signal to both HF and LF drivers and relying on the crossovers built into the speakers, why not have a crossover in the digital domain and use two DACs each feeding a separate amplifier? [1] Squeezebox -> Art DI/O DAC -> Rotel RA820A (modified)(HF) + Rotel RB850 (LF) I had a quick google around and found several devices that have analogue inputs and analogue outputs, but I couldn't find anything that simply takes a digital input signal and filters it digitally, producing a LF and HF digital output. Does anyone know of such a device? How easy would this sort of thing be to build? Thanks, R. -- http://robinbowes.com From tomerbe at san.rr.com Tue Jan 18 17:40:12 2005 From: tomerbe at san.rr.com (Tom Erbe) Date: Sun Jan 21 12:11:08 2007 Subject: [music-dsp] SHARC database Message-ID: Does anyone know the location of Gregory Sandell's SHARC database of musical timbre information? Maybe a local copy could be hosted at musicdsp.org? *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ tom erbe soundhack 608 carla way la jolla, ca 92037 tomerbe - at - san.rr.com *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ From howard.m.cornell.iii at lmco.com Tue Jan 18 18:08:33 2005 From: howard.m.cornell.iii at lmco.com (Cornell III, Howard M) Date: Sun Jan 21 12:11:08 2007 Subject: [music-dsp] Crossover in digital domain? Message-ID: <140F0E67720B194BB90FE31F40D6704404C4A0C6@emss02m19.us.lmco.com> Robin and List, For a perfect filter, how about running a low pass filter, delaying the raw input as many sample times as the filter requires, SUBTRACTING the filtered signal from the delayed input signal, and calling that difference the high pass? You can do it again for a three-way (yielding a band-pass and your real high-pass). Or is that how everyone (who filters) does it? Howard Cornell -----Original Message----- From: music-dsp-bounces@shoko.calarts.edu [mailto:music-dsp-bounces@shoko.calarts.edu] On Behalf Of Robin Bowes Sent: Tuesday, January 18, 2005 4:01 PM To: music-dsp@shoko.calarts.edu Subject: [music-dsp] Crossover in digital domain? Hi, I'm playing around with my bi-amping audio system [1] and an idea popped into my head: instead of feeding the same signal to both HF and LF drivers and relying on the crossovers built into the speakers, why not have a crossover in the digital domain and use two DACs each feeding a separate amplifier? [1] Squeezebox -> Art DI/O DAC -> Rotel RA820A (modified)(HF) + Rotel RB850 (LF) I had a quick google around and found several devices that have analogue inputs and analogue outputs, but I couldn't find anything that simply takes a digital input signal and filters it digitally, producing a LF and HF digital output. Does anyone know of such a device? How easy would this sort of thing be to build? Thanks, R. -- http://robinbowes.com -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://shoko.calarts.edu/musicdsp http://ceait.calarts.edu/mailman/listinfo/music-dsp From Valeriy_Shafiro at rush.edu Tue Jan 18 18:16:35 2005 From: Valeriy_Shafiro at rush.edu (Valeriy_Shafiro@rush.edu) Date: Sun Jan 21 12:11:08 2007 Subject: [music-dsp] SHARC database Message-ID: Tom, Is this what you were looking for? http://theremin.music.uiowa.edu/MIS.html Valeriy To: music-dsp@shoko.calarts.edu From: Tom Erbe Sent by: music-dsp-bounces@shoko.calarts.edu Date: 01/18/2005 04:40PM Subject: [music-dsp] SHARC database Does anyone know the location of Gregory Sandell's SHARC database of musical timbre information? Maybe a local copy could be hosted at musicdsp.org? *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ tom erbe soundhack 608 carla way la jolla, ca 92037 tomerbe - at - san.rr.com *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://shoko.calarts.edu/musicdsp http://ceait.calarts.edu/mailman/listinfo/music-dsp From robin-lists at robinbowes.com Tue Jan 18 18:51:03 2005 From: robin-lists at robinbowes.com (Robin Bowes) Date: Sun Jan 21 12:11:08 2007 Subject: [music-dsp] Crossover in digital domain? In-Reply-To: <140F0E67720B194BB90FE31F40D6704404C4A0C6@emss02m19.us.lmco.com> References: <140F0E67720B194BB90FE31F40D6704404C4A0C6@emss02m19.us.lmco.com> Message-ID: <41EDA0E7.5090500@robinbowes.com> Cornell III, Howard M wrote: > Robin and List, > > For a perfect filter, how about running a low pass filter, delaying the > raw input as many sample times as the filter requires, SUBTRACTING the > filtered signal from the delayed input signal, and calling that > difference the high pass? You can do it again for a three-way (yielding > a band-pass and your real high-pass). > > Or is that how everyone (who filters) does it? Howard, That sounds reasonable to me, but then it is over 13 years since I did my final year dissertation on Digital Filter Design (I have a degree in Electroacoustics). I guess what I am really asking is for information on commercially available DSP chips that I could use to build my own crossover. For example, could I buy a single chip DSP, feed it a digital input, write code to process the signal, and produce LF and HF outputs? Thanks, R. -- http://robinbowes.com From joshscholar at yahoo.com Tue Jan 18 18:57:45 2005 From: joshscholar at yahoo.com (Joshua Scholar) Date: Sun Jan 21 12:11:08 2007 Subject: [music-dsp] Crossover in digital domain? References: <140F0E67720B194BB90FE31F40D6704404C4A0C6@emss02m19.us.lmco.com> Message-ID: <010301c4fdb9$823b7bd0$b0e22641@antssoftware.com> You can certainly do that with a linear phase filter. I have no idea if that's how people do this sort of thing in the digital domain, but it's definately the most perfect way of doing it. On idea I've had for doing this sort of thing with minimal processing is to process data in overlapping blocks and to get a linear phase filter from a IIR filter by runing it both backwards and forwards over each block. ----- Original Message ----- From: "Cornell III, Howard M" To: "a list for musical digital signal processing" Sent: Tuesday, January 18, 2005 3:08 PM Subject: RE: [music-dsp] Crossover in digital domain? > > Robin and List, > > For a perfect filter, how about running a low pass filter, delaying the > raw input as many sample times as the filter requires, SUBTRACTING the > filtered signal from the delayed input signal, and calling that > difference the high pass? You can do it again for a three-way (yielding > a band-pass and your real high-pass). > > Or is that how everyone (who filters) does it? > > Howard Cornell > > > -----Original Message----- > From: music-dsp-bounces@shoko.calarts.edu > [mailto:music-dsp-bounces@shoko.calarts.edu] On Behalf Of Robin Bowes > Sent: Tuesday, January 18, 2005 4:01 PM > To: music-dsp@shoko.calarts.edu > Subject: [music-dsp] Crossover in digital domain? > > Hi, > > I'm playing around with my bi-amping audio system [1] and an idea popped > into my head: instead of feeding the same signal to both HF and LF > drivers and relying on the crossovers built into the speakers, why not > have a crossover in the digital domain and use two DACs each feeding a > separate amplifier? > > [1] Squeezebox -> Art DI/O DAC -> Rotel RA820A (modified)(HF) + Rotel > RB850 (LF) > > I had a quick google around and found several devices that have analogue > inputs and analogue outputs, but I couldn't find anything that simply > takes a digital input signal and filters it digitally, producing a LF > and HF digital output. > > Does anyone know of such a device? How easy would this sort of thing be > to build? > > Thanks, > > R. > -- > http://robinbowes.com > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp From koen at smartelectronix.com Tue Jan 18 18:56:33 2005 From: koen at smartelectronix.com (Koen Tanghe) Date: Sun Jan 21 12:11:08 2007 Subject: [music-dsp] New To List: Question About Melodyne + pitchtrackingquestions! References: <41ECF41B.6040501@qub.ac.uk> Message-ID: <00bc01c4fdb9$56b02ce0$6402a8c0@kthome1> On Tuesday, January 18, 2005 12:55 PM [GMT+1=CET], Dave Gamble wrote: > I've been meaning to post to ask about pitch tracking for a while; > there are some real clever techniques out there. > I've seen lots of stuff; LPC (and looking at pole locations), zero > crossings, AMDF, ADSDF (and the almost identical technique used in the > autotune), > all sorts of bizarre inventions based on band-pass filters (usually in > guitar tuner patents), MPS, and some Sprenger wavelet magic (well... > heard of)! ;) > > But what really works? > I implemented some autocorrelation based tricks, and it's nothing > special- really. > Had a play with MPS, not much to write home about, and it's still stuck > with being an FFT-based approach, so you still end up trying to > interpolate across > bins to estimate the peak. > Zero-crossing-based methods are fraught with a million problems. :-/ > LPC is hard enough to get to work well in the first place, nevermind > analysing the pole locations! > The wavelet based techniques, I just don't know anything about > (although I assume something cool like a chirp-z transform is used, and > a mother wavelet which > is suspiciously band-pass-like!) > > Does anyone have any methods that they'd like to show off? :) Well, but for the project I'm working on during my daytime job, a "melody extraction" module has been made available overhere: http://www.ipem.ugent.be/MAMI/ --> go to "Public" and then "Software" (there's a simple Win32 demo and a Win32/Linux library) Originally intended for sung vocal melodies, but it should now also work better for different instruments. You'll find the related papers there too (mainly uses an auditory model, with autocorrelation for the low end and subharmonic sum for the higher end). You might want to check it out if you're interested. Koen Tanghe From kvos at qualcomm.com Tue Jan 18 19:05:22 2005 From: kvos at qualcomm.com (Koen Vos) Date: Sun Jan 21 12:11:08 2007 Subject: [music-dsp] Crossover in digital domain? In-Reply-To: <010301c4fdb9$823b7bd0$b0e22641@antssoftware.com> References: <140F0E67720B194BB90FE31F40D6704404C4A0C6@emss02m19.us.lmco.com> <010301c4fdb9$823b7bd0$b0e22641@antssoftware.com> Message-ID: <6.0.0.22.2.20050118160226.043a1bd0@qcmail1.qualcomm.com> Joshua writes: >On idea I've had for doing this sort of thing with minimal processing is to >process data in overlapping blocks and to get a linear phase filter from a >IIR filter by runing it both backwards and forwards over each block. That's a good way of getting linear phase filters. It's done this way in some commercial products too, such as those from Weiss: http://www.weiss.ch/eq1/images/brochureEQ1-LP.PDF koen. From uli.brueggemann at freenet.de Wed Jan 19 04:36:43 2005 From: uli.brueggemann at freenet.de (Ulrich Brueggemann) Date: Sun Jan 21 12:11:08 2007 Subject: [music-dsp] Crossover in digital domain? References: <41ED871C.3070802@robinbowes.com> Message-ID: <003b01c4fe0a$63f587a0$32b9a8c0@BrueggemannNB> I use a fanless PC (mainboard, RAM, soundcard, memorystick) with BruteFIR and Linux to realize a 4-way digital XO including room correction. BruteFIR is open source and you can build a convolution engine quite easily. Of course then you have to design the desired filters but there are different programs available for this purpose. Uli ----- Original Message ----- From: "Robin Bowes" To: Sent: Tuesday, January 18, 2005 10:01 PM Subject: [music-dsp] Crossover in digital domain? > Hi, > > I'm playing around with my bi-amping audio system [1] and an idea popped > into my head: instead of feeding the same signal to both HF and LF drivers > and relying on the crossovers built into the speakers, why not have a > crossover in the digital domain and use two DACs each feeding a separate > amplifier? > > [1] Squeezebox -> Art DI/O DAC -> Rotel RA820A (modified)(HF) + Rotel > RB850 (LF) > > I had a quick google around and found several devices that have analogue > inputs and analogue outputs, but I couldn't find anything that simply > takes a digital input signal and filters it digitally, producing a LF and > HF digital output. > > Does anyone know of such a device? How easy would this sort of thing be to > build? > > Thanks, > > R. > -- > http://robinbowes.com > -- > dupswapdrop -- the music-dsp mailing list and website: subscription info, > FAQ, source code archive, list archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > > From eddie at roughproductions.co.uk Wed Jan 19 07:20:17 2005 From: eddie at roughproductions.co.uk (Eddie Al-Shakarchi) Date: Sun Jan 21 12:11:08 2007 Subject: [music-dsp] RMS Window Size For Compressor & General Performance Optimisation In-Reply-To: <003b01c4fe0a$63f587a0$32b9a8c0@BrueggemannNB> References: <41ED871C.3070802@robinbowes.com> <003b01c4fe0a$63f587a0$32b9a8c0@BrueggemannNB> Message-ID: <7A81C29A-6A14-11D9-A3D9-0003936A8584@roughproductions.co.uk> Hi guys, got a couple of questions Could you guys offer me advice on what kind of size of RMS window size (in samples) is best for performance/quality? I currently have a slider which allows the user to select between 0 and 10ms, which is way too much, for a stereo 16bit file, 44.1khz. Even at 1ms, that's 44 samples , which seems to be too much? I'm using contiguous *chunks* of audio, and when using peak compression i can process a stereo 16bi 44.1k wav file in realtime with no gaps in audio. Changing it to RMS introduces breakups/gaps between the chunks! The second question is about optimisation. I am using Java, so i'm already up against it. But can you guys give me some quick tips in how to generally optimise code, as i think i really need to squeeze every ounce of power the machine can handle. Many thanks Eddie From uli.brueggemann at freenet.de Wed Jan 19 07:46:28 2005 From: uli.brueggemann at freenet.de (Ulrich Brueggemann) Date: Sun Jan 21 12:11:08 2007 Subject: [music-dsp] RMS Window Size For Compressor & General PerformanceOptimisation References: <41ED871C.3070802@robinbowes.com><003b01c4fe0a$63f587a0$32b9a8c0@BrueggemannNB> <7A81C29A-6A14-11D9-A3D9-0003936A8584@roughproductions.co.uk> Message-ID: <000401c4fe24$e5f14a90$32b9a8c0@BrueggemannNB> Hi Eddi, if a signal has no DC component the RMS is identical to the standard deviation. The formula for calculation is with a given number of samples: Sum = x1 + x2 + x3 + ... +xN SumSquares = x1^2 + x2^2 + x3^2 +... xN^2 for N samples RMS = sqr((SumSquares-Sum^2/N)/(N-1)) Now you can process the next sample x(N+1) with Sum = Sum - x1 + x(N+1) SumSquares = SumSquares - x1^2 + x(N+1)^2 and calculate RMS and go on with Sum = Sum - x2 + x(N+2) SumSquares = SumSquares - x2^2 + x(N+2)^2 .... Thus you can compute the RMS over a given window with each new sample and you do not get *chunks*. Maybe the my math description is not fully correct but I hope you get the idea. Uli ----- Original Message ----- From: "Eddie Al-Shakarchi" To: "a list for musical digital signal processing" Sent: Wednesday, January 19, 2005 12:20 PM Subject: [music-dsp] RMS Window Size For Compressor & General PerformanceOptimisation > Hi guys, got a couple of questions > > Could you guys offer me advice on what kind of size of RMS window size (in > samples) is best for performance/quality? I currently have a slider which > allows the user to select between 0 and 10ms, which is way too much, for a > stereo 16bit file, 44.1khz. > > Even at 1ms, that's 44 samples , which seems to be too much? I'm using > contiguous *chunks* of audio, and when using peak compression i can > process a stereo 16bi 44.1k wav file in realtime with no gaps in audio. > Changing it to RMS introduces breakups/gaps between the chunks! > > The second question is about optimisation. I am using Java, so i'm already > up against it. But can you guys give me some quick tips in how to > generally optimise code, as i think i really need to squeeze every ounce > of power the machine can handle. > > Many thanks > > Eddie > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription info, > FAQ, source code archive, list archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > > From robin-lists at robinbowes.com Wed Jan 19 07:52:08 2005 From: robin-lists at robinbowes.com (Robin Bowes) Date: Sun Jan 21 12:11:09 2007 Subject: [music-dsp] Crossover in digital domain? In-Reply-To: <003b01c4fe0a$63f587a0$32b9a8c0@BrueggemannNB> References: <41ED871C.3070802@robinbowes.com> <003b01c4fe0a$63f587a0$32b9a8c0@BrueggemannNB> Message-ID: <41EE57F8.8050000@robinbowes.com> Ulrich Brueggemann wrote: > I use a fanless PC (mainboard, RAM, soundcard, memorystick) with > BruteFIR and Linux to realize a 4-way digital XO including room > correction. BruteFIR is open source and you can build a convolution > engine quite easily. > > Of course then you have to design the desired filters but there are > different programs available for this purpose. Uli, Thanks for the suggestion. I'm interested in that sort of stuff, but I am looking more for an "appliance" rather than another PC, i.e. something that can live on my hifi shelf. My initial idea is to use it with a pair of Art DI/O DACS, but I may even go further and build the whole lot into a custom box, i.e. I would pull the guts out of the DACs and connect the outputs of the filtering module directly to them internally. However, if I can't find a cheap way of doing this I most likely will put it on the back-burner Cheers, R. -- http://robinbowes.com From eddie at roughproductions.co.uk Wed Jan 19 08:04:07 2005 From: eddie at roughproductions.co.uk (Eddie Al-Shakarchi) Date: Sun Jan 21 12:11:09 2007 Subject: [music-dsp] RMS Window Size For Compressor & General PerformanceOptimisation In-Reply-To: <000401c4fe24$e5f14a90$32b9a8c0@BrueggemannNB> References: <41ED871C.3070802@robinbowes.com><003b01c4fe0a$63f587a0$32b9a8c0@BrueggemannNB> <7A81C29A-6A14-11D9-A3D9-0003936A8584@roughproductions.co.uk> <000401c4fe24$e5f14a90$32b9a8c0@BrueggemannNB> Message-ID: <9A18FCA4-6A1A-11D9-A247-0003936A8584@roughproductions.co.uk> Thanks for that Uli I am using chunks due to the nature of the software i'm coding for. The software takes an audio file and essentially streams it as contiguous chunks. The way it works is as follows: a 'LoadSound' tool (which allows you to select a 'wav' file) is dragged onto the work space, and connected via a virtual wire to a 'Play' unit which actually plays the audio. Anywhere in between this wire, DSP units can be dragged and plugged into the virtual wire. The chunks of audio must be used as the units do not know where the data will go next, they are just outputted. If the entire file is used then the NEXT unit in the chain (say, a compressor) will have to process the entire file before passing it on. If chunks of 1 second are used however, then playback can start after just processing a 1 second chunk of the audio is finished. The chunks are dealt with as unrelated pieces of audio be the other units. This software allows you to group units - and so a group of delays can be grouped and saved to allow the user to custom design their own schroeder reverb - and you can keep adding delays over and over. THEN, this software allows for distributed processing of these units. That is another story altogether though! So this is what i'm having trouble with. When adding anything much more than a peak compressor between the LoadSound and Play Units, i get blips introduced (when i set RMS window size to only 2 i get blips!). There's no doubt my playback code can be optimised however. Sorry to go on - but i wanted to explain what exactly it was that i was trying to do, and why chunks are being used. Thanks again Eddie On 19 Jan 2005, at 12:46, Ulrich Brueggemann wrote: > Hi Eddi, > > if a signal has no DC component the RMS is identical to the standard > deviation. > > The formula for calculation is with a given number of samples: > > Sum = x1 + x2 + x3 + ... +xN > SumSquares = x1^2 + x2^2 + x3^2 +... xN^2 for N samples > > RMS = sqr((SumSquares-Sum^2/N)/(N-1)) > > Now you can process the next sample x(N+1) with > > Sum = Sum - x1 + x(N+1) > SumSquares = SumSquares - x1^2 + x(N+1)^2 > > and calculate RMS > > and go on with > > Sum = Sum - x2 + x(N+2) > SumSquares = SumSquares - x2^2 + x(N+2)^2 .... > > Thus you can compute the RMS over a given window with each new sample > and you do not get *chunks*. > Maybe the my math description is not fully correct but I hope you get > the idea. > > Uli > > > ----- Original Message ----- From: "Eddie Al-Shakarchi" > > To: "a list for musical digital signal processing" > > Sent: Wednesday, January 19, 2005 12:20 PM > Subject: [music-dsp] RMS Window Size For Compressor & General > PerformanceOptimisation > > >> Hi guys, got a couple of questions >> >> Could you guys offer me advice on what kind of size of RMS window >> size (in samples) is best for performance/quality? I currently have a >> slider which allows the user to select between 0 and 10ms, which is >> way too much, for a stereo 16bit file, 44.1khz. >> >> Even at 1ms, that's 44 samples , which seems to be too much? I'm >> using contiguous *chunks* of audio, and when using peak compression i >> can process a stereo 16bi 44.1k wav file in realtime with no gaps in >> audio. Changing it to RMS introduces breakups/gaps between the >> chunks! >> >> The second question is about optimisation. I am using Java, so i'm >> already up against it. But can you guys give me some quick tips in >> how to generally optimise code, as i think i really need to squeeze >> every ounce of power the machine can handle. >> >> Many thanks >> >> Eddie >> >> -- >> dupswapdrop -- the music-dsp mailing list and website: subscription >> info, FAQ, source code archive, list archive, book reviews, dsp links >> http://shoko.calarts.edu/musicdsp >> http://ceait.calarts.edu/mailman/listinfo/music-dsp >> > > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription > info, FAQ, source code archive, list archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > From Knut-Inge.Hvidsten at ffi.no Wed Jan 19 08:08:57 2005 From: Knut-Inge.Hvidsten at ffi.no (Knut-Inge.Hvidsten@ffi.no) Date: Sun Jan 21 12:11:09 2007 Subject: [music-dsp] Re: Crossover in digital domain? Message-ID: <2969FC64ACA5D348937BF081FD5A2F2F1083EB@hbu-posten.ffi.no> In my diploma thesis, I simulated a multirate linear phase FIR filter that allowed ~100dB stop band attenuation and a couple of Hz between passband and stopband, using approximately the processing power of a digital filter based on traditional passive filter technology (4th order linkwitz reiley) The drawback is delay (50-100ms) best regards Knut Inge Hvidsten From 76145.2455 at compuserve.com Wed Jan 19 10:27:56 2005 From: 76145.2455 at compuserve.com (Greg Berchin) Date: Sun Jan 21 12:11:09 2007 Subject: [music-dsp] Crossover in digital domain? Message-ID: <200501191028_MC3-1-9399-50AF@compuserve.com> Howard Cornell wrote: >For a perfect filter, how about running a low pass filter, delaying the >raw input as many sample times as the filter requires, SUBTRACTING the >filtered signal from the delayed input signal, and calling that >difference the high pass? I presented a paper on this at the 1999 AES Convention; "Perfect Reconstruction Digital Crossover Exhibiting Optimum Time Domain Transient Response in All Bands". See also: Tak Kwong Ng and Martin Rothenberg, "A Matched Delay Approach to Subtractive Linear Phase High-Pass Filtering", IEEE Transactions on Circuits and Systems, Vol. cas-29, no. 8, August 1982, pp. 584-587 And: Stanley P. Lipshitz and John Vanderkooy, "A Family of Linear-Phase Crossover Networks of High Slope Derived by Time Delay", Journal of the Audio Engineering Society, Vol. 31, 1983 January/February, pp. 2-20. -- Greg Berchin From arcane at arcanemethods.com Wed Jan 19 14:13:58 2005 From: arcane at arcanemethods.com (Bob Cain) Date: Sun Jan 21 12:11:09 2007 Subject: [music-dsp] Crossover in digital domain? In-Reply-To: <010301c4fdb9$823b7bd0$b0e22641@antssoftware.com> References: <140F0E67720B194BB90FE31F40D6704404C4A0C6@emss02m19.us.lmco.com> <010301c4fdb9$823b7bd0$b0e22641@antssoftware.com> Message-ID: <41EEB176.7070103@arcanemethods.com> Joshua Scholar wrote: > You can certainly do that with a linear phase filter. I have no idea if > that's how people do this sort of thing in the digital domain, but it's > definately the most perfect way of doing it. What I did was use Adobe Audition to put an impulse on each of the left and right channels. Using Audition's built in "Scientific Filter" function I filtered one channel with a 19th order Butterworth LP and the other with a 19th order HP. I chose 19 arbitrarily; higher order will just make it longer. These are minimum phase impulse responses. When the two impulse responses were summed, of course the result wasn't perfect. It was an allpass but there was quite a bit of phase anomoly. To fix that I found the time domain inverse of that sum using the generalized Levinson-Durbin algorithm and convolved both the HP and LP with that inverse. The result is an HP and LP with the rolloff characteristic of high order Butterworth but which sum to a one sample impulse. I.e. a perfect crossover. I tried yesterday to post this with such an IR pair attached of length 256 crossed over at 3600 Hz with a 1.5 ms. latency. I guess even small attachments cause posts from being rejected for the list. If there is a file area I could upload it there should anyone want to look at it. Is this approach novel or simply obvious? It can be applied to any HP/LP pair. It would be better, actually, to use a high order minimum phase crossover pair, measure the sum at a point in front of the speaker using a sin sweep or whatever, and use that as the sum to invert and apply to compensate the pair you start with. Then any actual phase anomolies introduced by the physical driver pair would be compensated. In general this will result in longer crossover filters with greater latency. Fine for listening but not so good for monitoring mixes and such. Putting such a filter into a DSP box should be pretty easy if there is a generic audio DSP box for such purposes. Bob -- "Things should be described as simply as possible, but no simpler." A. Einstein From douglas at music.columbia.edu Wed Jan 19 15:17:21 2005 From: douglas at music.columbia.edu (douglas irving repetto) Date: Sun Jan 21 12:11:09 2007 Subject: [music-dsp] Crossover in digital domain? In-Reply-To: <41EEB176.7070103@arcanemethods.com> References: <140F0E67720B194BB90FE31F40D6704404C4A0C6@emss02m19.us.lmco.com> <010301c4fdb9$823b7bd0$b0e22641@antssoftware.com> <41EEB176.7070103@arcanemethods.com> Message-ID: bob cain asked: >I tried yesterday to post this with such an IR pair attached of >length 256 crossed over at 3600 Hz with a 1.5 ms. latency. I guess >even small attachments cause posts from being rejected for the list. >If there is a file area I could upload it there should anyone want >to look at it. > all attachments are deleted automatically. but your crossover code would make a perfect submission to http://musicdsp.org/submit.php ! douglas -- ............................................... http://artbots.org .....douglas.....irving........................ http://dorkbot.org ................................ http://ceait.calarts.edu/musicdsp .......... repetto............. http://music.columbia.edu/organism ............................... http://music.columbia.edu/~douglas From arcane at arcanemethods.com Wed Jan 19 17:06:15 2005 From: arcane at arcanemethods.com (Bob Cain) Date: Sun Jan 21 12:11:09 2007 Subject: [music-dsp] Crossover in digital domain? In-Reply-To: References: <140F0E67720B194BB90FE31F40D6704404C4A0C6@emss02m19.us.lmco.com> <010301c4fdb9$823b7bd0$b0e22641@antssoftware.com> <41EEB176.7070103@arcanemethods.com> Message-ID: <41EED9D7.2070409@arcanemethods.com> douglas irving repetto wrote: > > bob cain asked: > >> I tried yesterday to post this with such an IR pair attached of length >> 256 crossed over at 3600 Hz with a 1.5 ms. latency. I guess even >> small attachments cause posts from being rejected for the list. If >> there is a file area I could upload it there should anyone want to >> look at it. >> > > > all attachments are deleted automatically. but your crossover code would > make a perfect submission to http://musicdsp.org/submit.php ! It's not so much code as it is a technique. I just tried it with a Chebychev pair at 18th order with -50 dB stopband and the result is a 1024 sample filter with about 9 ms. latency. Bob -- "Things should be described as simply as possible, but no simpler." A. Einstein From douglas at music.columbia.edu Wed Jan 19 17:16:15 2005 From: douglas at music.columbia.edu (douglas irving repetto) Date: Sun Jan 21 12:11:09 2007 Subject: [music-dsp] Crossover in digital domain? In-Reply-To: <41EED9D7.2070409@arcanemethods.com> References: <140F0E67720B194BB90FE31F40D6704404C4A0C6@emss02m19.us.lmco.com> <010301c4fdb9$823b7bd0$b0e22641@antssoftware.com> <41EEB176.7070103@arcanemethods.com> <41EED9D7.2070409@arcanemethods.com> Message-ID: >douglas irving repetto wrote: >> >>bob cain asked: >> >>>I tried yesterday to post this with such an IR pair attached of >>>length 256 crossed over at 3600 Hz with a 1.5 ms. latency. I >>>guess even small attachments cause posts from being rejected for >>>the list. If there is a file area I could upload it there should >>>anyone want to look at it. >>> >> >> >>all attachments are deleted automatically. but your crossover code >>would make a perfect submission to http://musicdsp.org/submit.php ! > >It's not so much code as it is a technique. I just tried it with a >Chebychev pair at 18th order with -50 dB stopband and the result is >a 1024 sample filter with about 9 ms. latency. > that's okay, techniques work in the archive too! doesn't have to be actual code... -- ............................................... http://artbots.org .....douglas.....irving........................ http://dorkbot.org ................................ http://ceait.calarts.edu/musicdsp .......... repetto............. http://music.columbia.edu/organism ............................... http://music.columbia.edu/~douglas From arcane at arcanemethods.com Wed Jan 19 17:25:32 2005 From: arcane at arcanemethods.com (Bob Cain) Date: Sun Jan 21 12:11:09 2007 Subject: [music-dsp] Crossover in digital domain? In-Reply-To: References: <140F0E67720B194BB90FE31F40D6704404C4A0C6@emss02m19.us.lmco.com> <010301c4fdb9$823b7bd0$b0e22641@antssoftware.com> <41EEB176.7070103@arcanemethods.com> Message-ID: <41EEDE5C.6070603@arcanemethods.com> douglas irving repetto wrote: > all attachments are deleted automatically. but your crossover code would > make a perfect submission to http://musicdsp.org/submit.php ! I just submitted the Matlab and C code for the time domain impulse response inversion/division function. Bob -- "Things should be described as simply as possible, but no simpler." A. Einstein From tom at nullpointer.co.uk Wed Jan 19 18:21:44 2005 From: tom at nullpointer.co.uk (Tom Betts) Date: Sun Jan 21 12:11:09 2007 Subject: [music-dsp] chunking References: <140F0E67720B194BB90FE31F40D6704404C4A0C6@emss02m19.us.lmco.com><010301c4fdb9$823b7bd0$b0e22641@antssoftware.com><41EEB176.7070103@arcanemethods.com><41EED9D7.2070409@arcanemethods.com> Message-ID: <004e01c4fe7d$a5d8ea40$0300a8c0@kepler> Hi all, I am writing an app using portaudio at 44k with float output, I have written my wn software mixer bits and have written a vst hosting section, so i can introduce vst fx into the mix. However at the moment i am chunking things via the portaudio callback and looping there.. So i am processing 1 sample at a time (in a loop per callback) via the vst dll.. My question is should i be generating a software buffer array for each chunk and then passing the whole chunk to the vst dll in one call? I Imagine this would be more efficent, but by how much etc? ie. at the moment portaudio callback { for(i=0;i<010301c4fdb9$823b7bd0$b0e22641@antssoftware.com> <41EEB176.7070103@arcanemethods.com> Message-ID: <001d01c4fe80$b505c620$90e22641@antssoftware.com> Let's see if I understand, you used "generalized Levinson-Durbin" to create an IIR filter that approximates a convolution? How is "generalized Levinson-Durbin" different from Levinson-Durbin - does it give you zeros as well as poles? It would be cool if you could feed an impulse response into an algorithm and get the best filter of a given size with both zeros and poles. I have been guessing that you could do that with Remez exchange or something similar but it would take a bunch of steps I haven't worked out and don't want to mess with. Joshua Scholar From robertfehse at gmx.de Wed Jan 19 18:50:50 2005 From: robertfehse at gmx.de (Robert Fehse) Date: Sun Jan 21 12:11:10 2007 Subject: [music-dsp] chunking References: <140F0E67720B194BB90FE31F40D6704404C4A0C6@emss02m19.us.lmco.com><010301c4fdb9$823b7bd0$b0e22641@antssoftware.com><41EEB176.7070103@arcanemethods.com><41EED9D7.2070409@arcanemethods.com> <004e01c4fe7d$a5d8ea40$0300a8c0@kepler> Message-ID: <000901c4fe81$b495f7e0$9302a8c0@FSH> depening on the plugin it could be up to 8 times faster i guess. be sure to choose a power of 2 for the buffersize. be also sure to provide all of the eventdata for the plugin for the related time. Robert > Hi all, > > I am writing an app using portaudio at 44k with float output, > I have written my wn software mixer bits and have written a vst hosting > section, > so i can introduce vst fx into the mix. > However at the moment i am chunking things via the portaudio callback and > looping there.. So i am processing 1 sample at a time (in a loop per > callback) > via the vst dll.. My question is should i be generating a software buffer > array for each chunk and then passing the whole chunk to the vst dll in one > call? > I Imagine this would be more efficent, but by how much etc? > > ie. at the moment > > portaudio callback > { > for(i=0;i { > do vst stuff per sample > } > > } > > > > > > also... exactly what does the vst 'do mono' ability provide.. > > p.s. I know this might be vst questons, but i reckon someone here must know > too! > > Thanks > > Tom > --------------------------------------------- > http://www.nullpointer.co.uk > http://www.r4nd.org > http://www.q-q-q.net > > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > From tom at nullpointer.co.uk Wed Jan 19 19:04:01 2005 From: tom at nullpointer.co.uk (Tom Betts) Date: Sun Jan 21 12:11:10 2007 Subject: [music-dsp] chunking References: <140F0E67720B194BB90FE31F40D6704404C4A0C6@emss02m19.us.lmco.com><010301c4fdb9$823b7bd0$b0e22641@antssoftware.com><41EEB176.7070103@arcanemethods.com><41EED9D7.2070409@arcanemethods.com><004e01c4fe7d$a5d8ea40$0300a8c0@kepler> <000901c4fe81$b495f7e0$9302a8c0@FSH> Message-ID: <000301c4fe83$8d6cdfb0$0300a8c0@kepler> From: "Robert Fehse" > > depening on the plugin it could be up to 8 times faster i guess. wow.. great.. i spose it counts when you start to stack them up! > be sure to choose a power of 2 for the buffersize. sure.. i cant even count in anything else anymore ;) > be also sure to provide all of the eventdata for the plugin for the > related > time ah yeah.. didnt think of that.. hmm i spose that might include calculating some interpolated data for parameter shifts? (if i was wanting to include automation type stuff) thanks Tom --------------------------------------------- http://www.nullpointer.co.uk http://www.r4nd.org http://www.q-q-q.net ----- Original Message ----- . > > Robert > > >> Hi all, >> >> I am writing an app using portaudio at 44k with float output, >> I have written my wn software mixer bits and have written a vst hosting >> section, >> so i can introduce vst fx into the mix. >> However at the moment i am chunking things via the portaudio callback and >> looping there.. So i am processing 1 sample at a time (in a loop per >> callback) >> via the vst dll.. My question is should i be generating a software buffer >> array for each chunk and then passing the whole chunk to the vst dll in > one >> call? >> I Imagine this would be more efficent, but by how much etc? >> >> ie. at the moment >> >> portaudio callback >> { >> for(i=0;i> { >> do vst stuff per sample >> } >> >> } >> >> >> >> >> >> also... exactly what does the vst 'do mono' ability provide.. >> >> p.s. I know this might be vst questons, but i reckon someone here must > know >> too! >> >> Thanks >> >> Tom >> --------------------------------------------- >> http://www.nullpointer.co.uk >> http://www.r4nd.org >> http://www.q-q-q.net >> >> >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, source code archive, list archive, book reviews, > dsp links >> http://shoko.calarts.edu/musicdsp >> http://ceait.calarts.edu/mailman/listinfo/music-dsp >> > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > > From arcane at arcanemethods.com Wed Jan 19 20:25:49 2005 From: arcane at arcanemethods.com (Bob Cain) Date: Sun Jan 21 12:11:10 2007 Subject: [music-dsp] Crossover in digital domain? In-Reply-To: <001d01c4fe80$b505c620$90e22641@antssoftware.com> References: <140F0E67720B194BB90FE31F40D6704404C4A0C6@emss02m19.us.lmco.com><010301c4fdb9$823b7bd0$b0e22641@antssoftware.com> <41EEB176.7070103@arcanemethods.com> <001d01c4fe80$b505c620$90e22641@antssoftware.com> Message-ID: <41EF089D.9030801@arcanemethods.com> Joshua Scholar wrote: > Let's see if I understand, you used "generalized Levinson-Durbin" to create > an IIR filter that approximates a convolution? No, it takes two FIR's, a numerator and a denominator, and gives you back an FIR of specified length and delay which when convolved with the denominator gives the closest approximation to the numerator in a least squares sense. If the numerator is a one sample impulse, it performs an inversion of the denominator IR. Finding a good delay specification is trial and error. With a specification of zero, the average group delay (aproximately where the peak is) of the result will be about that of the numerator minus that of the denominator. If that should be negative the result won't be of much use. Generally for an initial delay specification I subtract that difference from about a quarter of the length of the desired result IR and tweak from there if necessasary. That puts the peak of the result about a quarter into it. For the crossover, I just found the inverse of the sum of the HP and LP FIR's and convolved each with that inverse. After that compensation, they will sum to a very close approximation to a one sample impulse which is what indicates perfect reconstruction. Only in the case of the Butterworth is the original shape of the magnitude function exactly retained on both the HP and LP. With the Chebychev I did it on, there was also few dB magnitude adjustment of each near the crossover point. > > How is "generalized Levinson-Durbin" different from Levinson-Durbin - does > it give you zeros as well as poles? Dunno why it is called "generalized". > > It would be cool if you could feed an impulse response into an algorithm and > get the best filter of a given size with both zeros and poles. Yes, that would be very cool indeed! Bob -- "Things should be described as simply as possible, but no simpler." A. Einstein From tomerbe at san.rr.com Wed Jan 19 21:32:31 2005 From: tomerbe at san.rr.com (Tom Erbe) Date: Sun Jan 21 12:11:10 2007 Subject: [music-dsp] SHARC database In-Reply-To: References: Message-ID: <89048C13-6A8B-11D9-8C18-000D93B0BD28@san.rr.com> No - the database I was looking for one that Gregory Sandell put together (at the Parmly Hearing Institute) in 1996. Here's his description: --- Announcing the SHARC TIMBRE DATABASE and invitation to join a Timbre Discussion email list SHARC is a public domain database of musical timbre information by Gregory Sandell. It stands for "Sandell Harmonic Archive." People for whom this dataset may be useful are Acousticians, Psychoacousticians, researchers in Music Percepion and Cognition, researchers in Digital Signal Processing, Music Theorists, and Musicologists. Over 1300 different notes have been analysed. Complete chromatic runs from the standard playing range of essentially all the non-percussive instruments of the modern orchestra have been included; for example, individual analyses of 32 different oboe notes (the chromatic scale from the pitches a#3 to f6) are available. A WWW front end for SHARC is available at: http://www.parmly.luc.edu/sharc/ ---- After a little googling, I found a copy here: http://people.cs.uchicago.edu/~odonnell/Scholar/Data/sharc.tar.Z Perhaps this could be put in the music-dsp archive? On Jan 18, 2005, at 3:16 PM, Valeriy_Shafiro@rush.edu wrote: > > > > > > Tom, > > Is this what you were looking for? > > http://theremin.music.uiowa.edu/MIS.html > > Valeriy > > > > > To: music-dsp@shoko.calarts.edu > From: Tom Erbe > Sent by: music-dsp-bounces@shoko.calarts.edu > Date: 01/18/2005 04:40PM > Subject: [music-dsp] SHARC database > > Does anyone know the location of Gregory Sandell's SHARC database of > musical timbre information? Maybe a local copy could be hosted at > musicdsp.org? > > *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ > tom erbe soundhack 608 carla way > la jolla, ca 92037 tomerbe - at - san.rr.com > *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book > reviews, > dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book > reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ tom erbe soundhack 608 carla way la jolla, ca 92037 tomerbe - at - san.rr.com *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ From steve.conner at optosci.com Thu Jan 20 07:29:13 2005 From: steve.conner at optosci.com (Steve Conner) Date: Sun Jan 21 12:11:10 2007 Subject: [music-dsp] Re: Crossover in digital domain In-Reply-To: <20050119232200.329D7191B5C1@music.calarts.edu> Message-ID: >To fix that I found the time >domain inverse of that sum using the generalized >Levinson-Durbin algorithm and convolved both the HP and LP >with that inverse. The result is an HP and LP with the >rolloff characteristic of high order Butterworth but which >sum to a one sample impulse. I.e. a perfect crossover. This sounds very neat. I would like to think that you could include your speaker system in the loop too. You would connect the crossover to the speakers, feed it an impulse, record the output with a precision microphone, and put the output from the mic back into your Levinson-Durbin algorithm. Room acoustics and environmental noise would be a serious issue with this method and I imagine you'd need to do it in an anechoic chamber. But I have seen other methods like MLSSA (maximum-length sequence spectrum analysis IIRC) that are supposed to measure the speaker response accurately without needing an anechoic room. There should be some way of incorporating this into the method- if MLSSA can produce a frequency response then it stands to reason that it can give an impulse response too. does anyone think this is a bad idea? Steve C. business http://www.optosci.com/ pleasure http://www.scopeboy.com/ From NAYRALORENZO at telefonica.net Thu Jan 20 07:52:17 2005 From: NAYRALORENZO at telefonica.net (NAYRALORENZO@telefonica.net) Date: Sun Jan 21 12:11:10 2007 Subject: [music-dsp] matlab doubt Message-ID: <3401f2f8d5.2f8d53401f@teleline.es> I know that this is not a list from ask about Matlab, but I have a big doubt and I can't find the way to solve, so maybe someone of you know the answer. Does somebody know if is a way to display the results from a function, not in the command window, even in other display, for example, a static text in the guide? Thank you for your time. Nayra Lorenzo From yaakov_s at rad.com Thu Jan 20 09:46:03 2005 From: yaakov_s at rad.com (Yaakov Stein) Date: Sun Jan 21 12:11:10 2007 Subject: [music-dsp] [repeat???] Fundamental Frequence of long period waves Message-ID: <27A0F290348F8E45AEF79889DDE65A52039D4BE4@exrad2.ad.rad.co.il> > I *suspect* a phase locked loop may be the answer here, but > that's a bit of a guess. I'm not sure you need the "loop" part, but you sure could use phase measurement. The derivative of the instantaneous phase is the instantaneous frequency. Alternatively, you could use a frequency locked loop (FLL). This consists of a numerically- (or voltage-) controlled oscillator, a frequency difference calculator, and an integrator. input --->--- FREQ DIFF --->--- INTEGRATOR --->--- VCO --->--- --->--- output | | ^ V | - - - - - - - - - - < - - - - - - - - - - - - - - - - - - - - - - - | You only have to go to a PLL if you need the absolute phase to lock-in too. Finally, my favorite "super-resolution" method of finding the frequency of a sine in noise is Pisarenko's method. Jonathan (Y) Stein From arcane at arcanemethods.com Thu Jan 20 13:07:53 2005 From: arcane at arcanemethods.com (Bob Cain) Date: Sun Jan 21 12:11:10 2007 Subject: [music-dsp] Re: Crossover in digital domain In-Reply-To: References: Message-ID: <41EFF379.9060002@arcanemethods.com> Steve Conner wrote: > This sounds very neat. I would like to think that you could include your > speaker system in the loop too. You would connect the crossover to the > speakers, feed it an impulse, record the output with a precision microphone, > and put the output from the mic back into your Levinson-Durbin algorithm. Exactly! And in the process, exactly idealize the speaker's response at the measurement point. The ear is generally not all that impressed with exactly flat speakers but it is a darned good place to start to digitally add coloration that is euphonic and is ideal for mix and mastering monitors. > > Room acoustics and environmental noise would be a serious issue with this > method and I imagine you'd need to do it in an anechoic chamber. But I have > seen other methods like MLSSA (maximum-length sequence spectrum analysis > IIRC) that are supposed to measure the speaker response accurately without > needing an anechoic room. Yes, there is a method called "time domain spectroscopy" which effectively windows the measurement in time to block out reflections but getting any kind of low end accuracy with such a method is very difficult. For anechoic I use the out of doors. Measuring a speaker flat on the ground pointing up is pretty anechoic if you are in an open area. > There should be some way of incorporating this into the method- if MLSSA can > produce a frequency response then it stands to reason that it can give an > impulse response too. MLSSA is used to measure impulse responses but a long logarithmically swept sin is better for a whole lot of reasons. Bob -- "Things should be described as simply as possible, but no simpler." A. Einstein From kouhia at nic.funet.fi Thu Jan 20 13:13:26 2005 From: kouhia at nic.funet.fi (Juhana Sadeharju) Date: Sun Jan 21 12:11:10 2007 Subject: [music-dsp] Re: Upsampling my Mod-Wheel Message-ID: >From: Jeff McClintock > >I've written a soft synth. One thing it does is apply MIDI controllers >to audio. I have to smooth these controllers, i.e. upsample them to >audio rate. Untill now I've been doing so with a crude ramping >technique, but now I want to upsample 'properly'. What was the problem with the ramping? Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software From kouhia at nic.funet.fi Thu Jan 20 13:13:28 2005 From: kouhia at nic.funet.fi (Juhana Sadeharju) Date: Sun Jan 21 12:11:10 2007 Subject: [music-dsp] IEEE papers Message-ID: [ This was under "kurtosis" discussion. ] >From: "Maciej Bartkowiak" >> >> Of course, as long as people (and IEEE owners) don't make >> any difference between $$$$ and "open access", the advantages >> of "open access" cannot be seen. Very sad. > >It took a year of hard work to collect, scan and index all the publications. >Why those people should not be paid? I wonder if you did read my original posting on this topic? Apparently you forgot what it was about. Motivated by the claim of one active author here that he had not heard of MLT, I suggested that IEEE would do marvelous if they would make one of their survey publications open-access. Only **one** publication of many journals and transactions, and of thousands proceedings was suggested to be open-access. It would be win for all of us: (1) All would be able to know about latest in tech; including non-educated open source developers. (2) IEEE would possibly get more purchases because survey papers are only surveys; people would have to buy the referenced papers for details. Yes, both IEEE SP and AES have done great job in digitizing the journals and proceedings. Most of IEEE journals and confs reach back to 1988 but SP journals and confs (icassp) reach back to roots. I have gone through these publications issue by issue and have found, browsed and read many interesting papers. Now the big question is how to get the papers "usable". E.g., how to get source code which can be easily used in our software? (Working source code such as IEEE DSP programs back from 197* seem to survive through time.) The answer is a major task. I have given some IEEE and AES papers to persons in hope that it spurs something to open source community. Nothing. Giving the papers free seems to not help. Puzzling. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software From kouhia at nic.funet.fi Thu Jan 20 13:13:32 2005 From: kouhia at nic.funet.fi (Juhana Sadeharju) Date: Sun Jan 21 12:11:10 2007 Subject: [music-dsp] Re: Announce: FScape 0.65 Message-ID: >From: Allan Hoeltje > >If you run the Install-FScape-0.65.jar file the installation will prompt you >to install the developer source code in addition to the application binary. FYI, I run executables only from our system directories, not executables given by third party via website or via e-mail. I repeat my plea: If anyone has already extracted the source code files, please upload to ftp://ftp.funet.fi/incoming/audio/ as zip or tar archive. (Other formats including Mac stuffit formats would do fine.) The source codes in the pack0 and pack1 files are readable but the packs are a mess. The code seems to be GPL and thus it can be given to me without legal problems. Thanks. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software From steve at hassard.net Thu Jan 20 13:29:38 2005 From: steve at hassard.net (Stephen Hassard) Date: Sun Jan 21 12:11:10 2007 Subject: [music-dsp] Re: Announce: FScape 0.65 In-Reply-To: References: Message-ID: <41EFF892.7090208@hassard.net> .jar files are actually just regular .zip files renamed. You should be able to rename the file back and extract as usual. Juhana Sadeharju wrote: >>From: Allan Hoeltje >> >>If you run the Install-FScape-0.65.jar file the installation will prompt you >>to install the developer source code in addition to the application binary. > > > FYI, I run executables only from our system directories, not > executables given by third party via website or via e-mail. > > I repeat my plea: > > If anyone has already extracted the source code files, please > upload to > ftp://ftp.funet.fi/incoming/audio/ > as zip or tar archive. (Other formats including Mac stuffit > formats would do fine.) > > The source codes in the pack0 and pack1 files are readable > but the packs are a mess. The code seems to be GPL and thus > it can be given to me without legal problems. > > Thanks. > Juhana From lists at wildgooses.com Thu Jan 20 13:54:19 2005 From: lists at wildgooses.com (Ed Wildgoose) Date: Sun Jan 21 12:11:10 2007 Subject: [music-dsp] Echo cancellation Message-ID: <41EFFE5B.6050905@wildgooses.com> Anyone got any pointers on doing echo cancellation for a VoIP type situation? I assume that one solution is to statically generate the impulse response of system, then perhaps invert the main spike, or even the first few ms of the IR..? Can this be done dynamically during the call by continually generating an IR of the system and assuming the background noise "cancels" over time...? Any papers on this stuff, or preferably some code? Thanks Ed W From douglas at music.columbia.edu Thu Jan 20 14:15:44 2005 From: douglas at music.columbia.edu (douglas irving repetto) Date: Sun Jan 21 12:11:10 2007 Subject: [music-dsp] SHARC database In-Reply-To: <89048C13-6A8B-11D9-8C18-000D93B0BD28@san.rr.com> References: <89048C13-6A8B-11D9-8C18-000D93B0BD28@san.rr.com> Message-ID: > >After a little googling, I found a copy here: > >http://people.cs.uchicago.edu/~odonnell/Scholar/Data/sharc.tar.Z > >Perhaps this could be put in the music-dsp archive? > files can be uploaded to the musicdsp.org archive by users, but i can't quite see where you do it...bram? -- ............................................... http://artbots.org .....douglas.....irving........................ http://dorkbot.org ................................ http://ceait.calarts.edu/musicdsp .......... repetto............. http://music.columbia.edu/organism ............................... http://music.columbia.edu/~douglas From andy at a2hd.com Thu Jan 20 18:37:47 2005 From: andy at a2hd.com (Andy W. Schmeder) Date: Sun Jan 21 12:11:10 2007 Subject: [music-dsp] Echo cancellation In-Reply-To: <41EFFE5B.6050905@wildgooses.com> References: <41EFFE5B.6050905@wildgooses.com> Message-ID: <41F040CB.3010707@a2hd.com> Ed Wildgoose wrote: > Anyone got any pointers on doing echo cancellation for a VoIP type > situation? > > I assume that one solution is to statically generate the impulse > response of system, then perhaps invert the main spike, or even the > first few ms of the IR..? Can this be done dynamically during the > call by continually generating an IR of the system and assuming the > background noise "cancels" over time...? > > Any papers on this stuff, or preferably some code? Storn, R., "Echo Cancellation Techniques for Multimedia Applications - A Survey" , Technical Report TR-96-046, ICSI, November 1996 http://www.icsi.berkeley.edu/~storn/tr-96-046.ps.gz from http://www.icsi.berkeley.edu/~storn/litera.html ...and on differential evolution in general, which can be used for online filter optimization, amoung other things http://www.icsi.berkeley.edu/~storn/code.html Andy. From rbj at audioimagination.com Thu Jan 20 21:38:52 2005 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sun Jan 21 12:11:10 2007 Subject: [music-dsp] matlab doubt In-Reply-To: <3401f2f8d5.2f8d53401f@teleline.es> Message-ID: on 01/20/2005 07:52, NAYRALORENZO@telefonica.net at NAYRALORENZO@telefonica.net wrote: > I know that this is not a list from ask about Matlab, but I have a big > doubt and I can't find the way to solve, so maybe someone of you know > the answer. > Does somebody know if is a way to display the results from a function, > not in the command window, even in other display, for example, a static > text in the guide? MATLAB has an fopen(), fclose(), fread(), and fwrite() utility, similar to C, so you can put the results into a file if you want. i dunno if that is what you are looking for. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From NAYRALORENZO at telefonica.net Fri Jan 21 03:56:27 2005 From: NAYRALORENZO at telefonica.net (NAYRALORENZO@telefonica.net) Date: Sun Jan 21 12:11:11 2007 Subject: [music-dsp] matlab doubt Message-ID: I know you can use that orders to work with files, but the problem is that I can not use a file because I need to do this in real time...so if you know a way to put all the mexprintf of a dll file in other place different to the command window, please tell me. Thanks, Nayra Lorenzo ----- Mensaje Original ----- De: robert bristow-johnson Fecha: Viernes, Enero 21, 2005 3:38 am Asunto: Re: [music-dsp] matlab doubt > on 01/20/2005 07:52, NAYRALORENZO@telefonica.net at > NAYRALORENZO@telefonica.net wrote: > > > I know that this is not a list from ask about Matlab, but I have > a big > > doubt and I can't find the way to solve, so maybe someone of you > know> the answer. > > Does somebody know if is a way to display the results from a > function,> not in the command window, even in other display, for > example, a static > > text in the guide? > > MATLAB has an fopen(), fclose(), fread(), and fwrite() utility, > similar to > C, so you can put the results into a file if you want. > > i dunno if that is what you are looking for. > > -- > > r b-j rbj@audioimagination.com > > "Imagination is more important than knowledge." > > > From rbj at audioimagination.com Fri Jan 21 10:27:47 2005 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sun Jan 21 12:11:11 2007 Subject: [music-dsp] matlab doubt In-Reply-To: Message-ID: on 01/21/2005 03:56, NAYRALORENZO@telefonica.net at NAYRALORENZO@telefonica.net wrote: > the problem is > that I can not use a file because I need to do this in real time... i didn't know you could really use MATLAB in real time. can you do real-time filtering or sound processing in MATLAB? (asking from ignorance.) -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From the8bitdeity at thegsp.com Fri Jan 21 11:55:14 2005 From: the8bitdeity at thegsp.com (Robert Kukuchka) Date: Sun Jan 21 12:11:11 2007 Subject: [music-dsp] matlab doubt In-Reply-To: References: Message-ID: <38B1D794-6BCD-11D9-8E0B-000A95D5F9FC@thegsp.com> -Matlab does have a real time suite IIRC, but I have yet to learn it. ~Rob On Jan 21, 2005, at 7:27 AM, robert bristow-johnson wrote: > on 01/21/2005 03:56, NAYRALORENZO@telefonica.net at > NAYRALORENZO@telefonica.net wrote: > >> the problem is >> that I can not use a file because I need to do this in real time... > > i didn't know you could really use MATLAB in real time. can you do > real-time filtering or sound processing in MATLAB? > > (asking from ignorance.) > > -- > > 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://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > From fatboy at vodafone.net Fri Jan 21 13:34:44 2005 From: fatboy at vodafone.net (Matt Avent) Date: Sun Jan 21 12:11:11 2007 Subject: [music-dsp] matlab doubt In-Reply-To: <38B1D794-6BCD-11D9-8E0B-000A95D5F9FC@thegsp.com> Message-ID: <002901c4ffe7$e0a56340$4a512cd9@HP18053272125> Typically you'd use Simulink to provide the real-time framework for matlab functions. What sort of data are you trying to display? If it's a load of sample values there are various scope options, including 3rd party stuff. If it's more statistical then there are counters etc. Matlab itself doesn't ever run in real-time as far as I'm aware - it just runs scripts as quickly as possible... -----Original Message----- From: music-dsp-bounces@ceait.calarts.edu [mailto:music-dsp-bounces@ceait.calarts.edu] On Behalf Of Robert Kukuchka Sent: 21 January 2005 16:55 To: a list for musical digital signal processing Subject: Re: [music-dsp] matlab doubt -Matlab does have a real time suite IIRC, but I have yet to learn it. ~Rob On Jan 21, 2005, at 7:27 AM, robert bristow-johnson wrote: > on 01/21/2005 03:56, NAYRALORENZO@telefonica.net at > NAYRALORENZO@telefonica.net wrote: > >> the problem is >> that I can not use a file because I need to do this in real time... > > i didn't know you could really use MATLAB in real time. can you do > real-time filtering or sound processing in MATLAB? > > (asking from ignorance.) > > -- > > 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://shoko.calarts.edu/musicdsp > http://ceait.calarts.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://shoko.calarts.edu/musicdsp http://ceait.calarts.edu/mailman/listinfo/music-dsp From rathben at yahoo.com Fri Jan 21 14:37:42 2005 From: rathben at yahoo.com (Ben Rathke) Date: Sun Jan 21 12:11:11 2007 Subject: [music-dsp] matlab doubt In-Reply-To: Message-ID: <20050121193742.64978.qmail@web60508.mail.yahoo.com> it may be overkill, but you could write the data to the serial port --- "NAYRALORENZO@telefonica.net" wrote: > I know you can use that orders to work with files, > but the problem is > that I can not use a file because I need to do this > in real time...so if > you know a way to put all the mexprintf of a dll > file in other place > different to the command window, please tell me. > > Thanks, > Nayra Lorenzo > > ----- Mensaje Original ----- > De: robert bristow-johnson > > Fecha: Viernes, Enero 21, 2005 3:38 am > Asunto: Re: [music-dsp] matlab doubt > > > on 01/20/2005 07:52, NAYRALORENZO@telefonica.net > at > > NAYRALORENZO@telefonica.net wrote: > > > > > I know that this is not a list from ask about > Matlab, but I have > > a big > > > doubt and I can't find the way to solve, so > maybe someone of you > > know> the answer. > > > Does somebody know if is a way to display the > results from a > > function,> not in the command window, even in > other display, for > > example, a static > > > text in the guide? > > > > MATLAB has an fopen(), fclose(), fread(), and > fwrite() utility, > > similar to > > C, so you can put the results into a file if you > want. > > > > i dunno if that is what you are looking for. > > > > -- > > > > 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://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From rob.hutchins at gmail.com Fri Jan 21 15:04:24 2005 From: rob.hutchins at gmail.com (Rob Hutchins) Date: Sun Jan 21 12:11:11 2007 Subject: [music-dsp] Newbie question related to IIR filtering Message-ID: <2d69befc05012112042669fa12@mail.gmail.com> Hello list, I realize that this may be a very elementary problem, but I'm new to DSP and would very much appreciate your help. If you are given a frequency response and you know that: 1. one part of the curve can be modeled using a narrow bandpass IIR filter 2. you want to flatten that part of the curve how would you design the inverse filter? how would you achieve the desired flat response? Thanks in advance, Rob From xue.wen at elec.qmul.ac.uk Fri Jan 21 15:28:31 2005 From: xue.wen at elec.qmul.ac.uk (Wen X) Date: Sun Jan 21 12:11:11 2007 Subject: [music-dsp] Newbie question related to IIR filtering References: <2d69befc05012112042669fa12@mail.gmail.com> Message-ID: <005e01c4fff7$d7faa830$6321258a@wenpc> if this filter can be decided up to filter coefficients, there's little more to do -- simply construct the inverse filter by exchanging poles and zeros. best, ----- Original Message ----- From: "Rob Hutchins" To: Sent: Friday, January 21, 2005 8:04 PM Subject: [music-dsp] Newbie question related to IIR filtering > Hello list, > > I realize that this may be a very elementary problem, but I'm new to > DSP and would very much appreciate your help. > > If you are given a frequency response and you know that: > > 1. one part of the curve can be modeled using a narrow bandpass IIR > filter > 2. you want to flatten that part of the curve > > how would you design the inverse filter? how would you achieve the > desired flat response? > > Thanks in advance, > Rob > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp From aclark at danvillesignal.com Fri Jan 21 15:45:35 2005 From: aclark at danvillesignal.com (Al Clark) Date: Sun Jan 21 12:11:11 2007 Subject: [music-dsp] matlab doubt In-Reply-To: References: Message-ID: <6.1.0.6.0.20050121144331.026452b8@localhost> At 09:27 AM 1/21/2005, you wrote: >on 01/21/2005 03:56, NAYRALORENZO@telefonica.net at >NAYRALORENZO@telefonica.net wrote: > > > the problem is > > that I can not use a file because I need to do this in real time... > >i didn't know you could really use MATLAB in real time. can you do >real-time filtering or sound processing in MATLAB? > >(asking from ignorance.) > >-- > >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://shoko.calarts.edu/musicdsp >http://ceait.calarts.edu/mailman/listinfo/music-dsp I understand that you can interface Matlab into Analog Devices' VisualAudio. VisualAudio executes its code in realtime on a SHARC DSP. I can't say I know the details (yet). Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.com From jeffmcc at ihug.co.nz Fri Jan 21 15:47:36 2005 From: jeffmcc at ihug.co.nz (Jeff McClintock) Date: Sun Jan 21 12:11:11 2007 Subject: [music-dsp] Re: Upsampling my Mod-Wheel In-Reply-To: <20050121183532.B5360192CD86@music.calarts.edu> References: <20050121183532.B5360192CD86@music.calarts.edu> Message-ID: <41F16A68.4040100@ihug.co.nz> >>I've written a soft synth. One thing it does is apply MIDI controllers >>to audio. I have to smooth these controllers, i.e. upsample them to >>audio rate. Untill now I've been doing so with a crude ramping >>technique, but now I want to upsample 'properly'. > > > What was the problem with the ramping? Ramping is an approximation. It's linear interpolation. When we're upsampling audio, linear interpolation is considered crude. sinc interpolation is the best. My interest is in converting MIDI controllers into smooth audio-rate signals. I can already do so of course. I guess my question is really: "regardless of the cost, what's the *best* way to upsample an irregular sampled signal (in real time)". Most of the stuff I've found on the web is iterative, uses fast-fourier-transforms, and relys on knowing all the samples in advance ( they're offline methods ). Since every MIDI synth in existance has to process MIDI CCs in real time, without zipper noise, I hoped someone had an better solution. To my thinking, you can't ramp or filter very effectivly unless you can estimate the MIDI CC rate. Different devices emit MIDI CCs at different rates, I want to avoid over-smoothing, and I want to avoid under-smoothing. My best result so far is to upsample to audio rate by padding with the last-recieved sample, then low pass filtering. ( zero-padding was a failure) I figure I should adapt my filtering to the CC rate in real time, and fall back to a reasonable default smoothing when the CC's are sparse or when I haven't received enough to estimate the rate. Keith suggested using splines. My guess is splines would sound pretty good. It's just that is not a 'signal processing' solution, and dosen't satify my curiosity about the *best* solution. James said: "Am just thinking that any kind of lopass upsampling will 'delay in time' the original control values a bit, and could at least slightly mess with the exact amplitude of the control values?" I hear this all the time, the idea that you must apply the controller "right now", or else you're introducing latency to the controller. This belief is completely wrong, of course I've never been able to convince anyone, I'm guess I'm not smart enough to articulate why, but basicly: -If you apply a controller "immediatly" you're going to get zipper noise. - So you need some smoothing right? - So you must somehow fade to the new value over some time period. - So there *must* be some delay till the controller reaches the new value. You have *no* choice but to introduce some latency. So latency is enevitable, the question is how to minimise it while still smoothing "enough". Considering that controllers are a kind of sampled signal, and that upsampling is going to involve a filter (even a ramp is a crude type of low-pass filter), and that the filter can't look ahead (we're doing this in real time), then that filter must introduce a phase delay (all real time low-pass filters do). In practice the delay is equal to the controller rate (perhaps 20ms) and is such a small fraction of the controller movement that it's inaudible. The alternative is zipper noize, the controller equivalent of aliasing due to upsampling without a reconstruction filter. Maciej said: "contemporary high-end virtual analogue synths (like Access Virus B/C) do smooth their controllers in realtime. My guess is they employ some prediction scheme for the upcoming events. I would use a low-order adaptive predictor, LPC perhaps?" I hear this quite often too. If you could predict the next controller in advance, you could smooth the signal without latency. In the case of me smoothly moving my mod wheel, I'm sure you could predict most of the controllers pretty accurately. But how do you predict the first one?. Must the first sample suffer latency, but not the remainder? When the mod wheel suddenly stops or changes direction how do you prevent overshoot? I'm not happy with that. You wouldn't try to predict the next audio sample in a hi-fi system, so I'm not comfortable doing so with controllers. I'm still not satisfied I have the answer, but I much appreciate the discussion. Cheers guys! Jeff From jchandjr at bellsouth.net Fri Jan 21 17:17:28 2005 From: jchandjr at bellsouth.net (James Chandler Jr) Date: Sun Jan 21 12:11:11 2007 Subject: [music-dsp] Re: Upsampling my Mod-Wheel References: <20050121183532.B5360192CD86@music.calarts.edu> <41F16A68.4040100@ihug.co.nz> Message-ID: <05a901c50006$fe87bec0$6401a8c0@JamesCompaq3080> Hi Jeff Maybe you missed the later post by Nigel Redmon, which looked like the most elegant and simple solution. I can't see anything wrong with Nigel's suggestion. Seems ideal. He suggested to treat each new-received controller as a step event, and remember its value until the next controller is received. On each sample processing, feed this remembered step value into an IIR lowpass filter to get the next interpolated control value. Am guessing that one would select a filter time constant large enough to avoid zipper noise, but small enough not to introduce excessive controller latency. Perhaps a time constant somewhere in the 1 mS to 10 mS range? With an IIR lopass filter, it will take several time constants before the filtered control value is 'effectively the same' as the input step. Perhaps you could save some clock cycles by bypassing the filtering as soon as the filter output is 'practically identical' to the input value. However, the if..then.. decision whether or not to run the filter, might take as long as just always running the lopass filter? IIR lopass filters don't eat many cycles. A possible drawback of an IIR-- On each time constant, the filter output will travel about 63% of the difference between the input sample and the filter output. So if a controller is ramping a long distance, perhaps 0 to 127, the filter output will approach the input value in about the same time frame that it would take to ramp only from 126 to 127. Perhaps big controller jumps might make the filter output value change too fast near the beginning of the first time constant, which might zipper a bit unless the time constant is "too long"? If one used Nigel's approach with a linear interpolation ramp rather than an IIR, it could be arranged so that it takes longer to ramp longer distances. That might better avoid zipper noise on big controller changes? There are probably advantages and disadvantages with each approach. HTH JCJR From rob.hutchins at gmail.com Fri Jan 21 18:21:04 2005 From: rob.hutchins at gmail.com (Rob Hutchins) Date: Sun Jan 21 12:11:11 2007 Subject: [music-dsp] Newbie question related to IIR filtering In-Reply-To: <2d69befc050121132777bb6d52@mail.gmail.com> References: <2d69befc05012112042669fa12@mail.gmail.com> <005e01c4fff7$d7faa830$6321258a@wenpc> <2d69befc050121132777bb6d52@mail.gmail.com> Message-ID: <2d69befc0501211521196b1e9f@mail.gmail.com> Once I have the inverse filter, how do I combine the two filter responses to get the desired flat response? Do I simply add them? On Fri, 21 Jan 2005 13:27:02 -0800, Rob Hutchins wrote: > Hi Wen, > > I'm trying to do this in MathCad, and am not entirely sure as to how > to exchange poles and zeros. Could you please elaborate on that? > > Also, once I have the inverse filter, do I add the two filter > responses to get the flat response? > > Thanks, > Rob. > > On Fri, 21 Jan 2005 20:28:31 -0000, Wen X wrote: > > if this filter can be decided up to filter coefficients, there's little more > > to do -- simply construct the inverse filter by exchanging poles and zeros. > > > > best, > > ----- Original Message ----- > > From: "Rob Hutchins" > > To: > > Sent: Friday, January 21, 2005 8:04 PM > > Subject: [music-dsp] Newbie question related to IIR filtering > > > > > Hello list, > > > > > > I realize that this may be a very elementary problem, but I'm new to > > > DSP and would very much appreciate your help. > > > > > > If you are given a frequency response and you know that: > > > > > > 1. one part of the curve can be modeled using a narrow bandpass IIR > > > filter > > > 2. you want to flatten that part of the curve > > > > > > how would you design the inverse filter? how would you achieve the > > > desired flat response? > > > > > > Thanks in advance, > > > Rob > > > -- > > > dupswapdrop -- the music-dsp mailing list and website: > > > subscription info, FAQ, source code archive, list archive, book reviews, > > > dsp links > > > http://shoko.calarts.edu/musicdsp > > > http://ceait.calarts.edu/mailman/listinfo/music-dsp > > > > > From jeffmcc at ihug.co.nz Fri Jan 21 19:40:42 2005 From: jeffmcc at ihug.co.nz (Jeff McClintock) Date: Sun Jan 21 12:11:11 2007 Subject: [music-dsp] Re: Upsampling my Mod-Wheel In-Reply-To: <20050105044426.31F141897F2A@music.calarts.edu> References: <20050105044426.31F141897F2A@music.calarts.edu> Message-ID: <41F1A10A.2050205@ihug.co.nz> Hi James, > Maybe you missed the later post by Nigel Redmon, which looked like the > most elegant and simple solution.... > > He suggested to treat each new-received controller as a step event, and remember its value until the next controller is received. On each sample processing, feed this remembered step value into an IIR lowpass filter to get the next interpolated control value. Agree, I think that's the best idea so far. That's what I meant by "upsample to audio rate by padding with the last-received sample, then low pass filter" > Am guessing that one would select a filter time constant large enough to avoid zipper noise, but small enough not to introduce excessive controller latency. *thats* what I'm not entirely happy with. What exactly is the best filter setting?. The best filter cuttoff depends on the controller rate, which varies from one device to the next. That's why I suggested tracking the rate somehow, and adjusting the filter to suit. Why am I so fussy?, I'm trying to create a system that can handle quite rapid controller updates (say 1000Hz), but adapt to slower rates too (like 20Hz). A filter set for 20Hz signals will ruin the 'detail' in a high-rate controller. What's the point of using a highly responsive controller if the synth heavily filters it?, That's why I don't want a one-size-fits-all filter. > Perhaps you could save some clock cycles by bypassing the filtering as > soon as the filter output is 'practically identical' to the input value. Yep, good idea. > However, the if..then.. decision whether or not to run the filter, might take as long as just always running the lopass filter? Well, i'd check once every 100 samples, not once-per-sample. So no problem. > A possible drawback of an IIR-- On each time constant, the filter output will travel about 63% of the difference between the input sample and the filter output. So if a controller is ramping a long distance, perhaps 0 to 127, the filter output will approach the input value in about the same time frame that it would take to ramp only from 126 to 127. Perhaps big controller jumps might make the filter output value change too fast near the beginning of the first time constant, which might zipper a bit unless the time constant is "too long"? Well yes, moving the mod wheel suddenly will cause the filter to react fast. Strickly speaking, that's what a good interpolater should do. It's not really a problem, "fast" for a mod wheel is 20ms. zipper noise is in the order of 1ms or less (I'm generalising). Anyhow, my aim is to reconstruct the mod wheel as accuratly as possible, if the mod wheel moves fast, and the reconstruction is fast, I consider that success (even if that's "too fast" for the synth to handle). The question of not changing a control "too fast", I call "bandwidth limiting" the control signal. How fast is too fast depends on what you're using that controller for, so I consider that a secondary issue, at least in this discussion. If you did need to filter a controller for bandwith limiting, the choice of filter would depend on what synth parameter you are modulating. So the type of filter, and the appropriate time constant has no relation to the mod-wheel reconstruction filter. You end up with two filters... MIDI CCs--->[rate-adaptive-filter]---->[Bandwidth Limiter]--->[Parameter] Typically the adaptive filter would have a 20ms time constant, and the Bandwidth limiter a 1ms time constant. Several people have suggested I don't need two filters, just use the Bandwidth limiter. But it's 1ms time constant is far too fast to smooth a typical MIDI controller. You could combine the two into a 'smart' filter. The result would be a rate-adaptive filter with a fixed 'ceiling' rate. Cheers James! Jeff James Chandler Jr wrote: > Hi Jeff > > Maybe you missed the later post by Nigel Redmon, which looked like the most elegant and simple solution. I can't see anything wrong with Nigel's suggestion. Seems ideal. > > He suggested to treat each new-received controller as a step event, and remember its value until the next controller is received. On each sample processing, feed this remembered step value into an IIR lowpass filter to get the next interpolated control value. > > Am guessing that one would select a filter time constant large enough to avoid zipper noise, but small enough not to introduce excessive controller latency. Perhaps a time constant somewhere in the 1 mS to 10 mS range? With an IIR lopass filter, it will take several time constants before the filtered control value is 'effectively the same' as the input step. > > Perhaps you could save some clock cycles by bypassing the filtering as soon as the filter output is 'practically identical' to the input value. However, the if..then.. decision whether or not to run the filter, might take as long as just always running the lopass filter? IIR lopass filters don't eat many cycles. > > A possible drawback of an IIR-- On each time constant, the filter output will travel about 63% of the difference between the input sample and the filter output. So if a controller is ramping a long distance, perhaps 0 to 127, the filter output will approach the input value in about the same time frame that it would take to ramp only from 126 to 127. Perhaps big controller jumps might make the filter output value change too fast near the beginning of the first time constant, which might zipper a bit unless the time constant is "too long"? > > If one used Nigel's approach with a linear interpolation ramp rather than an IIR, it could be arranged so that it takes longer to ramp longer distances. That might better avoid zipper noise on big controller changes? > > There are probably advantages and disadvantages with each approach. > > HTH > > JCJR From mbartkow at et.put.poznan.pl Fri Jan 21 20:59:31 2005 From: mbartkow at et.put.poznan.pl (Maciej Bartkowiak) Date: Sun Jan 21 12:11:11 2007 Subject: [music-dsp] Re: Upsampling my Mod-Wheel References: <20050121183532.B5360192CD86@music.calarts.edu> <41F16A68.4040100@ihug.co.nz> Message-ID: <004a01c50026$04c8c170$8f15153e@chloe> Hi Jeff > I hear this quite often too. If you could predict the next controller > in advance, you could smooth the signal without latency. In the case of > me smoothly moving my mod wheel, I'm sure you could predict most of the > controllers pretty accurately. > But how do you predict the first one?. Must the first sample suffer > latency, but not the remainder? When the mod wheel suddenly stops or > changes direction how do you prevent overshoot? > > I'm not happy with that. You wouldn't try to predict the next audio > sample in a hi-fi system, so I'm not comfortable doing so with controllers. Adaptive prediction is commonly used for audio coding and reconstruction of missing samples. I think you should consider using a simple adaptive algorithm, like the classic LMS (see http://www.cs.tut.fi/~tabus/course/ASP/LectureNew5.pdf). The default position of the wheel (0) may be used as a starting point. I don't see any problem with the mod wheel suddenly stoping. In real world there is always some minor jitter that fires new values from the a/c converter. As already suggested, the problem of irregularly spaced sample values of the wheel position may be simple solved by oversampling it with 0-order extension (keeping the last value). Just feed the samples to an adaptive algorithm and it shall smooth the samples adapting to the rate and magnitude of signal changes. regards, MB From arcane at arcanemethods.com Fri Jan 21 23:51:32 2005 From: arcane at arcanemethods.com (Bob Cain) Date: Sun Jan 21 12:11:11 2007 Subject: [music-dsp] Newbie question related to IIR filtering In-Reply-To: <2d69befc0501211521196b1e9f@mail.gmail.com> References: <2d69befc05012112042669fa12@mail.gmail.com> <005e01c4fff7$d7faa830$6321258a@wenpc> <2d69befc050121132777bb6d52@mail.gmail.com> <2d69befc0501211521196b1e9f@mail.gmail.com> Message-ID: <41F1DBD4.90106@arcanemethods.com> Rob Hutchins wrote: > Once I have the inverse filter, how do I combine the two filter > responses to get the desired flat response? Do I simply add them? Cascade them. Bob -- "Things should be described as simply as possible, but no simpler." A. Einstein From eli+ at cs.cmu.edu Sat Jan 22 02:29:46 2005 From: eli+ at cs.cmu.edu (Eli Brandt) Date: Sun Jan 21 12:11:12 2007 Subject: [music-dsp] Re: Upsampling my Mod-Wheel In-Reply-To: <41F1A10A.2050205@ihug.co.nz> from "Jeff McClintock" at Jan 22, 2005 01:40:42 PM Message-ID: <20050122073018.6E48C1932879@music.calarts.edu> Jeff McClintock wrote: > I hear this all the time, the idea that you must apply the > controller "right now", or else you're introducing latency to the > controller. This belief is completely wrong, of course I've never > been able to convince anyone, I'm guess I'm not smart enough to > articulate why, but basicly: > -If you apply a controller "immediatly" you're going to get zipper noise. > - So you need some smoothing right? > - So you must somehow fade to the new value over some time period. > - So there *must* be some delay till the controller reaches the new > value. You have *no* choice but to introduce some latency. I'd slice it this way: yes, you have no choice but to introduce latency. No, this doesn't make it right! I as a user may need for the controller to be at the value I set at the time I specified. Can you make your filter linear-phase with a known delay, and then adjust everything else to match? This eliminates the skew, which is what really kills me as a user. A little bit of delay is less damaging. If you're varying the filter cutoff, so varying its length, you'd set a max length, and add extra delay to the filtered controller signal as necessary to make it line up. > That's what I meant by "upsample to audio rate by padding with the > last-received sample, then low pass filter" One thing that's nice about spline-type interpolation is that it's an (acausal) FIR filter that varies its cutoff to exactly what's necessary. The gotcha with adaptive filtering is that it has to adapt neither too early nor too late, or a discontinuity in your sample-and-hold signal will leak as crud into the output. > It's not really a problem, "fast" for a mod wheel is 20ms. zipper noise > is in the order of 1ms or less (I'm generalising). > > Anyhow, my aim is to reconstruct the mod wheel as accuratly as possible, > if the mod wheel moves fast, and the reconstruction is fast, I consider > that success (even if that's "too fast" for the synth to handle). If you know you're reconstructing the motion of a physical mod wheel, that's one thing. If you also want to handle sequenced data, consider another case: I may deliberately use controller values that step -- maybe every sixteenth note (or, for a really nasty case, stepping at 20 Hz), or maybe as the discontinuity in a sawtooth shape. The position of these steps is a rhythmic element and should not be perturbed, certainly not more than a millisecond or so. Their timbre will depend on how much smoothing your reconstructor applies. I probably want a transition faster than 20 ms, and may even like the snap from sub-millisecond transitions. I guess the DSP way of putting the situation is that the reconstruction problem is not well-defined, since the "ideal" controller signal was not necessarily band-limited before being discretized. > The question of not changing a control "too fast", I call "bandwidth > limiting" the control signal. How fast is too fast depends on what > you're using that controller for, so I consider that a secondary issue, > at least in this discussion. Okay, I forgot you said this too. Anyway, what I'd try, and I'm thinking out loud here, is: determine the maximum interval t_cmax between controller updates that you'll ever see from an underlying smooth mod-wheel motion. 1a) When successive points arrive within t_cmax, spline-interpolate. The order of your interpolation will determine how many future points you need to see -- linear interpolation, just one future point. Your maximum interpolation delay will be t_delay = order*t_cmax. 1b) When successive points (v1, t1) and (v2, t2) arrive more than t_cmax apart, we assume that the underlying continuous-time signal is not smooth. Let's figure it's stepped instead. Insert a pseudo-update at (v1, t2 - t_transition), where t_transition is some small value. (Insert more as needed for higher-order interpolation.) 2) Delay interpolated signal out to t_delay. Fix up the rest of the system's time to match. I would probably try linear interpolation first, since it simplifies case (1b), and I don't expect that slope discontinuities will usually be a big deal musically. -- Eli Brandt | eli+@cs.cmu.edu | http://www.cs.cmu.edu/~eli/ From flashinc at mail.ru Sat Jan 22 03:02:06 2005 From: flashinc at mail.ru (Alex) Date: Sun Jan 21 12:11:12 2007 Subject: [music-dsp] Old plain samples and sampling frequency. In-Reply-To: <2d69befc0501211521196b1e9f@mail.gmail.com> References: <2d69befc05012112042669fa12@mail.gmail.com> <005e01c4fff7$d7faa830$6321258a@wenpc> <2d69befc050121132777bb6d52@mail.gmail.com> <2d69befc0501211521196b1e9f@mail.gmail.com> Message-ID: <1478898234.20050122140206@mail.ru> Hi, All A somewhat tricky question... ;) I`m developing on a weird box, which has a one hardware DMA for streaming 16bit/22050Hz audio to DAC. For playing audio, we using foreign xm module player, which is able mixing up 16 software channels into one. The problem I`m expecting greater sound quality. A few years ago even my Amiga600 with 8-bit samples sounds better. We playing a classical instruments, rich of harmonics and overtones, and we get a unwanted hisses, vibrations and resounds. I know that sample interpolation techniques may help, but we can`t do that. Not enough cpu power, and I can`t rewrite mixing code, coz it not mine and coz cpu is sun sparc. I start thoughts that choosing sampling frequency for _MUSICAL_ signals (such as a piano or cello samples) is not an arbitrty number, but should be selected very carefully. Probably old Ammy has the right choosen playback/sample frequency (afaik a 15625hz*2)? Any ideas, urls? -- Sincerely yours, Alex From laurent.de.soras.m1 at club-internet.fr Sat Jan 22 04:06:07 2005 From: laurent.de.soras.m1 at club-internet.fr (Laurent de Soras [Ohm Force]) Date: Sun Jan 21 12:11:12 2007 Subject: [music-dsp] Re: Upsampling my Mod-Wheel In-Reply-To: <41F1A10A.2050205@ihug.co.nz> References: <20050105044426.31F141897F2A@music.calarts.edu> <41F1A10A.2050205@ihug.co.nz> Message-ID: <41F2177F.3090905@club-internet.fr> Jeff McClintock wrote: > > What exactly is the best filter setting?. The best filter cuttoff > depends on the controller rate, which varies from one device to the next. > That's why I suggested tracking the rate somehow, and adjusting the > filter to suit. Maybe I don't understand completely your requirements, so please correct me if I'm wrong. I would have a solution to propose: Mod source -----------------------------> LPF2 ---> Parameter | ^Cutoff | | `-> Diff ---> abs() ---> {0, 1} ---> LPF1 -' The cutoff frequency of the main source filter is modulated by the rate tracker. This rate tracker is quite simple: differentiate the signal and rectify it to turn value changes into positive peaks. Quantize this signal to 1-bit in order to get the same output level for low and high- amplitude changes; put the gate threshold on a low value. Then filter the signal at a relatively low rate to average it. You'll need a function to map LPF1 ouput to LPF2 cutoff frequency, it will depend on these filter specs and the maximum change rate accepted by the parameter. Of course, LPF2 can be anything you want: classic 1-pole LPF, linear ramp, slew limiter, etc. So when changes are rare, modulation filter BW is low. When events become compact, cutoff frequency increases to adapt to the new rate. It's not perfect because the BW adaptation has a delay too, but I think it would do the job quite well. -- Laurent de Soras | Ohm Force DSP developer & Software designer | Digital Audio Software http://ldesoras.free.fr | http://www.ohmforce.com From akbutler at tiscali.co.uk Sat Jan 22 04:21:58 2005 From: akbutler at tiscali.co.uk (a k butler) Date: Sun Jan 21 12:11:12 2007 Subject: [music-dsp] Re: Re: Upsampling my Mod-Wheel In-Reply-To: <20050122004123.8DC6A1930843@music.calarts.edu> References: <20050122004123.8DC6A1930843@music.calarts.edu> Message-ID: <6.2.0.14.0.20050122085913.02b42580@pop.tiscali.co.uk> At 00:41 22/01/05, you wrote: > >>I've written a soft synth. One thing it does is apply MIDI controllers > >>to audio. I have to smooth these controllers, i.e. upsample them to > >>audio rate. Untill now I've been doing so with a crude ramping > >>technique, but now I want to upsample 'properly'. > > > > > > What was the problem with the ramping? > >Ramping is an approximation. as the actual controller has steps, you need an approximation >It's linear interpolation. The way I handle controllers is to limit the amount of change possible per sample. So that's linear ramping, but not linear interpolation. If the controller value jumps to far, any form of interpolation is likely to leave you with glitches in the audio, it sounds better to smooth the controller just enough so you don't hear artifacts. >When we're upsampling audio, linear interpolation is considered crude. >sinc interpolation is the best. ...but you're not upsampling audio. sinc interpolation would cause a controller to overshoot, so even if it was possible without latency, there would be problems. andy butler www.mathons.com From david at olofson.net Sat Jan 22 05:00:01 2005 From: david at olofson.net (David Olofson) Date: Sun Jan 21 12:11:12 2007 Subject: [music-dsp] Old plain samples and sampling frequency. In-Reply-To: <1478898234.20050122140206@mail.ru> References: <2d69befc05012112042669fa12@mail.gmail.com> <2d69befc0501211521196b1e9f@mail.gmail.com> <1478898234.20050122140206@mail.ru> Message-ID: <200501221100.02493.david@olofson.net> On Saturday 22 January 2005 09.02, Alex wrote: [...] > I start thoughts that choosing sampling frequency for _MUSICAL_ > signals (such as a piano or cello samples) is not an arbitrty > number, but should be selected very carefully. There no "right" sample rate, except one that is sufficiently high (Nyqvist > highest frequency component in the sound), but not so close that your resampling filters or other processing starts to misbehave. If you record, edit and downsample, and still get problems when playing the sound back without resampling (ie with the DAC running at the rate of the sound), something in the chain is broken, or at least not good enough for your purposes. So, rule #1: Make sure your instrument samples are clean! They should sound perfect (give or take whatever high frequency components that don't fit with the sample rate you've selected) when played back on proper gear. Otherwise, you're screwed before you start, no matter what you do. As to resampling without interpolation and/or proper filtering; well, all you can do is make sure you never play any sounds at a pitch that causes the sample rate to land above the hardware output sample rate. Or more accurately; make sure no frequency components in the sounds you play back land above Nykvist of the hardware output sample rate. The distinction may actually be quite important in this case, since using much higher sample rates for the instruments, with brickwall filters applied, gives about the same result as coarse interpolation. Try MIP-mapping the instrument samples. Instead of one waveform per instrument, use a few, downsampled (with proper filtering!) to various rates and/or brickwall filtered at various fractions of Nyqvist. IIRC, XM allows you to implement this in the instruments ("zones" or whatever they call it), so you sholdn't have to mess with the song data. (This was rather common in Amiga modules, though the reason was that you just couldn't play back at a higher sample rate than the DMA could handle. The only ways to play higher notes was to downsample, and to avoid killing the treble of low notes, one would keep the original samples and use the downsampled versions only when the original ones didn't work.) > Probably old Ammy > has the right choosen playback/sample frequency (afaik a > 15625hz*2)? Nope, the Amiga was rather special in that it didn't select any fixed sample rate at all. Each channel had it's own sample rate (one DAC per channel; 4 of them), so no resampling was needed. It just played each sample at the sample rate you told it to. (Well, to be accurate, there *was* a fixed sample rate: the time base clock at somewhere around 3.5 MHz that drove the "period" dividers. The waveforms were essentially resampled to 3.5 MHz, although AFAIK, the "throughput" of the output DACs was nowhere near 3.5 Msamples/s. The converters were just triggered by the dividers of their respective channels, rather than by a fixed clock as it's usually done these days.) //David Olofson - Programmer, Composer, Open Source Advocate .- Audiality -----------------------------------------------. | Free/Open Source audio engine for games and multimedia. | | MIDI, modular synthesis, real time effects, scripting,... | `-----------------------------------> http://audiality.org -' --- http://olofson.net --- http://www.reologica.se --- From kouhia at nic.funet.fi Sat Jan 22 06:51:18 2005 From: kouhia at nic.funet.fi (Juhana Sadeharju) Date: Sun Jan 21 12:11:12 2007 Subject: [music-dsp] Re: Upsampling my Mod-Wheel Message-ID: The zipper problem in my Theremin comes from two sources: (1) The audio buffer, i.e., the samples processed at a time is relatively long. (2) The parameter interpolation. The source (1) seems to be more severe than (2). I too have ended up to solution where the control events are spread over the next audio buffer, at correct locations, and then interpolated. It also would help if I would have shorter dsp processing buffer size than the audio card buffer size. But if audio card skips with some buffer size, perhaps Linux cannot handle shorter dsp buffers. In any case, use of this arrangement could be usable because audio card is just external compared to processor cache memory. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software From kaleja at estarcion.com Sat Jan 22 13:55:23 2005 From: kaleja at estarcion.com (Russell Borogove) Date: Sun Jan 21 12:11:12 2007 Subject: [music-dsp] Re: Upsampling my Mod-Wheel References: <20050105044426.31F141897F2A@music.calarts.edu> <41F1A10A.2050205@ihug.co.nz> Message-ID: <000b01c500b3$f03db8d0$0601000a@jaseroque> I think it's somewhat counterproductive to apply too much sampling theory to the reconstruction of MIDI controller data. High-quality reconstruction requires certain things of the sampling side - uniform sampling rate, high-quality lowpass filter in front of the ADC, etc., which you just can't rely on in budget MIDI hardware. It's entirely possible that the controller-side logic is along the lines of: if elapsed-time-since-last-controller-message > minimum then if current-controller-value != previous-controller-value then send controller message -- in other words, it intentionally "drops samples" to save MIDI overhead. In conjunction with the heavy quantization involved in 7-bit MIDI, any concept of uniform sampling really goes out the window. Even if you did have a uniform sampling rate, using, say, 4-point spline interpolation requires two controller samples on either side of the current output time, thereby introducing two sample periods of latency. It's also possible that it's using one message rate timer on multiple MIDI controllers, i.e. the effective sample rate changes depending on how many controllers are in use. So I would be strongly inclined to decide on a figure for acceptable introduced latency, and linearly interpolate from the current output toward the latest input over that timeframe. Applying a gentle lowpass beyond that to round off the corners isn't unreasonable, but personally I wouldn't bother - a stepped slope is way less zippery than a stepped level. -Borogove From citizenchunk at gmail.com Sat Jan 22 20:06:00 2005 From: citizenchunk at gmail.com (Citizen Chunk) Date: Sun Jan 21 12:11:12 2007 Subject: [music-dsp] RMS Window Size For Compressor & General PerformanceOptimisation In-Reply-To: <9A18FCA4-6A1A-11D9-A247-0003936A8584@roughproductions.co.uk> References: <41ED871C.3070802@robinbowes.com> <003b01c4fe0a$63f587a0$32b9a8c0@BrueggemannNB> <7A81C29A-6A14-11D9-A3D9-0003936A8584@roughproductions.co.uk> <000401c4fe24$e5f14a90$32b9a8c0@BrueggemannNB> <9A18FCA4-6A1A-11D9-A247-0003936A8584@roughproductions.co.uk> Message-ID: hi Eddie. if you're looking for an appropriate windows size, i'd recommend 5ms, as that should mimic the natural averaging time of the ear. (i think i read on this list that it's 5ms-50ms, depending on frequency and age.) btw, 10ms is not "way too much." remember, the point of a compressor's sidechain is to slow things down, hence, smoothing the gain changes. otherwise, you're basically making a waveshaper. i've noticed that a lot of programmers/users tend to go way too short with time constants because they want to completely kill overshoots. this is (IMO) a bad idea, and will lead to IM distortion and a generally "squashed" sound. if you absolutely must kill overshoots, use peak detection and employ a look-ahead (a.k.a. preview) buffer. RMS detection won't catch all the peaks, but it might sound more natural to you. and if 50ms SOUNDS good, then use it. now, the implementation. even though you may be processing "chunks" of audio, it's probably still a good idea to compute the RMS recursively. to do so... tc = time constant (window in samples) ave_coef = 1 / tc (averaging coefficient) ave_of_squares = (input^2 - ave_of_squares) * ave_coef rms = sqrt( ave_of_squares ) (of course, there are ways of optimizing the root calculation, which is the expensive part.) this way, you don't need to worry about buffering the window. and i'm sure you can optimize it in a way that will jive with java. hope this helps. == chunk From citizenchunk at gmail.com Sat Jan 22 20:17:57 2005 From: citizenchunk at gmail.com (Citizen Chunk) Date: Sun Jan 21 12:11:12 2007 Subject: [music-dsp] RMS Window Size For Compressor & General PerformanceOptimisation In-Reply-To: References: <41ED871C.3070802@robinbowes.com> <003b01c4fe0a$63f587a0$32b9a8c0@BrueggemannNB> <7A81C29A-6A14-11D9-A3D9-0003936A8584@roughproductions.co.uk> <000401c4fe24$e5f14a90$32b9a8c0@BrueggemannNB> <9A18FCA4-6A1A-11D9-A247-0003936A8584@roughproductions.co.uk> Message-ID: whoops! just caught my mistake. > ave_of_squares = (input^2 - ave_of_squares) * ave_coef should read: ave_of_squares = ave_of_squares + ave_coef * (input^2 - ave_of_squares) or in java/C++... ave_of_squares += ave_coef * (input * input - ave_of_squares) ; == chunk From noama at post.tau.ac.il Sun Jan 23 02:17:19 2005 From: noama at post.tau.ac.il (Noam Amir) Date: Sun Jan 21 12:11:12 2007 Subject: [music-dsp] Matlab real-time In-Reply-To: <20050122004123.8DC6A1930843@music.calarts.edu> References: <20050122004123.8DC6A1930843@music.calarts.edu> Message-ID: hi all, Matlab can do "semi realtime" easily. by "semi" i mean that you can't control latency very much, and the capabilities are very much dependent on your computer. but for many cute applications that's enough. what you need is the "Data Acquisition Toolbox". it has several demos that come with it, such as a software scope and a real time frequency analyzer. these are GUI front ends for the toolbox. if you look inside them you can see the buffering mechanisms etc. writing this stuff yourself is a hassle, but you can build on top of them. i took the frequency analyzer and added a pitch detection routine, so now i can use it as a guitar tuner, for example. works fine. later, noam. From rbj at audioimagination.com Sun Jan 23 10:27:49 2005 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sun Jan 21 12:11:12 2007 Subject: [music-dsp] Matlab real-time In-Reply-To: Message-ID: hi Moam, it's good to see you here in this mailing list. i would *still* like to see you publish *something* about Lent's algorithm for formant-corrected pitch shifting. i think that some of your ideas about it deserve discussion. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From rbj at audioimagination.com Sun Jan 23 15:50:30 2005 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sun Jan 21 12:11:13 2007 Subject: [music-dsp] Matlab real-time In-Reply-To: Message-ID: apologies, Noam, for misspelling your name. i hate when people do that to me (usually "bristoL-johnsTon"). nothing intended. just a screw-up. on 01/23/2005 10:27, robert bristow-johnson at rbj@audioimagination.com wrote: > > hi Moam, errr, that's Noam. > > it's good to see you here in this mailing list. i would *still* like to see > you publish *something* about Lent's algorithm for formant-corrected pitch > shifting. i think that some of your ideas about it deserve discussion. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From jeffmcc at ihug.co.nz Sun Jan 23 16:57:41 2005 From: jeffmcc at ihug.co.nz (Jeff McClintock) Date: Sun Jan 21 12:11:13 2007 Subject: [music-dsp] Re: Upsampling my Mod-Wheel In-Reply-To: <20050122185604.D92611935A4C@music.calarts.edu> References: <20050122185604.D92611935A4C@music.calarts.edu> Message-ID: <41F41DD5.7030706@ihug.co.nz> Thanks for th ideas everyone, I'll put together a web page comparing some of the different approaches. Cheers, Jeff From douglas at music.columbia.edu Sun Jan 23 17:32:39 2005 From: douglas at music.columbia.edu (douglas irving repetto) Date: Sun Jan 21 12:11:13 2007 Subject: [music-dsp] Re: Upsampling my Mod-Wheel In-Reply-To: <41F41DD5.7030706@ihug.co.nz> References: <20050122185604.D92611935A4C@music.calarts.edu> <41F41DD5.7030706@ihug.co.nz> Message-ID: you could add the upsampling question to the music-dsp FAQs page: http://www.musicdsp.org/phpWiki/index.php/MusicDspFaqs douglas >Thanks for th ideas everyone, > >I'll put together a web page comparing some of the different approaches. > >Cheers, >Jeff > >-- >dupswapdrop -- the music-dsp mailing list and website: subscription >info, FAQ, source code archive, list archive, book reviews, dsp >links http://shoko.calarts.edu/musicdsp >http://ceait.calarts.edu/mailman/listinfo/music-dsp -- ............................................... http://artbots.org .....douglas.....irving........................ http://dorkbot.org ................................ http://ceait.calarts.edu/musicdsp .......... repetto............. http://music.columbia.edu/organism ............................... http://music.columbia.edu/~douglas From earlevel at earlevel.com Sun Jan 23 19:13:54 2005 From: earlevel at earlevel.com (Nigel Redmon) Date: Sun Jan 21 12:11:13 2007 Subject: [music-dsp] Re: Upsampling my Mod-Wheel In-Reply-To: <41F41DD5.7030706@ihug.co.nz> References: <20050122185604.D92611935A4C@music.calarts.edu> <41F41DD5.7030706@ihug.co.nz> Message-ID: I'll add one more controller smoothing idea, which may be helpful in certain cases. Sometimes you may have the possibility of large steps in the controller that can cause clicks in the audio if you let them go through unsmoothed (for amplitude steps, for instance), yet you want as little smoothing as possible in avoiding the click. You could try one of Eli Brandt's minBLEPs (minimum phase bandlimited step). On Jan 23, 2005, at 1:57 PM, Jeff McClintock wrote: > Thanks for th ideas everyone, > > I'll put together a web page comparing some of the different > approaches. > > Cheers, > Jeff From rob.hutchins at gmail.com Sun Jan 23 21:06:12 2005 From: rob.hutchins at gmail.com (Rob Hutchins) Date: Sun Jan 21 12:11:13 2007 Subject: [music-dsp] Newbie question related to IIR filtering In-Reply-To: <005e01c4fff7$d7faa830$6321258a@wenpc> References: <2d69befc05012112042669fa12@mail.gmail.com> <005e01c4fff7$d7faa830$6321258a@wenpc> Message-ID: <2d69befc05012318064cc5c755@mail.gmail.com> The original response is given as part of a spec sheet and I am to construct the inverse filter to flatten the response. How do I obtain the filter coefficients? Thanks, Rob. On Fri, 21 Jan 2005 20:28:31 -0000, Wen X wrote: > if this filter can be decided up to filter coefficients, there's little more > to do -- simply construct the inverse filter by exchanging poles and zeros. > > best, > ----- Original Message ----- > From: "Rob Hutchins" > To: > Sent: Friday, January 21, 2005 8:04 PM > Subject: [music-dsp] Newbie question related to IIR filtering > > > Hello list, > > > > I realize that this may be a very elementary problem, but I'm new to > > DSP and would very much appreciate your help. > > > > If you are given a frequency response and you know that: > > > > 1. one part of the curve can be modeled using a narrow bandpass IIR > > filter > > 2. you want to flatten that part of the curve > > > > how would you design the inverse filter? how would you achieve the > > desired flat response? > > > > Thanks in advance, > > Rob > > -- > > dupswapdrop -- the music-dsp mailing list and website: > > subscription info, FAQ, source code archive, list archive, book reviews, > > dsp links > > http://shoko.calarts.edu/musicdsp > > http://ceait.calarts.edu/mailman/listinfo/music-dsp > > From kouhia at nic.funet.fi Mon Jan 24 01:13:31 2005 From: kouhia at nic.funet.fi (Juhana Sadeharju) Date: Sun Jan 21 12:11:13 2007 Subject: [music-dsp] Re: Announce: FScape 0.65 Message-ID: >From: Stephen Hassard > >.jar files are actually just regular .zip files renamed. You should be >able to rename the file back and extract as usual. Yes, Install-FScape-0.65.jar is a zip file, but not the mentioned pack0 and pack1 files. Author of FScape could give the source codes without that kind of extra packing. The packing is apparently unpacked with the izpack which is provided as executable only. Such executables are a security risk: izpack/util/HostAddressValidator.class izpack/installer/WebAccessor$MyDialogAuthenticator.class izpack/installer/WebAccessor.class What izpack does with the above classes? Even a single contact to the web without my permission is already a security violation in my standards. So, anyone has the source code unpacked and could provide it to me? Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software From rob.hutchins at gmail.com Mon Jan 24 01:23:53 2005 From: rob.hutchins at gmail.com (Rob Hutchins) Date: Sun Jan 21 12:11:13 2007 Subject: [music-dsp] Rephrasing my question on IIR filtering In-Reply-To: <2d69befc05012112042669fa12@mail.gmail.com> References: <2d69befc05012112042669fa12@mail.gmail.com> Message-ID: <2d69befc0501232223310b0184@mail.gmail.com> Hello list (again), I don't think I phrased my previous question properly, and may not have communicated what I have a problem with. My main problem is getting started on the inverse filtering. I've studied the basic IIR design technques - Impulse Invariance and Bilinear Transformation. For what I want to do, however, I don't start out given anything other than a response, a part of which can be modeled by a narrow bandpass IIR filter. I then need to flatten that part out using an inverse filter. Given the response, what would be the best way of designing an IIR filter to model the curve and its inverse filter? Thanks, Rob From rob.hutchins at gmail.com Mon Jan 24 01:26:24 2005 From: rob.hutchins at gmail.com (Rob Hutchins) Date: Sun Jan 21 12:11:13 2007 Subject: [music-dsp] Rephrasing my question on IIR filtering Message-ID: <2d69befc05012322267ba14ca9@mail.gmail.com> (I'm sorry if this is a duplicate... there appeared to be a problem in sending the original post) Hello list (again), I don't think I phrased my previous question properly, and may not have communicated what I have a problem with. My main problem is getting started on the inverse filtering. I've studied the basic IIR design technques - Impulse Invariance and Bilinear Transformation. For what I want to do, however, I don't start out given anything other than a response, a part of which can be modeled by a narrow bandpass IIR filter. I then need to flatten that part out using an inverse filter. Given the response, what would be the best way of designing an IIR filter to model the curve and its inverse filter? Thanks, Rob From deepak_pict at yahoo.co.in Mon Jan 24 03:32:15 2005 From: deepak_pict at yahoo.co.in (Deepak Iyer) Date: Sun Jan 21 12:11:13 2007 Subject: [music-dsp] Help in MATLAB GUIDE needed Message-ID: <20050124083215.68237.qmail@web8406.mail.in.yahoo.com> hi, i recently dloaded the code for an application in MATLAB. among the files i dloaded, i got a .m file of the GUI of tht application (containing the callback routines). but to run it, a .fig file is needed which was not present. cud i create a .fig file from the .m file or is there any way by which i cud get the application running without the .fig file. Thanx, Deepak ________________________________________________________________________ Yahoo! India Matrimony: Find your life partner online Go to: http://yahoo.shaadi.com/india-matrimony From eli+ at cs.cmu.edu Mon Jan 24 03:45:46 2005 From: eli+ at cs.cmu.edu (Eli Brandt) Date: Sun Jan 21 12:11:13 2007 Subject: [music-dsp] Re: Upsampling my Mod-Wheel In-Reply-To: from "Nigel Redmon" at Jan 23, 2005 04:13:54 PM Message-ID: <20050124084634.CD73419412C0@music.calarts.edu> Nigel Redmon wrote: > I'll add one more controller smoothing idea, which may be helpful in > certain cases. Sometimes you may have the possibility of large steps in > the controller that can cause clicks in the audio if you let them go > through unsmoothed (for amplitude steps, for instance), yet you want as > little smoothing as possible in avoiding the click. You could try one > of Eli Brandt's minBLEPs (minimum phase bandlimited step). I figure a minBLEP would be the best thing to use when you do want a click, a very nice click of ideally-shaped spectrum, running all the way up to 20 kHz and cutting off sharply there. :) For avoiding a click, yeah, you could use a lower-cutoff minBLEP, but the sharp-cutoff property that comes from the sinc is maybe not so important, and translates into time-domain ringing that may be ugly. Maybe do the step as an integrated window function? Decent time/frequency properties, and lets you maintain monotonicity. -- Eli Brandt | eli+@cs.cmu.edu | http://www.cs.cmu.edu/~eli/ From bos3 at chello.nl Mon Jan 24 03:50:31 2005 From: bos3 at chello.nl (bos3@chello.nl) Date: Sun Jan 21 12:11:13 2007 Subject: [music-dsp] (slightly OT) Two VST hosting q's Message-ID: <20050124085031.QSHR14848.amsfep17-int.chello.nl@localhost> Hi all.. I have two questions that aren't exactly about DSP, but I suspect this is the place where a lot of people hang out that may be able to help me out.. I'm the author of HammerHead and Tuareg (Tu2) and I'm working on a new project which features VST hosting. I have most of the hosting tricks figured out but there are two things that I need some help with: 1. When using a knob/button on some VSTi all processes on the host- app (including audio I/O) are suspended until I release the mousebutton. I know this shouldn't happen because I've seen these plugs in other hosts. I'm throwing lots of "idles" and "editidles" at the plugin but obviously I'm forgetting something important here. 2. Some plugins have edit-windows that can switch between a compact view and an extended edit-view. When I query them for the size of the editwindow I only get the extended windowsize. How can I support these are multiple size edit-windows? I hope someone can point me in the right direction for these two issues.. Thanks in advance! Bram Bos ---------------------------------------------- Amsterdam, The Netherlands http://www.brambos.com From fev at ckmedia.pl Mon Jan 24 06:36:24 2005 From: fev at ckmedia.pl (Bartlomiej Bazior) Date: Sun Jan 21 12:11:13 2007 Subject: [music-dsp] (slightly OT) Two VST hosting q's In-Reply-To: <20050124085031.QSHR14848.amsfep17-int.chello.nl@localhost> References: <20050124085031.QSHR14848.amsfep17-int.chello.nl@localhost> Message-ID: <41F4DDB8.9010003@ckmedia.pl> bos3@chello.nl : > 1. When using a knob/button on some VSTi all processes on the host- > app (including audio I/O) are suspended until I release the mousebutton. > I know this shouldn't happen because I've seen these plugs in other > hosts. I'm throwing lots of "idles" and "editidles" at the plugin but > obviously I'm forgetting something important here. > Do you run plugin GUI and audio in the separate threads? cheers, Bart From bos3 at chello.nl Mon Jan 24 07:14:38 2005 From: bos3 at chello.nl (bos3@chello.nl) Date: Sun Jan 21 12:11:13 2007 Subject: [music-dsp] (slightly OT) Two VST hosting q's Message-ID: <20050124121438.YTEC14848.amsfep17-int.chello.nl@localhost> Hi Bart, > > 1. When using a knob/button on some VSTi all processes on the host- > > app (including audio I/O) are suspended until I release the mousebutton. > > I know this shouldn't happen because I've seen these plugs in other > > hosts. I'm throwing lots of "idles" and "editidles" at the plugin but > > obviously I'm forgetting something important here. > > Do you run plugin GUI and audio in the separate threads? Yes, I run them in separate threads and 50% of the plugins don't have this problem anyway. But apparently I need to implement something a little differently because I've seen these plugins (e.g. reFX and LinPlug plugins) work alright in other hosts. Thanks for the input! cheers, Bram ---------------------------------------------- Amsterdam, The Netherlands http://www.brambos.com From fev at ckmedia.pl Mon Jan 24 08:46:12 2005 From: fev at ckmedia.pl (Bartlomiej Bazior) Date: Sun Jan 21 12:11:13 2007 Subject: [music-dsp] (slightly OT) Two VST hosting q's In-Reply-To: <20050124121438.YTEC14848.amsfep17-int.chello.nl@localhost> References: <20050124121438.YTEC14848.amsfep17-int.chello.nl@localhost> Message-ID: <41F4FC24.1060101@ckmedia.pl> bos3@chello.nl : > Yes, I run them in separate threads and 50% of the plugins don't have this > problem anyway. But apparently I need to implement something a little > differently because I've seen these plugins (e.g. reFX and LinPlug plugins) > work alright in other hosts. > Well I'm no expert in this matter since I've dealt only with a plugin side of vst(i), but something tells me that this is propably the case with plugins wich use vstgui, right? In most hosts I know tweaking knobs in plugins which use vstgui causes other visible vst editors to freeze (although only gui freezes - there's nothing wrong with audio output). Maybe you should look at vstgui code to get an idea of what you might need to implement? Alternately you can visit www.tobybear.de where you can find a source code of delphi vst(i) host class which was used by tobybear in his minihost. Maybe you can find some useful hints in his code? cheers, Bart From jon.guerin at gmail.com Mon Jan 24 09:48:38 2005 From: jon.guerin at gmail.com (jon guerin) Date: Sun Jan 21 12:11:14 2007 Subject: [music-dsp] Rephrasing my question on IIR filtering In-Reply-To: <2d69befc05012322267ba14ca9@mail.gmail.com> References: <2d69befc05012322267ba14ca9@mail.gmail.com> Message-ID: The sun hasn't risen yet and I haven't had my tea, so take this as a general overview-howto. I'm pretty sure the idea is correct, but you'll have to do some fuddling on your own with matlab to get it to work. This is a fun way of doing it if you have matlab and like to look at graphs and stuff: If you're trying to lower the amplitude of a peak, your filter would be some form of a notch. The filter might have the form Hinv(z) = k * Hi(z) * Hi(z*) where Hi(z) = (1 - zo / z) / (1 - zp / z). zo is the zero location and zp is the pole location, k is the gain to bring your filter to a reasonable level. zo and zp have the form a*e^jwc and b*e^jwc, where wc is the cutoff frequency or the frequency of the bandpass in your first filter. If you look at the z-plane pole/zero plot, you'll see that the pole and zero are on the radius of the unit circle, both at an angle of wc radians. Fiddling with a and b will change the distance of the pole and zero to the unit circle, which has the effect of increasing or decreasing the width of the notch. If you can use matlab, look into using the tfdata, zpk, and zpk2tf functions, they're really handy for this kind of thing. Find the a and b that makes you happy, then find a k to bring some flat part of your response (w = 0 or pi?) back to 0db. Now the fun part. Hinv(z) = Y(z) / X(z). Y(z) * denominator(Hinv(z)) = X(z) * numerator(Hinv(z)). (inverse z-transform magic leaves you with the difference equation). y[n] = b0 * x[n] + b1 * x[n-1] + b2 * x[n-2] - a1 * y[n-1] - a2 * y[n-2]... Tada! Implement that using the method of your choice and filter the data coming out of your first filter and (hopefully) it will be what you are looking for. Now the boring way: If you have the impulse response of the original filter, or a truncated version of it, take the z-transform of it (H(z)) and find all of the zeros. Using matlab you could use the tf function to create a filter system from h[n] and use tf2zpk to find the zeros if you're curious. Now, invert it (Hinv(z) = 1/H(z)). Proceed from equations as above. The tfdata function might be helpful for you to obtain the recursive filter's coefficients. Again, filter the output from the first filter. I don't know if either of these two methods work. Also, I've never really done any _real_ work with filters before - your mileage may vary. I'm mostly typing this up to jog my memory and prove to myself that those classes were worth the money =). I'm not sure what kind of gotchas may show up from doing it these ways, or if there are any other better, "correct", ways of doing this. I'd be interested to hear other methods. Hope it helped. -jguerin On Sun, 23 Jan 2005 22:26:24 -0800, Rob Hutchins wrote: > (I'm sorry if this is a duplicate... there appeared to be a problem in > sending the original post) > > Hello list (again), > > I don't think I phrased my previous question properly, and may not > have communicated what I have a problem with. > > My main problem is getting started on the inverse filtering. I've > studied the basic IIR design technques - Impulse Invariance and > Bilinear Transformation. > > For what I want to do, however, I don't start out given anything other > than a response, a part of which can be modeled by a narrow bandpass > IIR filter. I then need to flatten that part out using an inverse > filter. > > Given the response, what would be the best way of designing an IIR > filter to model the curve and its inverse filter? > > Thanks, > Rob > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > From yaakov_s at rad.com Mon Jan 24 11:31:21 2005 From: yaakov_s at rad.com (Yaakov Stein) Date: Sun Jan 21 12:11:14 2007 Subject: [music-dsp] Echo cancellation Message-ID: <27A0F290348F8E45AEF79889DDE65A5203B55515@exrad2.ad.rad.co.il> > Anyone got any pointers on doing echo cancellation for a VoIP > type situation? Are you interested in "line echo cancellation" (using a 2-wire phone) or "acoustic echo cancellation" ? Jonathan (Y) Stein From lists at silverblade.co.uk Mon Jan 24 12:36:28 2005 From: lists at silverblade.co.uk (Andrew "Silver Blade" Greenwood) Date: Sun Jan 21 12:11:14 2007 Subject: [music-dsp] Binaural panning question Message-ID: <41F5321C.8000809@silverblade.co.uk> Does anyone know how binaural auto-panning is actually achieved? I use this function (aka Brainwave Synchronizer) in Cool Edit 2000 and it appears to be different to the alternative "binaural" sound processing (where you have 2 tones, one a few hz higher than the other, one in each ear.) I'm wondering if it'd be possible to somehow "fake" this kind of effect so that it can be applied as an effect over some music, inside Reason for example. I thought of maybe panning each channel at a different speed, but that's wrong I think. How would I go about creating such an effect using Reason? If it's possible, of course... I just want to get it all done in one program rather than having to rely on a separate editor :) From earlevel at earlevel.com Mon Jan 24 13:12:39 2005 From: earlevel at earlevel.com (Nigel Redmon) Date: Sun Jan 21 12:11:14 2007 Subject: [music-dsp] Re: Upsampling my Mod-Wheel In-Reply-To: <20050124084634.CD73419412C0@music.calarts.edu> References: <20050124084634.CD73419412C0@music.calarts.edu> Message-ID: <8826FF42-6E33-11D9-B8BA-000A959AF1E4@earlevel.com> Well, yes.. I was going to say "pop" but for some reason changed it to click... I meant more that you would use that as the maximum speed change if you wanted to gate something on "instantly"--0 ms attack times tend to make a nasty pop, and I figured that a minBLEP would be better, though I haven't experimented with that in particular. On Jan 24, 2005, at 12:45 AM, Eli Brandt wrote: > Nigel Redmon wrote: >> I'll add one more controller smoothing idea, which may be helpful in >> certain cases. Sometimes you may have the possibility of large steps >> in >> the controller that can cause clicks in the audio if you let them go >> through unsmoothed (for amplitude steps, for instance), yet you want >> as >> little smoothing as possible in avoiding the click. You could try one >> of Eli Brandt's minBLEPs (minimum phase bandlimited step). > > I figure a minBLEP would be the best thing to use when you do want a > click, a very nice click of ideally-shaped spectrum, running all the > way up to 20 kHz and cutting off sharply there. :) > > For avoiding a click, yeah, you could use a lower-cutoff minBLEP, but > the sharp-cutoff property that comes from the sinc is maybe not so > important, and translates into time-domain ringing that may be ugly. > Maybe do the step as an integrated window function? Decent > time/frequency properties, and lets you maintain monotonicity. > > -- > Eli Brandt | eli+@cs.cmu.edu | http://www.cs.cmu.edu/~eli/ > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book > reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > From A.S.Basi at warwick.ac.uk Mon Jan 24 14:06:40 2005 From: A.S.Basi at warwick.ac.uk (Amarpreet Basi) Date: Sun Jan 21 12:11:14 2007 Subject: [music-dsp] Root Mean Square Normalisation Message-ID: ok, i understand. i think its fair to say i've been doing it all wrong, i've done some reading around the subject and must shamefully admit i wasn't using a moving window approach. i was just breaking the signal into disjoint chunks (441 samples to a chunk) and then computing the RMS for each chunk. thanks very much for your explanation. i'll have another go at it and let you know how i get on. >>> Citizen Chunk 01/14/05 23:17 PM >>> the reason that you are getting distortion is because you are clipping the output level. as you may know, the RMS is the AVERAGE POWER, and usually lies about 10-20dB below the peak value in musical signals. therefore, if you are normallizing RMS values, you are overshooting 0dB by about 10-20dB. (clipping produces nasty harmonic distortion--that's a recipe for horrible sound.) now, if you were to follow the normallizer with a peak limiter or saturator, it would help to prevent (or lessen) the distortion. a saturator is basically a waveshaper (an input-to-output transform) that gracefully eases the output signal up to a certain threshold, so as not to just clip it. a limiter (hard or soft refers to the linearity of the "knee") does this dynamically, applying gradual gain changes to level that exceed the threshold. also... you haven't mentioned anything about your RMS window size. this will affect everything. == chunk On Fri, 14 Jan 2005 07:41:04 -0000, Ulrich Brueggemann wrote: > I don't know if I fully understand your problem. > But you do the RMS in blocks. > IMO you should calculate the RMS with a moving windows of size N over all > sampled data. > See dspguide chapter 2 from www.dspguide.com > > Uli > ----- Original Message ----- > From: "Amarpreet Basi" > To: > Sent: Thursday, January 13, 2005 6:08 PM > Subject: [music-dsp] Root Mean Square Normalisation > > This was my understanding on how to do it. (But of course didn't work, hence > my post)... > > Segment the signal sample into blocks, so that we have N blocks per second > (in my configuration I have N=100). > > Then for every block, compute the root mean square of the samples in that > block (so each block will be a measure of instantaneous RMS power). > > Next step: for every K blocks, compute the average. > > Finally of all the averages computed, pick the maximum. This value should be > a near enough estimate of the sustained RMS power for the entire signal. > > Now all that remains to be done is to apply the gain to the signal (I > think). This part, which should be trivial, is giving me some bother. My > implementation of the above algorithm seems to be correct; when I compare > the RMS values recorded by SoundForge with my own app, they are about 1-5% > different. > > Do I take the ratio of the highest peak in the signal to the sustained RMS > power and apply this to the entire signal? For whatever reason, the > resulting signal is never nothing like what happens in SoundForge when you > apply RMS Normalisation with the saturate-on-clipping option. In SoundForge, > the signal is just very loud whilst in mine it distorts and produces a > horrible noise in the speakers. Anything obvious that I am doing wrong? > > Also, what is the difference between hard-limiting, soft-limiting and > saturation? > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp > links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://shoko.calarts.edu/musicdsp http://ceait.calarts.edu/mailman/listinfo/music-dsp From A.S.Basi at warwick.ac.uk Mon Jan 24 14:26:38 2005 From: A.S.Basi at warwick.ac.uk (Amarpreet Basi) Date: Sun Jan 21 12:11:14 2007 Subject: [music-dsp] Real Time Tempo & Synchronising Issues Message-ID: I'm developing a simple drum machine sequencer in Visual C++. I am using a quite crude "clock" for triggering the sounds. If the beat is to be played at N bpm, and I want a clock pulse at every sixteenth division of a musical bar, I calculate the time lapse in milliseconds between each division and set a timer of that value. E.g. 1 bar at 80 bpm lapses in 3 seconds, meaning (if I've done my arithmetic correctly) that every 1/16th of bar occurs every 187.5 millseconds. So I set a timer to 187.5 ms and whenever 187.5 ms lapses I play the sounds. However this is not working out - for a start the tempo that plays is actually 68 (ish) bpm (in the case when I set it to 80 bpm). And when the application window is moved or resized, the tempo actually starts to fluctuate as the sounds are being played. I want to achieve the same rigid synchronicity that commercial sequencer applications have. I know I'm doing it all so horribly wrong, and right now I'm at a loss at what the next step should be. Would I have to interact with my system's soundcard and get access to some hardware clock? I hope not, because up till now I've been doing the sound playback on a "high level" ; making calls to an API called FMOD (with elegant functions like e.g. PlaySound (channel, sample) that abstract away from all that horrid low level detail ;) ). Any help at all would be appreciated. From jchandjr at bellsouth.net Mon Jan 24 15:50:37 2005 From: jchandjr at bellsouth.net (James Chandler Jr) Date: Sun Jan 21 12:11:14 2007 Subject: [music-dsp] Real Time Tempo & Synchronising Issues References: Message-ID: <080701c50256$5bd47360$6401a8c0@JamesCompaq3080> Hi Amarpreet Are you triggering MIDI sounds in an external MIDI synth, or are you generating the audio inside your program and piping it out the soundcard WAVE output? If triggering MIDI sounds, a Timer (or realtime timetracker of some kind) is probably the right avenue. But if generating your own audio, perhaps deriving the timebase from the audio playback position would be more productive? IOW, every time your wave render process gets called, the render process can easily calc the time position represented by the sample position of the current wave buffer? The sound card's wave playback rate (44.1 K samples per second or whatever) will determine the rate at which buffers are 'pulled' out of your wave render process? JCJR ----- Original Message ----- From: "Amarpreet Basi" To: Sent: Monday, January 24, 2005 2:26 PM Subject: [music-dsp] Real Time Tempo & Synchronising Issues I'm developing a simple drum machine sequencer in Visual C++. I am using a quite crude "clock" for triggering the sounds. If the beat is to be played at N bpm, and I want a clock pulse at every sixteenth division of a musical bar, I calculate the time lapse in milliseconds between each division and set a timer of that value. E.g. 1 bar at 80 bpm lapses in 3 seconds, meaning (if I've done my arithmetic correctly) that every 1/16th of bar occurs every 187.5 millseconds. So I set a timer to 187.5 ms and whenever 187.5 ms lapses I play the sounds. However this is not working out - for a start the tempo that plays is actually 68 (ish) bpm (in the case when I set it to 80 bpm). And when the application window is moved or resized, the tempo actually starts to fluctuate as the sounds are being played. I want to achieve the same rigid synchronicity that commercial sequencer applications have. I know I'm doing it all so horribly wrong, and right now I'm at a loss at what the next step should be. Would I have to interact with my system's soundcard and get access to some hardware clock? I hope not, because up till now I've been doing the sound playback on a "high level" ; making calls to an API called FMOD (with elegant functions like e.g. PlaySound (channel, sample) that abstract away from all that horrid low level detail ;) ). Any help at all would be appreciated. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://shoko.calarts.edu/musicdsp http://ceait.calarts.edu/mailman/listinfo/music-dsp From uli.brueggemann at freenet.de Mon Jan 24 16:37:11 2005 From: uli.brueggemann at freenet.de (Ulrich Brueggemann) Date: Sun Jan 21 12:11:14 2007 Subject: [music-dsp] Root Mean Square Normalisation References: Message-ID: <000b01c5025c$dd8d9f20$65b9a8c0@BrueggemannNB> Thant's what I meant :-) Uli ----- Original Message ----- From: "Amarpreet Basi" To: Sent: Monday, January 24, 2005 7:06 PM Subject: Re: [music-dsp] Root Mean Square Normalisation ok, i understand. i think its fair to say i've been doing it all wrong, i've done some reading around the subject and must shamefully admit i wasn't using a moving window approach. i was just breaking the signal into disjoint chunks (441 samples to a chunk) and then computing the RMS for each chunk. thanks very much for your explanation. i'll have another go at it and let you know how i get on. >>> Citizen Chunk 01/14/05 23:17 PM >>> the reason that you are getting distortion is because you are clipping the output level. as you may know, the RMS is the AVERAGE POWER, and usually lies about 10-20dB below the peak value in musical signals. therefore, if you are normallizing RMS values, you are overshooting 0dB by about 10-20dB. (clipping produces nasty harmonic distortion--that's a recipe for horrible sound.) now, if you were to follow the normallizer with a peak limiter or saturator, it would help to prevent (or lessen) the distortion. a saturator is basically a waveshaper (an input-to-output transform) that gracefully eases the output signal up to a certain threshold, so as not to just clip it. a limiter (hard or soft refers to the linearity of the "knee") does this dynamically, applying gradual gain changes to level that exceed the threshold. also... you haven't mentioned anything about your RMS window size. this will affect everything. == chunk On Fri, 14 Jan 2005 07:41:04 -0000, Ulrich Brueggemann wrote: > I don't know if I fully understand your problem. > But you do the RMS in blocks. > IMO you should calculate the RMS with a moving windows of size N over all > sampled data. > See dspguide chapter 2 from www.dspguide.com > > Uli > ----- Original Message ----- > From: "Amarpreet Basi" > To: > Sent: Thursday, January 13, 2005 6:08 PM > Subject: [music-dsp] Root Mean Square Normalisation > > This was my understanding on how to do it. (But of course didn't work, > hence > my post)... > > Segment the signal sample into blocks, so that we have N blocks per second > (in my configuration I have N=100). > > Then for every block, compute the root mean square of the samples in that > block (so each block will be a measure of instantaneous RMS power). > > Next step: for every K blocks, compute the average. > > Finally of all the averages computed, pick the maximum. This value should > be > a near enough estimate of the sustained RMS power for the entire signal. > > Now all that remains to be done is to apply the gain to the signal (I > think). This part, which should be trivial, is giving me some bother. My > implementation of the above algorithm seems to be correct; when I compare > the RMS values recorded by SoundForge with my own app, they are about 1-5% > different. > > Do I take the ratio of the highest peak in the signal to the sustained RMS > power and apply this to the entire signal? For whatever reason, the > resulting signal is never nothing like what happens in SoundForge when you > apply RMS Normalisation with the saturate-on-clipping option. In > SoundForge, > the signal is just very loud whilst in mine it distorts and produces a > horrible noise in the speakers. Anything obvious that I am doing wrong? > > Also, what is the difference between hard-limiting, soft-limiting and > saturation? > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp > links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://shoko.calarts.edu/musicdsp http://ceait.calarts.edu/mailman/listinfo/music-dsp -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://shoko.calarts.edu/musicdsp http://ceait.calarts.edu/mailman/listinfo/music-dsp From jimw at pobox.com Mon Jan 24 17:13:25 2005 From: jimw at pobox.com (Jim Wintermyre) Date: Sun Jan 21 12:11:14 2007 Subject: [music-dsp] (slightly OT) Two VST hosting q's In-Reply-To: <20050124085031.QSHR14848.amsfep17-int.chello.nl@localhost> References: <20050124085031.QSHR14848.amsfep17-int.chello.nl@localhost> Message-ID: >Hi all.. > >I have two questions that aren't exactly about DSP, but I suspect this >is the place where a lot of people hang out that may be able to help >me out.. > >I'm the author of HammerHead and Tuareg (Tu2) and I'm working on >a new project which features VST hosting. I have most of the hosting >tricks figured out but there are two things that I need some help with: > >1. When using a knob/button on some VSTi all processes on the host- >app (including audio I/O) are suspended until I release the mousebutton. >I know this shouldn't happen because I've seen these plugs in other >hosts. I'm throwing lots of "idles" and "editidles" at the plugin but >obviously I'm forgetting something important here. Are you handling the audioMasterIdle *host* callback? At least on the Mac this is generally called during mouse tracking so that the host can have time to update its UI during tracking. However this shouldn't affect audio I/O if it's in a separate thread. >2. Some plugins have edit-windows that can switch between a >compact view and an extended edit-view. When I query them for >the size of the editwindow I only get the extended windowsize. >How can I support these are multiple size edit-windows? Dunno, you might try the VST development list. Below is the footer from messages on that list: >This message is sent to you because you are subscribed to > the mailing list . >To unsubscribe, E-mail to: >To switch to the DIGEST mode, E-mail to > >To switch to the INDEX mode, E-mail to >Send administrative queries to postmaster@steinberg.de Jim From lists at wildgooses.com Mon Jan 24 19:38:19 2005 From: lists at wildgooses.com (Ed Wildgoose) Date: Sun Jan 21 12:11:14 2007 Subject: [music-dsp] Echo cancellation In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5203B55515@exrad2.ad.rad.co.il> References: <27A0F290348F8E45AEF79889DDE65A5203B55515@exrad2.ad.rad.co.il> Message-ID: <41F594FB.2020207@wildgooses.com> Yaakov Stein wrote: > > > >>Anyone got any pointers on doing echo cancellation for a VoIP >>type situation? >> >> > >Are you interested in "line echo cancellation" >(using a 2-wire phone) >or "acoustic echo cancellation" ? > > Acoustic echo cancellation. Basically having speakers and a mic in the same room and not creating a feedback loop, or having the recipient hearing themselves. Basically it seems to come down to estimating the room IR (constantly). Interesting problem though Anyone know of a code implementation...? Ed W From arcane at arcanemethods.com Mon Jan 24 21:14:35 2005 From: arcane at arcanemethods.com (Bob Cain) Date: Sun Jan 21 12:11:14 2007 Subject: [music-dsp] Rephrasing my question on IIR filtering In-Reply-To: <2d69befc0501232223310b0184@mail.gmail.com> References: <2d69befc05012112042669fa12@mail.gmail.com> <2d69befc0501232223310b0184@mail.gmail.com> Message-ID: <41F5AB8B.7030901@arcanemethods.com> Rob Hutchins wrote: > Given the response, what would be the best way of designing an IIR > filter to model the curve and its inverse filter? From the magnitude of the filter response, you can calculate the minimum phase FIR that corresponds to it using the complex cepstrum method. I've written Matlab code to do that. Having done that, you can use the code I recently archived to find the time domain inverse of that FIR or you can use the faster FFT method if you zero pad your specification enough so that time domain aliasing won't be a problem. There is then a Matlab function which attempts to fit a minimum phase FIR to a specified order IIR but it doesn't work very well if high order is required. I don't remember the name of it off the top of my head. Do you have and use Matlab? Bob -- "Things should be described as simply as possible, but no simpler." A. Einstein From labmeister at gmx.de Mon Jan 24 23:13:33 2005 From: labmeister at gmx.de (Roman Katzer) Date: Sun Jan 21 12:11:14 2007 Subject: [music-dsp] Rephrasing my question on IIR filtering In-Reply-To: <2d69befc05012322267ba14ca9@mail.gmail.com> References: <2d69befc05012322267ba14ca9@mail.gmail.com> Message-ID: <842833606.20050124231333@gmx.de> Hello Rob, On Monday, January 24, 2005, 01:26:24, Rob Hutchins wrote: > My main problem is getting started on the inverse filtering. I've > studied the basic IIR design technques - Impulse Invariance and > Bilinear Transformation. Ah, the black art of IIR filter design... :) > For what I want to do, however, I don't start out given anything other > than a response, a part of which can be modeled by a narrow bandpass > IIR filter. I then need to flatten that part out using an inverse > filter. Look at Matlab's help browser. On the Contents tab, choose the Signal Processing Toolbox, then Filter Design and Implementation, then IIR Filter Design. There's a list of filter design functions and what they're for. I've found it very useful many times. Regards, Roman -- Life is a riddle wrapped in a mystery inside an enigma. From labmeister at gmx.de Mon Jan 24 23:14:53 2005 From: labmeister at gmx.de (Roman Katzer) Date: Sun Jan 21 12:11:15 2007 Subject: [music-dsp] Help in MATLAB GUIDE needed In-Reply-To: <20050124083215.68237.qmail@web8406.mail.in.yahoo.com> References: <20050124083215.68237.qmail@web8406.mail.in.yahoo.com> Message-ID: <1448304323.20050124231453@gmx.de> On Monday, January 24, 2005, 03:32:15, Deepak Iyer wrote: > cud i create a .fig file from the .m file or is > there any way by which i cud get the application running without the > .fig file. Probably not. Go back to where you downloaded the .m file and try to find the accompanying .fig file. Regards, Roman -- On an occasion of this kind, it becomes more than a moral duty to speak one's mind. It becomes a pleasure. -- Oscar Wilde From NAYRALORENZO at telefonica.net Tue Jan 25 04:22:43 2005 From: NAYRALORENZO at telefonica.net (NAYRALORENZO@telefonica.net) Date: Sun Jan 21 12:11:15 2007 Subject: [music-dsp] matlab handles Message-ID: <8800b92b.b92b8800@teleline.es> Hello again, Does somebody know how can I make that every printf from C to Matlab (mex files) is printing not in the Command Window, even in other graphic (in a box in a Graphical User Interface). I know is a strange question but if somebody knows something about it, please tell me. Thanks Nayra Lorenzo From contact at sciss.de Tue Jan 25 05:40:35 2005 From: contact at sciss.de (contact@sciss.de) Date: Sun Jan 21 12:11:15 2007 Subject: [music-dsp] Re: Announce: FScape 0.65 Message-ID: hallo, someone asked me to make the installer because it was to diffult for him to handle installation manually, that's why. ok, here's the separate source code www.sciss.de/fscape/FScape-0.65-src.tar.gz (sourceforge ftp upload doesn't work at the moment, it seems, but you'll also find this on the sourceforge file release site ASAP) best ,-sciss- From ben at glw.com Tue Jan 25 10:18:03 2005 From: ben at glw.com (Ben Loftis) Date: Sun Jan 21 12:11:15 2007 Subject: [music-dsp] Re: music-dsp Digest, Vol 13, Issue 23 In-Reply-To: <20050125021530.1F77619493B4@music.calarts.edu> References: <20050125021530.1F77619493B4@music.calarts.edu> Message-ID: <200501251018.03754.ben@glw.com> > From: "Amarpreet Basi" > Subject: [music-dsp] Real Time Tempo & Synchronising Issues ... > I want to achieve the same rigid synchronicity that commercial sequencer > applications have. I know I'm doing it all so horribly wrong, and right now > I'm at a loss at what the next step should be. > > Would I have to interact with my system's soundcard and get access to some > hardware clock? I hope not, because up till now I've been doing the sound > playback on a "high level" ; making calls to an API called FMOD (with > elegant functions like e.g. PlaySound (channel, sample) that abstract away > from all that horrid low level detail ;) ). > The "hardware clock" that you need to get access to is that of the soundcard in your computer. The way to take advantage of the soundcard's clock is to use a "callback" based API. This means that, as the soundcard outputs audio samples, your callback function will be asked to fill the buffers before they are sent to the sound card. You have the ability to touch every outgoing sample before it is sent to the soundcard,and therefore you can derive your timing very accurately (assuming that the soundcard's clock is accurate!) I'm not familiar with FMOD but I think it allows for a "callback" based API in additon to the simplified API you are using. I see a feature called "WAV marker synchronization call-backs" which might allow you to fire sounds on sample-accurate locations within the stream, while still taking advantage of the high-level file abstractions. Maybe you should look into that. -Ben Loftis From A.S.Basi at warwick.ac.uk Tue Jan 25 14:19:51 2005 From: A.S.Basi at warwick.ac.uk (Amarpreet Basi) Date: Sun Jan 21 12:11:15 2007 Subject: [music-dsp] Re: music-dsp Digest, Vol 13, Issue 23 Message-ID: brilliant advice, i've spoken to one of the good fellows at FMOD on their support forums and they suggest the same thing. thanks for the suggestion, i'll have a crack at it and will let you know how i get on. cheers >>> ben@glw.com 01/25/05 16:21 PM >>> The "hardware clock" that you need to get access to is that of the soundcard in your computer. The way to take advantage of the soundcard's clock is to use a "callback" based API. This means that, as the soundcard outputs audio samples, your callback function will be asked to fill the buffers before they are sent to the sound card. You have the ability to touch every outgoing sample before it is sent to the soundcard,and therefore you can derive your timing very accurately (assuming that the soundcard's clock is accurate!) I'm not familiar with FMOD but I think it allows for a "callback" based API in additon to the simplified API you are using. I see a feature called "WAV marker synchronization call-backs" which might allow you to fire sounds on sample-accurate locations within the stream, while still taking advantage of the high-level file abstractions. Maybe you should look into that. -Ben Loftis -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://shoko.calarts.edu/musicdsp http://ceait.calarts.edu/mailman/listinfo/music-dsp From rbj at audioimagination.com Tue Jan 25 15:57:49 2005 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sun Jan 21 12:11:15 2007 Subject: [music-dsp] if you receive the music-dsp digest version, may i suggest ... In-Reply-To: Message-ID: ... that you manually copy and paste the title of the tread into your Subject: header when you post a reply? "Re: music-dsp Digest, Vol 13, Issue 23" means much less than "[music-dsp] Real Time Tempo & Synchronising Issues". -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From A.S.Basi at warwick.ac.uk Tue Jan 25 16:50:38 2005 From: A.S.Basi at warwick.ac.uk (Amarpreet Basi) Date: Sun Jan 21 12:11:15 2007 Subject: [music-dsp] if you receive the music-dsp digest version,may i suggest ... Message-ID: yeah sorry about that >>> rbj@audioimagination.com 01/25/05 20:58 PM >>> ... that you manually copy and paste the title of the tread into your Subject: header when you post a reply? "Re: music-dsp Digest, Vol 13, Issue 23" means much less than "[music-dsp] Real Time Tempo & Synchronising Issues". -- 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://shoko.calarts.edu/musicdsp http://ceait.calarts.edu/mailman/listinfo/music-dsp From ISMAEVAL at terra.es Tue Jan 25 16:59:09 2005 From: ISMAEVAL at terra.es (Ismael Valladolid Torres) Date: Sun Jan 21 12:11:15 2007 Subject: [music-dsp] if you receive the music-dsp digest version, may i suggest ... In-Reply-To: References: Message-ID: <20050125215909.GG9155@buddha> robert bristow-johnson escribe: > "Re: music-dsp Digest, Vol 13, Issue 23" means much less than > "[music-dsp] Real Time Tempo & Synchronising Issues". Probably not from a Shannon's point of view. Back to lurking! =:) Cordially, Ismael From the8bitdeity at thegsp.com Tue Jan 25 20:12:35 2005 From: the8bitdeity at thegsp.com (Robert Kukuchka) Date: Sun Jan 21 12:11:15 2007 Subject: [music-dsp] Phase Shifting Message-ID: <1fde125ba43c01aadbc3604a54ce1430@thegsp.com> Hello all, I'm having a dumb moment here. What's the simplest way to shift audio by 90 degrees? I'm working on a 2 delay line chorus plugin, and I'd like the second delay line to be in quadrature to the first. Cheers Rob From tebjan at gmx.de Tue Jan 25 20:38:54 2005 From: tebjan at gmx.de (Tebjan Halm) Date: Sun Jan 21 12:11:15 2007 Subject: [music-dsp] how does it work ... ? Message-ID: <41F6F4AE.8020704@gmx.de> like this !? hello music-dsp mailing list ! From urs at u-he.com Tue Jan 25 20:50:05 2005 From: urs at u-he.com (Urs Heckmann) Date: Sun Jan 21 12:11:15 2007 Subject: [music-dsp] how does it work ... ? In-Reply-To: <41F6F4AE.8020704@gmx.de> References: <41F6F4AE.8020704@gmx.de> Message-ID: <99B06CE0-6F3C-11D9-94FD-000A9595B180@u-he.com> Tebjan Halm: > like this !? hello music-dsp mailing list ! Yeah, exactly like that. Hallo Tebjam! ;) Urs From erikd-music-dsp at mega-nerd.com Tue Jan 25 21:14:58 2005 From: erikd-music-dsp at mega-nerd.com (Erik de Castro Lopo) Date: Sun Jan 21 12:11:15 2007 Subject: [music-dsp] Phase Shifting In-Reply-To: <1fde125ba43c01aadbc3604a54ce1430@thegsp.com> References: <1fde125ba43c01aadbc3604a54ce1430@thegsp.com> Message-ID: <20050126131458.2e25d629.erikd-music-dsp@mega-nerd.com> On Tue, 25 Jan 2005 17:12:35 -0800 Robert Kukuchka wrote: > Hello all, > I'm having a dumb moment here. What's the simplest way to shift audio > by 90 degrees? Its called a Hilbert Transformer. > I'm working on a 2 delay line chorus plugin, and I'd > like the second delay line to be in quadrature to the first. Err, you do realise that for a sine wave at 1/4 of the sample rate (ie fs/4), a 90 degree phase shift is exactly a 1 sample delay don't you? Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo nospam@mega-nerd.com (Yes it's valid) +-----------------------------------------------------------+ "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind." -- Alan Kay From tebjan at gmx.de Tue Jan 25 21:24:08 2005 From: tebjan at gmx.de (Tebjan Halm) Date: Sun Jan 21 12:11:16 2007 Subject: [music-dsp] how does it work ... ? In-Reply-To: <99B06CE0-6F3C-11D9-94FD-000A9595B180@u-he.com> References: <41F6F4AE.8020704@gmx.de> <99B06CE0-6F3C-11D9-94FD-000A9595B180@u-he.com> Message-ID: <41F6FF48.8020509@gmx.de> great ! so, like most people joining here, i have an audio related problem. i try to write a small freeware application to fulfill most live VJs desire: a (very) fast audio analysis and beatdetection. this should be an application as small and fast as possible to use it as a background tool. the data will be provided by midi and/or (better) TCP/IP and/or OSC. only asio diver support (having the free asio4all driver in mind). ... will start a new topic, to have a better headline ... greets, tebjan Urs Heckmann schrieb: > Tebjan Halm: > >> like this !? hello music-dsp mailing list ! > > > Yeah, exactly like that. Hallo Tebjam! > > ;) Urs > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription > info, FAQ, source code archive, list archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > > From the8bitdeity at thegsp.com Tue Jan 25 21:25:54 2005 From: the8bitdeity at thegsp.com (Robert Kukuchka) Date: Sun Jan 21 12:11:16 2007 Subject: [music-dsp] Phase Shifting In-Reply-To: <20050126131458.2e25d629.erikd-music-dsp@mega-nerd.com> References: <1fde125ba43c01aadbc3604a54ce1430@thegsp.com> <20050126131458.2e25d629.erikd-music-dsp@mega-nerd.com> Message-ID: <0ed6d6379c71a31528b3559e97e861b8@thegsp.com> On Jan 25, 2005, at 6:14 PM, Erik de Castro Lopo wrote: > On Tue, 25 Jan 2005 17:12:35 -0800 > Robert Kukuchka wrote: > >> Hello all, >> I'm having a dumb moment here. What's the simplest way to shift audio >> by 90 degrees? > > Its called a Hilbert Transformer. - Ok, I'll do some research on that. Thanks. > >> I'm working on a 2 delay line chorus plugin, and I'd >> like the second delay line to be in quadrature to the first. > > Err, you do realise that for a sine wave at 1/4 of the sample > rate (ie fs/4), a 90 degree phase shift is exactly a 1 sample > delay don't you? > - I see, so any frequencies abover fs/4 will not be properly phase delayed. Hrmm. Thanks at least for pointing me towards the HT. It's likely to be ineffectual for higher frequencies, but I'm curious if I can at least get a version of it coded. Might be useful later on for something else. Cheers ~Rob From joshscholar at yahoo.com Tue Jan 25 22:10:42 2005 From: joshscholar at yahoo.com (Joshua Scholar) Date: Sun Jan 21 12:11:16 2007 Subject: [music-dsp] Phase Shifting References: <1fde125ba43c01aadbc3604a54ce1430@thegsp.com><20050126131458.2e25d629.erikd-music-dsp@mega-nerd.com> <0ed6d6379c71a31528b3559e97e861b8@thegsp.com> Message-ID: <001701c50354$9fb36ec0$51e22641@antssoftware.com> ----- Original Message ----- From: "Robert Kukuchka" To: "a list for musical digital signal processing" Sent: Tuesday, January 25, 2005 6:25 PM Subject: Re: [music-dsp] Phase Shifting > > On Jan 25, 2005, at 6:14 PM, Erik de Castro Lopo wrote: > > > On Tue, 25 Jan 2005 17:12:35 -0800 > > Robert Kukuchka wrote: > > > >> Hello all, > >> I'm having a dumb moment here. What's the simplest way to shift audio > >> by 90 degrees? > > > > Its called a Hilbert Transformer. > > - Ok, I'll do some research on that. Thanks. > > > >> I'm working on a 2 delay line chorus plugin, and I'd > >> like the second delay line to be in quadrature to the first. > > > > Err, you do realise that for a sine wave at 1/4 of the sample > > rate (ie fs/4), a 90 degree phase shift is exactly a 1 sample > > delay don't you? > > > > - I see, so any frequencies abover fs/4 will not be properly phase > delayed. Hrmm. > > Thanks at least for pointing me towards the HT. It's likely to be > ineffectual for higher frequencies, but I'm curious if I can at least > get a version of it coded. Might be useful later on for something else. > > Cheers > ~Rob > The longer the HT the better it will be for both low and high frequencies. Keep in mind that ANY Hilbert tranformer will introduce a constant delay AS WELL AS the phase delay and you'll have to delay the other the first line by the same constant delay to keep the two lines together. I'm not sure about the correct mathematical term for it, but a Hilbert tranformer is a phase rotation, not just a delay ... something about including negatives frequencies in the delay. Joshua Scholar From labmeister at gmx.de Tue Jan 25 22:43:38 2005 From: labmeister at gmx.de (Roman Katzer) Date: Sun Jan 21 12:11:16 2007 Subject: [music-dsp] Phase Shifting In-Reply-To: <1fde125ba43c01aadbc3604a54ce1430@thegsp.com> References: <1fde125ba43c01aadbc3604a54ce1430@thegsp.com> Message-ID: <357001347.20050125224338@gmx.de> On Tuesday, January 25, 2005, 20:12:35, Robert Kukuchka wrote: > What's the simplest way to shift audio by 90 degrees? I'm working on a 2 > delay line chorus plugin, and I'd like the second delay line to be in > quadrature to the first. You have to come up with two all-pass filters that are 90? apart. A Hilbert Transformer as Erik mentioned isn't practical here. For the all-passes, there's some geometric pole spacing between the two filters that will do that, I don't know off-hand what it was. Regards, Roman -- Always use tasteful words. You may have to eat them. From dgm at baykitty.com Tue Jan 25 23:02:17 2005 From: dgm at baykitty.com (don) Date: Sun Jan 21 12:11:16 2007 Subject: [music-dsp] Phase Shifting In-Reply-To: <357001347.20050125224338@gmx.de> Message-ID: <008001c5035b$d6e4e700$0301a8c0@liuxing> I confess ignorance but also curiosity. The Hilbert Transformer IS and all-pass filter, done with a long enough FIR, it can produce low ripple and a -90 degree phase shift over the input. With the FIR, it can even be done on a sample by sample basis. I use it to produce this phase shift in audio processors. I assumed it would work here too - is it something about chorusing that makes it impractical. Do you somehow need an IIR characteristic? Don -----Original Message----- From: music-dsp-bounces@ceait.calarts.edu [mailto:music-dsp-bounces@ceait.calarts.edu] On Behalf Of Roman Katzer Sent: Tuesday, January 25, 2005 7:44 PM To: a list for musical digital signal processing Subject: Re: [music-dsp] Phase Shifting On Tuesday, January 25, 2005, 20:12:35, Robert Kukuchka wrote: > What's the simplest way to shift audio by 90 degrees? I'm working on a 2 > delay line chorus plugin, and I'd like the second delay line to be in > quadrature to the first. You have to come up with two all-pass filters that are 90? apart. A Hilbert Transformer as Erik mentioned isn't practical here. For the all-passes, there's some geometric pole spacing between the two filters that will do that, I don't know off-hand what it was. Regards, Roman -- Always use tasteful words. You may have to eat them. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://shoko.calarts.edu/musicdsp http://ceait.calarts.edu/mailman/listinfo/music-dsp From dgm at baykitty.com Tue Jan 25 23:19:51 2005 From: dgm at baykitty.com (don) Date: Sun Jan 21 12:11:16 2007 Subject: [music-dsp] Phase Shifting In-Reply-To: <357001347.20050125224338@gmx.de> Message-ID: <008101c5035e$4b3327a0$0301a8c0@liuxing> Is it the group delay in the FIR? This would mess up the delay line? Don -----Original Message----- From: music-dsp-bounces@ceait.calarts.edu [mailto:music-dsp-bounces@ceait.calarts.edu] On Behalf Of Roman Katzer Sent: Tuesday, January 25, 2005 7:44 PM To: a list for musical digital signal processing Subject: Re: [music-dsp] Phase Shifting On Tuesday, January 25, 2005, 20:12:35, Robert Kukuchka wrote: > What's the simplest way to shift audio by 90 degrees? I'm working on a 2 > delay line chorus plugin, and I'd like the second delay line to be in > quadrature to the first. You have to come up with two all-pass filters that are 90? apart. A Hilbert Transformer as Erik mentioned isn't practical here. For the all-passes, there's some geometric pole spacing between the two filters that will do that, I don't know off-hand what it was. Regards, Roman -- Always use tasteful words. You may have to eat them. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://shoko.calarts.edu/musicdsp http://ceait.calarts.edu/mailman/listinfo/music-dsp From labmeister at gmx.de Tue Jan 25 23:33:26 2005 From: labmeister at gmx.de (Roman Katzer) Date: Sun Jan 21 12:11:16 2007 Subject: [music-dsp] Phase Shifting In-Reply-To: <008001c5035b$d6e4e700$0301a8c0@liuxing> References: <357001347.20050125224338@gmx.de> <008001c5035b$d6e4e700$0301a8c0@liuxing> Message-ID: <1223679936.20050125233326@gmx.de> Hi Don, On Tuesday, January 25, 2005, 23:02:17, don wrote: > I confess ignorance but also curiosity. The Hilbert Transformer IS and > all-pass filter, done with a long enough FIR, it can produce low ripple > and a -90 degree phase shift over the input. With the FIR, it can even > be done on a sample by sample basis. I forget what the problem was. Maybe only computational cost. > Do you somehow need an IIR characteristic? Let me find out, I think not. But then again you might get away with two fourth-order all-passes. To be continued... Regards, Roman -- Is there an imaginary cure for hypochondria? From arcane at arcanemethods.com Wed Jan 26 01:14:25 2005 From: arcane at arcanemethods.com (Bob Cain) Date: Sun Jan 21 12:11:16 2007 Subject: [music-dsp] Phase Shifting In-Reply-To: <357001347.20050125224338@gmx.de> References: <1fde125ba43c01aadbc3604a54ce1430@thegsp.com> <357001347.20050125224338@gmx.de> Message-ID: <41F73541.5050400@arcanemethods.com> Roman Katzer wrote: > > A Hilbert Transformer as Erik mentioned isn't practical here. Why? Bob -- "Things should be described as simply as possible, but no simpler." A. Einstein From joshscholar at yahoo.com Wed Jan 26 01:42:39 2005 From: joshscholar at yahoo.com (Joshua Scholar) Date: Sun Jan 21 12:11:16 2007 Subject: [music-dsp] Phase Shifting References: <1fde125ba43c01aadbc3604a54ce1430@thegsp.com><20050126131458.2e25d629.erikd-music-dsp@mega-nerd.com> <0ed6d6379c71a31528b3559e97e861b8@thegsp.com> Message-ID: <006a01c50372$3bd447d0$51e22641@antssoftware.com> ----- Original Message ----- From: "Robert Kukuchka" To: "a list for musical digital signal processing" Sent: Tuesday, January 25, 2005 6:25 PM Subject: Re: [music-dsp] Phase Shifting > > On Jan 25, 2005, at 6:14 PM, Erik de Castro Lopo wrote: > > > On Tue, 25 Jan 2005 17:12:35 -0800 > > Robert Kukuchka wrote: > > > >> Hello all, > >> I'm having a dumb moment here. What's the simplest way to shift audio > >> by 90 degrees? > > > > Its called a Hilbert Transformer. > > - Ok, I'll do some research on that. Thanks. > > > >> I'm working on a 2 delay line chorus plugin, and I'd > >> like the second delay line to be in quadrature to the first. > > > > Err, you do realise that for a sine wave at 1/4 of the sample > > rate (ie fs/4), a 90 degree phase shift is exactly a 1 sample > > delay don't you? > > > > - I see, so any frequencies abover fs/4 will not be properly phase > delayed. Hrmm. > > Thanks at least for pointing me towards the HT. It's likely to be > ineffectual for higher frequencies, but I'm curious if I can at least > get a version of it coded. Might be useful later on for something else. > > Cheers > ~Rob > By the way, you can Hilbert tranform higher frequencies with a shorter FIR (and therefor less group delay) if the original signal is oversampled. If group delay is a problem (because you're using it in performance), perhaps you can exclude subsonics or even base from the effect - or process them separately, allowing more group delay for subsonics. From tebjan at gmx.de Wed Jan 26 11:56:33 2005 From: tebjan at gmx.de (Tebjan Halm) Date: Sun Jan 21 12:11:16 2007 Subject: [music-dsp] shortest c code to access asio driver and open the control panel ? Message-ID: <41F7CBC1.7090508@gmx.de> dear dsp gurus ;) i try to write a small freeware application to fulfill most live VJs desire: a (very) fast audio analysis and beatdetection. this should be an application as small and fast as possible to use it as a background tool. the data will be provided by midi and/or (better) TCP/IP and/or OSC. only asio diver support (having the free asio4all driver in mind). this are the tools i planned to use: - devc++/MinGW - portaudio API what i think to know: - digital audio is an onedimensional array of floats with same size than the buffersize of my soundcard - one value of this array is called a sample - the amount of time in the array is dependant to the samplerate - every n*buffersize samples my souncard provides this array (frame) - i need a callback function to get the (pointer to the) array every n*buffersize samples - than i can call my analysis functions and store my data in variables and make some get functions - a second thread is needed, that calls the get functions and sends the midi data in adjustable framerate. - a little gui to control (please correct if wrong or bad style ...) what i dont know: - how to import the portaudio API to devc++ - and the same for the asio sdk like discribed here: http://www.portaudio.com/docs/pa_tut_asio.html - can i manage the task easy using only asio sdk ? - how to open the asio control panel maybe many people here have done all this before and can send me a c file or devc++ project to start with just by browsing their code directories. will save some days of work for me ... only thing i need is that sweet array from my asio driver (with devc++). thanks for every help and hint and sorry for my bad english. best wishes, tebjan From ISMAEVAL at terra.es Wed Jan 26 15:45:54 2005 From: ISMAEVAL at terra.es (Ismael Valladolid Torres) Date: Sun Jan 21 12:11:16 2007 Subject: MIDI versus TCP/IP, was Re: [music-dsp] how does it work ... ? In-Reply-To: <41F6FF48.8020509@gmx.de> References: <41F6F4AE.8020704@gmx.de> <99B06CE0-6F3C-11D9-94FD-000A9595B180@u-he.com> <41F6FF48.8020509@gmx.de> Message-ID: <20050126204554.GC5368@buddha> Tebjan Halm escribe: > the data will be provided by midi and/or (better) TCP/IP and/or OSC. Lots of experts around here will tell you (probably) that TCP/IP is not better than real MIDI for exchange of MIDI data. I mean speed is higher but latency unpredictable. I recall having read an article of Emagic people telling the world why they discarded Ethernet for communication between Logic Control consoles, and why they decided to use MIDI connectors instead. Sorry I don't have links to that article. Cordially, Ismael From ISMAEVAL at terra.es Wed Jan 26 15:50:27 2005 From: ISMAEVAL at terra.es (Ismael Valladolid Torres) Date: Sun Jan 21 12:11:16 2007 Subject: [music-dsp] shortest c code to access asio driver and open the control panel ? In-Reply-To: <41F7CBC1.7090508@gmx.de> References: <41F7CBC1.7090508@gmx.de> Message-ID: <20050126205027.GD5368@buddha> Tebjan Halm escribe: > this are the tools i planned to use: > > - devc++/MinGW I don't know if devc++ is available to Cygwin. Using Cygwin instead of MinGW could be a nice alternative, as almost all GPL'ed existing UNIX code compile there with few, if any, tweaks. However, any code compiled using Cygwin must be released as GPL, and maybe that's not what you really want. MinGW doesn't put any restriction regarding licenses. Sorry if you already know well about what I am telling. Cordially, Ismael From tebjan at gmx.de Wed Jan 26 16:00:41 2005 From: tebjan at gmx.de (Tebjan Halm) Date: Sun Jan 21 12:11:17 2007 Subject: MIDI versus TCP/IP, was Re: [music-dsp] how does it work ... ? In-Reply-To: <20050126204554.GC5368@buddha> References: <41F6F4AE.8020704@gmx.de> <99B06CE0-6F3C-11D9-94FD-000A9595B180@u-he.com> <41F6FF48.8020509@gmx.de> <20050126204554.GC5368@buddha> Message-ID: <41F804F9.3060809@gmx.de> Ismael Valladolid Torres schrieb: >Tebjan Halm escribe: > > >>the data will be provided by midi and/or (better) TCP/IP and/or OSC. >> >> > >Lots of experts around here will tell you (probably) that TCP/IP is >not better than real MIDI for exchange of MIDI data. I mean speed is >higher but latency unpredictable. > > thx, thats a good information, low latency is the most important thing to me ! so midi is the choice. tebjan >I recall having read an article of Emagic people telling the world why >they discarded Ethernet for communication between Logic Control >consoles, and why they decided to use MIDI connectors instead. Sorry I >don't have links to that article. > > >Cordially, Ismael >-- >dupswapdrop -- the music-dsp mailing list and website: >subscription info, FAQ, source code archive, list archive, book reviews, dsp links >http://shoko.calarts.edu/musicdsp >http://ceait.calarts.edu/mailman/listinfo/music-dsp > > > > From gogins at pipeline.com Wed Jan 26 16:38:56 2005 From: gogins at pipeline.com (gogins@pipeline.com) Date: Sun Jan 21 12:11:17 2007 Subject: [music-dsp] shortest c code to access asio driver and open thecontrol panel ? Message-ID: <255700-220051326213856410@M2W055.mail2web.com> Unfortunately most configure script writers don't bother with non-*nix audio configuration. I prefer MSys/MinGW on Windows over Cygwin because of this problem, which means that Cygwin delivers no additional value over MSys/MinGW for audio programming, whereas MSys/MinGW is smaller, provides easier access to native Windows APIs, does not require cygwin1.dll, and has a better license. Original Message: ----------------- From: Ismael Valladolid Torres ISMAEVAL@terra.es Date: Wed, 26 Jan 2005 21:50:27 +0100 To: music-dsp@ceait.calarts.edu Subject: Re: [music-dsp] shortest c code to access asio driver and open thecontrol panel ? Tebjan Halm escribe: > this are the tools i planned to use: > > - devc++/MinGW I don't know if devc++ is available to Cygwin. Using Cygwin instead of MinGW could be a nice alternative, as almost all GPL'ed existing UNIX code compile there with few, if any, tweaks. However, any code compiled using Cygwin must be released as GPL, and maybe that's not what you really want. MinGW doesn't put any restriction regarding licenses. Sorry if you already know well about what I am telling. Cordially, Ismael -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://shoko.calarts.edu/musicdsp http://ceait.calarts.edu/mailman/listinfo/music-dsp -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . From martin.eisenberg at udo.edu Wed Jan 26 20:38:11 2005 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Sun Jan 21 12:11:17 2007 Subject: [music-dsp] Phase Shifting References: <1fde125ba43c01aadbc3604a54ce1430@thegsp.com><20050126131458.2e25d629.erikd-music-dsp@mega-nerd.com> <0ed6d6379c71a31528b3559e97e861b8@thegsp.com> Message-ID: <005f01c50410$e24fde00$1e0d060a@mooncode> From: "Robert Kukuchka" > On Jan 25, 2005, at 6:14 PM, Erik de Castro Lopo wrote: [...] > > Err, you do realise that for a sine wave at 1/4 of the sample > > rate (ie fs/4), a 90 degree phase shift is exactly a 1 sample > > delay don't you? What is your remark intended to convey? (Not sounding nasty.) > - I see, so any frequencies abover fs/4 will not be properly phase > delayed. Hrmm. No, that's not right. You can delay a signal by a fraction of a sample perfectly well, as any filter does to frequencies near a phase response zero. Olli Niemitalo describes a specific 8th-order allpass pair with approximately 90 deg phase difference at http://www.biochem.oulu.fi/~oniemita/dsp/hilbert/ Martin From chalil.lists at gmail.com Wed Jan 26 23:41:09 2005 From: chalil.lists at gmail.com (md chalil) Date: Sun Jan 21 12:11:17 2007 Subject: [music-dsp] matlab doubt In-Reply-To: <20050121193742.64978.qmail@web60508.mail.yahoo.com> References: <20050121193742.64978.qmail@web60508.mail.yahoo.com> Message-ID: as a simple solution, make faster file access using RAMDisk. i used this in my old DOS time. possible for windows too eg: http://www.winsoft.sk/ramdisk.htm ~chalil On Fri, 21 Jan 2005 11:37:42 -0800 (PST), Ben Rathke wrote: > it may be overkill, but you could write the data to > the serial port > > --- "NAYRALORENZO@telefonica.net" > wrote: > > > I know you can use that orders to work with files, > > but the problem is > > that I can not use a file because I need to do this > > in real time...so if > > you know a way to put all the mexprintf of a dll > > file in other place > > different to the command window, please tell me. > > > > Thanks, > > Nayra Lorenzo > > > > ----- Mensaje Original ----- > > De: robert bristow-johnson > > > > Fecha: Viernes, Enero 21, 2005 3:38 am > > Asunto: Re: [music-dsp] matlab doubt > > > > > on 01/20/2005 07:52, NAYRALORENZO@telefonica.net > > at > > > NAYRALORENZO@telefonica.net wrote: > > > > > > > I know that this is not a list from ask about > > Matlab, but I have > > > a big > > > > doubt and I can't find the way to solve, so > > maybe someone of you > > > know> the answer. > > > > Does somebody know if is a way to display the > > results from a > > > function,> not in the command window, even in > > other display, for > > > example, a static > > > > text in the guide? > > > > > > MATLAB has an fopen(), fclose(), fread(), and > > fwrite() utility, > > > similar to > > > C, so you can put the results into a file if you > > want. > > > > > > i dunno if that is what you are looking for. > > > > > > -- > > > > > > 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://shoko.calarts.edu/musicdsp > > http://ceait.calarts.edu/mailman/listinfo/music-dsp > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > From P.Maddox at signal.QinetiQ.com Thu Jan 27 04:28:45 2005 From: P.Maddox at signal.QinetiQ.com (Paul Maddox) Date: Sun Jan 21 12:11:17 2007 Subject: MIDI versus TCP/IP, was Re: [music-dsp] how does it work ... ? References: <41F6F4AE.8020704@gmx.de> <99B06CE0-6F3C-11D9-94FD-000A9595B180@u-he.com> <41F6FF48.8020509@gmx.de><20050126204554.GC5368@buddha> <41F804F9.3060809@gmx.de> Message-ID: <015801c50452$99adc9e0$4da8a8c0@dtg.qinetiq.com> Tebjan, > thx, thats a good information, low latency is the most important thing > to me ! > so midi is the choice. the key thing is that TCP/IP has no gauranteed delivery time, in-fact, no gaurantee of delivery at all.. Midi is ok, but its not good for a lot of data or high speed data. If you want those, look at firwire, USB is somewhere between MIDI and firwire.. Paul From brianw at sounds.wa.com Thu Jan 27 04:50:21 2005 From: brianw at sounds.wa.com (Brian Willoughby) Date: Sun Jan 21 12:11:17 2007 Subject: MIDI versus TCP/IP, was Re: [music-dsp] how does it work ... ? In-Reply-To: <015801c50452$99adc9e0$4da8a8c0@dtg.qinetiq.com> References: <41F6F4AE.8020704@gmx.de> <99B06CE0-6F3C-11D9-94FD-000A9595B180@u-he.com> <41F6FF48.8020509@gmx.de><20050126204554.GC5368@buddha> <41F804F9.3060809@gmx.de> <015801c50452$99adc9e0$4da8a8c0@dtg.qinetiq.com> Message-ID: <200501270951.j0R9pZ601122@mortem.sounds.wa.com> [ > thx, thats a good information, low latency is the most important thing [ > to me ! [ > so midi is the choice. [ [ the key thing is that TCP/IP has no gauranteed delivery time, in-fact, no [ gaurantee of delivery at all.. [ Midi is ok, but its not good for a lot of data or high speed data. [ If you want those, look at firwire, USB is somewhere between MIDI and [ firwire.. [ [ Paul Actually, TCP does have guaranteed delivery, it's UDP that does not have guaranteed delivery. It's up to the streaming protocol designer to decide whether to use TCP or UDP. Many times, especially for audio streaming, UDP is selected because TCP takes more bandwidth and has higher overhead. But you're right about delivery time. TCP does not have that. USB-MIDI has guaranteed delivery similar to TCP. But USB-MIDI was not even designed to perform as well as USB offers, so the latency can be random. I haven't looked into MIDI over FireWire yet. I hear a bit of a buzz about mLAN, but I'd like to know more. Brian Willoughby Sound Consulting From paul.kellett at mda-vst.com Thu Jan 27 05:02:46 2005 From: paul.kellett at mda-vst.com (Paul Kellett) Date: Sun Jan 21 12:11:17 2007 Subject: [music-dsp] Phase Shifting References: <20050126204639.A0AE2195ACAE@music.calarts.edu> Message-ID: <007001c50457$5a032ab0$c300a8c0@Paul> Robert Kukuchka wrote: > >> I'm working on a 2 delay line chorus plugin, and I'd >> like the second delay line to be in quadrature to the first. > I don't think anyone else has mentioned this yet, but usually in a chorus it's the modulation of the delay lines that's in quadrature (or some other angle) not the phase of the audio. Doing this distributes the pitches output by the chorus nicely around the original pitch. Paul. From jamie at postlude.co.uk Thu Jan 27 05:18:14 2005 From: jamie at postlude.co.uk (Jamie Bullock) Date: Sun Jan 21 12:11:17 2007 Subject: MIDI versus TCP/IP, was Re: [music-dsp] how does it work ... ? In-Reply-To: <015801c50452$99adc9e0$4da8a8c0@dtg.qinetiq.com> References: <41F6F4AE.8020704@gmx.de> <99B06CE0-6F3C-11D9-94FD-000A9595B180@u-he.com> <41F6FF48.8020509@gmx.de> <20050126204554.GC5368@buddha> <41F804F9.3060809@gmx.de> <015801c50452$99adc9e0$4da8a8c0@dtg.qinetiq.com> Message-ID: <1106821093.2322.49.camel@localhost.localdomain> True, IP doesn't provide guarantee of delivery, but TCP, which works above IP in the protocol stack exists to provide guarantees using a system of packet acknowledgement and checksums. It is the overhead generated by this extra traffic that often causes extra throughput and sometimes latency problems. UDP, which is an alternative to TCP is leaner because it doesn't provide the delivery guarantees, and throughput is therefore increased. That is why it is used for Media streaming, and often for OSC. Latency with both is primarily, although not solely governed by the hardware the traffic travels through. With a peer-to-peer 100-1000Mb link, latency between the cards could be in the region of 150-500 microseconds. MIDI between dedicated devices has a theoretical latency in the order nanoseconds, but I don't think it can be argued that this justifies choosing MIDI over UDP. Firstly, the difference in latency is not audible, and secondly once either protocol comes near a PC, the latency is delimited by other factors such as the granularity of hardware clocks, the OS and the drivers. I think my point is that the latency is dependent on the hardware used and not the protocol itself. Neither MIDI nor OSC protocols are going to provide a noticeable latency bottleneck unless you're running OSC through a router or a slow link. If you want a wide user base choose MIDI, if you want high resolution and better network support choose OSC. Jamie On Thu, 2005-01-27 at 09:28, Paul Maddox wrote: > Tebjan, > > > thx, thats a good information, low latency is the most important thing > > to me ! > > so midi is the choice. > > the key thing is that TCP/IP has no gauranteed delivery time, in-fact, no > gaurantee of delivery at all.. > Midi is ok, but its not good for a lot of data or high speed data. > If you want those, look at firwire, USB is somewhere between MIDI and > firwire.. > > Paul > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp From P.Maddox at signal.QinetiQ.com Thu Jan 27 05:31:43 2005 From: P.Maddox at signal.QinetiQ.com (Paul Maddox) Date: Sun Jan 21 12:11:17 2007 Subject: MIDI versus TCP/IP, was Re: [music-dsp] how does it work ... ? References: <41F6F4AE.8020704@gmx.de><99B06CE0-6F3C-11D9-94FD-000A9595B180@u-he.com><41F6FF48.8020509@gmx.de><20050126204554.GC5368@buddha><41F804F9.3060809@gmx.de><015801c50452$99adc9e0$4da8a8c0@dtg.qinetiq.com> <200501270951.j0R9pZ601122@mortem.sounds.wa.com> Message-ID: <01f801c5045b$65459080$4da8a8c0@dtg.qinetiq.com> Brian, > Actually, TCP does have guaranteed delivery, it's UDP that does not have > guaranteed delivery. sorry, yes... I got the two mixed up. > I haven't looked into MIDI over FireWire yet. I hear a bit of a buzz about > mLAN, but I'd like to know more. Yes, I'd like to know more about mLAN, not just the sales blurb.. Paul From ee04571 at elec.qmul.ac.uk Thu Jan 27 15:43:29 2005 From: ee04571 at elec.qmul.ac.uk (Gavin Burke) Date: Sun Jan 21 12:11:17 2007 Subject: [music-dsp] Cepstral Vocoder in real-time? Message-ID: <41F95271.30705@elec.qmul.ac.uk> Nubie question time! I have written a cepstral based vocoder for the TI6711 DSP chip, but have been unsuccessful in getting it to run in real-time, even when using DMA for hadling the audio inputs. At the moment I'm storing the voice and synth inputs in memory first and then doing the processing (phase vocoder, 512 point FFT\IFFTs etc...). My question is this, would it be worth the effort of trying to re-write optimised assembly code or is a real-time cepstral vocoder beyond the capabilities of a single DSP chip? From mbartkow at et.put.poznan.pl Thu Jan 27 08:12:02 2005 From: mbartkow at et.put.poznan.pl (Maciej Bartkowiak) Date: Sun Jan 21 12:11:17 2007 Subject: [music-dsp] Cepstral Vocoder in real-time? References: <41F95271.30705@elec.qmul.ac.uk> Message-ID: <002901c50471$cb352340$f81dfe96@cpo.multimedia.edu.pl> what is the advantage of using cepstrum in a vocoder, over the approach based on vanilla fft? MB From yaakov_s at rad.com Thu Jan 27 09:13:51 2005 From: yaakov_s at rad.com (Yaakov Stein) Date: Sun Jan 21 12:11:17 2007 Subject: [music-dsp] Echo cancellation Message-ID: <27A0F290348F8E45AEF79889DDE65A5203B55F7E@exrad2.ad.rad.co.il> > Acoustic echo cancellation. Basically having speakers and a > mic in the same room and not creating a feedback loop, or > having the recipient hearing themselves. Acoustic echo cancellers aer somewhat more complex than LECs, since the tail is longer. However, the conventional ones still consist of an LMS or NLMS engine, supplemented by a nonlinear processor (center clipper) and a double-talk detector. More sophisticated algorithms resulting in lower MIPS perform the adaptive filtering in the frequency, filter-bank or Gabor domain. There are several examples of acoustic echo cancellers available on the web. Try one of the AECs contributed to the OpenH323 distribution. Jonsthan (Y) Stein From ee04571 at elec.qmul.ac.uk Thu Jan 27 17:35:16 2005 From: ee04571 at elec.qmul.ac.uk (Gavin Burke) Date: Sun Jan 21 12:11:17 2007 Subject: [music-dsp] Re: Cepstral Vocoder in real-time? Message-ID: <41F96CA4.6010308@elec.qmul.ac.uk> The main reason for going down the cepstrum route over IIR filter banks for the vocoder, is that its somthing I can build on ie. cross-synthesis by swapping the cepstral coeff. of the two inputs, pitch shifting using the phase vocoder. From hin at hin.nu Thu Jan 27 09:58:35 2005 From: hin at hin.nu (Hans Insulander) Date: Sun Jan 21 12:11:17 2007 Subject: MIDI versus TCP/IP, was Re: [music-dsp] how does it work ... ? In-Reply-To: <1106821093.2322.49.camel@localhost.localdomain> (Jamie Bullock's message of "Thu, 27 Jan 2005 10:18:14 +0000") References: <41F6F4AE.8020704@gmx.de> <99B06CE0-6F3C-11D9-94FD-000A9595B180@u-he.com> <41F6FF48.8020509@gmx.de> <20050126204554.GC5368@buddha> <41F804F9.3060809@gmx.de> <015801c50452$99adc9e0$4da8a8c0@dtg.qinetiq.com> <1106821093.2322.49.camel@localhost.localdomain> Message-ID: <87y8eegbqc.fsf@magasin.hin.nu> Jamie Bullock writes: > peer-to-peer 100-1000Mb link, latency between the cards could be in the > region of 150-500 microseconds. > > MIDI between dedicated devices has a theoretical latency in the order > nanoseconds, but I don't think it can be argued that this justifies Are you really sure about these numbers? I did some calculations, and MIDI should a theoretical lowest latency of (1/31250)*10*3 = 0.96 milliseconds. That is 31250 symbols/s, 10 symbols/byte and 3 byte message length. 100Mbit Ethernet, on the other hand, would be (1/100000000)*64*8 = 5.12 microseconds. (100 Mbit/s, 64 byte minimum ethernet packet, 8 bits/byte). Of course you'd then need to add to those times because of things like either the MIDI UART or the Ethernet MAC and PHY, and also (if relevant) the computers interrupt latency, OS overhead and so on. I don't have the equipment to measure MIDI latency, but i can measure ethernet latency, and that is below 100 microseconds, including the overhead caused by the computer and its software. That is between two PCs on a switched 100 Mbit/s ethernet with about 50 devices. It is true though that the latency over Ethernet will jitter, and there's nothing you can do about that - tt's the nature of any shared medium. However, if you're using full duplex links, not to many devices, and a dedicated ethernet, i can hardly think that jittering would be a problem - you're only using a *very* tiny fraction of the available bandwidth. If you use all the available bandwidth of MIDI you'll get 1041 messages/second (3 byte messages). If the same thing was running over 100 Mbit ethernet, you'd use 0.53% of the available bandwidth. So that means that either - I haven't done my math correctly (in which case I'd gladly be corrected!) or - ethernet latency should be about one order of magnitude better than MIDI. -- --- Hans Insulander , SM0UTY ------------------------------- Duct tape is like the force; it has a light side, it has a dark side, and it holds the universe together. From mxmora at apple.com Thu Jan 27 10:06:32 2005 From: mxmora at apple.com (Matthew Xavier Mora) Date: Sun Jan 21 12:11:17 2007 Subject: MIDI versus TCP/IP, was Re: [music-dsp] how does it work ... ? In-Reply-To: <200501270951.j0R9pZ601122@mortem.sounds.wa.com> References: <41F6F4AE.8020704@gmx.de> <99B06CE0-6F3C-11D9-94FD-000A9595B180@u-he.com> <41F6FF48.8020509@gmx.de> <20050126204554.GC5368@buddha> <41F804F9.3060809@gmx.de> <015801c50452$99adc9e0$4da8a8c0@dtg.qinetiq.com> <200501270951.j0R9pZ601122@mortem.sounds.wa.com> Message-ID: At 1:50 AM -0800 1/27/05, Brian Willoughby wrote: >[ > thx, thats a good information, low latency is the most important thing >[ > to me ! >[ > so midi is the choice. >[ >[ the key thing is that TCP/IP has no gauranteed delivery time, in-fact, no >[ gaurantee of delivery at all.. >[ Midi is ok, but its not good for a lot of data or high speed data. >[ If you want those, look at firwire, USB is somewhere between MIDI and >[ firwire.. >[ >[ Paul > >Actually, TCP does have guaranteed delivery, it's UDP that does not have >guaranteed delivery. It's up to the streaming protocol designer to decide >whether to use TCP or UDP. Many times, especially for audio >streaming, UDP is >selected because TCP takes more bandwidth and has higher overhead. > >But you're right about delivery time. TCP does not have that. > >USB-MIDI has guaranteed delivery similar to TCP. But USB-MIDI was not even >designed to perform as well as USB offers, so the latency can be random. USB MIDI support in Mac OS X is probably the best implementation of USB midi on any platform both data rate and jitter are well below the MIDI spec and in some cases even better than USB over FireWire. >I haven't looked into MIDI over FireWire yet. I hear a bit of a buzz about >mLAN, but I'd like to know more. MIDI over FireWire is covered under it's own spec I believe from the MMA. mLAN and Music subunit devices both use this protocol (since both are based on 61883-6). MIDI over ethernet was cover at this year's AES using rtp. See: Here is another link to someone's thesis: Matt From lazzaro at eecs.berkeley.edu Thu Jan 27 13:56:06 2005 From: lazzaro at eecs.berkeley.edu (lazzaro) Date: Sun Jan 21 12:11:18 2007 Subject: [music-dsp] Re: MIDI versus TCP/IP In-Reply-To: <20050127103459.78B4019601A3@music.calarts.edu> References: <20050127103459.78B4019601A3@music.calarts.edu> Message-ID: <167c6cc50751d04d788f303e949dfb18@eecs.berkeley.edu> On Jan 27, 2005, at 2:34 AM, music-dsp-request@shoko.calarts.edu wrote: > With a > peer-to-peer 100-1000Mb link, latency between the cards could be in the > region of 150-500 microseconds. Yea, if you're doing a true apples-to-apples comparison -- an Ethernet cable connecting 2 peers running IP (making an isolated network with 2 nodes) vs a MIDI cable connecting 2 peers, there is no contest -- UDP wins. You can't lose packets, and your only source of problems is the OS stacks on either end. As a bonus, you can time stamp the MIDI commands in the packets to represent simultaneous commands, which is not possible to do on a MIDI cable. See: http://www.cs.berkeley.edu/~lazzaro/rtpmidi/index.html For standardization work underway in the IETF for RTP MIDI. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- From jamie at postlude.co.uk Thu Jan 27 14:16:05 2005 From: jamie at postlude.co.uk (Jamie Bullock) Date: Sun Jan 21 12:11:18 2007 Subject: MIDI versus TCP/IP, was Re: [music-dsp] how does it work ... ? In-Reply-To: <87y8eegbqc.fsf@magasin.hin.nu> References: <41F6F4AE.8020704@gmx.de> <99B06CE0-6F3C-11D9-94FD-000A9595B180@u-he.com> <41F6FF48.8020509@gmx.de> <20050126204554.GC5368@buddha> <41F804F9.3060809@gmx.de> <015801c50452$99adc9e0$4da8a8c0@dtg.qinetiq.com> <1106821093.2322.49.camel@localhost.localdomain> <87y8eegbqc.fsf@magasin.hin.nu> Message-ID: <1106853365.6246.152.camel@localhost.localdomain> Dear Hans, You are totally correct about the theoretical limits. Thank you. In terms of the MIDI latency, I wasn't sure when I wrote my original post, so I did a quick check using Google - I should have just got my calculator out instead! In terms of ethernet, I was talking about real world times and not theoretical. However it seems like I am rather out-of-date here also. I just ran lmbench on my new laptop, and it gives udp latency figures of around 30 microseconds, compared to upwards of 150 on my old desktop, which has an older 100Mb NIC. Jamie On Thu, 2005-01-27 at 14:58, Hans Insulander wrote: > Jamie Bullock writes: > > > peer-to-peer 100-1000Mb link, latency between the cards could be in the > > region of 150-500 microseconds. > > > > MIDI between dedicated devices has a theoretical latency in the order > > nanoseconds, but I don't think it can be argued that this justifies > > Are you really sure about these numbers? > > I did some calculations, and MIDI should a theoretical lowest latency > of (1/31250)*10*3 = 0.96 milliseconds. That is 31250 symbols/s, > 10 symbols/byte and 3 byte message length. > > 100Mbit Ethernet, on the other hand, would be (1/100000000)*64*8 = > 5.12 microseconds. (100 Mbit/s, 64 byte minimum ethernet packet, > 8 bits/byte). > From ISMAEVAL at terra.es Thu Jan 27 15:40:39 2005 From: ISMAEVAL at terra.es (Ismael Valladolid Torres) Date: Sun Jan 21 12:11:18 2007 Subject: MIDI versus TCP/IP, was Re: [music-dsp] how does it work ... ? In-Reply-To: <200501270951.j0R9pZ601122@mortem.sounds.wa.com> References: <41F6F4AE.8020704@gmx.de> <99B06CE0-6F3C-11D9-94FD-000A9595B180@u-he.com> <41F804F9.3060809@gmx.de> <015801c50452$99adc9e0$4da8a8c0@dtg.qinetiq.com> <200501270951.j0R9pZ601122@mortem.sounds.wa.com> Message-ID: <20050127204039.GC4743@buddha> Brian Willoughby escribe: > USB-MIDI has guaranteed delivery similar to TCP. But USB-MIDI was not even > designed to perform as well as USB offers, so the latency can be random. That's why manufacturers have developed timestamped USB-MIDI protocols (at least on their Windows and Mac OS drivers), allowing software MIDI sequencers to develop a timing as precise as that of older hardware sequencers. Still nothing compares to that lovely Yamaha QY-20 playing techno beats like a hammer. :) Cordially, Ismael From ISMAEVAL at terra.es Thu Jan 27 15:40:39 2005 From: ISMAEVAL at terra.es (Ismael Valladolid Torres) Date: Sun Jan 21 12:11:18 2007 Subject: MIDI versus TCP/IP, was Re: [music-dsp] how does it work ... ? In-Reply-To: <200501270951.j0R9pZ601122@mortem.sounds.wa.com> References: <41F6F4AE.8020704@gmx.de> <99B06CE0-6F3C-11D9-94FD-000A9595B180@u-he.com> <41F804F9.3060809@gmx.de> <015801c50452$99adc9e0$4da8a8c0@dtg.qinetiq.com> <200501270951.j0R9pZ601122@mortem.sounds.wa.com> Message-ID: <20050127204039.GC4743@buddha> Brian Willoughby escribe: > USB-MIDI has guaranteed delivery similar to TCP. But USB-MIDI was not even > designed to perform as well as USB offers, so the latency can be random. That's why manufacturers have developed timestamped USB-MIDI protocols (at least on their Windows and Mac OS drivers), allowing software MIDI sequencers to develop a timing as precise as that of older hardware sequencers. Still nothing compares to that lovely Yamaha QY-20 playing techno beats like a hammer. :) Cordially, Ismael From alex at pixar.com Thu Jan 27 16:58:37 2005 From: alex at pixar.com (Alex Stahl) Date: Sun Jan 21 12:11:18 2007 Subject: MIDI versus TCP/IP, was Re: [music-dsp] how does it work ... ? In-Reply-To: <20050127204039.GC4743@buddha> References: <41F6F4AE.8020704@gmx.de> <99B06CE0-6F3C-11D9-94FD-000A9595B180@u-he.com> <41F804F9.3060809@gmx.de> <015801c50452$99adc9e0$4da8a8c0@dtg.qinetiq.com> <200501270951.j0R9pZ601122@mortem.sounds.wa.com> <20050127204039.GC4743@buddha> Message-ID: <98E1AB88-70AE-11D9-8100-000A95C5FA68@pixar.com> There are time-stamped protocols for audio networking as well, that offer predictable and constant latencies in the couple of msec range. Good enough for some applications, where this much latency can be compensated with pre-read data, or where it is overwhelmed by acoustic latency, or both (as in cinema). On Jan 27, 2005, at 12:40 PM, Ismael Valladolid Torres wrote: > Brian Willoughby escribe: >> USB-MIDI has guaranteed delivery similar to TCP. But USB-MIDI was >> not even >> designed to perform as well as USB offers, so the latency can be >> random. > > That's why manufacturers have developed timestamped USB-MIDI protocols > (at least on their Windows and Mac OS drivers), allowing software MIDI > sequencers to develop a timing as precise as that of older hardware > sequencers. Still nothing compares to that lovely Yamaha QY-20 playing > techno beats like a hammer. :) > > Cordially, Ismael > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book > reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp From frederik at hjorth-jensen.dk Thu Jan 27 17:59:21 2005 From: frederik at hjorth-jensen.dk (Frederik Hjorth-Jensen) Date: Sun Jan 21 12:11:18 2007 Subject: [music-dsp] VST vs. DirectX Message-ID: <002b01c504c3$d6dbf3c0$0200000a@dfg> Hi I have recently startet on developing my own plugins as a way of doing real time DSP. And I'm in doubt about which technology I should choose when talking either VST or DirectX. I have tried to write a simple plugin with both and I dont think it's harder to develope DirectX to VST and vice versa (but I'm inexperienced so I might get a surprise) and they both works fine. So my question is more about which technology is going to last in the future? Some of my colleages says that DirectX is on it's way out but I'm not sure.... greets, Frederik From arcane at arcanemethods.com Fri Jan 28 02:54:17 2005 From: arcane at arcanemethods.com (Bob Cain) Date: Sun Jan 21 12:11:18 2007 Subject: [music-dsp] VST vs. DirectX In-Reply-To: <002b01c504c3$d6dbf3c0$0200000a@dfg> References: <002b01c504c3$d6dbf3c0$0200000a@dfg> Message-ID: <41F9EFA9.6070903@arcanemethods.com> I recommend VST since it is reputed to be fairly easy to write them so that they are easily ported among Mac, Win and Linux systems. Bob Frederik Hjorth-Jensen wrote: > Hi > > I have recently startet on developing my own plugins as a way of doing real time DSP. And I'm in doubt about which technology I should choose when talking either VST or DirectX. I have tried to write a simple plugin with both and I dont think it's harder to develope DirectX to VST and vice versa (but I'm inexperienced so I might get a surprise) and they both works fine. > > So my question is more about which technology is going to last in the future? Some of my colleages says that DirectX is on it's way out but I'm not sure.... > > greets, > Frederik > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > > -- "Things should be described as simply as possible, but no simpler." A. Einstein From jon.guerin at gmail.com Fri Jan 28 09:54:18 2005 From: jon.guerin at gmail.com (jon guerin) Date: Sun Jan 21 12:11:18 2007 Subject: [music-dsp] VST vs. DirectX In-Reply-To: <41F9EFA9.6070903@arcanemethods.com> References: <002b01c504c3$d6dbf3c0$0200000a@dfg> <41F9EFA9.6070903@arcanemethods.com> Message-ID: I have to second VST. Steinberg's done quite a good job with the VST and ASIO systems. There's also a VSTGUI API for making GUIs for your VST plugins. All three of these APIs are well documented and common-sensical. I think if you download Cakewalk's (?) DXi package for creating DX plugins and play around with it for a while and then go back and look over the VST packages again, you will see that there really isn't any question about which route to take. .jg On Thu, 27 Jan 2005 23:54:17 -0800, Bob Cain wrote: > I recommend VST since it is reputed to be fairly easy to > write them so that they are easily ported among Mac, Win and > Linux systems. > > Bob > From sbenno at gardena.net Sat Jan 29 10:50:58 2005 From: sbenno at gardena.net (Benno Senoner) Date: Sun Jan 21 12:11:18 2007 Subject: [music-dsp] Garritan Stradivari Violin with Sonic Morphing Message-ID: <41FBB0E2.1030202@gardena.net> Hi, just curious about your thoughts: read this thread and watch the videos, very impressive. http://www.northernsounds.com/forum/showthread.php?t=30170&highlight=stradivardi I'd be curious about this sonic morphing and what it does. Basically as far as I understands, when you do sample crossfading when you are in the middle of 2 layers eg you mix together sample 1 and sample 2 you could run into phasing effects especially in solo instruments because the waves are not aligned. So the question is does the algorithm in your opinion work offline or in real time. Eg you sample a bunch of layers and then run an algorithm on the samples that tries to align phases and the frequency. Probably you need a pitchshifting algorithm too becausse small variations of pitch can introduce phasing after a small number cycles in the wave. If this offline method is fleasible it would have the advantage that the playback engine is very simple (a traditonal sample playback engine with crossfading support) and you can achieve high polyphony without too much cpu load. An alternative method that comes to mind (not sure what the sonic result looks like) would be to store the samples in the frequency domanin using the STFT (short term fourier transformation) http://cnmat.cnmat.berkeley.edu/~alan/MS-html/MSv2.html Basically you subdivide a long sample in small pieces, apply FFT to it , modify coefficients and the apply the inverse FFT to it. Since the fourier transformation assumes periodic signals you need to use windowing techniques and overlapping to achieve decent audio quality (but it burns quite some CPU since you have to do the FFT operations multiple times per block (eg 4-8fold overlapping gives decent results). A few years ago I did a FFT filter for an university project where you could change the filter curve in real time using an arbitrary FFT size. It sounded quite good and impulse response measurements gave good results too. So what one could do is "crossfade" in the frequenct domain. Eg doing the average of the 2 frequency diagrams of a block and then convert it back in the time domain. Not sure what to do with the phase information in order to minimize phasing effects ? (keep them constant over the whole crossfading layer ?) opinions ? cheers, Benno http://www.linuxsampler.org From kaleja at estarcion.com Sat Jan 29 21:28:11 2005 From: kaleja at estarcion.com (Russell Borogove) Date: Sun Jan 21 12:11:18 2007 Subject: [music-dsp] VST vs. DirectX References: <002b01c504c3$d6dbf3c0$0200000a@dfg><41F9EFA9.6070903@arcanemethods.com> Message-ID: <002e01c50673$5a200220$0601000a@jaseroque> > All three of these APIs [VST, ASIO, VSTGUI] are well documented and > common-sensical. If VST and VSTGUI are well-documented, I'm a three-headed monkey. From vtatila at mail.student.oulu.fi Sun Jan 30 04:51:11 2005 From: vtatila at mail.student.oulu.fi (Veli-Pekka Tatila) Date: Sun Jan 21 12:11:18 2007 Subject: [music-dsp] VST vs. DirectX References: <002b01c504c3$d6dbf3c0$0200000a@dfg><41F9EFA9.6070903@arcanemethods.com> <002e01c50673$5a200220$0601000a@jaseroque> Message-ID: <000b01c506b1$3e4fc380$8c01a8c0@tollb137> Russell Borogove wrote: > If VST and VSTGUI are well-documented, I'm a three-headed monkey. Hehe, a good point. That is I'm just learning VST and here are my top 10 annoyences so far (starting with the docs). Note that these are only the bad things, there are things I like in VST as well. And I also understand the lack of OOP because the underlying interface is in C and thus more portable and faster. Still having to re-invent the wheel in a scalable plug-in architecture is annoying. 0. Documentation sucks in many regards. -there are consistant typos "ample frames" -sometimes you see the writer changing (pre and post conditions in some funcs but not in others) -not all functions are even documented -only 2 of the 7 tutorial examples are explained -and how would the following sound? * "The actual mechanism in which your class gets constructed is not important right now" Part of the class docs and never properly explained) * "I hope all of this is utterly correct because i can't access the sources while writing this" Mac specific but still. Don't they have formal technical reviews at Steinberg's? Come on this is final plug-in documentation. 1. The architecture seems like a blob to me from an object-oriented point of view. 2. About a dozen changes need to be made when adding a new parameter just to make the String UI work. (getting around this requires you to do some hashlookups and build your own OOPy architecture or something) 3. Preset management requires a lot of manual effort and care by default. 4. In synths process and processReplacing are almost identical resulting in cut-and-paste coding (another anti-pattern identified). The way around this is to call processReplacing in process. 5. MIDI data is real raw, there are no definitions for even something like a note on, even though this is a specialized framework. Compare to Java. Oh yes and MIDi learns etc... needd to be re-coded by every VST programmer. 6. Some string limits are poorly documented and not really checcked. IT is not specified whether the terminating null is part of the given limit. Don't even dream of localizing synths using unicode, no way. WHy don't they support this as we are talking about computer programs and not a static piece of hardware? 7. The parameter order in float2string and other such functions is different from strcpy which also gets used a lot. 8. Some functions are host-to-plug and others are plug-to-host yet both are in the same class and thus overridable. As no common naming convention is used you must check the docs to see which way something like setBlockSize goes. 9. Some functions are only allowed to be called in the constructor. WOuldn't it be better to feed such params to a plugin factory object that would give you the final plugin (which wouldn't have the methods for changing these things later on, of course). PS: Not sure if DirectX is any better. -- With kind regards Veli-Pekka T?til? (vtatila@mail.student.oulu.fi) Accessibility, game music, synthesizers and more: http://www.student.oulu.fi/~vtatila From martin.eisenberg at udo.edu Sun Jan 30 07:02:34 2005 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Sun Jan 21 12:11:18 2007 Subject: [music-dsp] VST vs. DirectX References: <002b01c504c3$d6dbf3c0$0200000a@dfg><41F9EFA9.6070903@arcanemethods.com><002e01c50673$5a200220$0601000a@jaseroque> <000b01c506b1$3e4fc380$8c01a8c0@tollb137> Message-ID: <001901c506c3$99f3ac80$1e0d060a@mooncode> From: "Veli-Pekka Tatila" > * "I hope all of this is utterly correct because i can't access > the sources while writing this" > Mac specific but still. Don't they have formal technical reviews > at Steinberg's? Come on this is final plug-in documentation. Sweet Jesus, I hadn't noticed that one yet. > 2. About a dozen changes need to be made when adding > a new parameter just to make the String UI work. > (getting around this requires you to do some hashlookups > and build your own OOPy architecture or something) Assuming that the parameter set cannot change dynamically (which I think is the case, but that doesn't mean much) you just need an array/some linear collection of param descriptors, don't you? > 4. In synths process and processReplacing are almost > identical resulting in cut-and-paste coding (another anti- > pattern identified). The way around this is to call > processReplacing in process. I'm having an idea how to ameliorate that with templates: struct Adder { float operator()(float& dest, float src) { return dest += src; } } struct Replacer { float operator()(float& dest, float src) { return dest = src; } } template void Plug::doProcess(float** out, yadda yadda) { for(long n ...) fb = assign()(out[0][n], sin(fb * n)); } void Plug::process(...) { doProcess(args); } void Plug::processReplacing(...) { doProcess(args); } But I think it would make for more readable code to wrap the output array with something providing the appropriate assignment semantics instead of just abstracting the assignment itself. That might also help to encompass blockwise processing. While the doProcess object code is still duplicated, at least the machine does the work for you like it should. Martin From rfreeze at charter.net Sun Jan 30 07:58:19 2005 From: rfreeze at charter.net (BobF) Date: Sun Jan 21 12:11:18 2007 Subject: [music-dsp] VST vs. DirectX In-Reply-To: <001901c506c3$99f3ac80$1e0d060a@mooncode> References: <002b01c504c3$d6dbf3c0$0200000a@dfg><41F9EFA9.6070903@arcanemethods.com><002e01c50673$5a200220$0601000a@jaseroque> <000b01c506b1$3e4fc380$8c01a8c0@tollb137> <001901c506c3$99f3ac80$1e0d060a@mooncode> Message-ID: <41FCD9EB.7000909@charter.net> Don't even consider DX/i from TTS. I was making the same decision well over a year ago. I asked RK about the future of the SDK. He said an update was coming right behind the release of Sonar 3 ... Still on the same version and Sonar 4 has been out long for two minor updates. You'll see an occassional post from RK on the vst-plugin list - he's chairing an MMA working group to define requirements for an industry-wide plug-in interface standard. I'm *guessing* this means DX/i SDK is about as good as its going to get. BobF From citizenchunk at gmail.com Sun Jan 30 14:32:28 2005 From: citizenchunk at gmail.com (Citizen Chunk) Date: Sun Jan 21 12:11:18 2007 Subject: [music-dsp] VST vs. DirectX In-Reply-To: <000b01c506b1$3e4fc380$8c01a8c0@tollb137> References: <002b01c504c3$d6dbf3c0$0200000a@dfg> <41F9EFA9.6070903@arcanemethods.com> <002e01c50673$5a200220$0601000a@jaseroque> <000b01c506b1$3e4fc380$8c01a8c0@tollb137> Message-ID: > 2. About a dozen changes need to be made when adding a new parameter just to > make the String UI work. > (getting around this requires you to do some hashlookups and build your own > OOPy architecture or something) i hate the parameter situation too. i thought about a better, more OOP way of handling the parameters (as opposed to "Switch Statement Spaghetti"), but ultimately came to the conclusion that it wasn't going to make my coding any easier, other than maybe putting the Name and Label assignment in 1 place. you still need to assign it somewhere in your code, and it won't change for the duration of the plugin. (which is one of MY gripes about VST.) btw, does AU use objects/structs for each parameter? > 3. Preset management requires a lot of manual effort and care by default. don't know about the chunk method, but i've simplified my presets by using a vector of floats for each preset, rather than the method used in the SDK, which is individually-named float values. it just makes accessing the values easier. i still don't know why they have getProgramName() and getProgramNameIndexed(). seems to me like getProgramNameIndexed() would cover both bases... > 4. In synths process and processReplacing are almost identical resulting in > cut-and-paste coding (another anti-pattern identified). The way around this > is to call processReplacing in process. as someone has already pointed out, there is a better way, using function templates. real easy, and efficient. do a search on www.kvraudio.com Dev forum for a post by "texture" regarding this method. > 7. The parameter order in float2string and other such functions is different > from strcpy which also gets used a lot. i don't use float2string anymore; just sprintf(), which allows for manipulation of decimal point precision. == chunk From fatboy at vodafone.net Sun Jan 30 16:31:24 2005 From: fatboy at vodafone.net (Matt Avent) Date: Sun Jan 21 12:11:18 2007 Subject: [music-dsp] RE: a thought.. chameleon group project In-Reply-To: <004801c50461$66b08370$6501a8c0@Pbalris> Message-ID: <002701c50713$0c79a940$1eea9b51@HP18053272125> Hi all I'd really like to get involved in a group chameleon project. I've got pretty good dsp and c++ skills; just starting to learn the assembler side of things now and struggling somewhat... Would also have no problem helping with some of the admin side of things. Maybe soundart could host the source control? Matt A -----Original Message----- From: chameleon-dev-bounces@ampfea.org [mailto:chameleon-dev-bounces@ampfea.org] On Behalf Of Gert van Santen Sent: 27 January 2005 11:15 To: Chameleon hackers in the ampfea.org community. Subject: Re: a thought.. tony scharf wrote: > You know, I had a thought... > > has anyone actually tried to setup a *group* project with the > chameleon? a full open source project? you know...setup through > sourceforge or some such? > > I dont know...maybe if there were some *community* projects, the > community would grow. Also, a lot of people each doing a little is > far better than one person trying to do a lot. > > Any takers? I'd be up for this, as it would be a great way to learn > and use the chameleon. > Sounds like a good idea to me, Tony. The problem is that I'm not a programmer. I just use the Chammy with the skins that other people have made. I hope others might be interested, though. Cheers, Gert www.waveworld.tv _______________________________________________ Chameleon-dev mailing list Chameleon-dev@ampfea.org http://www.ampfea.org/mailman/listinfo/chameleon-dev Brought to you by: http://www.ampfea.org From urs at u-he.com Sun Jan 30 16:35:04 2005 From: urs at u-he.com (Urs Heckmann) Date: Sun Jan 21 12:11:19 2007 Subject: [music-dsp] VST vs. DirectX In-Reply-To: References: <002b01c504c3$d6dbf3c0$0200000a@dfg> <41F9EFA9.6070903@arcanemethods.com> <002e01c50673$5a200220$0601000a@jaseroque> <000b01c506b1$3e4fc380$8c01a8c0@tollb137> Message-ID: Hiya, >> 2. About a dozen changes need to be made when adding a new parameter >> just to >> make the String UI work. >> (getting around this requires you to do some hashlookups and build >> your own >> OOPy architecture or something) > > i hate the parameter situation too. i thought about a better, more OOP > way of handling the parameters (as opposed to "Switch Statement > Spaghetti"), but ultimately came to the conclusion that it wasn't > going to make my coding any easier, other than maybe putting the Name > and Label assignment in 1 place. you still need to assign it somewhere > in your code, and it won't change for the duration of the plugin. > (which is one of MY gripes about VST.) Well, I have done it this way: All plugins consist of a number of modules (oscillators, filters, delays etc.). Each module has a set of parameters, buffers whatsoever. On top of these I have a management object. When I create a signal flow, I create those modules and tell the management object about it. The management object will then publish a parameter list, allocate memory etc. In my destructor, I just kill the management object and I'm done. Not having to maintain a central parameter list, not having anything that includes more than 1-3 headers (no deep dependencies) etc. and - of course - not having any code specific to plugin api in the dsp classes was about the best thing I ever did ;-) > btw, does AU use objects/structs for each parameter? Yes. VST has this too, maybe not as elegant as AU, but I know only 1 plugin and 1 host which afaik supports this (SFX Machine and Live) > >> 3. Preset management requires a lot of manual effort and care by >> default. > > don't know about the chunk method, but i've simplified my presets by > using a vector of floats for each preset, rather than the method used > in the SDK, which is individually-named float values. it just makes > accessing the values easier. > > i still don't know why they have getProgramName() and > getProgramNameIndexed(). seems to me like getProgramNameIndexed() > would cover both bases... IIRC getProgramName() was first (VST 1.0?), the other one came later. In the beginings, when a plugin was opened, the host would iterate through the presets (thus change the current Program one by one) and read out the preset name. Which of course is stupid, as it can take quite some time (i.e. in a plugin that loads samples for each preset/program) - getProgramName is a relic... > >> 4. In synths process and processReplacing are almost identical >> resulting in >> cut-and-paste coding (another anti-pattern identified). The way >> around this >> is to call processReplacing in process. > > as someone has already pointed out, there is a better way, using > function templates. real easy, and efficient. do a search on > www.kvraudio.com Dev forum for a post by "texture" regarding this > method. I would just implement Process(). In ProcessReplacing() I would just clear the buffer first before calling into Process(). With current machines, the overhead of clearing the buffer is, uhm, academic ;-) > >> 7. The parameter order in float2string and other such functions is >> different >> from strcpy which also gets used a lot. > > i don't use float2string anymore; just sprintf(), which allows for > manipulation of decimal point precision. Hehehe, what I never understood in VST is, you can't use the plugin's internal string conversion routines for the "Displays" in VSTGUI... Cheers, ;) Urs From jeffmcc at ihug.co.nz Sun Jan 30 17:02:24 2005 From: jeffmcc at ihug.co.nz (Jeff McClintock) Date: Sun Jan 21 12:11:19 2007 Subject: [music-dsp] Re: VST vs. DirectX In-Reply-To: <20050130193303.84CDC19794EB@music.calarts.edu> References: <20050130193303.84CDC19794EB@music.calarts.edu> Message-ID: <41FD5970.6020005@ihug.co.nz> VST has many 'annoyances', many due I think to the way VST evolved in steps from a very basic standard. Each iteration had to accommodate the limitations of the previous. There was was no up-front grand design. Despite these issues, VST works, it's very widely supported by hosts, much more so than DXi, and there's plenty of people available to help you on the mailing list. I suspect the only reason DXi survives at all is that most large plugin vendors have their own "portability layer" allowing them to deploy the same plugin on VST, DXi and AU with little effort. There is no need for 3 plugin standards, eventually DXi will die. GMPI is a new open standard in development. having the benefit of hindsight, the GMPI API can be clean, modern and consistent. There's been much thought into sparing the plugin coder from complications such as threading issues. for example.. In VST, SetParameter() might be called from either the UI thread, or the background automation playback thread, at the same time the host may be calling DoProcess() on a 3rd thread. This mess only works in most cases because VST parameters are 32 bit floats, which can be updated 'atomically' i.e. without mutex type locking code. When you attempt anything more complicated in setParameter(), like converting that parameter value to a string, that's when the headaches start... The GMPI SDK will include free VST wrapper code. You write one plugin that can be deployed on both platforms. In fact with care, I figure a single dll could support both standards. very cool. Jeff From urs at u-he.com Sun Jan 30 17:21:05 2005 From: urs at u-he.com (Urs Heckmann) Date: Sun Jan 21 12:11:19 2007 Subject: [music-dsp] Re: VST vs. DirectX In-Reply-To: <41FD5970.6020005@ihug.co.nz> References: <20050130193303.84CDC19794EB@music.calarts.edu> <41FD5970.6020005@ihug.co.nz> Message-ID: <3BC220A6-730D-11D9-89CE-000A9595B180@u-he.com> Jeff McClintock: > The GMPI SDK will include free VST wrapper code. You write one plugin > that can be deployed on both platforms. In fact with care, I figure a > single dll could support both standards. very cool. When will that be? I've seen that they made it to sorta draft of requirements recently, does that mean that they start on kinda concept now? Cheers, ;) Urs From culann at rocudo.com Mon Jan 31 04:35:49 2005 From: culann at rocudo.com (Culann mac Cabe) Date: Sun Jan 21 12:11:19 2007 Subject: [music-dsp] Anybody have experience with Windows ACM driver writing? In-Reply-To: <3BC220A6-730D-11D9-89CE-000A9595B180@u-he.com> Message-ID: <01LK8W5X87RW0019ZW@beacon.nuigalway.ie> Help! Does anyone have any experience with writing Windows ACM drivers (repeat: drivers, not clients)? I'm writing one and am observing strange behaviour for different clients (SoundRecorder, WinMedia Player, WinAmp) related to my responses to the ACMD_STREAM_SIZE and ACMD_STREAM_CONVERT messages. Yours hopefully, Culann From joshscholar at yahoo.com Mon Jan 31 15:34:05 2005 From: joshscholar at yahoo.com (Joshua Scholar) Date: Sun Jan 21 12:11:19 2007 Subject: [music-dsp] Anybody have experience with Windows ACM driver writing? References: <01LK8W5X87RW0019ZW@beacon.nuigalway.ie> Message-ID: <000501c507d4$366c8530$94e22641@antssoftware.com> I wrote one once. Not that I know much about them. One huge problem was the assumption, in the design, that compressors are NEVER variable bit rate. Any attempt to get around this problem will probably fail for some clients. Joshua Scholar ----- Original Message ----- From: "Culann mac Cabe" To: "'a list for musical digital signal processing'" Sent: Monday, January 31, 2005 1:35 AM Subject: [music-dsp] Anybody have experience with Windows ACM driver writing? > Help! > > Does anyone have any experience with writing Windows ACM drivers (repeat: > drivers, not clients)? I'm writing one and am observing strange behaviour > for different clients (SoundRecorder, WinMedia Player, WinAmp) related to my > responses to the ACMD_STREAM_SIZE and ACMD_STREAM_CONVERT messages. > > Yours hopefully, > Culann > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp From douglas at roar.music.columbia.edu Sat Jan 1 00:00:01 2005 From: douglas at roar.music.columbia.edu (douglas repetto) Date: Wed Jun 27 19:18:12 2007 Subject: [music-dsp] [admin] music-dsp FAQ Message-ID: <200501010500.j01501UW031863@roar.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://shoko.calarts.edu/musicdsp/musicdspFAQ.html also of interest to new and not-so-new list members: the music-dsp list archives http://shoko.calarts.edu/musicdsp/musicdsparchives.html the music-dsp source code archive http://www.musicdsp.org music-dsp books and reviews http://shoko.calarts.edu/musicdsp/dspbooks.html all this and more at: http://shoko.calarts.edu/musicdsp hotdawg! douglas (this is an automated message sent out on the 1st and 15th of each month) From david.fee at qub.ac.uk Sun Jan 2 10:40:19 2005 From: david.fee at qub.ac.uk (David Fee) Date: Wed Jun 27 19:18:12 2007 Subject: [music-dsp] Implementing kurtosis maximization for dereverberation Message-ID: <41D815E3.2090900@qub.ac.uk> Hi I'm wondering if anyone has come across a paper "Speech dereverberation via maximum-kurtosis subband adaptive filtering" ICASSP 2001, Gillespie, Malvar and Florencio. I've been able to get the technique to give good results without splitting the signal into subbands. However, I haven't been able to get the subband approach to work successfully. The paper recommends using Modulated Complex Lapped Transforms (MCLT). I've been using Modulated Lapped Transform (purely real) as outlined in Malvar's book but with no real success. Would anybody have any ideas on this or be prepared to discuss it? Thanks David Fee -- David Fee Innovative Audio Systems Group Sonic Arts Research Centre Queen's University, Belfast Tel. (mob) +44 (0)7729 883433 Tel. (office) +44 (0)28 9027 4761 Email david.fee@qub.ac.uk From tsquank at yahoo.com Sun Jan 2 20:35:05 2005 From: tsquank at yahoo.com (Darren Gibbs) Date: Wed Jun 27 19:18:12 2007 Subject: [music-dsp] Fixed Point FFT question Message-ID: Hello, I've been searching for info about doing real FFTs on fixed point processors and found a post from r b-j in April 2000: > i have _definitely_ found an advantage of using such an algorithm over > zero > padding the imaginary parts of the input and performing an N point > complex > FFT. i don't recall how Numerical Recipes sets it up but i have set > it up > where the even indexed real samples go into the real parts and the odd > indexed samples go into the imaginary parts, an N/2 point complex FFT > is > done, and the result of that (which does not have the symmetry it > would if > the input had zero imag part) is untangled to get the result you want. > even though the N/2 point complex FFT needs N/4 twiddle factors (the > sine > function is sampled N/8 equally spaced samples from theta=0 to > theta=pi/2), > you still need the the other N/4 twiddles (sample the same quarter > cycle > sine N/4 times) to get the required N/2 twiddles for an N point FFT. > the > other N/4 twiddles are used in the "untangling" part of the algorithm. I found on the net a chunk of (PXA255) XScale/ARM assembler code that does a "split radix" complex FFT. I'm not wise in the ways of FFT algorithms, but I don't think I need a complex FFT for my situation. Could someone spare a few sentences to describe in high-level terms the difference between a complex and real FFT and appropriate contexts for using one over the other. I've found piles of articles on DFT v.s. FFT, and incredibly over-my-head detailed info on implementing various algorithms, but I don't fully understand this distinction. If I correctly understand the quote above, it's possible to use the complex FFT function to perform a real FFT, thus saving many cycles. Could someone hand hold me a little bit as to how this untangling works? Do I need to modify the complex FFT algorithm itself, or just massage the output somehow? thanks for any advice, darren From rbj at surfglobal.net Sun Jan 2 23:42:07 2005 From: rbj at surfglobal.net (robert bristow-johnson) Date: Wed Jun 27 19:18:12 2007 Subject: [music-dsp] Fixed Point FFT question In-Reply-To: Message-ID: on 01/02/2005 20:35, Darren Gibbs at tsquank@yahoo.com wrote: > Hello, > > I've been searching for info about doing real FFTs on fixed point > processors and found a post from r b-j in April 2000: > >> i have _definitely_ found an advantage of using such an algorithm over zero >> padding the imaginary parts of the input and performing an N point complex >> FFT. i don't recall how Numerical Recipes sets it up but i have set it up >> where the even indexed real samples go into the real parts and the odd >> indexed samples go into the imaginary parts, an N/2 point complex FFT is >> done, and the result of that (which does not have the symmetry it would if >> the input had zero imag part) is untangled to get the result you want. >> even though the N/2 point complex FFT needs N/4 twiddle factors (the sine >> function is sampled N/8 equally spaced samples from theta=0 to theta=pi/2), >> you still need the the other N/4 twiddles (sample the same quarter cycle >> sine N/4 times) to get the required N/2 twiddles for an N point FFT. the >> other N/4 twiddles are used in the "untangling" part of the algorithm. > > I found on the net a chunk of (PXA255) XScale/ARM assembler code that > does a "split radix" complex FFT. I'm not wise in the ways of FFT > algorithms, but I don't think I need a complex FFT for my situation. > Could someone spare a few sentences to describe in high-level terms the > difference between a complex and real FFT and appropriate contexts for > using one over the other. I've found piles of articles on DFT v.s. > FFT, and incredibly over-my-head detailed info on implementing various > algorithms, but I don't fully understand this distinction. the FFT is a "fast" way of performing the DFT. it is sorta like comparing some slick "Quick sort" algorithm to the bonehead "Bubble sort". they both do the same thing, but one might do it more efficiently. > If I correctly understand the quote above, it's possible to use the > complex FFT function to perform a real FFT, thus saving many cycles. yes. it saves computation over simply zeroing the imaginary part and performing the regular old N point FFT. you put all the even indexed samples in the real part of the N/2 input points, all of the odd indexed samples in the imaginary part those N/2 input points, ... > Could someone hand hold me a little bit as to how this untangling > works? Do I need to modify the complex FFT algorithm itself, ... run a normal N/2 point FFT, and ... > or just massage the output somehow? ... diddle with (massage) the the result. oh geez, if i knew the post you mention, i might have had some math in it. lessee, you have N samples of real input data: u[n] 0 <= n < N you conceptually split it into two N/2 sized blocks of real data: u_e[n] = u[2*n] 0 <= n < N/2 u_o[n] = u[2*n+1] construct N/2 points of complex input data: x[n] = u_e[n] + j*u_o[n] 0 <= n < N/2 run a N/2 point complex DFT on that and get: X[k] = U_e[k] + j*U_o[k] 0 <= k < N/2 Because the input to this DFT was not real, the conjugate symmetry is not valid (unless of course all of the odd samples of u[n] are zero). X[N/2 - k] = conj{ X[k] } if and only if Im{ x[n] } = 0 But we use that symmetry for U_e[k] and U_o[k] since they are DFTs of purely real input. The goal is the N point DFT of u[n] which is: N-1 U[k] = sum{ u[n] * exp(-j*2*pi*n*k/N) } n=0 which, if N is even, can be split into two summations: N/2-1 U[k] = sum{ u[2*n] * exp(-j*2*pi*(2*n)*k/N) } n=0 N/2-1 + sum{ u[2*n+1] * exp(-j*2*pi*(2*n+1)*k/N) } n=0 N/2-1 = sum{ u_e[n] * exp(-j*2*pi*n*k/(N/2)) } n=0 N/2-1 + exp(-j*2*pi*k/N) * sum{ u_o[n] * exp(-j*2*pi*n*k/(N/2)) } n=0 = U_e[k] + exp(-j*2*pi*k/N) * U_o[k] So if we can untangle U_e[k] and U_o[k] (both real and imaginary parts) from X[k] = U_e[k] + j*U_o[k] then we can plug those U_e[k] and U_o[k] into U[k] = U_e[k] + exp(-j*2*pi*k/N) * U_o[k] then we have the result you are looking for. It is okay that U_e[k] and U_o[k] are defined for only N/2 points because U[k], being the DFT of a real input, is conjugate symmetric. U[N - k] = conj{ U[k] } because Im{ u[n] } = 0 Also, because Im{ u_e[n] } = Im{ u_o[n] } = 0 U_e[N/2 - k] = conj{ U_e[k] } U_o[N/2 - k] = conj{ U_o[k] } We use this fact to extract U_e[k] and U_o[k] out of X[k] 2*Re{ U_e[k] } = Re{ X[k] + X[N/2-k] } 2*Im{ U_e[k] } = Im{ X[k] - X[N/2-k] } 2*Re{ U_o[k] } = Im{ X[k] + X[N/2-k] } -2*Im{ U_o[k] } = Re{ X[k] - X[N/2-k] } (keep the periodicity of the DFT in mind when you think about X[N/2-0].) So U[k] = U_e[k] + exp(-j*2*pi*k/N) * U_o[k] = 0.5 * ( Re{ X[k] + X[N/2-k] } + j*Im{ X[k] - X[N/2-k] } ) + 0.5 * exp(-j*2*pi*k/N) * ( Im{ X[k] + X[N/2-k] } - j*Re{ X[k] - X[N/2-k] } ) I skipped a couple of steps getting the last two equations, but just use that conjugate symmetry and slug it out. > thanks for any advice, clear as mud? -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From rbj at surfglobal.net Sun Jan 2 23:45:20 2005 From: rbj at surfglobal.net (robert bristow-johnson) Date: Wed Jun 27 19:18:12 2007 Subject: [music-dsp] Fixed Point FFT question In-Reply-To: Message-ID: i made a mental note about the subject line and then forgot it. i would *not* recommend any of this for Fixed-point FFT unless you gotta lotta bits (32 bit words with 64 bit accumulators). the roundoff noise of the FFT (as opposed to the straight forward slow DFT) is a bitch. definitely not good for 16 bit words. but if you're doing double precision float, this works very well. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From tsquank at yahoo.com Mon Jan 3 15:22:49 2005 From: tsquank at yahoo.com (Darren Gibbs) Date: Wed Jun 27 19:18:12 2007 Subject: [music-dsp] Fixed Point FFT question In-Reply-To: References: Message-ID: <3D0CEABD-5DC5-11D9-8B3A-000D93C2E232@yahoo.com> On Jan 2, 2005, at 8:42 PM, robert bristow-johnson wrote: >> Could someone spare a few sentences to describe in high-level terms >> the >> difference between a complex and real FFT and appropriate contexts for >> using one over the other. I've found piles of articles on DFT v.s. >> FFT, and incredibly over-my-head detailed info on implementing various >> algorithms, but I don't fully understand this distinction. > > the FFT is a "fast" way of performing the DFT. it is sorta like > comparing > some slick "Quick sort" algorithm to the bonehead "Bubble sort". they > both > do the same thing, but one might do it more efficiently. Yes, the DFT v.s. FFT I get... but the real v.s. complex I'm less clear about. > oh geez, if i knew the post you mention, i might have had some math in > it. nope... just the possibility teaser I quoted... :-) > lessee, you have N samples of real input data: > > u[n] 0 <= n < N > > you conceptually split it into two N/2 sized blocks of real data: > > u_e[n] = u[2*n] > 0 <= n < N/2 > u_o[n] = u[2*n+1] [lots of cool looking equations that make me really really wish I'd taken more math in college clipped] > clear as mud? Well, conceptually I was able to follow you, but not deep enough to implement it in code... I reckon I'm gonna to have to admit a certain level of defeat, for the time being treat the FFT as a slightly translucent black box, and find someone to implement the low-level magic for me. > i would *not* recommend any of this for Fixed-point FFT unless you > gotta > lotta bits (32 bit words with 64 bit accumulators). the roundoff > noise of > the FFT (as opposed to the straight forward slow DFT) is a bitch. Hmmm.... If I've correctly understood certain bits of the articles I've been perusing, a real FFT requires 1/2 the space/time to perform. In general, is it more clever to use the complex FFT in the way you've described, or to implement a real FFT as a separate algorithm? The ARM CPU I'm targeting is 32-bit, but does FP in software emulation which is what got me on the trail of a fixed point solution. I haven't been able to find an explanation I could grok that describes the algorithmic difference between a real v.s. complex FFT. Thanks! darren From paulwebb at rocketmail.com Mon Jan 3 16:34:33 2005 From: paulwebb at rocketmail.com (paul webb) Date: Wed Jun 27 19:18:13 2007 Subject: [music-dsp] filtered grains in granular synthesis In-Reply-To: <3D0CEABD-5DC5-11D9-8B3A-000D93C2E232@yahoo.com> Message-ID: <20050103213433.69717.qmail@web51410.mail.yahoo.com> hello, I am coding myself a granular synthesis engine and am now adding possibility to have grains that can have individual filters. Knowing when the grain has finished is easy when it has no filter, its just its duration, but what techniques do people use to decide to stop the grain audio when it has a filter. For example if it has a IIR filter the grain envelope may be down to zero but the tap of the filter can still be supplying audio. I am making a few techniques such as *just stopping everything when grain envelope finishes *letting the filter carry on for X ammount of time then stopping *having a short decay envelope acting on the filter after grain finishes *trying to test when the filter is outputing zeros some of the above is sounding fine but anyone have any other suggestions / techniques I can try ? cheers, paul ===== .................................................................................... http://www.fexia.com http://www.robotsoftware.co.uk http://www.nicetoanimals.org ..................................................................................... __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From kaleja at estarcion.com Mon Jan 3 18:18:02 2005 From: kaleja at estarcion.com (Russell Borogove) Date: Wed Jun 27 19:18:13 2007 Subject: [music-dsp] Re: filtered grains in granular synthesis Message-ID: <20050103231802.GA87323@regency.estarcion.com> On Mon, Jan 03, 2005 at 01:34:33PM -0800, paul webb wrote: > I am making a few techniques such as > *just stopping everything when grain envelope finishes > *letting the filter carry on for X ammount of time > then stopping > *having a short decay envelope acting on the filter > after grain finishes > *trying to test when the filter is outputing zeros > > some of the above is sounding fine but anyone have > any other suggestions / techniques I can try ? * simplest solution, but it will affect the sound somewhat: filter the signal *before* putting it through the envelope - when the envelope hits zero, the filtered signal is zero. * If you have a high resonance setting on the filter, drop the resonance very low when the grain envelope goes to 0, then let the filter ring for X amount of time - lowering the resonance will shorten the ring time. -Borogove From paulwebb at rocketmail.com Mon Jan 3 19:36:49 2005 From: paulwebb at rocketmail.com (paul webb) Date: Wed Jun 27 19:18:13 2007 Subject: [music-dsp] Re: filtered grains in granular synthesis In-Reply-To: <20050103231802.GA87323@regency.estarcion.com> Message-ID: <20050104003649.64132.qmail@web51401.mail.yahoo.com> hello, thanks. I'll give them a go. paul --- Russell Borogove wrote: > On Mon, Jan 03, 2005 at 01:34:33PM -0800, paul webb > wrote: > > I am making a few techniques such as > > *just stopping everything when grain envelope > finishes > > *letting the filter carry on for X ammount of time > > then stopping > > *having a short decay envelope acting on the > filter > > after grain finishes > > *trying to test when the filter is outputing zeros > > > > some of the above is sounding fine but anyone have > > any other suggestions / techniques I can try ? > > * simplest solution, but it will affect the sound > somewhat: > filter the signal *before* putting it through the > envelope - > when the envelope hits zero, the filtered signal is > zero. > > * If you have a high resonance setting on the > filter, drop the > resonance very low when the grain envelope goes to > 0, then let > the filter ring for X amount of time - lowering the > resonance > will shorten the ring time. > > -Borogove > -- > dupswapdrop -- the music-dsp mailing list and > website: > subscription info, FAQ, source code archive, list > archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > ===== .................................................................................... http://www.fexia.com http://www.robotsoftware.co.uk http://www.nicetoanimals.org ..................................................................................... __________________________________ Do you Yahoo!? Send holiday email and support a worthy cause. Do good. http://celebrity.mail.yahoo.com From earlevel at earlevel.com Mon Jan 3 21:03:04 2005 From: earlevel at earlevel.com (Nigel Redmon) Date: Wed Jun 27 19:18:13 2007 Subject: [music-dsp] Fixed Point FFT question In-Reply-To: <3D0CEABD-5DC5-11D9-8B3A-000D93C2E232@yahoo.com> References: <3D0CEABD-5DC5-11D9-8B3A-000D93C2E232@yahoo.com> Message-ID: On Jan 3, 2005, at 12:22 PM, Darren Gibbs wrote: > Yes, the DFT v.s. FFT I get... but the real v.s. complex I'm less > clear about. The DFT/FFT inherently uses complex values as its input and output. So, if you start with real data, you have to convert them to complex (0.95 converts to 0.95 + 0i)--you end up with a whole lot of wasted zero multiplies and generating a redundant set of (mirrored) harmonics. Fortunately, there's an easy way to rearrange your real input values and plug them into the transform (even samples in the real part, odd in the complex), do the transform, then do a similar complex to real conversion. That's a rough explanation, but I think that's all you need to know--a real FFT makes more efficient use of the algorithm when you have real data. From Dogstoyevsky at gmx.net Tue Jan 4 05:34:24 2005 From: Dogstoyevsky at gmx.net (Fido Dogstoyevsky) Date: Wed Jun 27 19:18:13 2007 Subject: [music-dsp] Fixed Point FFT question Message-ID: <24441.1104834864@www48.gmx.net> rbj wrote: > i would *not* recommend any of this for Fixed-point FFT unless you gotta > lotta bits (32 bit words with 64 bit accumulators). the roundoff noise of > the FFT (as opposed to the straight forward slow DFT) is a bitch. > definitely not good for 16 bit words. > but if you're doing double precision float, this works very well. It works well for 24 bits as well. I used the Motorola Block Floating Point FFT and it improved the S/N. Robert, do you think a Block Floating Point FFT could work reasonable with 16 bit words? best Fido -- +++ GMX - die erste Adresse für Mail, Message, More +++ 1 GB Mailbox bereits in GMX FreeMail http://www.gmx.net/de/go/mail From Dogstoyevsky at gmx.net Tue Jan 4 05:55:18 2005 From: Dogstoyevsky at gmx.net (Fido Dogstoyevsky) Date: Wed Jun 27 19:18:13 2007 Subject: [music-dsp] [OT] Stupid C Question Message-ID: <17027.1104836118@www43.gmx.net> Laurent de Soras [Ohm Force] wrote: > double (*a) [2] = malloc (n * sizeof (a [0])); Sorry to flog a dead horse, but houldn't this be more like: double * a[2] = { NULL, NULL }; a[0] = malloc ( 2 * n * sizeof(double) ); a[1] = a + n; /* This is important, isn't it? */ /* do stuff */ printf("%f", a[0][x]); printf("%f", a[1][y]); free( a[0] ); Best Fido -- +++ GMX - die erste Adresse für Mail, Message, More +++ 1 GB Mailbox bereits in GMX FreeMail http://www.gmx.net/de/go/mail From yaakov_s at rad.com Tue Jan 4 09:20:52 2005 From: yaakov_s at rad.com (Yaakov Stein) Date: Wed Jun 27 19:18:13 2007 Subject: [music-dsp] Fixed Point FFT question Message-ID: <27A0F290348F8E45AEF79889DDE65A52038DBA1C@exrad2.ad.rad.co.il> > rbj wrote: > > i would *not* recommend any of this for Fixed-point FFT unless you > > gotta lotta bits (32 bit words with 64 bit accumulators). The radix-2 FFT, as conventionally implemented, requires reduction of 1 bit of accuracy per stage for worst-case safe behavior (i.e. predivision by N). Thus only very small FFTs are benign. If you are willing to risk the occasional overflow (assuming that you are using saturation arithmetic) you can get away with 1/2 bit per stage (i.e. predivision by sqrt(N)). This can be done without risk by scaling per alternate stage (which doesn't cost more in MIPS if you have a shifter). Even better is conditional scaling per stage; and there are more careful ways to perform the rouding that give further improvements. Finally, in theory number theoretical transforms (NTT) can be used to eliminate all loss of precision. At the expense of significantly lower performance on conventional architectures and much harder coding. Jonathan (Y) Stein From signalzerodb at yahoo.co.uk Tue Jan 4 11:56:15 2005 From: signalzerodb at yahoo.co.uk (Dave Gamble) Date: Wed Jun 27 19:18:13 2007 Subject: [music-dsp] Fixed Point FFT question In-Reply-To: <24441.1104834864@www48.gmx.net> References: <24441.1104834864@www48.gmx.net> Message-ID: <8C0207C2-5E71-11D9-B8B8-000A958903DE@yahoo.co.uk> On 4 Jan 2005, at 10:34, Fido Dogstoyevsky wrote: > rbj wrote: >> i would *not* recommend any of this for Fixed-point FFT unless you >> gotta >> lotta bits (32 bit words with 64 bit accumulators). the roundoff >> noise of >> the FFT (as opposed to the straight forward slow DFT) is a bitch. > >> definitely not good for 16 bit words. > >> but if you're doing double precision float, this works very well. > > It works well for 24 bits as well. I used the Motorola Block Floating > Point > FFT and it improved the S/N. > > Robert, do you think a Block Floating Point FFT could work reasonable > with > 16 bit words? > Iirc, Knuth2 (seminumerical algorithms), the section on multiplying polynomials using FFTs has an indepth discussion of precisely what the roundoff requirements are for FFTs. Dave. From signalzerodb at yahoo.co.uk Tue Jan 4 12:03:50 2005 From: signalzerodb at yahoo.co.uk (Dave Gamble) Date: Wed Jun 27 19:18:13 2007 Subject: [music-dsp] [OT] Stupid C Question In-Reply-To: References: Message-ID: <9B5BA8EA-5E72-11D9-B8B8-000A958903DE@yahoo.co.uk> > > In the hands of experts each of these languages allows for the creation > of beauty. > > In the hands of novices, they are all disasters waiting to happen. > > You have two choices: > > master the tools appropriate to the task, create new ones, and > get work done. > > or > bitch and moan about some perceived mismatch between a given > tool and your idealized perception of some out dated design metaphor > (which is still somewhat useful on occasion) that for some reason has > been elevated to religion in the minds of some. > I agree completely. However, I very much like the idea of telling people that 'this sounds better, because it was written in C, not C++'. 'Oh yeah, the virtual functions in C++ degrade the signal quality, so by using 100% pure C, we get better sound quality'. It's like all the hi-fi discussions, about what type of material your pcb/cables/connectors/speaker cone/coffee mug should be made from to get the best signal quality. 99% of the time, these discussions are complete nonsense, but they don't half entertain me. So, what advertising memes can we come up with for various languages and DSP? "Oh, I never use C# for programming - the 'sharp' element of it means that it actually runs at a slightly faster samplerate internally, so it pitches all your audio up slightly." "JAVA is very quick for development, yes, but since Sun wanted to make it so portable, they had to default to using the lowest-common-denominator for connectivity." "Oh, C is great, but try writing an auto-tune for Dminor with it!" There may well be a small prize for the best suggestion! :) Dave. From emanuel.landeholm at telia.com Tue Jan 4 12:18:53 2005 From: emanuel.landeholm at telia.com (Emanuel Landeholm) Date: Wed Jun 27 19:18:13 2007 Subject: [music-dsp] [OT] Stupid C Question In-Reply-To: <9B5BA8EA-5E72-11D9-B8B8-000A958903DE@yahoo.co.uk> References: <9B5BA8EA-5E72-11D9-B8B8-000A958903DE@yahoo.co.uk> Message-ID: <41DACFFD.5030404@telia.com> > "Oh, I never use C# for programming - the 'sharp' element of it means > that it actually runs at a slightly faster samplerate internally, so it > pitches all your audio up slightly." That's fucking funny.. From paulwebb at rocketmail.com Tue Jan 4 13:01:03 2005 From: paulwebb at rocketmail.com (paul webb) Date: Wed Jun 27 19:18:13 2007 Subject: [music-dsp] [OT] Stupid C Question In-Reply-To: <41DACFFD.5030404@telia.com> Message-ID: <20050104180103.56163.qmail@web51406.mail.yahoo.com> I never use C/C++/Csharp for music because C is like see and this is audio stuff. if you are C'ing you are doing visuals. oh and never use Lisp for speech processing --- Emanuel Landeholm wrote: > > "Oh, I never use C# for programming - the 'sharp' > element of it means > > that it actually runs at a slightly faster > samplerate internally, so it > > pitches all your audio up slightly." > > That's fucking funny.. > -- > dupswapdrop -- the music-dsp mailing list and > website: > subscription info, FAQ, source code archive, list > archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > ===== .................................................................................... http://www.fexia.com http://www.robotsoftware.co.uk http://www.nicetoanimals.org ..................................................................................... __________________________________ Do you Yahoo!? Dress up your holiday email, Hollywood style. Learn more. http://celebrity.mail.yahoo.com From paulwebb at rocketmail.com Tue Jan 4 13:01:03 2005 From: paulwebb at rocketmail.com (paul webb) Date: Wed Jun 27 19:18:13 2007 Subject: [music-dsp] [OT] Stupid C Question In-Reply-To: <41DACFFD.5030404@telia.com> Message-ID: <20050104180103.56163.qmail@web51406.mail.yahoo.com> I never use C/C++/Csharp for music because C is like see and this is audio stuff. if you are C'ing you are doing visuals. oh and never use Lisp for speech processing --- Emanuel Landeholm wrote: > > "Oh, I never use C# for programming - the 'sharp' > element of it means > > that it actually runs at a slightly faster > samplerate internally, so it > > pitches all your audio up slightly." > > That's fucking funny.. > -- > dupswapdrop -- the music-dsp mailing list and > website: > subscription info, FAQ, source code archive, list > archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > ===== .................................................................................... http://www.fexia.com http://www.robotsoftware.co.uk http://www.nicetoanimals.org ..................................................................................... __________________________________ Do you Yahoo!? Dress up your holiday email, Hollywood style. Learn more. http://celebrity.mail.yahoo.com From joshscholar at yahoo.com Tue Jan 4 16:21:38 2005 From: joshscholar at yahoo.com (Joshua Scholar) Date: Wed Jun 27 19:18:13 2007 Subject: [music-dsp] [OT] Stupid C Question References: <20050104180103.56163.qmail@web51406.mail.yahoo.com> Message-ID: <001901c4f2a3$617316e0$bde22641@antssoftware.com> I never program in C because major keys are so boring. Joshua Scholar ----- Original Message ----- From: "paul webb" To: "a list for musical digital signal processing" ; "a list for musical digital signal processing" Sent: Tuesday, January 04, 2005 10:01 AM Subject: Re: [music-dsp] [OT] Stupid C Question > I never use C/C++/Csharp for music because C is like > see and this is audio stuff. if you are C'ing you are > doing visuals. > > > oh and never use Lisp for speech processing > > > > > > > --- Emanuel Landeholm > wrote: > > > > "Oh, I never use C# for programming - the 'sharp' > > element of it means > > > that it actually runs at a slightly faster > > samplerate internally, so it > > > pitches all your audio up slightly." > > > > That's fucking funny.. > > -- > > dupswapdrop -- the music-dsp mailing list and > > website: > > subscription info, FAQ, source code archive, list > > archive, book reviews, dsp links > > http://shoko.calarts.edu/musicdsp > > http://ceait.calarts.edu/mailman/listinfo/music-dsp > > > > ===== > ............................................................................ ........ > http://www.fexia.com > http://www.robotsoftware.co.uk > http://www.nicetoanimals.org > ............................................................................ ......... > > > > __________________________________ > Do you Yahoo!? > Dress up your holiday email, Hollywood style. Learn more. > http://celebrity.mail.yahoo.com > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp From paranoiaspoisondoor at gmail.com Tue Jan 4 16:39:52 2005 From: paranoiaspoisondoor at gmail.com (Keith Handy) Date: Wed Jun 27 19:18:13 2007 Subject: [music-dsp] [OT] Stupid C Question In-Reply-To: <001901c4f2a3$617316e0$bde22641@antssoftware.com> References: <20050104180103.56163.qmail@web51406.mail.yahoo.com> <001901c4f2a3$617316e0$bde22641@antssoftware.com> Message-ID: <79a2ad4105010413395f52751f@mail.gmail.com> One thing I'd like to point out is that C is for cookie; that's good enough for me. As you might know, C is for cookie; that's good enough for me. Like I mentioned earlier, C is for cookie; that's good enough for me. And of course, cookie, cookie, cookie starts with C. -Keith On Tue, 4 Jan 2005 13:21:38 -0800, Joshua Scholar wrote: > I never program in C because major keys are so boring. > > Joshua Scholar > > ----- Original Message ----- > From: "paul webb" > To: "a list for musical digital signal processing" > ; "a list for musical digital signal > processing" > Sent: Tuesday, January 04, 2005 10:01 AM > Subject: Re: [music-dsp] [OT] Stupid C Question > > > I never use C/C++/Csharp for music because C is like > > see and this is audio stuff. if you are C'ing you are > > doing visuals. > > > > > > oh and never use Lisp for speech processing > > > > > > > > > > > > > > --- Emanuel Landeholm > > wrote: > > > > > > "Oh, I never use C# for programming - the 'sharp' > > > element of it means > > > > that it actually runs at a slightly faster > > > samplerate internally, so it > > > > pitches all your audio up slightly." > > > > > > That's fucking funny.. > > > -- > > > dupswapdrop -- the music-dsp mailing list and > > > website: > > > subscription info, FAQ, source code archive, list > > > archive, book reviews, dsp links > > > http://shoko.calarts.edu/musicdsp > > > http://ceait.calarts.edu/mailman/listinfo/music-dsp > > > > > > > ===== > > > ............................................................................ > ........ > > http://www.fexia.com > > http://www.robotsoftware.co.uk > > http://www.nicetoanimals.org > > > ............................................................................ > ......... > > > > > > > > __________________________________ > > Do you Yahoo!? > > Dress up your holiday email, Hollywood style. Learn more. > > http://celebrity.mail.yahoo.com > > -- > > dupswapdrop -- the music-dsp mailing list and website: > > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > > http://shoko.calarts.edu/musicdsp > > http://ceait.calarts.edu/mailman/listinfo/music-dsp > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp > http://ceait.calarts.edu/mailman/listinfo/music-dsp > -- -Keith From tony at mtx-media.com Tue Jan 4 16:54:28 2005 From: tony at mtx-media.com (Tony Scharf) Date: Wed Jun 27 19:18:13 2007 Subject: [music-dsp] [OT] Stupid C Question In-Reply-To: <79a2ad4105010413395f52751f@mail.gmail.com> References: <20050104180103.56163.qmail@web51406.mail.yahoo.com> <001901c4f2a3$617316e0$bde22641@antssoftware.com> <79a2ad4105010413395f52751f@mail.gmail.com> Message-ID: <41DB1094.4070206@mtx-media.com> Keith Handy said on 1/4/2005 3:39 PM: > One thing I'd like to point out is that C is for cookie; that's good > enough for me. As you might know, C is for cookie; that's good enough > for me. Like I mentioned earlier, C is for cookie; that's good enough > for me. And of course, cookie, cookie, cookie starts with C. > > -Keith cause what we really need on sessame street, is a C++ monster Tony From rbj at surfglobal.net Tue Jan 4 17:43:02 2005 From: rbj at surfglobal.net (robert bristow-johnson) Date: Wed Jun 27 19:18:13 2007 Subject: [music-dsp] Fixed Point FFT question In-Reply-To: <24441.1104834864@www48.gmx.net> Message-ID: on 01/04/2005 05:34, Fido Dogstoyevsky at Dogstoyevsky@gmx.net wrote: > rbj wrote: >> i would *not* recommend any of this for Fixed-point FFT unless you gotta >> lotta bits (32 bit words with 64 bit accumulators). the roundoff noise of >> the FFT (as opposed to the straight forward slow DFT) is a bitch. > >> definitely not good for 16 bit words. > >> but if you're doing double precision float, this works very well. > > It works well for 24 bits as well. I used the Motorola Block Floating Point > FFT and it improved the S/N. it should. i could never find a good copy of a block floating point 56K program that efficiently uses that S bit. so i took the regular FFT benchmark and modified it. this is so old that i'll give it away (probably no one uses the 56K series anymore). it's at the bottom. you'll have to unwrap some of the lines that wrapped. could you compare it to the one you got? > Robert, do you think a Block Floating Point FFT could work reasonable with > 16 bit words? it'll be 48 dB more noisy than 24 bit block floating-point. one other problem is that the DFT coefficients (a.k.a. "twiddle factors") are also quantized and the result of that imprecision of the coefficients is that (very low level) spurious bleeding of one bin into an unrelated bin will happen. try it i guess. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." page 255 opt cex,mex lstcol 8,8,10,13,13 ; ; copyright (C) 1994 by Robert Bristow-Johnson ; tel: 802/865-4525 ; e-mail: ; ; ; ; This subroutine is identical to the Motorola benchmark fftr2a ; except that scaling is optimized using block floating point. ; This requires a DSP56002, DSP56004, DSP56007 or DSP56001A. ; Some FFT passes have the divide by 2 scaling mode set (depending ; on the result of the S bit in the CCR). This insures ; against, overflow for any signal. N must be a power of 2. ; ; To be completely safe, the input should be scaled so that ; the magnitude of every real or imaginary part does not ; exceed 0.31066 ($27C3B5) . ; ; ; N-1 ; X[n] = 1/M SUM{ x[k]*exp(-j*2*PI*n*k/N) } ; k=0 ; ; where ; x[k] = input in normal order ; X[n] = output in bit reverse order ; ; N = 2^p ; ; M = 2^q (q = integer, number of passes that ; right shifting was necessary. ; 0 <= q <= p ) ; ; ; input: r1 -> data; x:(r1) is real part, y:(r1) is imag part ; r2 -> coefficients; x:(r2) is cos, y:(r2) is sin ; n1 = log2(number of points) = p ; r4 = block floating point exponent input (perhaps initialized to 0) ; ; output: r4 = block floating point exponent output ; = q + input r4 ; ; uses: a, b, x0, x1, y0, y1, mr, ccr ; r1, r2, r3, r4, r5, r6 ; n1, n2, n3, n4, n5, n6 ; m1, m2, m3, m4, m5, m6 ; x:-1,m5 ;2 init A and B address modifiers move m5,m6 ;1 for linear addressing move m5,m4 ;1 move m5,m1 ;1 move m5,m2 ;1 move #<0,m3 ;1 init C address modifier ; for bit-reversed addressing andi #$7F,ccr ;1 clear sticky bit ; ; Do FFT passes with triple nested DO loop. ; do n1,end_pass ;3 move x:-1,m5 move m5,m2 clr a #delta_table,r5 move #<2,n5 move #<1,a1 do n1,_shift asl a (r5)+n5 _shift lsr a #<-1.0,x0 ;-cos move a,n5 ;N/2 move p:(r5)+,x1 ;-cosdel move p:(r5)+,y1 ;-sindel mpyr -x0,x1,a #<0.0,y0 ;-sin do n5,_sincos_loop mpy -x0,y1,b a,x0 macr -y0,x1,b a,x:(r2) ; b = new sin mpy -x0,x1,a b,y0 macr y0,y1,a b,y:(r2)+ ; a = new cos _sincos_loop rts twopi equ 6.28318530717959 delta_table dc -@cos(twopi/1.0) dc -@sin(twopi/1.0) dc -@cos(twopi/2.0) dc -@sin(twopi/2.0) dc -@cos(twopi/4.0) dc -@sin(twopi/4.0) dc -@cos(twopi/8.0) dc -@sin(twopi/8.0) dc -@cos(twopi/16.0) dc -@sin(twopi/16.0) dc -@cos(twopi/32.0) dc -@sin(twopi/32.0) dc -@cos(twopi/64.0) dc -@sin(twopi/64.0) dc -@cos(twopi/128.0) dc -@sin(twopi/128.0) dc -@cos(twopi/256.0) dc -@sin(twopi/256.0) dc -@cos(twopi/512.0) dc -@sin(twopi/512.0) dc -@cos(twopi/1024.0) dc -@sin(twopi/1024.0) dc -@cos(twopi/2048.0) dc -@sin(twopi/2048.0) dc -@cos(twopi/4096.0) dc -@sin(twopi/4096.0) dc -@cos(twopi/8192.0) dc -@sin(twopi/8192.0) dc -@cos(twopi/16384.0) dc -@sin(twopi/16384.0) dc -@cos(twopi/32768.0) dc -@sin(twopi/32768.0) END From aclark at danvillesignal.com Tue Jan 4 18:21:46 2005 From: aclark at danvillesignal.com (Al Clark) Date: Wed Jun 27 19:18:13 2007 Subject: [music-dsp] Fixed Point FFT question In-Reply-To: References: <24441.1104834864@www48.gmx.net> Message-ID: <6.1.0.6.0.20050104171841.02700420@localhost> I prefer fixed point for many algorithms such as FIR and IIR filters, but FFTs are much easier with floating point. This is where a DSP like the SHARC works well since you have native floating point and fixed point capability. Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.com At 04:43 PM 1/4/2005, you wrote: >on 01/04/2005 05:34, Fido Dogstoyevsky at Dogstoyevsky@gmx.net wrote: > > > rbj wrote: > >> i would *not* recommend any of this for Fixed-point FFT unless you gotta > >> lotta bits (32 bit words with 64 bit accumulators). the roundoff noise of > >> the FFT (as opposed to the straight forward slow DFT) is a bitch. > > > >> definitely not good for 16 bit words. > > > >> but if you're doing double precision float, this works very well. > > > > It works well for 24 bits as well. I used the Motorola Block Floating Point > > FFT and it improved the S/N. > >it should. i could never find a good copy of a block floating point 56K >program that efficiently uses that S bit. so i took the regular FFT >benchmark and modified it. this is so old that i'll give it away (probably >no one uses the 56K series anymore). it's at the bottom. you'll have to >unwrap some of the lines that wrapped. could you compare it to the one you >got? > > > Robert, do you think a Block Floating Point FFT could work reasonable with > > 16 bit words? > >it'll be 48 dB more noisy than 24 bit block floating-point. one other >problem is that the DFT coefficients (a.k.a. "twiddle factors") are also >quantized and the result of that imprecision of the coefficients is that >(very low level) spurious bleeding of one bin into an unrelated bin will >happen. > >try it i guess. > > >-- > >r b-j rbj@audioimagination.com > >"Imagination is more important than knowledge." > > > > > > > page 255 > opt cex,mex > lstcol 8,8,10,13,13 > > >; >; copyright (C) 1994 by Robert Bristow-Johnson >; tel: 802/865-4525 >; e-mail: >; >; >; >; This subroutine is identical to the Motorola benchmark fftr2a >; except that scaling is optimized using block floating point. >; This requires a DSP56002, DSP56004, DSP56007 or DSP56001A. >; Some FFT passes have the divide by 2 scaling mode set (depending >; on the result of the S bit in the CCR). This insures >; against, overflow for any signal. N must be a power of 2. >; >; To be completely safe, the input should be scaled so that >; the magnitude of every real or imaginary part does not >; exceed 0.31066 ($27C3B5) . >; >; >; N-1 >; X[n] = 1/M SUM{ x[k]*exp(-j*2*PI*n*k/N) } >; k=0 >; >; where >; x[k] = input in normal order >; X[n] = output in bit reverse order >; >; N = 2^p >; >; M = 2^q (q = integer, number of passes that >; right shifting was necessary. >; 0 <= q <= p ) >; >; >; input: r1 -> data; x:(r1) is real part, y:(r1) is imag part >; r2 -> coefficients; x:(r2) is cos, y:(r2) is sin >; n1 = log2(number of points) = p >; r4 = block floating point exponent input (perhaps >initialized to 0) >; >; output: r4 = block floating point exponent output >; = q + input r4 >; >; uses: a, b, x0, x1, y0, y1, mr, ccr >; r1, r2, r3, r4, r5, r6 >; n1, n2, n3, n4, n5, n6 >; m1, m2, m3, m4, m5, m6 >; x:; x:; >; Leaves mr in no scaling mode. >; >; Requires 78 words of internal p: memory >; and p*( 3*N + 20 ) + 8*N + 15 instruction cycles. >; >; To execute optimally, the fft routine sould be in >; internal p: space. >; >; > > org x:$0 >data ds $1 >coef ds $1 > > > org p:$40 >fft > move r1,x: clr a #<1,n4 ;1 init >groups per pass > move n4,a1 ;1 > do n1,_shift ;3 > lsl a ;p >_shift > lsr a r2,x: lsr a a1,n5 ;1 init bfy >per group > move a1,n3 ;1 init C >pointer offset > move #>-1,m5 ;2 init A >and B address modifiers > move m5,m6 ;1 for >linear addressing > move m5,m4 ;1 > move m5,m1 ;1 > move m5,m2 ;1 > move #<0,m3 ;1 init C >address modifier > ; for >bit-reversed addressing > andi #$7F,ccr ;1 clear >sticky bit > >; >; Do FFT passes with triple nested DO loop. >; > do n1,end_pass ;3 > > move x:input pointer > move r5,r1 ;p init A >output pointer > lua (r5)+n5,r6 ;p init B >input pointer > move x:input pointer > lua (r6)-,r2 ;2p init B >output pointer > move n5,n6 ;p init >pointer offsets > move n5,n1 ;p > move n5,n2 ;p > > jset #7,sr,scale_down ;2p test >scaling bit > > andi #$F3,mr ;p reset >scaling to normal scaling mode > do n4,_end_grp1 ;3p > move x:(r6),x1 y:(r3),y0 ;N-1 lookup >-sine and > ; >-cosine values > move x:(r2),a y:(r5),b ;N-1 preload >b and > ; >update C pointer > move x:(r3)+n3,x0 ;N-1 > > do n5,_end_bfy1 ;3(N-1) > mac x1,y0,b y:(r6)+,y1 ;pN/2 > macr -x0,y1,b a,x:(r2)+ y:(r5),a ;pN/2 > subl