From douglas at music.columbia.edu Mon Jun 1 07:00:00 2009 From: douglas at music.columbia.edu (douglas repetto) Date: Mon Jun 1 07:00:04 2009 Subject: [music-dsp] [admin] music-dsp FAQ Message-ID: <20090601110000.C2A1990854C@music.columbia.edu> Hi, Just a reminder that if you are new to the list you should read the music-dsp FAQ. It contains answers to both technical _and_ adminstrative questions that often come up on the list. If your question appears in the FAQ it is safe to assume that it has been discussed on the list many times in the past, and you should probably have a look through the list archives before posting your question to the list. http://music.columbia.edu/cmc/music-dsp/musicdspFAQ.html Also of interest to new and not-so-new list members: The music-dsp list archives http://music.columbia.edu/cmc/music-dsp/musicdsparchives.html The music-dsp source code archive http://www.musicdsp.org music-dsp books and reviews http://music.columbia.edu/cmc/music-dsp/dspbooks.html All this and more at: http://music.columbia.edu/cmc/music-dsp Hasta la pasta, douglas (this is an automated message sent out on the 1st and 15th of each month) From thevinn at yahoo.com Tue Jun 2 01:22:55 2009 From: thevinn at yahoo.com (Vinnie) Date: Tue Jun 2 01:23:11 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes Message-ID: <483575.35024.qm@web58205.mail.re3.yahoo.com> > Date: Sat, 23 May 2009 19:57:26 +0200 > From: "Martin Eisenberg" > So it seems your best options are: > a) leave the tests in Prepare() alone and make it clear to > subclass authors that the index passed to GetPole/Zero() > ranges > over both members of any complex root pairs. > b) have Prepare() count only up to "stages" and let > subclasses > specify each stage as a unit (two Complex values which > Prepare() > combines with their conjugates if nonreal), rather than > treating > poles and zeros separately. Subclasses get to decide > whether real > roots are combined into 2nd-order sections or are turned > into > stages of their own. I think this raises no technical > problem > once the cleverness in Set*Stage is dropped, and it saves > the > currently wasted half of Prepare()'s computation. I've been studying the Orfanidis book, also Digital Filters... by Andreas Antoniou, a couple of research papers by Orfanidis, and the DSP Filters cookbook series by John Lane et. al. I have a much better grasp of the transfer function, the s/z plane, and what is going on inside these filters. I have identified the formula in the Orfanidis book that corresponds to the Butterworth poles in the code, as well as the highpass/bandpass/bandstop transformations. I finally invented my own filter by taking H(s)=A(s)/B(s) bandpass and transforming it into a peaking filter by setting H'(s)=1+A(s)/B(s) and solving the resulting equation, getting it back into a rational polynomial. At first, I thought that the computation of the conjugate poles was a waste. It was embarassing to compute them, only to have SetAStage() and SetBStage() throw them away. The current interface also suffers from the problem that constant intermediate calculations are re-computed for every pole and/or zero when they don't have to be. A better model would be a functional programming style, implemented by removing the state variables and switching over to having the derived class drive the setup of stages rather than going through the base. Anyway... It turns out that the calculation of the conjugate poles are in fact necessary. Witness: for( int i=0;i0 ) SetAStage( 2*c.real(), -std::norm(c) ); } In the case where the imaginary part of the pole or zero is sufficiently close to the i axis, the coordinate and its conjugate are merged together and get factored into the stages twice. SetAStage() is called twice with the same value c.real(), with the imaginary part set to 0, for the case where conjugate poles or zeroes are sufficiently close to the i axis (in this case within 1e-6 units). Is my analysis correct? Is there an easy way to ignore the conjugates? From vadim.zavalishin at native-instruments.de Tue Jun 2 05:20:47 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Tue Jun 2 05:21:02 2009 Subject: [music-dsp] Name of delay-free loop technique In-Reply-To: <000a01c9e21b$441cc3e0$0201a8c0@mooncode> References: <002401c9d7d1$0aee5ce0$0201a8c0@mooncode><56BDCC96E6B94AF5BC7DF68F893A63C1@nibln01077><001201c9d8a6$2f916bc0$0201a8c0@mooncode><001201c9dca5$332d6f60$0201a8c0@mooncode><86DBA60A6D954C829C23571C46248EFE@nibln01077><029244E7BAD549C78B29E3DAB113FC06@nibln01077> <000a01c9e21b$441cc3e0$0201a8c0@mooncode> Message-ID: >> Now insert a lowpass filter into the feedback. Let f be the >> filter cutoff. Let the feedback run over the time period > deltaT. >> Now let f approach infinity and deltaT approach zero, where >> f is approaching infinity "faster" than deltaT is approaching >> zero, so that their product is approaching infinity. > > While this description differs somewhat from that in your > article, you still end up looking for the final value of a step > response, no? This double-limit business would thus seem > overcomplicated. Overcomplicated compared to what? Basically this double-limit business is a formal expression of the fact that the signal in the instantaneous feedback path is allowed to change only continuously (ensured by the lowpass filter), whereas certain "very fast" (comparable to the lowpass filter's characteristic decay time) changes do not interest us. While the final formula is of course simple compared to the "double-limit business", do you know an easier way to formally express the same requirements? The article doesn't explicitly contain the above formal description, however it basically states the same: the signal is allowed to change only continuously in the instantaneous feedback loop. Actually, this "unstable instantaneous feedback" business is *almost* academic, as it usually occurs in extreme cases. Still I think it's important to be aware of it, particularly it becomes more important in the presence of nonlinearities. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From martin.eisenberg at udo.edu Tue Jun 2 09:10:49 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Tue Jun 2 09:12:05 2009 Subject: [music-dsp] Name of delay-free loop technique References: <002401c9d7d1$0aee5ce0$0201a8c0@mooncode><56BDCC96E6B94AF5BC7DF68F893A63C1@nibln01077><001201c9d8a6$2f916bc0$0201a8c0@mooncode><001201c9dca5$332d6f60$0201a8c0@mooncode><86DBA60A6D954C829C23571C46248EFE@nibln01077><029244E7BAD549C78B29E3DAB113FC06@nibln01077><000a01c9e21b$441cc3e0$0201a8c0@mooncode> Message-ID: <003b01c9e383$904dab80$0201a8c0@mooncode> Vadim Zavalishin wrote: >>> Now insert a lowpass filter into the feedback. Let f be the >>> filter cutoff. Let the feedback run over the time period >>> deltaT. Now let f approach infinity and deltaT approach zero, >>> where f is approaching infinity "faster" than deltaT is >>> approaching zero, so that their product is approaching >>> infinity. >> >> While this description differs somewhat from that in your >> article, you still end up looking for the final value of a >> step response, no? This double-limit business would thus >> seem overcomplicated. > > Overcomplicated compared to what? Let me show how I translate the article's description into mathematics. You suggest to treat the feedback equation y = g*(x-k*y) + s not as a formal identity but as a state to be attained by a damped system, i.e., y[n] := u(t_end), u(0) := y[n-1]; u' = a*(g*(x-k*u) + s - u) = a*(c - d*u); c = g*x+s, d = 1+g*k, a > 0. Now, it is true that as a goes to infinity, u(t) approaches u_end (whether finite or not) on ]0, infty[ -- so we *can* bring t_end toward 0 -- but it does so ever slower the smaller t is -- so we must ensure that a*t_end -> infty, as you said. But those are overly esoteric considerations, for if we just solve the auxiliary system and let t_end = infty then this time limit becomes trivial and the damping limit unneeded. The solution is u(t) = { y[n-1] + a*c*t, d = 0 { (y[n-1]-c/d) * exp(-a*d*t) + c/d, d != 0 with end value c/d if d > 0 and S*infty otherwise, where S = sgn(y[n-1]-c/d) = sgn(c-d*y[n-1]), d < 0 is seen to cover the case d = 0 as well. This is of course your result but with u_end clear from inspection, disregarding a, as opposed to interdependent limits which I wouldn't call generally obvious. > Actually, this "unstable instantaneous feedback" business is > *almost* academic, as it usually occurs in extreme cases. Still > I think it's important to be aware of it, particularly it > becomes more important in the presence of nonlinearities. Yes, I'm glad you pointed it out. Do you know any analog devices, besides perhaps oscillators, that routinely operate that way? Have you generally found it sufficient to solve the system as if linear and then saturate the result? It bothers me that the result is a square wave whenever the linearized loop is unstable, overestimating the signal values and tone brightness. Also, do you have some more thoughts on the hysteretic case you mentioned before (k < -1 in the ladder filter)? Martin From martin.eisenberg at udo.edu Tue Jun 2 09:51:01 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Tue Jun 2 09:48:32 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes References: <483575.35024.qm@web58205.mail.re3.yahoo.com> Message-ID: <004e01c9e389$2dd617c0$0201a8c0@mooncode> Vinnie wrote: > I have a much better grasp of the transfer function, the s/z > plane, and what is going on inside these filters. Right on! > for( int i=0;i { > c=GetPole( i ); > if( ::std::abs(c.imag())<1e-6 ) > c=Complex( c.real(), 0 ); > if( c.imag()==0 ) > SetAStage( c.real(), 0 ); > else if( c.imag()>0 ) > SetAStage( 2*c.real(), -std::norm(c) ); > } > > In the case where the imaginary part of the pole or zero is > sufficiently close to the i axis, To the real axis actually, otherwise the test would be c.real() < 1e-6. > the coordinate and its conjugate are merged together and get > factored into the stages twice. When the conjugates are both close to the real axis they are also close to each other, so they almost form a double root and it may do no harm to force this case to a double real root, though I wondered about the reason before. In any case, you can always write the loop like this and touch each complex pair just once: c=GetPole( i ); if( c.imag()==0 ) SetAStage( c.real(), 0 ); else if( ::std::abs(c.imag())<1e-6 ) SetAStage( 2*c.real(), -c.real()*c.real() ); else SetAStage( 2*c.real(), -std::norm(c) ); Martin From vadim.zavalishin at native-instruments.de Tue Jun 2 10:11:09 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Tue Jun 2 10:11:26 2009 Subject: [music-dsp] Name of delay-free loop technique In-Reply-To: <003b01c9e383$904dab80$0201a8c0@mooncode> References: <002401c9d7d1$0aee5ce0$0201a8c0@mooncode><56BDCC96E6B94AF5BC7DF68F893A63C1@nibln01077><001201c9d8a6$2f916bc0$0201a8c0@mooncode><001201c9dca5$332d6f60$0201a8c0@mooncode><86DBA60A6D954C829C23571C46248EFE@nibln01077><029244E7BAD549C78B29E3DAB113FC06@nibln01077><000a01c9e21b$441cc3e0$0201a8c0@mooncode> <003b01c9e383$904dab80$0201a8c0@mooncode> Message-ID: > But those are > overly esoteric considerations, for if we just solve the > auxiliary system and let t_end = infty then this time limit > becomes trivial and the damping limit unneeded. Except that you have introduced a different time scale, where t_end=infinity occurs before y[n] (or at the same time). I found it more intuitive to think of a lowpass filter with an infinitely high cutoff, which then can be considered to reach the stability point within infinitely short time (corresponding to the current sample's "duration"). Otherwise I think both approaches are fully equivalent. > >> Actually, this "unstable instantaneous feedback" business is >> *almost* academic, as it usually occurs in extreme cases. Still >> I think it's important to be aware of it, particularly it >> becomes more important in the presence of nonlinearities. > > Yes, I'm glad you pointed it out. Do you know any analog devices, > besides perhaps oscillators, that routinely operate that way? > Have you generally found it sufficient to solve the system as if > linear and then saturate the result? Of course generally it's not sufficient. This question has been discussed in Sefafini/Zamboni paper. In my article I briefly mention this approach as "cheap" (beginning of p.5). From the practical perspective, if you happen to have Reaktor, then there are Reaktor Core implementations of both "cheap" and "correct" versions available for the ladder filter in the user library here: http://www.nativeinstruments.de/index.php?id=userlibrary&type=0&ulbr=1&plview=detail&patchid=7775 which you can compare for yourself. > It bothers me that the > result is a square wave whenever the linearized loop is unstable, > overestimating the signal values and tone brightness. I'm not sure how do you get to the square wave? Are you trying to apply the "cheap" version to the instantaneously unstable case? Still I think there should be no square wave, the system should just stay "clipped" at one of the extremes. > Also, do > you have some more thoughts on the hysteretic case you mentioned > before (k < -1 in the ladder filter)? I must admit I didn't explicitly experiment with or analyse the instantaneously unstable structures. The "nonzero impedance" was just mentioned in the article as an approach which can be used to handle those. Still, Fig.6 from my article might serve as a graphical illustration which can help to analyse the matter in the nonlinear case. Instantaneously unstable cases will correspond to the horizontally-reverted graph of g*tanh(x-ky), where the graph's steepness (derivative) must exceed 1, in which case the system "wants" to go into the opposite direction of the intersection of the h(y)=y-s and the nonlinearity's tangent line (I think). That should pretty much define the choice of the solution point. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From thevinn at yahoo.com Tue Jun 2 10:22:08 2009 From: thevinn at yahoo.com (Vinnie) Date: Tue Jun 2 10:22:23 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes Message-ID: <952121.14493.qm@web58206.mail.re3.yahoo.com> > From: "Martin Eisenberg" > Subject: Re: [music-dsp] Re: Revisiting C++ Filtering > Classes > it may do no harm to force this case to a double real root I can confirm that when I simply ignore poles and zeroes with negative imaginary components, I get an incorrect magnitude response (usually when the cutoff frequency is near DC or Fs/2). When I force it to be a double real root as you suggested, the magnitude response is correct. > In any case, you can always write the loop like this and > touch each complex pair just once: Now that I understand more, I see that the 'imperative' programming style is not ideal. I am going to change it to a functional programming style. The derived class will drive generation of the coefficients instead of the reverse. This will also make it possible to re-use calculations which are the same between poles. I seem to have run into a stumbling block though. I understand the low-pass to low-pass and low-pass to high-pass transformations. I'm getting stuck on the low-pass to band-pass. These are my bilinear transforms: Complex c; // Calculated s-plane pole or zero //... CalcT k=-1./tan(m_wc*0.5); // prewarped frequency mapping return (-1.-c*k)/(1.-c*k); // low-pass to high-pass bilinear CalcT k=tan(m_wc*0.5); return (1.+c*k)/(1.-c*k); These are the formulas from Orfanidis. Here is the low pass to band pass transform: s = f(z) = ( 1 - 2*c*z[-1] + z[-2] ) / ( 1 - z[-2] ) What the heck is z[-2]? Is that ::pow(z,0.5)? What is z? For that matter what does z[-1] mean? Is that 1/z? I calculated the placement of the zero for a butterworth low shelf from the numerator of the transfer function H(s): numerator = s + ::pow(g,1/(2*N))*exp(i*a) N=order, a=pole angle, g=gain I found the s-pole by setting s = -::pow(g,1/(2*N))*exp(i*a) With the s-pole I applied the low-pass to low-pass bilinear transformation with frequency shift as described above. But now I am lost, how do I take s = f(z) = ( 1 - 2*c*z[-1] + z[-2] ) / ( 1 - z[-2] ) and use it to transform the same s-pole to get the bandpass pole? I know that this equation is going to double my filter order. From thevinn at yahoo.com Wed Jun 3 05:41:07 2009 From: thevinn at yahoo.com (Vinnie) Date: Wed Jun 3 05:41:23 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes Message-ID: <406790.64415.qm@web58206.mail.re3.yahoo.com> > Date: Tue, 2 Jun 2009 15:51:01 +0200 > From: "Martin Eisenberg" > When the conjugates are both close to the real axis they > are also close to each other, so they almost form a double root and > it may do no harm to force this case to a double real root Unfortunately, this doesn't work. For filters of odd order (for example Butterworth) one of the poles usually lands on the real axis. Ideally, the imaginary component would be zero. But due to floating point quantization sometimes the pole has a miniscule imaginary part. For example, I got this pole: -3.3693318 + i*4.126241e-16 This is not half of a conjugate pair, this is the odd-man-out (i.e. a singleton, realized using half of a second order section) on an odd-order Butterworth. By the time we get to SetAStage(), we do not have sufficient information to determine if it should be treated as a double root, or if it should just be treated as a complex number with the imaginary part slammed to zero. I'm in the middle of a huge rewrite of the classes and I just ran into this problem...I changed all the code to assume that computation of the conjugate pairs was unnecessary. :-( I would still like to avoid those calculations, I just don't see a clean, obvious way of doing it. From neolit123 at gmail.com Wed Jun 3 08:10:38 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Wed Jun 3 08:11:29 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes References: <952121.14493.qm@web58206.mail.re3.yahoo.com> Message-ID: <001401c9e444$63d321e0$0201a8c0@LuboPC> ----- Original Message ----- From: "Vinnie" > What the heck is z[-2]? Is that ::pow(z,0.5)? What is z? For that matter > what does z[-1] mean? Is that 1/z? z[-1] same as: z ^ (-1) = 1 / z z is a complex variable (z-transform) z = exp(j * omega) = cos(omega) + j * sin(omega) <- j - imaginary number. z[-2] = z ^ (-2) = exp(-2 * j * omega) <- or two samples delay. f(z) is the transfer function. plotting poles / zeros on the z-plane will give you the maginitude and phase response of the filter. Lubomir From martin.eisenberg at udo.edu Wed Jun 3 08:51:10 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Wed Jun 3 08:48:45 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes References: <406790.64415.qm@web58206.mail.re3.yahoo.com> Message-ID: <002301c9e449$fbf5b820$0201a8c0@mooncode> Vinnie wrote: > Unfortunately, this doesn't work. For filters of odd order > (for example Butterworth) one of the poles usually lands on > the real axis. Ideally, the imaginary component would be zero. Oops, yeah, at least we've learned why the code is done that way... Both the Butterworth and Chebyshev versions of GetSPole() sample a path that starts somewhere along the imaginary axis, goes up in an arc to the negative reals, and conjugate-symmetrically onwards back to the imaginaries. It's not hard to make them traverse just one quadrant, starting right on the real axis at odd orders. Trouble is that the complex division in BilinearTransform() can still yield a nonzero imaginary part even if the input is real. But if you do drive the process from the subclasses you can special-case this. A sketch: template void Subclass::MakePoles() { const int UniquePoles = (Order + 1)/2; const int Parity = Order % 2; // prepare stuff for(int i = 0; i < UniquePoles; ++i) { CalcT theta = kPi + (2*i+1-Parity)*kPi/(2*Order); Complex pole = some_expression(prepared_stuff, theta); pole = BilinearTransform(pole); Baseclass::PutPole((i < Parity) ? pole.real() : pole); } } Note how I changed the s-plane angle expression from kPi_2 + (2*i+1) * kPi/(2*n) where i went up to n-1 into kPi + (2*i+1 - (n%2))*kPi/(2*n) where i stops at (n-1)/2, thus restricting to one quadrant. This also applies to the Cheby2 zeros using cos(x) = sin(pi/2+x). > I'm in the middle of a huge rewrite of the classes and I just > ran into this problem...I changed all the code to assume that > computation of the conjugate pairs was unnecessary. :-( Sorry about that. But rewriting a 3k line module on an assumption is a sure road into pain -- better extract a minimal subset of code (leave out SSE, Brent, ComplexT, optimized trig, all but one filter type) to hack up, then transfer back whatever works out. Martin From thevinn at yahoo.com Wed Jun 3 09:26:14 2009 From: thevinn at yahoo.com (Vinnie) Date: Wed Jun 3 09:26:23 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes Message-ID: <996099.51955.qm@web58208.mail.re3.yahoo.com> > From: "Martin Eisenberg" > Subject: Re: [music-dsp] Re: Revisiting C++ Filtering > Classes > Trouble is that the complex division in BilinearTransform() > can > still yield a nonzero imaginary part even if the input is > real. > But if you do drive the process from the subclasses you > can > special-case this. A sketch: Actually what I was thinking is making a container called "Roots" that has two sections. A list of conjugate roots, and a list of the real-valued roots (expressed as Complex numbers, possibly with a miniscule imaginary part which will get slammed to 0 in the set stages). It would be up to the class modeling the analog prototype to fill out the container properly, placing the intended conjugates (well, the one that lies above the real axis) in the implied pair list, and putting the singleton (the one that is supposed to land on the real axis for odd orders) into the singleton list. Then it is a trivial matter to build the A coefficients in two steps. First, process the list of conjugates. If the imaginary part lies close to the real axis then set it to zero and set the stage twice. Then, process the list of real valued singletons. For these, if the imaginary part is close to the real axis we still set it to zero but only process the pole once. The same process is repeated for the B coefficients. > better extract a minimal subset > of code (leave out SSE, Brent, ComplexT, optimized trig, all > but one filter type) to hack up, then transfer back whatever works > out. Well yeah, thats what I did. I created new, simplified and non-templated versions of Cascade, et. al. This was just an unexpected complication. Thanks! From martin.eisenberg at udo.edu Wed Jun 3 09:31:23 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Wed Jun 3 09:28:50 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes References: <952121.14493.qm@web58206.mail.re3.yahoo.com> Message-ID: <002701c9e44f$9a0d9320$0201a8c0@mooncode> Vinnie wrote: > Here is the low pass to band pass transform: > > s = f(z) = ( 1 - 2*c*z[-1] + z[-2] ) / ( 1 - z[-2] ) > > What the heck is z[-2]? It means z^(-2) = 1/z^2. Does your reference really write it like that? > What is z? It's discrete-time complex frequency, the discrete-time transfer function's independent variable. It's also the transfer function of the time-domain operator that advances a sequence by one one position, so z^(-1) corresponds to a unit delay. > But now I am lost, how do I take > > s = f(z) = ( 1 - 2*c*z[-1] + z[-2] ) / ( 1 - z[-2] ) > > and use it to transform the same s-pole to get the bandpass > pole? Augment the right-hand fraction by z^2 giving polynomials in z, move the denominator over to the left, and solve the resulting quadratic equation for z as a function of s (and c). Evaluate both solutions at each s-domain root to get the set of z-domain roots. That is, each s-plane pole gives rise to two z-plane poles. Also, you can check that conjugating the input s conjugates each z solution too, so that mapping just one member of each s-plane conjugate pair is enough. Martin From thevinn at yahoo.com Wed Jun 3 09:35:24 2009 From: thevinn at yahoo.com (Vinnie) Date: Wed Jun 3 09:35:33 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes Message-ID: <765409.62956.qm@web58206.mail.re3.yahoo.com> > From: "Martin Eisenberg" > Trouble is that the complex division in BilinearTransform() > can still yield a nonzero imaginary part even if the input is > real. UGH! I just figured out the implications of this. I calculate the poles in the s-plane first and then do the transformation. So I cannot be sure if a singleton in the s plane will remain so after the transform. I have one list of complex conjugate pairs, and another list of complex singletons, is there a one to one mapping after the bilinear transformation of the pairs to a new set of conjugate pairs? Or do they lose the conjugate property? Do singletons become pairs? They certainly can take on an imaginary component... Should I just give up on the 'optimization' of not calculating some of the poles? It is turning out to be more trouble than it is worth. I don't relish the thought of resampling the poles in a different order just to get the conjugates to land at the 'end'. And plus, if I do this, it will place an extra burden on anyone who wants to design their own filter. From martin.eisenberg at udo.edu Wed Jun 3 10:36:46 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Wed Jun 3 10:34:11 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes References: <996099.51955.qm@web58208.mail.re3.yahoo.com> Message-ID: <005201c9e458$bc811180$0201a8c0@mooncode> Vinnie wrote: > First, process the list of conjugates. If the imaginary > part lies close to the real axis then set it to zero and set > the stage twice. Once the two groups are handled separately (by whatever protocol) I don't think that flushing genuine close pairs to real roots accomplishes anything. I believe this was done in your raw material only to avoid the problem you came up against of duplicating roots that are nominally but not numerically real. Martin From martin.eisenberg at udo.edu Wed Jun 3 11:01:43 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Wed Jun 3 10:59:13 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes References: <765409.62956.qm@web58206.mail.re3.yahoo.com> Message-ID: <005601c9e45c$38bffc40$0201a8c0@mooncode> Vinnie wrote: > placing the intended conjugates (well, the one that lies > above the real axis) in the implied pair list Which of the conjugates you choose is immaterial because you only apply real() and norm() to the number. >> Trouble is that the complex division in BilinearTransform() >> can still yield a nonzero imaginary part even if the input is >> real. > > UGH! I just figured out the implications of this. I calculate > the poles in the s-plane first and then do the transformation. > So I cannot be sure if a singleton in the s plane will remain > so after the transform. No, you've overinterpreting the problem. I noted that the numerical BLT does not preserve realness, but it's still one number in and one out. There is no problem as long as you preserve the logical information about singleness separately, which you just decided to do anyway. > I have one list of complex conjugate pairs, and another list > of complex singletons, is there a one to one mapping after the > bilinear transformation of the pairs to a new set of conjugate > pairs? Or do they lose the conjugate property? They may, if you store both and remap them independently -- in fact, if you explicitly compute both members of a pair they may be out of conjugacy from the start. But it's a red herring. If you create the stage from just one (or the other) member just like it's been all along, conjugacy is automatic. > Do singletons become pairs? They certainly can take on an > imaginary component... You'll throw it away, it's fine. Martin From rbj at audioimagination.com Wed Jun 3 11:46:29 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Wed Jun 3 11:46:51 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes In-Reply-To: <765409.62956.qm@web58206.mail.re3.yahoo.com> References: <765409.62956.qm@web58206.mail.re3.yahoo.com> Message-ID: <65A46D60-ED93-490D-BCE1-3CA5FE207690@audioimagination.com> hi Vinnie, i'm trying to understand what your "bottom line" is. you want a create a class of IIR filters, right? these filters are limited to 2nd-order? or are you trying to put together filters of higher order? you want to understand the math, right? now, while it's no substitute for taking a good class in what we used to call "Linear System Theory" (but now i think the title "Signals and Systems" is now more in vogue), some of this can be understood, but how deep do you want to go? do you understand what "s" is in the analog prototypes and why we substitute s <- jw when we want to evaluate frequency response? likewise, do you understand what "z" is in a digital filter and why we substitute z <- exp(jw) when we want to evaluate frequency response? so what we do on the jw axis (Re{s}=0) in analog filters is what we do on the unit circle (|z|=1) for digital filters. do you understand why (or do you really need to know)? so, to transform an analog prototype to a digital filter, we have to map the imaginary axis to the unit circle and the proper mapping is that exponential function: z = exp(s/Fs) where Fs is the sampling frequency. so we invert the mapping to find out *what*, in terms of z, we have to stick into the analog "s". that inverse mapping is s = Fs * ln(z) ("ln" is the natural log.) but we don't have functional blocks that accomplish ln(z). we only have negative powers of z which turn out to be delays of as many samples as that power of z. so someone (whoever invented the Bilinear Transform, and i dunno if that is credited to anyone) decided to approximate that natural log function by truncating this infinite series at the first term: ln(x) = 2*(x-1)/(x+1) + 2/3*((x-1)/(x+1))^3 + 2/5*((x-1)/(x+1)) ^5 + ... so the BLT does this approximation: s = Fs * ln(z) ~= 2*Fs*(z-1)/(z+1) = 2*Fs*(1 - (z^-1))/(1 + (z^-1)) what the BLT does is map the unit circle of the z-plane to the imaginary axis of the s-plane just like the ln(z) function does except that the BLT mapping maps a particular z on the unit circle to a slightly different place on the jw axis on the s-plane than does the ln(z) function. this is then understood to be the frequency warping of the BLT and you can fix it (compensate) at every significant frequency that you have a control parameter for (just scaling frequency in the analog domain). for a simple LPF or HPF, there is only one degree freedom that you can scale to compensate frequency warping. with an BPF there are two (the two bandedges, but an easier way to look at it is to compensate the center frequency and the bandwidth). now, the point of writing this is, this scaling of s to compensate the effect of frequency warping at the singular "significant frequency" *and* this scaling with Fs that is explicit with the BLT can be teamed up together into a single operation. this is done at the bottom of the Audio EQ Cookbook, which i might suggest you look up to save you some work. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From martin.eisenberg at udo.edu Wed Jun 3 17:20:50 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Wed Jun 3 17:18:22 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes References: <765409.62956.qm@web58206.mail.re3.yahoo.com> <65A46D60-ED93-490D-BCE1-3CA5FE207690@audioimagination.com> Message-ID: <000701c9e491$2f7298c0$0201a8c0@mooncode> robert bristow-johnson wrote: > (whoever invented the Bilinear Transform, and i > dunno if that is credited to anyone) Just dug this up: http://control.ee.ethz.ch/index.cgi?page=news&action=details&id=5 50 Martin From thevinn at yahoo.com Wed Jun 3 18:45:58 2009 From: thevinn at yahoo.com (Vinnie) Date: Wed Jun 3 18:46:17 2009 Subject: [music-dsp] Re: music-dsp Digest, Vol 66, Issue 6 Message-ID: <217067.32995.qm@web58203.mail.re3.yahoo.com> > From: robert bristow-johnson > i'm trying to understand what your "bottom line" is. I want to make this a comprehensive C++ library for IIR filters. I would like to keep the single-header design. The goals: - Butterworth, Chebyshev Type I, Chebyshev Type II, Elliptic, Bessel response types - All Biquad variants - Low Pass, High Pass, Band Pass, Band Stop, Low Shelf, High Shelf, Peaking, Notch of every response type - Arbitrary order, changable at runtime - Flexibility to control the floating point types used for calculation and output - Robust class hierarchy that encapsulates each concept neatly - No repeated formulas or code - Fast parameter changes using cached calculations - Functional programming style that allows easy assembly of filters from primitives using templates From rbj at audioimagination.com Wed Jun 3 20:07:07 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Wed Jun 3 20:07:32 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes In-Reply-To: <217067.32995.qm@web58203.mail.re3.yahoo.com> References: <217067.32995.qm@web58203.mail.re3.yahoo.com> Message-ID: On Jun 3, 2009, at 6:45 PM, Vinnie wrote: > >> From: robert bristow-johnson >> i'm trying to understand what your "bottom line" is. > > I want to make this a comprehensive C++ library for IIR filters. I > would like to keep the single-header design. The goals: > laudable goal. okay, i will let you worry about this stuff: >> - Arbitrary order, changable at runtime >> >> - Flexibility to control the floating point types used for >> calculation and output >> >> - Robust class hierarchy that encapsulates each concept neatly >> >> - No repeated formulas or code >> >> - Fast parameter changes using cached calculations >> >> - Functional programming style that allows easy assembly of >> filters from primitives using templates >> about this stuff: > - Butterworth, Chebyshev Type I, Chebyshev Type II, Elliptic, > Bessel response types there are nice closed form formulae for the s-plane coefficients (as "normalized s" LPF prototypes) for the first three (perhaps that is what you're trying to figure out, you might want to learn some neat stuff about the Tchebyshev polynomials to do that). not so nice for the latter two, but you might be able to dig up someone's C code for the Jacobi elliptical function and the Bessel functions. now, with the Chebyshev/Elliptical responses, i would recommend to restrict the passband ripple to be less than 3.0103 dB, the max stopband gain to be always lower than -3.0103 dB, so that on the transition slope, there is always a unique -3.0103 dB point which will always be the "corner frequency" when switching between response types. > - All Biquad variants by this, i think you mean Direct Forms 1&2 and their transposes, Lattice and normalized ladder, i think there is a Rader/Gold form but i forget what it is. maybe a "state-variable" form that has discrete- time integrators, 1/(z-1), as elements instead of 1/z. you might want to look into stuff that Duane Wise has done with different forms. sometimes there are numerical issues. i think if you first go after the Direct Form coefs, you'll be able to map to the other forms straight-forwardly. that's something to worry about later in the venture. > - Low Pass, High Pass, Band Pass, Band Stop, Low Shelf, High Shelf, > Peaking, Notch of every response type i think that Band Stop and Notch might be the same thing, no? what i might call "Band Reject Filter". a Band Stop or Notch that does not go down to -inf dB at the resonant frequency would be a Peaking filter with a negative dB gain parameter. okay, for this, you want to always bring in the *normalized* frequency (that is that the corner is at w=1) LPF prototype of the chosen response type above. then use the following s-plane substitutions for the first four shapes: LPF: s <- s HPF: s <- 1/s BPF: s <- Q*(s + 1/s) BRF: s <- Q/(s + 1/s) note that the order of the filter will double when starting with an Nth-order Butterworth/Chebyshev/whatever LPF prototype and mapping that to a BPF or BRF. here, the "Q" is not necessarily the biquad Q unless you started with a 1st-order LPF prototype. think of it as the approximate reciprocal of the bandwidth parameter. i think the good mapping should be (from the cookbook): 1/Q = 2*sinh( ln(2)/2 * BW * w0/sin(w0) ) where BW is the bandwidth in octaves and w0 = 2*pi*f0/Fs . now, you're gonna need to think about what are the best definitions for your Peaking and Shelf filters. even though i would *not* necessarily recommend taking exactly the definitions in the cookbook, i think what you *do* want are definitions so that leaving the Q and resonant frequency parameters untouched, a cut of N dB will look exactly like a upside-down mirrored reflection of the same with a boost of N dB. in series, the aggregate two should be equivalent to a "wire". if you simply define the Peaking, Low Shelf, or High Shelf to be the unscaled input added to the scaled output of a BPF, LPF, or HPF (respectively), you may very well get into a situation where the boost and cut are not complementary. so you need to think about this a bit. BW or slope parameters may need to be "fudged" a bit in some cases. also, if you define your Shelves as a scaled LPF/HPF added to a wire (with the LPF/HPF as perhaps a higher-order Butterworth/Chebyshev/ whatever), then you don't have, in the definition, a shelf-slope control since there is no "Q" in either the LPF or HPF (to LPF) mapping above. you might not like it that way. finally, after you've done that substitution, you have an analog prototype with the filter shape (Low Pass, etc.) and response type (Butterworth, etc.), but it is *still* happening at a *normalized* frequency, w=1. to move it to the desired frequency, w0 = 2*pi*f0/Fs (where f0 is expressed in the same units as the sampling frequency Fs), you take your normalized s-plane prototype and make this Bilinear Transform substitution: s <- ( 1/tan(w0/2) )*(1 - z^-1)/(1 + z^-1) that takes care of the BLT substitution *and* compensating the BLT frequency warping effect on the resonant frequency at the same time. the compensation of the effect that frequency warping has on bandwidth is done approximately (but pretty goodly) by the w0/sin(w0) stretching factor applied to the octave BW above. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From vadim.zavalishin at native-instruments.de Thu Jun 4 05:24:37 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Thu Jun 4 05:24:48 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes In-Reply-To: References: <217067.32995.qm@web58203.mail.re3.yahoo.com> Message-ID: <09D83B83D93842DAAFCD780CD4C57130@nibln01077> > maybe a "state-variable" form that has discrete- time integrators, > 1/(z-1), as elements instead of 1/z. you might want to look into stuff > that Duane Wise has done with different forms. With a risk of becoming an annoyance: why not use BLT integrators with resolved delayless feedback? In my experience this form is kind-of "the best" one (ATM I don't know a "better" one, maybe someone can enlighten me?) Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From thevinn at yahoo.com Thu Jun 4 07:03:13 2009 From: thevinn at yahoo.com (Vinnie) Date: Thu Jun 4 07:03:26 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes Message-ID: <301954.33658.qm@web58203.mail.re3.yahoo.com> I rewrote each of the response types to represent an analog prototype of a low-pass filter with a fixed angular frequency pi/2 (normalized frequency). Then I use the low-pass to low-pass transformation on the roots: c' = (1+kc)/(1-kc) Where c is the complex root (i.e. pole or zero), k is a frequency transformation coefficient k=tan(w/2) with w=new cutoff frequency. This is working great for Butterworth and Chebyshev Type I. But it is failing for the inverse Chebyshev. Is this technique generalizable to any analog prototype filter or did I just get lucky? From michael.gogins at gmail.com Thu Jun 4 08:54:02 2009 From: michael.gogins at gmail.com (Michael Gogins) Date: Thu Jun 4 08:54:44 2009 Subject: [music-dsp] Re: music-dsp Digest, Vol 66, Issue 6 In-Reply-To: <217067.32995.qm@web58203.mail.re3.yahoo.com> References: <217067.32995.qm@web58203.mail.re3.yahoo.com> Message-ID: <898dd7270906040554qec4d019je79721cae8be26ed@mail.gmail.com> I think this is a really good idea, and if you succeed in creating this header I will surely use it. Regards, Mike On 6/3/09, Vinnie wrote: > >> From: robert bristow-johnson >> i'm trying to understand what your "bottom line" is. > > I want to make this a comprehensive C++ library for IIR filters. I would > like to keep the single-header design. The goals: > > - Butterworth, Chebyshev Type I, Chebyshev Type II, Elliptic, Bessel > response types > > - All Biquad variants > > - Low Pass, High Pass, Band Pass, Band Stop, Low Shelf, High Shelf, Peaking, > Notch of every response type > > - Arbitrary order, changable at runtime > > - Flexibility to control the floating point types used for calculation and > output > > - Robust class hierarchy that encapsulates each concept neatly > > - No repeated formulas or code > > - Fast parameter changes using cached calculations > > - Functional programming style that allows easy assembly of filters from > primitives using templates > > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp > links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com From thevinn at yahoo.com Thu Jun 4 09:58:00 2009 From: thevinn at yahoo.com (Vinnie) Date: Thu Jun 4 09:58:14 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes Message-ID: <130941.72675.qm@web58204.mail.re3.yahoo.com> Given only the poles and zeroes of a low-pass analog prototype is there a simple formula to transform it into a low-shelf analog prototype? From martin.eisenberg at udo.edu Thu Jun 4 10:06:01 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Thu Jun 4 10:03:30 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes References: <301954.33658.qm@web58203.mail.re3.yahoo.com> Message-ID: <002801c9e51d$9b4e9300$0201a8c0@mooncode> This is not a direct answer, but Losada, Pellissier: Designing IIR Filters with a Given 3-dB Point, IEEE Signal Processing Magazine, July 2005 shows how to design Chebyshev I & II filters with specified 3-dB band edges, as opposed to the usual transition bandwidth. Martin From martin.eisenberg at udo.edu Thu Jun 4 10:08:48 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Thu Jun 4 10:06:16 2009 Subject: [music-dsp] Re: music-dsp Digest, Vol 66, Issue 6 References: <217067.32995.qm@web58203.mail.re3.yahoo.com> Message-ID: <002e01c9e51d$fea358a0$0201a8c0@mooncode> Vinnie wrote: > - Robust class hierarchy that encapsulates each concept neatly > > - No repeated formulas or code You might think about exposing pole/zero generators so people can build their own multiband subclasses while exploiting the SSE and multichannel machinery. Martin From rbj at audioimagination.com Thu Jun 4 12:45:17 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Thu Jun 4 12:45:40 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes In-Reply-To: <130941.72675.qm@web58204.mail.re3.yahoo.com> References: <130941.72675.qm@web58204.mail.re3.yahoo.com> Message-ID: <2C0B3C5A-36D0-48C6-A56C-85FB2182DD6A@audioimagination.com> On Jun 4, 2009, at 7:03 AM, Vinnie wrote: > I rewrote each of the response types to represent an analog > prototype of a low-pass filter with a fixed angular frequency pi/2 > (normalized frequency). that's not what i (nor a zillion textbooks) mean by "normalized frequency". when we say "normalized frequency" we mean that the action is happening when the angular frequency w = s/j = 1. i.e. for 2nd order: LPF: H(s) = 1/(s^2 + s/Q + 1) BPF: H(s) = s/(s^2 + s/Q + 1) HPF: H(s) = s^2/(s^2 + s/Q + 1) BRF: H(s) = (s^2 + 1)/(s^2 + s/Q + 1) APF: H(s) = (s^2 - s/Q + 1)/(s^2 + s/Q + 1) *those* are transfer functions with normalized angular frequency. w=1 is the "significant frequency". note that the 2nd-order BPF filter (which is the minimum order BPF) comes from the simple 1st-order LPF prototype (with normalized frequency) H(s) = 1/(s + 1) with the substitution of s <- Q*(s + 1/s) there is a gain difference (1/Q), this gets you BPF: H(s) = (s/Q)/(s^2 + s/Q + 1) the latter here has gain of 1 when w = s/j = 1 whereas the one about has gain of Q at the same resonant frequency. but the LPF to BPF mapping should be clear. the LPF has maximum gain when w=0 (DC). but that point (w=0) gets mapped to w=1 with the substitution, s <- Q*(s + 1/s). so this BPF has the same gain at w=1 that the LPF had at w=0. this is *much* easier to do when doing this in truly normalized frequency. you can send it to the frequency you want (complete with compensation for frequency warping) with the BLT substitution i shown you before (which is also depicted in the cookbook). i'm just trying to save you a little work and headache. > Then I use the low-pass to low-pass transformation on the roots: > > c' = (1+kc)/(1-kc) > > Where c is the complex root (i.e. pole or zero), k is a frequency > transformation coefficient k=tan(w/2) with w=new cutoff frequency. > > This is working great for Butterworth and Chebyshev Type I. But it > is failing for the inverse Chebyshev. inverse Chebyshev (a.k.a. Chebyshev Type II) has s-plane zeros, but not Type I nor Butterworth. > Is this technique generalizable to any analog prototype filter or > did I just get lucky? i don't think you're lucky yet. On Jun 4, 2009, at 9:58 AM, Vinnie wrote: > Given only the poles and zeroes of a low-pass analog prototype is > there a simple formula to transform it into a low-shelf analog > prototype? what if your LPF prototype does have any zeros? (strictly speaking, the zeros are out there at infinity.) the low shelf will have zeros. if you assemble your LPF transfer function from the poles/zeros, scale it by (K-1) where K is your shelf gain, and add that transfer function to a wire (H(s)=1), you will get a shelf (of sorts) and the poles will remain unchanged. you can work out what you get for zeros. i don't necessarily recommend this shelf. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From rbj at audioimagination.com Thu Jun 4 12:50:00 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Thu Jun 4 12:50:19 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes In-Reply-To: <002801c9e51d$9b4e9300$0201a8c0@mooncode> References: <301954.33658.qm@web58203.mail.re3.yahoo.com> <002801c9e51d$9b4e9300$0201a8c0@mooncode> Message-ID: On Jun 4, 2009, at 10:06 AM, Martin Eisenberg wrote: > This is not a direct answer, but > Losada, Pellissier: Designing IIR Filters with a Given 3-dB > Point, > IEEE Signal Processing Magazine, July 2005 > shows how to design Chebyshev I & II filters with specified 3-dB > band edges, as opposed to the usual transition bandwidth. this looks pretty relevant. i don't get IEEE. can someone send me a pdf of it if they have such? i've actually done all of that work before (it's a nice learning experience with the general Tchebyshev function which turns out to be polynomials), but i'd like to compare notes. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From thevinn at yahoo.com Thu Jun 4 14:42:49 2009 From: thevinn at yahoo.com (Vinnie) Date: Thu Jun 4 14:42:59 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes Message-ID: <577622.8827.qm@web58204.mail.re3.yahoo.com> > From: robert bristow-johnson > that's not what i (nor a zillion textbooks) mean by > "normalized?frequency". Yeah I know that, I was just using the terminology from "Digital Filters: Analysis, Design, and Applications" by Andreas Antoniou. Admittedly he goes against the grain, every magnitude response diagram is inverted (he refers to them as "loss characteristics"). I've been trying to move towards this implementation model: template struct Filter : Cascade { void Setup( Specification &spec ) { Prototype proto; Layout layout; proto.Design( spec, &layout ); Family t; t.Transform( spec, &layout ); Realize( layout ); } } Where Prototype is Butter, ChebyI, ChebyI, Elliptic, Bessel, and Family is LowPass, HighPass, BandPass, BandStop, LowShelf, HighShelf, or BandEq. Unfortunately as you pointed out, it can't work exactly this way because of the zeros (I have it working for the poles). It seems like each family needs some special case depending on the prototype for zero treatment. I have it mostly working except that there is some hacking going on to get the zeros. By hacking, I mean that I have to do things slightly differently to each prototype in order to yield the correct zeros. I will post something as soon as it is back to the functionality it had before. From bogac at bteaudio.com Thu Jun 4 15:35:43 2009 From: bogac at bteaudio.com (Bogac Topaktas) Date: Thu Jun 4 15:36:58 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes Message-ID: <20d7bf49$6d1660f7$6807a079$@com> > > This is not a direct answer, but > > Losada, Pellissier: Designing IIR Filters with a Given 3-dB > > Point, > > IEEE Signal Processing Magazine, July 2005 > > shows how to design Chebyshev I & II filters with specified 3-dB > > band edges, as opposed to the usual transition bandwidth. > > this looks pretty relevant. i don't get IEEE. can someone send me a > pdf of it if they have such? The article and associated .m files are available online at: http://www.mathworks.com/matlabcentral/files/7932/iir3db.zip From neolit123 at gmail.com Thu Jun 4 18:07:14 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Thu Jun 4 18:08:28 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes References: <577622.8827.qm@web58204.mail.re3.yahoo.com> Message-ID: <00f901c9e560$ed75c7f0$0201a8c0@LuboPC> Looks good, But I question the categorization of filters by their frequency response as "Family". Or at least I've never seen it written this way. Example: "This digital filter, derived from a 'Butterworth' analog filter Prototype (class) is from the 'LowPass' Family (class)" While "Family" is correct in a way, I guess frequency response would be more accurate, or just "Type" but the words "Prototype", "Type" share roots. So maybe "Design" / "Type" - "Design" because your are essentially modelling analog filter designs with DSP based on a prototype. - "Type" because this filter can produce different "Types" of frequency response. --- Another thing is to consider that the Elliptic design on its own allows some flexibility, so that in certain limits for xi and epsilon - Butterworth Chebyshev Type I and Chebyshev Type II *can* be derived from it. Lubomir ----- Original Message ----- From: "Vinnie" > I've been trying to move towards this implementation model: > template > struct Filter : Cascade > { > void Setup( Specification &spec ) > { > Prototype proto; > Layout layout; > proto.Design( spec, &layout ); > Family t; > t.Transform( spec, &layout ); > Realize( layout ); > } > } > > Where Prototype is Butter, ChebyI, ChebyI, Elliptic, Bessel, and Family is > LowPass, HighPass, BandPass, BandStop, > LowShelf, HighShelf, or BandEq. From rbj at audioimagination.com Thu Jun 4 20:05:37 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Thu Jun 4 20:06:04 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes In-Reply-To: <00f901c9e560$ed75c7f0$0201a8c0@LuboPC> References: <577622.8827.qm@web58204.mail.re3.yahoo.com> <00f901c9e560$ed75c7f0$0201a8c0@LuboPC> Message-ID: On Jun 4, 2009, at 6:07 PM, Lubomir I. Ivanov wrote: > Looks good, > > But I question the categorization of filters by their frequency > response as > "Family". Or at least I've never seen it written this way. > > Example: > "This digital filter, derived from a 'Butterworth' analog filter > Prototype > (class) is from the 'LowPass' Family (class)" > > While "Family" is correct in a way, I guess frequency response > would be more > accurate, or just "Type" i would call LowPass vs. BandPass vs. HighShelf to be "shape". and leave Butterworth, Chebyshev, etc. as "design". but, Vinnie, i don't think you'll be able to put this on a rectangular grid and always get good results by fitting together: 8th- order, Elliptical, HighShelf. you might get better high-order shelves than just adding some LPF or HPF output to a wire from the input. well, at least it will be interesting. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From raga.raga at gmx.de Fri Jun 5 04:43:39 2009 From: raga.raga at gmx.de (Jan Baumgart) Date: Fri Jun 5 04:44:05 2009 Subject: [music-dsp] mda plugins now open source! Message-ID: <4A28DABB.8030303@gmx.de> Although this is old news, i wanted to share the info, that the great freeware mda plugin-bundle (vst/au) from smartelectronix has been released as open source under the GNU/MIT License on sourceforge earlier this year. Features amongst other stuff some nice distortion and dynamic processing... http://sourceforge.net/projects/mda-vst/ http://mda.smartelectronix.com/ greetz, jan. From neolit123 at gmail.com Fri Jun 5 11:39:13 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Fri Jun 5 11:39:46 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes References: <577622.8827.qm@web58204.mail.re3.yahoo.com><00f901c9e560$ed75c7f0$0201a8c0@LuboPC> Message-ID: <001701c9e5f3$ce069000$0201a8c0@LuboPC> ----- Original Message ----- From: "robert bristow-johnson" > but, Vinnie, i don't think you'll be able to put this on a rectangular > grid and always get good results by fitting together: 8th- order, > Elliptical, HighShelf. you might get better high-order shelves than just > adding some LPF or HPF output to a wire from the input. well, at least > it will be interesting. > As you have mentioned before, wiring the input with the high-order filter will result phase cancellation ("dip") near Fc. Wich will increase with the order of the lp / hp. I thought today of some quick methods to compensate for the "dip" while retaining the high-order IIR low-pass, hi-pass structure. Here is a 4th order Chebyshev Type I, LP wired to the input to produce a low-shelf: scale = 10 ^ (dbvalue / 20) - 1; output = lp_out + input * scale; 3db boost at 600Hz, minimal ripple. magnitude: http://img36.imageshack.us/img36/4267/cheby24dbwire3dbboostma.png phase: http://img36.imageshack.us/img36/1084/cheby24dbwire3dbboostph.png ------ While - depending of the cutoff frequency (Fc), the ripple factor epsilon and the filter order, a delay-line (feedforward comb) can be introduced on the input signal before summing it with the low-pass output: scale = 10 ^ (dbvalue / 20) - 1; output = lp_out + input_delayed * scale; Fine tuning of the delay time will shift the input and partially compensate for the "dip" artifact. 3db boost at 600Hz, minimal ripple, 0.56ms delay (approx 24 samples at Fs = 44100Hz) magnitude: http://img36.imageshack.us/img36/6125/cheby24dbwirewithwire3d.png phase: http://img36.imageshack.us/img36/2968/cheby24dbwirewithwire3di.png --- problems with this method: - in the case of Chebyshev prototype the delay times should be a function of these parameters: -- Fs -- Fc -- Epsilon (also Xi for Elliptic) -- scale - negative values (cutting) require additional work. - inaccuracy - not possible to tweak sufficiently, due to the limitations of the descrete signal processing. I'm not sure if oversampling will improve accuracy here.. - unstable above Fs / 4 - same as above - altering the phase response of the filter ("comb" filtering) ... There aren't many benefits in this solution ;).. and I wouldn't recommend it for anything other than static design. Still it is possible to dynamically compensate for the artifact with more complex (parameter dependent) calculation of delay times. Lubomir From contact at quikquak.com Sat Jun 6 10:55:25 2009 From: contact at quikquak.com (contact) Date: Sat Jun 6 10:55:38 2009 Subject: [music-dsp] Stereo widening a reverb References: <577622.8827.qm@web58204.mail.re3.yahoo.com><00f901c9e560$ed75c7f0$0201a8c0@LuboPC> <001701c9e5f3$ce069000$0201a8c0@LuboPC> Message-ID: <004201c9e6b6$d30b2890$6401a8c0@DaveUpstairs> Hello all. I have a reverb in development, and the stereo channels get completely mixed in its process - so the two have the same frequencies but are extremely mixed in phase. I was wondering if there was a way to separate the two channels, or basically create a 'hole' in the middle of the mix? The stereo separation code in musicdsp.org has no effect, presumably because of the phase changes. I thought I could use an FFT and bias the peak differences from each of the channels to one side or the other, but apart from unwanted latency, I think I'll get noise from this technique. I realise that normal reverbs pan the early reflections to achieve this widening, but I'm looking for a post-effect solution. Any ideas? Thanks Dave From dt_spam at comcast.net Sat Jun 6 16:45:50 2009 From: dt_spam at comcast.net (Daniele) Date: Sat Jun 6 16:46:37 2009 Subject: [music-dsp] Which Signal Processing Device? In-Reply-To: <00fa01c9d8fb$c38cdf30$0773a8c0@rossmacbook> References: <20090519135801.4BD4B83A0E2@music.columbia.edu><0E1EA11F-FF27-45A2-8C75-C27A508AFF81@korgrd.com> <00fa01c9d8fb$c38cdf30$0773a8c0@rossmacbook> Message-ID: <001e01c9e6e7$c77112c0$56533840$@net> > I've been very happy using MSVC++ for the last three years (and > relatively > unhappy using XCode on OSX) but havn't had much joy with performance > tuning > when evaluating VTune and am starting to wonder whether it's worth > doing > Linux builds just to leverage C++ profiling and tuning tools that > aren't > available on Windows... (I know about valgrind but I presume there are > others). Hi Ross, VTune is good, but there are also other Windows profilers around: - profiler included in some versions of Visual Studio - Windows Performance Tools (free download, requires Vista, http://msdn.microsoft.com/en-us/performance/default.aspx) - AMD Code Analyst (free download, not specific to AMD processors) Daniele From neolit123 at gmail.com Sat Jun 6 17:03:00 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Sat Jun 6 17:04:19 2009 Subject: [music-dsp] Stereo widening a reverb References: <577622.8827.qm@web58204.mail.re3.yahoo.com><00f901c9e560$ed75c7f0$0201a8c0@LuboPC><001701c9e5f3$ce069000$0201a8c0@LuboPC> <004201c9e6b6$d30b2890$6401a8c0@DaveUpstairs> Message-ID: <002401c9e6ea$49e09300$0201a8c0@LuboPC> ----- Original Message ----- From: "contact" > Hello all. I have a reverb in development, and the stereo channels get > completely mixed in its process - so the two have the same frequencies but > are extremely mixed in phase. Is this the result from an all-pass cascade? Why not execute the thread twice, once for each channel? :] > I was wondering if there was a way to separate the two channels, or > basically create a 'hole' in the middle of the mix? > The stereo separation code in musicdsp.org has no effect, presumably > because of the phase changes. If the frequency response of the two is identical the separated 'side' would be empty i.e. -inf. > I thought I could use an FFT and bias the peak differences from each of > the channels to one side or the other, but apart from unwanted latency, I > think I'll get noise from this technique. > > I realise that normal reverbs pan the early reflections to achieve this > widening, but I'm looking for a post-effect solution. Any ideas? Panning the reflections is a nice effect, but it also creates a lot of phase cancellation, when summed to mono. Summing the output of such reverbs to mono, will result in elimination of most of the character of the reverbed signal. So most of the character of the reverb should be in the center, while the 'side' compliments. Well at least this is what I think... But, again if the frequency response of the two channels is identical (post reverb), I think, this should be treated in the lines of pseudo mono-to-stereo processing. Some of your options are: changing the frequency response of the two channels (oldest trick in the book), applying different modulation to both (comb filter with different delay times) and some others. Here is a the basic m/s splitter with 2 band peak/notch filter, which is applied to side-left, side-right. You can also use high-shelf boost, low-shelf cut for one channel and the inverse for the other. //---------------------------------------------------- // decibels to amp for the stereo gain // db is your value in decibels (e.x: +6dB) sgain = 10^(db / 20); // inl, inr - input samples (post reverb) // mid - extract center mid = (inl + inr) / 2; // extract left, right left = inl - mid; right = inr - mid; // process left / right separately // to create pseudo stereo effect // bellow example of 2 band peak/notch filter function process(input, f_cut, f_boost) { // filter code here } processed_left = process(left, 500, 2000); processed_right = process(right, 2000, 500); // outl, outr - output samples // widen the processed_left / processed_right with 'sgain' // you can exclude 'mid' to output only the 'side' outl = mid + processed_left * sgain; outr = mid + processed_right * sgain; //---------------------------------------------------- I think I can say more if you post sample-aligned: dry stereo sample, and a wet audio sample, so that i can check the transfer function. :] Lubomir I. Ivanov http://www.tu-varna.bg From martin.eisenberg at udo.edu Sat Jun 6 19:49:08 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Sat Jun 6 19:46:34 2009 Subject: [music-dsp] Stereo widening a reverb References: <577622.8827.qm@web58204.mail.re3.yahoo.com><00f901c9e560$ed75c7f0$0201a8c0@LuboPC><001701c9e5f3$ce069000$0201a8c0@LuboPC> <004201c9e6b6$d30b2890$6401a8c0@DaveUpstairs> Message-ID: <001a01c9e701$66b21460$0201a8c0@mooncode> contact wrote: > Hello all. I have a reverb in development, and the stereo > channels get completely mixed in its process - so the two have > the same frequencies but are extremely mixed in phase. > I was wondering if there was a way to separate the two > channels, or basically create a 'hole' in the middle of the > mix? The core idea is that the channel outputs should be decorrelated, i.e., pick up differing phase shifts. Dattorro's plate reverb (Effect Design I, http://www.stanford.edu/~dattorro/research.html) constructs each output from its own selection of taps into the diffusor structure. I think it was Moorer who has recommended in some paper or other to share most of the diffusion stages in a cascade-type reverb but duplicate and mutate the last one or two stages. If you really don't want to change the algorithm you have now, try feeding the output directly to one channel and through an additional allpass to the other. But it can also be a magnitude filter since that will inevitable have phase shift too. Martin From bogac at bteaudio.com Sun Jun 7 07:58:47 2009 From: bogac at bteaudio.com (Bogac Topaktas) Date: Sun Jun 7 08:00:09 2009 Subject: [music-dsp] Stereo widening a reverb Message-ID: <6214db40$73a2a878$26851a6f$@com> > I was wondering if there was a way to separate the two channels, or > basically create a 'hole' in the middle of the mix? Theoretically, you can obtain N decorrelated channels from one input channel by utilizing a decorrelation process. See the following paper for full details on the theory and practical limitations: "The Decorrelation of Audio Signals and Its Impact on Spatial Imagery" by Gary S. Kendall Computer Music Journal, Vol. 19, No. 4. (Winter, 1995), pp. 71-87. http://www.dxarts.washington.edu/courses/567/08WIN/KendallDecorrelation_lr.p df -------- Original Message -------- > From: "contact" > Sent: Saturday, June 06, 2009 5:56 PM > To: "A discussion list for music-related DSP" > Subject: [music-dsp] Stereo widening a reverb > > Hello all. I have a reverb in development, and the stereo channels get > completely mixed in its process - so the two have the same frequencies but > are extremely mixed in phase. > I was wondering if there was a way to separate the two channels, or > basically create a 'hole' in the middle of the mix? > The stereo separation code in musicdsp.org has no effect, presumably because > of the phase changes. > > I thought I could use an FFT and bias the peak differences from each of the > channels to one side or the other, but apart from unwanted latency, I think > I'll get noise from this technique. > > I realise that normal reverbs pan the early reflections to achieve this > widening, but I'm looking for a post-effect solution. Any ideas? > > Thanks > Dave > > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From contact at quikquak.com Sun Jun 7 11:19:10 2009 From: contact at quikquak.com (contact) Date: Sun Jun 7 11:19:22 2009 Subject: [music-dsp] Stereo widening a reverb References: <6214db40$73a2a878$26851a6f$@com> Message-ID: <003c01c9e783$4f099590$6401a8c0@DaveUpstairs> Thanks for all the ideas guys. O.K. here's my FX tail of a tambourine hit: http://tinyurl.com/nzos3s dry: http://tinyurl.com/kmhox9 As you can hear, I would like to keep the current stereo image, but it would be great to allow the user to widen the sound. The idea of swapping frequency bands between channels to make them unique is interesting, but I feel it would colour each channel differently - I will give it a try with subtle notch/peak filters though. Decorrelation appears to be the keyword I was looking for, I will look into your suggestions on this. Thanks again, Dave ----- Original Message ----- From: "Bogac Topaktas" To: "A discussion list for music-related DSP" Sent: Sunday, June 07, 2009 12:58 PM Subject: re: [music-dsp] Stereo widening a reverb > >> I was wondering if there was a way to separate the two channels, or >> basically create a 'hole' in the middle of the mix? > > Theoretically, you can obtain N decorrelated channels from one input > channel > by utilizing a decorrelation process. See the following paper for full > details on the > theory and practical limitations: > > "The Decorrelation of Audio Signals and Its Impact on Spatial Imagery" > by Gary S. Kendall > Computer Music Journal, Vol. 19, No. 4. (Winter, 1995), pp. 71-87. > http://www.dxarts.washington.edu/courses/567/08WIN/KendallDecorrelation_lr.p > df > > -------- Original Message -------- >> From: "contact" >> Sent: Saturday, June 06, 2009 5:56 PM >> To: "A discussion list for music-related DSP" > >> Subject: [music-dsp] Stereo widening a reverb >> >> Hello all. I have a reverb in development, and the stereo channels get >> completely mixed in its process - so the two have the same frequencies > but >> are extremely mixed in phase. >> I was wondering if there was a way to separate the two channels, or >> basically create a 'hole' in the middle of the mix? >> The stereo separation code in musicdsp.org has no effect, presumably > because >> of the phase changes. >> >> I thought I could use an FFT and bias the peak differences from each of > the >> channels to one side or the other, but apart from unwanted latency, I > think >> I'll get noise from this technique. >> >> I realise that normal reverbs pan the early reflections to achieve this >> widening, but I'm looking for a post-effect solution. Any ideas? >> >> Thanks >> Dave >> >> >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, source code archive, list archive, book reviews, > dsp links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp > > > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From neolit123 at gmail.com Sun Jun 7 13:06:23 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Sun Jun 7 13:06:46 2009 Subject: [music-dsp] Stereo widening a reverb References: <6214db40$73a2a878$26851a6f$@com> <003c01c9e783$4f099590$6401a8c0@DaveUpstairs> Message-ID: <001d01c9e792$4d89fca0$0201a8c0@LuboPC> The dry signal seems to have its 'side' peaking around -63dBFS. The wet signal on the other hand, has quite healthy 'side' peaking around -16dBFS. I believe this is the result of some interesting L / R distribution of the taps from the algorithm. I don't see why the M / S splitter code (post-reverb) wouldn't work here. Here is an example of the 'wet' signal flow: ---[ reverb ] -- [ mod ] -- [ tone ] -- [m / s] --[ +] [dry / wet sum] [mod] - a post reverb modulation (delay based fx such as chorus) can ensure that stereo is always acheived, if the reverb does not deal well with mono inputs. [tone eq] - can be bass / treble control or a hp / lp chain. [m / s] - controls the width of the stereo-image (check 'sgain' variable in my previous message) Lubomir ----- Original Message ----- From: "contact" > Thanks for all the ideas guys. > O.K. here's my FX tail of a tambourine hit: > http://tinyurl.com/nzos3s > dry: > http://tinyurl.com/kmhox9 > > As you can hear, I would like to keep the current stereo image, but it > would be great to allow the user to widen the sound. > The idea of swapping frequency bands between channels to make them unique > is interesting, but I feel it would colour each channel differently - I > will give it a try with subtle notch/peak filters though. > Decorrelation appears to be the keyword I was looking for, I will look > into your suggestions on this. > Thanks again, > Dave > From vadim.zavalishin at native-instruments.de Mon Jun 8 05:39:15 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Mon Jun 8 05:39:42 2009 Subject: [music-dsp] Name for the integrator replacement technique Message-ID: Hi everyone In parallel to the thread which Martin started to find a name for the delayless feedback handling technique, I'd like to discuss the name of the integrator replacement technique combined with delayless feedback handling (that is if anyone besides me puts any value in there). I'd suggest "topology-preserving transform" or TPT. The reason is that the transfer function of the resulting system is exactly what it would have been if one applied an s- to z-plane transform (most commonly BLT) to the analog prototype transfer function, but simultaneously also the topology of the system is preserved. Any comments? Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From gasmoa at gmail.com Mon Jun 8 08:29:40 2009 From: gasmoa at gmail.com (george bezerianos) Date: Mon Jun 8 08:29:50 2009 Subject: [music-dsp] Name for the integrator replacement technique In-Reply-To: References: Message-ID: <4c23fbf70906080529s4eddfcbcy6a80c05301224739@mail.gmail.com> Hi, I hadn't really the time to check the actual method but i can definitely comment on a badly chosen name. "Topology-preserving trasform" could actually be an informal (and possibly imprecise) name for a homeomorphism, a bicontinuous function between two topological spaces that actually preserves their topology - an isomorphism of topological spaces. Topology is a rather deep, extremely influential and extensively used mathematical discipline and language that I wouldn't touch for baptism anymore. That said, "Signal-Flow Preserving Transform" sounds more on the lines of Signal Processing literature (if, from a quick read a i had through this list's posts, is what you're talking about). I'd remove anything that has to do with "topology" and derivatives all together. Yours, George Bezerianos On Mon, Jun 8, 2009 at 11:39 AM, Vadim Zavalishin wrote: > > Hi everyone > > In parallel to the thread which Martin started to find a name for the delayless feedback handling technique, I'd like to discuss the name of the integrator replacement technique combined with delayless feedback handling (that is if anyone besides me puts any value in there). > > I'd suggest "topology-preserving transform" or TPT. The reason is that the transfer function of the resulting system is exactly what it would have been if one applied an s- to z-plane transform (most commonly BLT) to the analog prototype transfer function, but simultaneously also the topology of the system is preserved. > > Any comments? > > Regards, > Vadim > > -- > Vadim Zavalishin > Senior Software Developer | R&D > > Tel +49-30-611035-0 > Fax +49-30-611035-2600 > > NATIVE INSTRUMENTS GmbH > Schlesische Str. 28 > 10997 Berlin, Germany > http://www.native-instruments.com > > Registergericht: Amtsgericht Charlottenburg > Registernummer: HRB 72458 > UST.-ID.-Nr. DE 20 374 7747 > Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp From gasmoa at gmail.com Mon Jun 8 08:41:09 2009 From: gasmoa at gmail.com (george bezerianos) Date: Mon Jun 8 08:41:21 2009 Subject: [music-dsp] Name for the integrator replacement technique In-Reply-To: References: Message-ID: <4c23fbf70906080541q644fbd87i360f145147cd0dbf@mail.gmail.com> Hi, I hadn't really the time to check the actual method but i can definitely comment on a badly chosen name. "Topology-preserving trasform" could actually be an informal (and possibly imprecise) name for a homeomorphism, a bicontinuous function between two topological spaces that actually preserves their topology - an isomorphism of topological spaces. Topology is a rather deep, extremely influential and extensively used mathematical discipline and language that I wouldn't touch for baptism anymore. That said, "Signal-Flow Preserving Transform" sounds more on the lines of Signal Processing literature (if, from a quick read a i had through this list's posts, is what you're talking about). I'd remove anything that has to do with "topology" and derivatives all together. Yours, George Bezerianos On Mon, Jun 8, 2009 at 11:39 AM, Vadim Zavalishin wrote: > Hi everyone > > In parallel to the thread which Martin started to find a name for the > delayless feedback handling technique, I'd like to discuss the name of the > integrator replacement technique combined with delayless feedback handling > (that is if anyone besides me puts any value in there). > > I'd suggest "topology-preserving transform" or TPT. The reason is that the > transfer function of the resulting system is exactly what it would have been > if one applied an s- to z-plane transform (most commonly BLT) to the analog > prototype transfer function, but simultaneously also the topology of the > system is preserved. > > Any comments? > > Regards, > Vadim > > -- > Vadim Zavalishin > Senior Software Developer | R&D > > Tel +49-30-611035-0 > Fax +49-30-611035-2600 > > NATIVE INSTRUMENTS GmbH > Schlesische Str. 28 > 10997 Berlin, Germany > http://www.native-instruments.com > > Registergericht: Amtsgericht Charlottenburg > Registernummer: HRB 72458 > UST.-ID.-Nr. DE 20 374 7747 > Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription info, > FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From gasmoa at gmail.com Mon Jun 8 08:48:25 2009 From: gasmoa at gmail.com (george bezerianos) Date: Mon Jun 8 08:48:40 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077> Message-ID: <4c23fbf70906080548h447263acp403a8f337c05d3f5@mail.gmail.com> Hi, (and sorry for the double-posting as i had some email issues with gmail and musicdsp). I had a brief look at the article and i can't find the motivation behind it apart from providing us with a bunch of formulas that one can check out with a Computer Algebra System. And that because I don't see where you're hoping to get at with (complex) analysis, as this certainly leads to the manifestation of special functions which will infest your algorithm with numerical issues very fast as your article already points out. There are better numerical alternatives as I'm gonna elaborate on soon. Also it doesn't really provide _any_ useful generalization which renders it mathematically useless - performing analytical calculations doesn't reveal anything to us about the underlying symmetry and structure of the problem. Some time ago, as you already know well as we had some chat on another forum, I released an article on the general problem of the efficient bandlimiting of oscillator hard-syncing; that of arbitary waveform hard sync. I provide the link again here: http://s1gnals.blogspot.com/2008/12/bloo_6897.html Admittedly, the language it's written in is rather ...autistic (forgive an aspie). It also has some other issues that I will try to make it short here: its main problem is that while it attenuates inharmonic partials it lets harmonics leak resulting in waveforms not being on their original form, but infested with harmonic artifacts even on their original (integer period) setting. It turns out that these go away as one increases the overlapping (or in other words the time that the slave oscillator will be "ringing" (btw, it seems to also be related to the number of harmonics already present in the original waveform and thus the sine case works quite well as it is and it's quite efficient with very low noise as it's just convolution!)). So, that led me to the insight: There is a perfect analogy here to the well known Taylor's Theorem. One interpretation of this theorem is that we can approximate a function (let's stick to one variable without loss of generality) by knowing the derivatives at one single point. In a similar manner we can bandlimit a generic hard-sync case by bandlimiting higher order derivatives of a Cn discontinuity through integration but also by convolving a BLIT tuned tot he master frequency with sufficiently long iterations of the original waveform!!. I'm pretty sure that one can even find a formula connecting the sufficient length of the slave waveform to the order of the discontinuity and that's to my eyes a clear analogy to the Taylor case!! One can easily verify the correctness of the above numerically using the matlab code I provide in the above link. Or just convolve a BLIT tuned to the master frequency with the output of the slave oscillator ringing long enough using the enviroment of your choice. Unfortunately professional obligations don't allow for a deep formal representation of the above insight at the moment, so If anyone would like to contribute that would be very nice for the sake of theoretical justification and insight to the problem. I will also try to fix some C++/SIMD implementation as soon as i find some time so that anyone can check easily what's claimed but also be able to use it in real-world applications as it's aiming to practicality as well apart from the theoretical consequences. The low numerical noise of convolution would be really hard to surpass by the integration (BLEP category) methods as many people have verified already and it puts out of the question any analytic / special function ridden attempts. Yours, George Bezerianos On Wed, May 6, 2009 at 2:12 PM, Vadim Zavalishin wrote: > Hi everyone > > Here's a new article about the sine waveform syncing antialiasing. Three > different methods are proposed. I don't know if this is a pioneering work, > or just repeating someone else's footsteps, anyway FWIW. > > http://www.native-instruments.de/index.php?id=dsparticles > > Comments welcome. > > One correction: in the references the article says that the full preview of > the current edition of NR in C++ is available online. Apparently, this is no > longer the case, but I was somewhat loath to correct the already finished > article after finding out. I apologize for the mistake. Anyway, an older > edition still is. > > Regards, > Vadim > > -- > Vadim Zavalishin > Senior Software Developer | R&D > > Tel +49-30-611035-0 > Fax +49-30-611035-2600 > > NATIVE INSTRUMENTS GmbH > Schlesische Str. 28 > 10997 Berlin, Germany > http://www.native-instruments.com > > Registergericht: Amtsgericht Charlottenburg > Registernummer: HRB 72458 > UST.-ID.-Nr. DE 20 374 7747 > Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription info, > FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From vadim.zavalishin at native-instruments.de Mon Jun 8 09:04:31 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Mon Jun 8 09:04:41 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <4c23fbf70906080548h447263acp403a8f337c05d3f5@mail.gmail.com> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077> <4c23fbf70906080548h447263acp403a8f337c05d3f5@mail.gmail.com> Message-ID: <39846A9B4047463EBC4741838DB002EB@nibln01077> > Also it doesn't really provide _any_ useful generalization which > renders it mathematically useless - performing analytical calculations > doesn't reveal anything to us about the underlying symmetry and > structure of the problem. Well, I don't know what do you mean by "mathematically useless". However the methods definitely work in practice, as you can see by the spectrum diagrams at the end of the article (also I have built a test implementation in Reaktor Core which is available in Reaktor user library). Also, the first of the three described methods is actually an obvious generalization of the BLEP sync antialiasing method. Is the latter then also "mathematically useless" in your opinion as well? > > Some time ago, as you already know well as we had some chat on another > forum, I released an article on the general problem of the efficient > bandlimiting of oscillator hard-syncing; that of arbitary waveform > hard sync. I provide the link again here: > > http://s1gnals.blogspot.com/2008/12/bloo_6897.html I've read that article. My main problem with it is that it doesn't provide any practical analysis on how "wrong" the resulting spectra are going to be. I was too lazy to do the respective analysis myself. > One interpretation of this theorem is that we can approximate a > function (let's stick to one variable without loss of generality) by > knowing the derivatives at one single point. In a similar manner we > can bandlimit a generic hard-sync case by bandlimiting higher order > derivatives of a Cn discontinuity through integration That's exactly the first of the methods described in my article. Thanks for the suggestion on the integrator replacement technique BTW. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From martin.eisenberg at udo.edu Mon Jun 8 10:01:25 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Mon Jun 8 09:58:50 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077> <4c23fbf70906080548h447263acp403a8f337c05d3f5@mail.gmail.com> Message-ID: <000d01c9e841$a11b29c0$0201a8c0@mooncode> george bezerianos wrote: > There is a perfect analogy here to the well known Taylor's > Theorem. One interpretation of this theorem is that we can > approximate a function (let's stick to one variable without > loss of generality) by knowing the derivatives at one single > point. In a similar manner we can bandlimit a generic > hard-sync case by bandlimiting higher order derivatives of a > Cn discontinuity through integration but also by convolving a > BLIT tuned tot he master frequency with sufficiently long > iterations of the original waveform!!. I'm pretty sure that > one can even find a formula connecting the sufficient length > of the slave waveform to the order of the discontinuity and > that's to my eyes a clear analogy to the Taylor case!! It has been noted in the field of interpolation that the sign-flipped monomials sgn(x)*x^n, in a sense the prototypical C^n discontinuities, are related to B-splines by differencing. It's something of another direction but perhaps you get something out of the lead. See e.g. reference http://dx.doi.org/10.1109/TIP.2003.818018 available at http://www.ee.cuhk.edu.hk/~tblu/monsite/pdfs/blu0302.pdf Martin From gasmoa at gmail.com Mon Jun 8 09:59:59 2009 From: gasmoa at gmail.com (george bezerianos) Date: Mon Jun 8 10:00:21 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <39846A9B4047463EBC4741838DB002EB@nibln01077> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077> <4c23fbf70906080548h447263acp403a8f337c05d3f5@mail.gmail.com> <39846A9B4047463EBC4741838DB002EB@nibln01077> Message-ID: <4c23fbf70906080659u48af2fdexd04596bc03b137b2@mail.gmail.com> On Mon, Jun 8, 2009 at 3:04 PM, Vadim Zavalishin wrote: >> Also it doesn't really provide _any_ useful generalization which >> renders it mathematically useless - performing analytical calculations >> doesn't reveal anything to us about the underlying symmetry and >> structure of the problem. > > Well, I don't know what do you mean by "mathematically useless". However the > methods definitely work in practice, as you can see by the spectrum diagrams > at the end of the article (also I have built a test implementation in > Reaktor Core which is available in Reaktor user library). Also, the first of > the three described methods is actually an obvious generalization of the > BLEP sync antialiasing method. Is the latter then also "mathematically > useless" in your opinion as well? > Accept my apologies on that, including a rather harsh language. It is actually that this method has been discussed in some musicdsp-oriented channels and forums for a rather while, so I just assumed that not being any new knowledge, though it's the first formal attempt to the description of the problem I've seen and you should be definitely be credited for that. >> >> Some time ago, as you already know well as we had some chat on another >> forum, I released an article on the general problem of the efficient >> bandlimiting of oscillator hard-syncing; that of arbitary waveform >> hard sync. I provide the link again here: >> >> http://s1gnals.blogspot.com/2008/12/bloo_6897.html > > I've read that article. My main problem with it is that it doesn't provide > any practical analysis on how "wrong" the resulting spectra are going to be. > I was too lazy to do the respective analysis myself. > Agreed. That's mainly what this post is about. Later I hint on what i think is the way to actually theoretically determine these limits in terms of connecting it to the actual discontinuity! There are definitely problems about that article and method but I think we have a kinda deep and nice connection between this and the actual higher-order generalization of BLEPs. >> One interpretation of this theorem is that we can approximate a >> function (let's stick to one variable without loss of generality) by >> knowing the derivatives at one single point. In a similar manner we >> can bandlimit a generic hard-sync case by bandlimiting higher order >> derivatives of a Cn discontinuity through integration > > That's exactly the first of the methods described in my article. > Well, I believe I covered that above. Otoh the sentence you cut in the middle here is actually the one that hints the actual connection and possible equivalence of the two methods. My main issue with BLEP generalizations lie on the numerical errors involved, something that's completely missing on the convolution representation of the problem. In terms of _practical_ techniques as opposed to purely theoretical mangling I think the convolution method has certain positive qualities. Also the harmonicity of the artifacts is a side-effect that still renders it usable for musical applications without any extension as opposed to inharmonic aliasing. And it's still quite vectorizable if we brink the actual implementation up. Now, it happens that there seems to be a beautiful connection between them, possibly having to do with taylor series as i say in my first post. This automatically would prove the correctness of BLOO and also set the basis for calculating sufficient convolution kernel lengths (how long the slave will ring) . I would love to get into this deeper but as i said I'm rather busy atm. However, If you wanna share any additional insight I'd be glad to discuss and possibly make something out of it. > > Thanks for the suggestion on the integrator replacement technique BTW. > No problem. Yours, George Bezerianos > Regards, > Vadim > > -- > Vadim Zavalishin > Senior Software Developer | R&D > > Tel +49-30-611035-0 > Fax +49-30-611035-2600 > > NATIVE INSTRUMENTS GmbH > Schlesische Str. 28 > 10997 Berlin, Germany > http://www.native-instruments.com > > Registergericht: Amtsgericht Charlottenburg > Registernummer: HRB 72458 > UST.-ID.-Nr. DE 20 374 7747 > Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription info, > FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From martin.eisenberg at udo.edu Mon Jun 8 10:11:31 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Mon Jun 8 10:08:55 2009 Subject: [music-dsp] Name for the integrator replacement technique References: <4c23fbf70906080529s4eddfcbcy6a80c05301224739@mail.gmail.com> Message-ID: <002501c9e843$09308f40$0201a8c0@mooncode> george bezerianos wrote: > "Topology-preserving trasform" could actually be an informal > (and possibly imprecise) name for a homeomorphism, a > bicontinuous function between two topological spaces that > actually preserves their topology - an isomorphism of > topological spaces. At issue is exactly that -- isomorphism of graphs up to labeling, or in other words, unchanged discrete connectivity. Martin From vadim.zavalishin at native-instruments.de Mon Jun 8 10:14:23 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Mon Jun 8 10:14:36 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <4c23fbf70906080659u48af2fdexd04596bc03b137b2@mail.gmail.com> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077><4c23fbf70906080548h447263acp403a8f337c05d3f5@mail.gmail.com><39846A9B4047463EBC4741838DB002EB@nibln01077> <4c23fbf70906080659u48af2fdexd04596bc03b137b2@mail.gmail.com> Message-ID: <59F0D1E3E5534153B03D414EF177B32F@nibln01077> > It is actually that this method has been discussed > in some musicdsp-oriented channels and forums for a rather while, so I > just assumed > that not being any new knowledge, though it's the first formal attempt to > the > description of the problem I've seen and you should be definitely be > credited for that. If you have any links to the relevant discussions I'd appreciate them. I must admit, I might have missed a lot, and I don't really claim my work as pioneering :-) Still, as you seem to be familiar with the subject, do you happen to know, are all the three methods described in my article already known, or are you referring only to the BLEP generalization in this respect? >> I've read that article. My main problem with it is that it doesn't >> provide >> any practical analysis on how "wrong" the resulting spectra are going to >> be. >> I was too lazy to do the respective analysis myself. >> > > Agreed. That's mainly what this post is about. Later I hint on what i > think is the way to actually > theoretically determine these limits in terms of connecting it to the > actual discontinuity! Well, even some practical demonstrations for some specific cases would probably help a lot here. > Well, I believe I covered that above. Otoh the sentence you cut in the > middle here is actually the one that hints the actual connection > and possible equivalence of the two methods. There's definitely a connection between the BLEP and BLIT, one being analytic integration, the other being numerical integration, otherwise they are very close. I fail to see the specific connection in the context of BLOO, as I fail to get a good intuitive picture of what's happening there. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From martin.eisenberg at udo.edu Mon Jun 8 10:17:53 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Mon Jun 8 10:15:18 2009 Subject: [music-dsp] Name for the integrator replacement technique References: Message-ID: <002b01c9e843$ed1e2b40$0201a8c0@mooncode> Vadim Zavalishin wrote: > I'd suggest "topology-preserving transform" or TPT. The reason > is that the transfer function of the resulting system is > exactly what it would have been if one applied an s- to > z-plane transform (most commonly BLT) to the analog prototype > transfer function, but simultaneously also the topology of the > system is preserved. You're assuming that the analog circuit is based on cascaded integrators in the first place, so "topology-preserving" is underspecific. How about "state variable preserving"? Martin From thevinn at yahoo.com Mon Jun 8 10:20:52 2009 From: thevinn at yahoo.com (Vinnie) Date: Mon Jun 8 10:21:02 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes Message-ID: <34518.30788.qm@web58201.mail.re3.yahoo.com> > From: "Lubomir I. Ivanov" > output = lp_out + input * scale; The problem is that this cannot be represented in my CascadeFilter, it requires additional processing after the cascade executes (specifically, to add the scaled input into the output). I am restricting myself only to the filters that can be realized using the cascade structure only. The good news is that I was able to decrypt the text of "Parametric Higher-Order Shelving Filters" to yield an implementation of a low shelf with Butterworth response characteristics. Through a stroke of fortune I was able to transform the analog low shelf into a digital low shelf, high shelf, and peaking/notch eq (of double the order). Now I am prospecting for the Chebyshev type I low shelf, Chebyshev type II low shelf, and Elliptic low shelf. Similar transformations should yield the corresponding low hself, high shelf, and peaking/notch eq. As was pointed out earlier it is not possible to generalize the construction of the zeros of low pass, high pass, band pass, and band stop filters from the corresponding analog prototype (for example, the Butterworth zeros are out at infinity). I was hoping this was possible because it would make the construction of template based classes very elegant. I was still able to get a decent class hierarchy working it just wasn't as streamlined or general as I hoped it would be. For example, the Butterworth high pass is constructed using: m_proto->Design( spec ); HighPass x; x.Transform( spec, &Poles(), m_proto->Poles() ); int n=spec.order; SetZeros( n ); for( int i=0;iDesign( spec ); BandPass x; x.Transform( spec, &Poles(), m_proto->Poles() ); x.Transform( spec, &Zeros(), m_proto->Zeros() ); Realize( this ); NormalizePassband( ((spec.centerFreq/spec.sampleRate)<0.25)?kPi:0 ); Notice the differing treatment of the zeros. It would have been REALLY cool if every filter could be constructed by first designing the analog poles and zeroes, and then uniformly applying a transformation (from the set Low Pass, High Pass, Band Pass, Band Stop, Low Shelf, High Shelf, Peaking) but that is just not in the cards. I think I have gotten as close to this as is possible given the problem space. This new method of construction allows for great optimizations for rapid parameter changes. I have everything working using this new model, and it solves a number of problems with the old implementation. I am still doing the busy work of converting all the classes to the new code, I just got done with the Butterworths I still have ChebyI ChebyII and Elliptic left. From vadim.zavalishin at native-instruments.de Mon Jun 8 10:25:57 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Mon Jun 8 10:26:10 2009 Subject: [music-dsp] Name for the integrator replacement technique In-Reply-To: <002b01c9e843$ed1e2b40$0201a8c0@mooncode> References: <002b01c9e843$ed1e2b40$0201a8c0@mooncode> Message-ID: <4D00D095655A4788A5607240CE8B94E1@nibln01077> >> I'd suggest "topology-preserving transform" or TPT. The reason >> is that the transfer function of the resulting system is >> exactly what it would have been if one applied an s- to >> z-plane transform (most commonly BLT) to the analog prototype >> transfer function, but simultaneously also the topology of the >> system is preserved. > > You're assuming that the analog circuit is based on cascaded > integrators in the first place, Not necessarily cascaded (as I understand that term implies serial connection), but simply somehow interconnected. I was assuming that any real-world analog circuit is expressible using integrators, directly corresponding to the state-space equations describing the circuit. At any rate, the analog reactive elements (capacitors and inductors) essentially translate as integrators in block diagrams. > so "topology-preserving" is > underspecific. How about "state variable preserving"? Considering the above, the state variables should be identical to the integrator states. Which other state variables do you have in mind? Also "state-variable preserving" is less specific, as you can have different block diagrams having the same state variables. The time-variant behavior will probably be the same though, but only if there are no nonlinearities and if we ignore the computation precision issues. So IMHO the preservation of the state variables is a side effect, and the relation between those is logical implication, not the equivalence: preserved topology ==> preserved state variables Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From gasmoa at gmail.com Mon Jun 8 10:32:47 2009 From: gasmoa at gmail.com (george bezerianos) Date: Mon Jun 8 10:33:10 2009 Subject: [music-dsp] Name for the integrator replacement technique In-Reply-To: <002501c9e843$09308f40$0201a8c0@mooncode> References: <4c23fbf70906080529s4eddfcbcy6a80c05301224739@mail.gmail.com> <002501c9e843$09308f40$0201a8c0@mooncode> Message-ID: <4c23fbf70906080732r5a791fat2c62a371dab8567c@mail.gmail.com> On Mon, Jun 8, 2009 at 4:11 PM, Martin Eisenberg wrote: > george bezerianos wrote: > >> "Topology-preserving trasform" could actually be an informal >> (and possibly imprecise) name for a homeomorphism, a >> bicontinuous function between two topological spaces that >> actually preserves their topology - an isomorphism of >> topological spaces. > > At issue is exactly that -- isomorphism of graphs up to labeling, > or in other words, unchanged discrete connectivity. > Good point, but it is a _directed_ graph and as such it is homeomorphic to all directed graphs with the same discrete connectivity and to exactly one un-directed graph. However, different directed graphs correspond to dramatically different transfer functions. So I would insist on the Signal Flow to preserve directivity, unless one can suggest something better. Yours, George Bezerianos > > Martin > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From jerry at novadsp.com Mon Jun 8 10:35:48 2009 From: jerry at novadsp.com (Jerry Evans) Date: Mon Jun 8 10:36:47 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes In-Reply-To: <34518.30788.qm@web58201.mail.re3.yahoo.com> References: <34518.30788.qm@web58201.mail.re3.yahoo.com> Message-ID: <4A2D21C4.8010205@NovaDSP.com> > > Notice the differing treatment of the zeros. It would have been REALLY cool if every filter could be constructed by first designing the analog poles and zeroes, and then uniformly applying a transformation (from the set Low Pass, High Pass, Band Pass, Band Stop, Low Shelf, High Shelf, Peaking) but that is just not in the cards. I think I have gotten as close to this as is possible given the problem space. > > This new method of construction allows for great optimizations for rapid parameter changes. I have everything working using this new model, and it solves a number of problems with the old implementation. I am still doing the busy work of converting all the classes to the new code, I just got done with the Butterworths I still have ChebyI ChebyII and Elliptic left. > It still looks *very* nifty. Keep up the great work! Thx++ Jerry. From vadim.zavalishin at native-instruments.de Mon Jun 8 10:37:39 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Mon Jun 8 10:37:53 2009 Subject: [music-dsp] Name for the integrator replacement technique In-Reply-To: <4c23fbf70906080732r5a791fat2c62a371dab8567c@mail.gmail.com> References: <4c23fbf70906080529s4eddfcbcy6a80c05301224739@mail.gmail.com><002501c9e843$09308f40$0201a8c0@mooncode> <4c23fbf70906080732r5a791fat2c62a371dab8567c@mail.gmail.com> Message-ID: <568726FD5F134067AD4A2D4E01C34939@nibln01077> > Good point, but it is a _directed_ graph and as such it is > homeomorphic to all directed graphs with the same discrete > connectivity and to exactly one un-directed graph. However, > different directed graphs correspond to dramatically different > transfer functions. So I would insist on the Signal Flow > to preserve directivity, unless one can suggest something better. My problem with "Signal Flow Preserving Transform" (SFPT?) is that feels a little bit too long, otherwise being quite on the point. However, in the context of LTI systems and signal processing in general, doesn't the term "topology of the system" have an unambiguous meaning anyway (including the directivity)? Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From gasmoa at gmail.com Mon Jun 8 10:51:32 2009 From: gasmoa at gmail.com (george bezerianos) Date: Mon Jun 8 10:51:45 2009 Subject: [music-dsp] Name for the integrator replacement technique In-Reply-To: <568726FD5F134067AD4A2D4E01C34939@nibln01077> References: <4c23fbf70906080529s4eddfcbcy6a80c05301224739@mail.gmail.com> <002501c9e843$09308f40$0201a8c0@mooncode> <4c23fbf70906080732r5a791fat2c62a371dab8567c@mail.gmail.com> <568726FD5F134067AD4A2D4E01C34939@nibln01077> Message-ID: <4c23fbf70906080751xe452395n115b046c9801c771@mail.gmail.com> On Mon, Jun 8, 2009 at 4:37 PM, Vadim Zavalishin wrote: >> Good point, but it is a _directed_ graph and as such it is >> homeomorphic to all directed graphs with the same discrete >> connectivity and to exactly one un-directed graph. However, >> different directed graphs correspond to dramatically different >> transfer functions. So I would insist on the Signal Flow >> to preserve directivity, unless one can suggest something better. > > My problem with "Signal Flow Preserving Transform" (SFPT?) is that feels a > little bit too long, otherwise being quite on the point. However, in the > context of LTI systems and signal processing in general, doesn't the term > "topology of the system" have an unambiguous meaning anyway (including the > directivity)? > Well, I myself come from a signal processing background so I have used the term quite often in the past. However, these days I would avoid confusion with the modern mathematical language - the worst one can get is in the end to have a consistent language for everything mathematical. Now, Signal Flow Diagrams is how I'm used to call these things and it's fairly consistent with signal processing literature (I think that's how Oppenheim/Schafer call them in their DTSP IIRC). Yours, George Bezerianos > Regards, > Vadim > > -- > Vadim Zavalishin > Senior Software Developer | R&D > > Tel +49-30-611035-0 > Fax +49-30-611035-2600 > > NATIVE INSTRUMENTS GmbH > Schlesische Str. 28 > 10997 Berlin, Germany > http://www.native-instruments.com > > Registergericht: Amtsgericht Charlottenburg > Registernummer: HRB 72458 > UST.-ID.-Nr. DE 20 374 7747 > Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription info, > FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From neolit123 at gmail.com Mon Jun 8 11:03:51 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Mon Jun 8 11:04:38 2009 Subject: [music-dsp] Name for the integrator replacement technique References: <4c23fbf70906080529s4eddfcbcy6a80c05301224739@mail.gmail.com><002501c9e843$09308f40$0201a8c0@mooncode><4c23fbf70906080732r5a791fat2c62a371dab8567c@mail.gmail.com> <568726FD5F134067AD4A2D4E01C34939@nibln01077> Message-ID: <00ba01c9e84a$5f7d9760$0201a8c0@LuboPC> Path Preserving Transform (PPT), Vanim ? ^ can be a bit confusing. I guess... But I also like "Topology"...The problem here is that the word "Topology" (mathematics), essentially suggest preservation of properties. So if you insert "Topology-preserving" a sort of "doubling" is created. At least in my opinion. Lubomir ----- Original Message ----- From: "Vadim Zavalishin" > My problem with "Signal Flow Preserving Transform" (SFPT?) is that feels a > little bit too long, otherwise being quite on the point. However, in the > context of LTI systems and signal processing in general, doesn't the term > "topology of the system" have an unambiguous meaning anyway (including the > directivity)? From neolit123 at gmail.com Mon Jun 8 11:23:33 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Mon Jun 8 11:23:57 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes References: <34518.30788.qm@web58201.mail.re3.yahoo.com> Message-ID: <00bf01c9e84d$1c865020$0201a8c0@LuboPC> Nevertheless, I wouldn't (probably never) suggest the "wiring" for high-order filters to the input. As discussed before, some problems emerge by doing so. If you look a few post above you will see that I've proposed a robust solution. But even if you compensate for the artefacts from the "wire", you are not only changing the magnitude of the filter, its phase response, but also its stability is compromised. Consolidating the code is always a good thing! But it would be a bit difficult use the same structuring for every single type of IIR filter out there :] As and example, the same: - input parameters - coefficient calculation - recursion ...for all You may also have to consider the possibility, that future users of your code may want to do assembler (opt-codes) optimization (I believe Martin suggested this earlier) for a specific filter type only. This will require some straight forward porting, but the current C++ optimizations you are doing should not "split" the code a lot, thus making the "port" a bit difficult. But of course these are your decisions to make. Everything is looking good so far from the classes you have posted. Happy coding. :] Lubomir ----- Original Message ----- From: "Vinnie" To: Sent: Monday, June 08, 2009 5:20 PM Subject: [music-dsp] Re: Revisiting C++ Filtering Classes > >> From: "Lubomir I. Ivanov" >> output = lp_out + input * scale; > > The problem is that this cannot be represented in my CascadeFilter, it > requires additional processing after the cascade executes (specifically, > to add the scaled input into the output). I am restricting myself only to > the filters that can be realized using the cascade structure only. > The good news is that I was able to decrypt the text of "Parametric > Higher-Order Shelving Filters" to yield an implementation of a low shelf > with Butterworth response characteristics. Through a stroke of fortune I > was able to transform the analog low shelf into a digital low shelf, high > shelf, and peaking/notch eq (of double the order). > > Now I am prospecting for the Chebyshev type I low shelf, Chebyshev type II > low shelf, and Elliptic low shelf. Similar transformations should yield > the corresponding low hself, high shelf, and peaking/notch eq. > > As was pointed out earlier it is not possible to generalize the > construction of the zeros of low pass, high pass, band pass, and band stop > filters from the corresponding analog prototype (for example, the > Butterworth zeros are out at infinity). I was hoping this was possible > because it would make the construction of template based classes very > elegant. > > I was still able to get a decent class hierarchy working it just wasn't as > streamlined or general as I hoped it would be. For example, the > Butterworth high pass is constructed using: > > m_proto->Design( spec ); > HighPass x; > x.Transform( spec, &Poles(), m_proto->Poles() ); > int n=spec.order; > SetZeros( n ); > for( int i=0;i Zero(i)=Complex( 1, 0 ); > Realize( this ); > NormalizePassband( kPi ); > > But the peaking/notch filter is constructed this way: > > m_proto->Design( spec ); > BandPass x; > x.Transform( spec, &Poles(), m_proto->Poles() ); > x.Transform( spec, &Zeros(), m_proto->Zeros() ); > Realize( this ); > NormalizePassband( > ((spec.centerFreq/spec.sampleRate)<0.25)?kPi:0 ); > > Notice the differing treatment of the zeros. It would have been REALLY > cool if every filter could be constructed by first designing the analog > poles and zeroes, and then uniformly applying a transformation (from the > set Low Pass, High Pass, Band Pass, Band Stop, Low Shelf, High Shelf, > Peaking) but that is just not in the cards. I think I have gotten as close > to this as is possible given the problem space. > > This new method of construction allows for great optimizations for rapid > parameter changes. I have everything working using this new model, and it > solves a number of problems with the old implementation. I am still doing > the busy work of converting all the classes to the new code, I just got > done with the Butterworths I still have ChebyI ChebyII and Elliptic left. > > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From gasmoa at gmail.com Mon Jun 8 11:29:56 2009 From: gasmoa at gmail.com (george bezerianos) Date: Mon Jun 8 11:30:06 2009 Subject: [music-dsp] Name for the integrator replacement technique In-Reply-To: <00ba01c9e84a$5f7d9760$0201a8c0@LuboPC> References: <4c23fbf70906080529s4eddfcbcy6a80c05301224739@mail.gmail.com> <002501c9e843$09308f40$0201a8c0@mooncode> <4c23fbf70906080732r5a791fat2c62a371dab8567c@mail.gmail.com> <568726FD5F134067AD4A2D4E01C34939@nibln01077> <00ba01c9e84a$5f7d9760$0201a8c0@LuboPC> Message-ID: <4c23fbf70906080829i2f4fac5eq2a5f158d591855b0@mail.gmail.com> On Mon, Jun 8, 2009 at 5:03 PM, Lubomir I. Ivanov wrote: > Path Preserving Transform (PPT), Vanim ? > ^ can be a bit confusing. I guess... > > But I also like "Topology"...The problem here is that the word "Topology" > (mathematics), essentially suggest preservation of properties. > So if you insert "Topology-preserving" a sort of "doubling" is created. > At least in my opinion. > Topology is the natural setting for studying continuity (even though its definition looks rather counter-intuitive, but it makes much more sense if one sees its emergence from metric spaces). "Preserving properties" is something assigned to functions and transforms and not topological spaces themselves, or any algebraic structure or mathematical constructions of this kind. What we're talking about here, if we decide to be mathematically rigorous, is rather a Directed Graph Isomorphism. Yours, George Bezerianos > > > Lubomir > > > ----- Original Message ----- From: "Vadim Zavalishin" > > >> My problem with "Signal Flow Preserving Transform" (SFPT?) is that feels a >> little bit too long, otherwise being quite on the point. However, in the >> context of LTI systems and signal processing in general, doesn't the term >> "topology of the system" have an unambiguous meaning anyway (including the >> directivity)? > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription info, > FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From neolit123 at gmail.com Mon Jun 8 11:29:50 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Mon Jun 8 11:30:21 2009 Subject: [music-dsp] Name for the integrator replacement technique References: <4c23fbf70906080529s4eddfcbcy6a80c05301224739@mail.gmail.com><002501c9e843$09308f40$0201a8c0@mooncode><4c23fbf70906080732r5a791fat2c62a371dab8567c@mail.gmail.com> <568726FD5F134067AD4A2D4E01C34939@nibln01077> Message-ID: <00da01c9e84d$f9824600$0201a8c0@LuboPC> Pff...sorry for the mistype. Lubomir From vadim.zavalishin at native-instruments.de Mon Jun 8 11:45:17 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Mon Jun 8 11:45:33 2009 Subject: [music-dsp] Name for the integrator replacement technique In-Reply-To: <00da01c9e84d$f9824600$0201a8c0@LuboPC> References: <4c23fbf70906080529s4eddfcbcy6a80c05301224739@mail.gmail.com><002501c9e843$09308f40$0201a8c0@mooncode><4c23fbf70906080732r5a791fat2c62a371dab8567c@mail.gmail.com><568726FD5F134067AD4A2D4E01C34939@nibln01077> <00da01c9e84d$f9824600$0201a8c0@LuboPC> Message-ID: > Pff...sorry for the mistype. You mean my name? Nevermind, happens a lot while typing :-) Back to the original topic. So far, TPT is still my personal favorite, as it seems to be the best-sounding, and aside from the mentioned minor formal issues, it doesn't seem to cause any confusion. Others: SVPT - underspecified (although might be a good name for a property of a transformation technique to preserve the state variables) SFPT - sounds slighly bulky PPT - sounds confusing Also in regards to SFPT vs TPT, while there is the term "Signal Flow Diagram", what is being displayed in that diagram is the system's topology, isn't it? :-) Therefore the signal flow diagram is only a form of displaying something (the topology), which is what we are trying to preserve. While I'm no topology expert, I think it is also correct to say "preserve the topology" in the math sense. E.g. the transformation x'=1/x doesn't preserve the topology of the x axis, right? Thus, no "doubling" is created. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From thevinn at yahoo.com Mon Jun 8 12:54:07 2009 From: thevinn at yahoo.com (Vinnie) Date: Mon Jun 8 12:54:23 2009 Subject: [music-dsp] A Collection of C++ Classes for DSP Message-ID: <137575.2516.qm@web58201.mail.re3.yahoo.com> I have released version 0.8.4 of this library. It is located here: http://sourceforge.net/projects/dspfilterscpp/ The changes: - Rewrote entire class hierarchy - Templatized classes have been pushed farther down the derivation hierarchy - Code for non templatized classes has been moved into a .cpp file. - Low-pass analog prototypes for Butterworth, Chebyshev, Inverse Chebyshev, and Elliptic responses are each represented by their own class. - A Butterworth low-shelf analog prototype is also provided. (Can anyone point me to the Chebyshevs and Elliptic shelves?) - Low pass to low pass, Low pass to high pass, low pass to band pass, and low pass to band stop transformations are each encapsulated and represented by their own class. - A Layout of poles and zeros is represented by its own class. This allows the computation of the analog prototype to be saved and re-used for speed. - The set of all possible filter parameters is encapsulated in a single structure and passed to all classes. This allows specifications to be cached and re-used, or compared against for changes. - Filter order can now be specified at run-time. Storage classes allow specification of a 'maxorder' (i.e. provide sufficient state storage for order from 1 up to maxorder). - As in the original design, there is no dynamic memory allocation (i.e. calls to new/delete). - Each concept of IIR filtering is mapped cleanly to one corresponding class in the library. - Top down programming design allows the entire process of designing and realizing a digital filter to take place in the body of a single function (this allows for any type of optimization at any level). - Functional programming style, no side effects from function calls and elimination of most state variables. - A small lightweight class is provided for determining if processor specific optimizations are available (MSVC only) - Processing template definitions moved to the .cpp file, and the explicit template instantiation model is used, with float and double available (you can add more at the bottom of the source file if needed). - Some bug fixes to utility functions, and a few trivial utility functions added. The Elliptic prototype implementation is fairly rough there are hard coded limits on the order, and it consumes a lot of memory (something like 12 kilobytes) even if the order is low. I plan on fixing this. There are also plenty of optimizations that can be performed, like moving constant expressions out of loops, re-using the poles of the analog prototypes, partial recomputation when only a subset of filter parameters change, etc... I will get to that shortly. For now, everything in there should work. These filters have been tested: BiquadLowPass BiquadHighPass BiquadBandPass1 BiquadBandPass2 BiquadBandStop BiquadAllPass BiquadLowShelf BiquadHighShelf BiquadPeak ButterLowPass ButterHighPass ButterBandPass ButterBandStop ButterLowShelf ButterHighShelf ButterPeak ChebyILowPass ChebyIHighPass ChebyIBandPass ChebyIBandStop ChebyIILowPass ChebyIIHighPass ChebyIIBandPass ChebyIIBandStop EllipticLowPass EllipticHighPass EllipticBandPass EllipticBandStop None of this would have been possible without the insights and help from the members here as well as the contributions upon which portions of the library were built. Thanks! From rbj at audioimagination.com Mon Jun 8 13:27:31 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Mon Jun 8 13:27:44 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <4c23fbf70906080548h447263acp403a8f337c05d3f5@mail.gmail.com> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077> <4c23fbf70906080548h447263acp403a8f337c05d3f5@mail.gmail.com> Message-ID: <6E309835-DBE2-42B4-8C04-EC0BF8318CFB@audioimagination.com> On Jun 8, 2009, at 8:48 AM, george bezerianos wrote: > > http://s1gnals.blogspot.com/2008/12/bloo_6897.html > ... On Wed, May 6, 2009 at 2:12 PM, Vadim Zavalishin wrote: >> >> http://www.native-instruments.de/index.php?id=dsparticles >> >> Comments welcome. >> hi Vadim and George. i took a look at both the bloo.pfd and the SineSyncRC.pdf (i could not extract what i was looking for in the SineSync.pdf). now in bloo, George is creating a blit, as best as i can tell, and i am not sure if you're getting a sinusoid out of it, but if you are, is your BLIT going through some resonant filter or something? i don't see where the sin(wt) is coming out of it. in SineSyncRC, Vadim is using a quite long polynomial of |x| to approximate a sine function over a period (and i presume he's driving that with a sawtooth function coming out of a phase-accumulator that defines the phase of the waveform). are my understandings reasonably correct? about Vadim's method, that's fine and good, but i think you're throwing *much* more polynomial at it to get an acceptable synthesized sine wave. the sine function is fully analytic (not the Hilbert transform meaning of "analytic"). it is continuous and has continuous derivatives, no matter how deep you go. that lends itself to very good polynomial approximation, *particularly* for the 1/2 cycle before the sin() bends around back (and +/- pi/2). i would suggest aiming to approximate sin( pi/2 * x ) for -1 <= x <= +1 sin(x) is a completely odd-symmetry, so any decent polynomial approximation would be odd-symmetry (and odd-order). if you factor out the x, and express as sin( pi/2 * x ) = x * p(x^2) you are left with a simple polynomial that is made into an even- symmetry polynomial when x^2 is the argument. p(x^2) = sin(pi/2*x)/(pi/2*x) * pi/2 = pi/2 * sinc(x/2) -1 <= x <= +1 or p(x) = pi/2 * sinc( sqrt(x)/2 ) for 0 <= x <= +1 unlike George, i (and nearly all my EE textbooks) define the sinc(x) function to have the pi in it: sinc(x) = sin(pi*x)/(pi*x) that is the polynomial that you want coefficients for (after determining the order necessary). you might be surprized to see how good of a fit you get for merely a 2nd or 3rd-order approximation to the sinc(sqrt(x)/2) function. don't use Taylor series, but try to be more optimal in getting the coefficients. least-squares would be good, in this case, but the Remes Exchange algorithm would work also. oh, the other thing is that you need to turn your sawtooth phase function into a triangle since the sin(x) function is being fit for only 1/2 period. if your saw goes from -1 to +1, then tri(x) = 2*|saw(x)| - 1 that absolute value operation is the only one you'll need. everything else is just plug-and-chug into the polynomial. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From martin.eisenberg at udo.edu Mon Jun 8 13:34:58 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Mon Jun 8 13:32:21 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes References: <34518.30788.qm@web58201.mail.re3.yahoo.com> Message-ID: <003301c9e85f$761080e0$0201a8c0@mooncode> Vinnie wrote: > As was pointed out earlier it is not possible to generalize > the construction of the zeros of low pass, high pass, band > pass, and band stop filters from the corresponding analog > prototype (for example, the Butterworth zeros are out at > infinity). Unless I'm overlooking something, it is perfectly possible. It's just that since the computer can't do calculus, you have to spell out the treatment of zeros at infinity. That is, enumerate as many infinities in Design() as the s-degrees of numerator and denominator differ by, and map infinity to +1 and/or -1 in Transform(). That will make the snippets you quoted look the same. Martin From martin.eisenberg at udo.edu Mon Jun 8 14:09:06 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Mon Jun 8 14:06:29 2009 Subject: [music-dsp] Name for the integrator replacement technique References: <002b01c9e843$ed1e2b40$0201a8c0@mooncode> <4D00D095655A4788A5607240CE8B94E1@nibln01077> Message-ID: <003b01c9e864$3a150700$0201a8c0@mooncode> Vadim Zavalishin wrote: > I was assuming that any real-world analog circuit is > expressible using integrators, directly corresponding to the > state-space equations describing the circuit. At any rate, the > analog reactive elements (capacitors and inductors) > essentially translate as integrators in block diagrams. You mean going from one Kirchhoff quantity to the other? And in conjunction with an attached resistor, each reactive element can be presented as an integrator in the more abstract block diagram for any circuit? If that's so, I misapprehended what "state variable" means in EE parlance and will say that TPT sounds nice. Martin From martin.eisenberg at udo.edu Mon Jun 8 14:11:33 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Mon Jun 8 14:08:52 2009 Subject: [music-dsp] Re: Revisiting C++ Filtering Classes References: <34518.30788.qm@web58201.mail.re3.yahoo.com> <00bf01c9e84d$1c865020$0201a8c0@LuboPC> Message-ID: <004301c9e864$913ae720$0201a8c0@mooncode> Lubomir I. Ivanov wrote: > You may also have to consider the possibility, that future > users of your code may want to do assembler (opt-codes) > optimization (I believe Martin suggested this earlier) for a > specific filter type only. To clarify, I was referring to users leveraging Vinnie's own assembler optimizations with ease. Martin From martin.eisenberg at udo.edu Mon Jun 8 18:01:38 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Mon Jun 8 17:59:10 2009 Subject: [music-dsp] Name of delay-free loop technique References: <002401c9d7d1$0aee5ce0$0201a8c0@mooncode><56BDCC96E6B94AF5BC7DF68F893A63C1@nibln01077><001201c9d8a6$2f916bc0$0201a8c0@mooncode><001201c9dca5$332d6f60$0201a8c0@mooncode><86DBA60A6D954C829C23571C46248EFE@nibln01077><029244E7BAD549C78B29E3DAB113FC06@nibln01077><000a01c9e21b$441cc3e0$0201a8c0@mooncode><003b01c9e383$904dab80$0201a8c0@mooncode> Message-ID: <000d01c9e884$b65c5000$0201a8c0@mooncode> Vadim Zavalishin wrote: > Except that you have introduced a different time scale, where > t_end=infinity occurs before y[n] (or at the same time). I thought of this as happening outside true time. A matter of taste, I guess. >> Do you know any analog devices, besides perhaps >> oscillators, that routinely operate that way? Have you >> generally found it sufficient to solve the system as if linear >> and then saturate the result? > > Of course generally it's not sufficient. I have a feeling you've answered a different question than I intended -- have you mostly been satisfied with the cheap results? > Instantaneously unstable cases > will correspond to the horizontally-reverted graph of > g*tanh(x-ky), where the graph's steepness (derivative) must > exceed 1, in which case the system "wants" to go into the > opposite direction of the intersection of the h(y)=y-s and the > nonlinearity's tangent line (I think). I can't quite picture it. Tangent line where -- at the steepest point? And by "in the opposite direction of", do you mean "away from" the intersection? I'd guess you do because that interpretation does make the selection unique; namely, the solution jumps from one outside branch of the multivalued inverse function to the other as soon as the input enters the latter's support. Is that what you're saying? Martin From czhenry at gmail.com Mon Jun 8 18:08:54 2009 From: czhenry at gmail.com (Charles Henry) Date: Mon Jun 8 18:09:07 2009 Subject: [music-dsp] Name for the integrator replacement technique In-Reply-To: References: Message-ID: <518fe7b20906081508u54da7475wddd44a47feefb6d5@mail.gmail.com> On Mon, Jun 8, 2009 at 4:39 AM, Vadim Zavalishin wrote: > I'd suggest "topology-preserving transform" or TPT. "structure preserving transform" or "filter structure preserving transform" "graph preserving transform"? You might confuse people with "topology", but that's not your fault :) It has the correct meaning in this context. Chuck From richarddobson at blueyonder.co.uk Mon Jun 8 19:15:16 2009 From: richarddobson at blueyonder.co.uk (Richard Dobson) Date: Mon Jun 8 19:16:57 2009 Subject: [music-dsp] Name for the integrator replacement technique In-Reply-To: <518fe7b20906081508u54da7475wddd44a47feefb6d5@mail.gmail.com> References: <518fe7b20906081508u54da7475wddd44a47feefb6d5@mail.gmail.com> Message-ID: <4A2D9B84.2000309@blueyonder.co.uk> Charles Henry wrote: > On Mon, Jun 8, 2009 at 4:39 AM, Vadim > Zavalishin wrote: > >> I'd suggest "topology-preserving transform" or TPT. > > "structure preserving transform" or "filter structure preserving transform" > > "graph preserving transform"? > Or, since the I word is already in common use - Graph Invariant Transform? Richard Dobson (who understands perhaps 1% of this thread...) From thevinn at yahoo.com Mon Jun 8 19:28:34 2009 From: thevinn at yahoo.com (Vinnie) Date: Mon Jun 8 19:28:44 2009 Subject: [music-dsp] Ripple specification for Chebyshev Type I Low Shelf? Message-ID: <794796.53796.qm@web58202.mail.re3.yahoo.com> I found the analog prototypes that I was looking for (Chebyshev and Elliptic shelves) here http://www.ece.rutgers.edu/~orfanidi/ece521/hpeq.pdf Anyway...Orfanidis designs his filter based on G and Gb, gain and gain at the transition band respectively. In my opinion this is inconvenient. I prefer to have the standard passband ripple specification (which is directly related to transition band gain). After some hacking I came up with: void ChebyIShelf::Design( const Spec &spec ) { int n=spec.order; CalcT gainDb=-spec.gainDb; CalcT rippleDb=spec.passRippleDb; if( rippleDb>=abs(gainDb) ) rippleDb=abs(gainDb); if( gainDb<0 ) rippleDb=-rippleDb; CalcT G=std::pow( 10., gainDb/20.0 ); CalcT Gb=std::pow( 10., (gainDb-rippleDb)/20.0 ); CalcT G0=1; CalcT g0=pow(G0,1./n); CalcT eps; if( Gb!=G0 ) eps=sqrt((G*G-Gb*Gb)/(Gb*Gb-G0*G0)); else eps=G-1; // This is surely wrong CalcT b=pow(G/eps+Gb*sqrt(1+1/(eps*eps)), 1./n); CalcT u=log(b/g0); CalcT v=log(pow(1./eps+sqrt(1+1/(eps*eps)),1./n)); SetPoles( n ); SetZeros( n ); for( int i=0;i<4c23fbf70906080529s4eddfcbcy6a80c05301224739@mail.gmail.com><002501c9e843$09308f40$0201a8c0@mooncode><4c23fbf70906080732r5a791fat2c62a371dab8567c@mail.gmail.com><568726FD5F134067AD4A2D4E01C34939@nibln01077><00da01c9e84d$f9824600$0201a8c0@LuboPC> Message-ID: <003c01c9e892$6495d4e0$0201a8c0@LuboPC> I admit my confusion... :P But its confusing, because topology is an area of study (in mathematics) - cannot be preserved, same goes for astronomy ? But in our case, we look at it, as a property of a electronic circuit and indeed it can be preserved. I think the confusion apears when the noun "transform" is added. Should be "network/circuit topology preserving transform" ...etc to be more clear. Still its accurate to say just TPT, I guess. Another one: "Prototype network transform" (PNT )- from the integrator replacements. Lubomir ----- Original Message ----- From: "Vadim Zavalishin" > I think it is also correct to say "preserve the topology" in the math > sense. E.g. the transformation x'=1/x doesn't preserve the topology of the > x axis, right? Thus, no "doubling" is created. > > Regards, > Vadim > + ----- Original Message ----- From: "Charles Henry" > You might confuse people with "topology", but that's not your fault :) > It has the correct meaning in this context. > > Chuck From peter at loihde.fi Mon Jun 8 22:11:48 2009 From: peter at loihde.fi (=?ISO-8859-1?Q?Peter_Hillerstr=F6m?=) Date: Mon Jun 8 22:12:13 2009 Subject: [music-dsp] Re: music-dsp Digest, Vol 66, Issue 17 In-Reply-To: <20090608140020.9AFFE974C01@music.columbia.edu> References: <20090608140020.9AFFE974C01@music.columbia.edu> Message-ID: "Martin Eisenberg" wrote: > Date: Mon, 8 Jun 2009 16:01:25 +0200 > From: "Martin Eisenberg" > Subject: Re: [music-dsp] Article: antialiased sine waveform syncing > To: "A discussion list for music-related DSP" > > Message-ID: <000d01c9e841$a11b29c0$0201a8c0@mooncode> > Content-Type: text/plain; charset="iso-8859-1" > > george bezerianos wrote: >> In a similar manner we can bandlimit a generic >> hard-sync case by bandlimiting higher order derivatives of a >> Cn discontinuity through integration but also by convolving a >> BLIT tuned tot he master frequency with sufficiently long >> iterations of the original waveform!!. I'm pretty sure that >> one can even find a formula connecting the sufficient length >> of the slave waveform to the order of the discontinuity and >> that's to my eyes a clear analogy to the Taylor case!! > > It has been noted in the field of interpolation that the > sign-flipped monomials sgn(x)*x^n, in a sense the prototypical > C^n discontinuities, are related to B-splines by differencing. > It's something of another direction but perhaps you get something > out of the lead. See e.g. reference > http://dx.doi.org/10.1109/TIP.2003.818018 available at > http://www.ee.cuhk.edu.hk/~tblu/monsite/pdfs/blu0302.pdf > > > Martin When I read the original posting, I immediately got an idea how I would do this. I would have made a more mathematical description, but I'm not a mathematician, and I'm short on time now. And I'm still learning DSP techniques, so I apologise if my terminology feels weird... Imagine the sine wave signals traveling along unit circle (and more complex signals inside an unit circle on the complex plane). At time instant t=0 the two signals are on different points on the circle arc depending on their phase, say Z1 and Z2. Now what is the shortest distance between them? A straight line (chord) between them, of course. So, to make a smooth transition between the signals, I will treat the signal samples as vectors having polar coordinates, decide some time window for the transition length, and make a gradient between them with a similar method that is made when B-splines are calculated. In other words, the resulting signal X3 for signals X1 and X2 is just a element wise addition of vector matrices containing complex (vector) samples: time Tn = 0..w (w is for one full period of samples, gradient could be longer also) X1 = Tn*e^j(wt+theta) X2 = (1-Tn)e^j(wt+rho) X3 = X1 + X2 <-- simple vector addition Note! This can be much improved by using a sigmoid function for the amplitude gradient, instead of plain linear gradient (that is used with B-splines). This should produce a kind of spiral on the complex plane. If you doubt this will work, look at it geometrically and gradually decrease first signals amplitude as you increase the second signals amplitude just as much, and add them as vectors. If someone tries this, I would be very interested to know what the resulting spetra is when using a sigmoid function. And of course, I want credit for the idea. :-) -- Peter Hillerstr?m ? http://peter.vasb.fi/ ? http://www.loihde.fi/ From gasmoa at gmail.com Mon Jun 8 22:18:02 2009 From: gasmoa at gmail.com (george bezerianos) Date: Mon Jun 8 22:18:15 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <6E309835-DBE2-42B4-8C04-EC0BF8318CFB@audioimagination.com> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077> <4c23fbf70906080548h447263acp403a8f337c05d3f5@mail.gmail.com> <6E309835-DBE2-42B4-8C04-EC0BF8318CFB@audioimagination.com> Message-ID: <4c23fbf70906081918rf6cd30dqa103c0bdf613fc0f@mail.gmail.com> On Mon, Jun 8, 2009 at 7:27 PM, robert bristow-johnson wrote: > > On Jun 8, 2009, at 8:48 AM, george bezerianos wrote: > >> >> http://s1gnals.blogspot.com/2008/12/bloo_6897.html >> > ... > > On Wed, May 6, 2009 at 2:12 PM, Vadim Zavalishin wrote: > >>> >>> http://www.native-instruments.de/index.php?id=dsparticles >>> >>> Comments welcome. >>> > > hi Vadim and George. > > i took a look at both the bloo.pfd and the SineSyncRC.pdf (i could not > extract what i was looking for in the SineSync.pdf). > > now in bloo, George is creating a blit, as best as i can tell, and i am not > sure if you're getting a sinusoid out of it, but if you are, is your BLIT > going through some resonant filter or something? ?i don't see where the > sin(wt) is coming out of it. > Well, if you convolve a BLIT with a sufficiently long sine wave you will be approximating a sine fine - and while you can find a multitude of ways to do that better the actual BLOO method is supposed to generalize for _arbitrary_ waveforms. The sine function is used as an example because of its Cinf discontinuity. As I said in a previous post while the article resets the slave oscillator near the sync point, one can get rid of the harmonics by increasing the overlapping and thus hard-sync _any_ waveform as the actual convolution kernel can be anything. So, the two articles are rather different in terms of genericity. The actual interesting bit as i said in a previous post would be to actually connect the higher order BLEP method (generalized for _arbitrary_ waveforms) with the convolution BLOO suggests. That would actually add some additional theoretical justification and insight, but numerically the method works fine both in terms of complexity and numerical error. > in SineSyncRC, Vadim is using a quite long polynomial of |x| to approximate > a sine function over a period (and i presume he's driving that with a > sawtooth function coming out of a phase-accumulator that defines the phase > of the waveform). > > are my understandings reasonably correct? > > about Vadim's method, that's fine and good, but i think you're throwing > *much* more polynomial at it to get an acceptable synthesized sine wave. > ?the sine function is fully analytic (not the Hilbert transform meaning of > "analytic"). ?it is continuous and has continuous derivatives, no matter how > deep you go. ?that lends itself to very good polynomial approximation, > *particularly* for the 1/2 cycle before the sin() bends around back (and +/- > pi/2). > > i would suggest aiming to approximate > > ? ?sin( pi/2 * x ) ? ?for ? ?-1 <= x <= +1 > > sin(x) is a completely odd-symmetry, so any decent polynomial approximation > would be odd-symmetry (and odd-order). ?if you factor out the x, and express > as > > ? ?sin( pi/2 * x ) = ?x * p(x^2) > > you are left with a simple polynomial that is made into an even-symmetry > polynomial when x^2 is the argument. > > > ? ?p(x^2) = sin(pi/2*x)/(pi/2*x) * pi/2 = pi/2 * sinc(x/2) ? ? -1 <= x <= +1 > > or > > ? ?p(x) = pi/2 * sinc( sqrt(x)/2 ) ? ? ?for ?0 <= x <= +1 > > > unlike George, i (and nearly all my EE textbooks) define the sinc(x) > function to have the pi in it: > > ? ?sinc(x) = sin(pi*x)/(pi*x) Correct, however I use pi explicitly when i utilize "my" sinc definition as you can see in equation (1). Sorry for the confusion. > > that is the polynomial that you want coefficients for (after determining the > order necessary). ?you might be surprized to see how good of a fit you get > for merely a 2nd or 3rd-order approximation to the sinc(sqrt(x)/2) function. > ?don't use Taylor series, but try to be more optimal in getting the > coefficients. ?least-squares would be good, in this case, but the Remes > Exchange algorithm would work also. > > oh, the other thing is that you need to turn your sawtooth phase function > into a triangle since the sin(x) function is being fit for only 1/2 period. > ?if your saw goes from -1 to +1, then > > ? ?tri(x) = 2*|saw(x)| - 1 > > that absolute value operation is the only one you'll need. ?everything else > is just plug-and-chug into the polynomial. > > > -- > > 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 > linkshttp://music.columbia.edu/cmc/music-dsphttp://music.columbia.edu/mailman/listinfo/music-dsp > From gasmoa at gmail.com Mon Jun 8 22:40:32 2009 From: gasmoa at gmail.com (george bezerianos) Date: Mon Jun 8 22:40:42 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <59F0D1E3E5534153B03D414EF177B32F@nibln01077> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077> <4c23fbf70906080548h447263acp403a8f337c05d3f5@mail.gmail.com> <39846A9B4047463EBC4741838DB002EB@nibln01077> <4c23fbf70906080659u48af2fdexd04596bc03b137b2@mail.gmail.com> <59F0D1E3E5534153B03D414EF177B32F@nibln01077> Message-ID: <4c23fbf70906081940m71f424d3oe24efdb102370a09@mail.gmail.com> On Mon, Jun 8, 2009 at 4:14 PM, Vadim Zavalishin wrote: >> It is actually that this method has been discussed >> in some musicdsp-oriented channels and forums for a rather while, so I >> just assumed >> that not being any new knowledge, though it's the first formal attempt to >> the >> description of the problem I've seen and you should be definitely be >> credited for that. > > If you have any links to the relevant discussions I'd appreciate them. I > must admit, I might have missed a lot, and I don't really claim my work as > pioneering :-) Still, as you seem to be familiar with the subject, do you > happen to know, are all the three methods described in my article already > known, or are you referring only to the BLEP generalization in this respect? > I'm talking _only_ about the BLEP generalization - the rest I don't remember having seen anywhere. http://www.kvraudio.com/forum/viewtopic.php?t=235913&highlight=bloo The post by user mystran here hints the generlization and also that the method has been on the street for a while. I remember numerous IRC discussions on the subjectas well, but anyway not a biggy - it is a rather suboptimal method when comes to arbitrary waveforms (or any high order Cn discontinuity) with bad numerical performance. >>> I've read that article. My main problem with it is that it doesn't >>> provide >>> any practical analysis on how "wrong" the resulting spectra are going to >>> be. >>> I was too lazy to do the respective analysis myself. >>> >> >> Agreed. That's mainly what this post is about. Later I hint on what i >> think is the way to actually >> theoretically determine these limits in terms of connecting it to the >> actual discontinuity! > > Well, even some practical demonstrations for some specific cases would > probably help a lot here. > I provided some matlab code with the article, ploting results is an one-liner. You can easily check the generalization to arbitrary waveforms as well. As i said at some point full implementation for c++/simd is planned but time's short. >> Well, I believe I covered that above. Otoh the sentence you cut in the >> middle here is actually the one that hints the actual connection >> and possible equivalence of the two methods. > > There's definitely a connection between the BLEP and BLIT, one being > analytic integration, the other being numerical integration, otherwise they > are very close. I fail to see the specific connection in the context of > BLOO, as I fail to get a good intuitive picture of what's happening there. > Ok I'll try to rephrase it as clear as i can. We have a BLIT tuned at the master oscillator frequency. We now _convolve_ that BLIT with the actual slave oscillator output. That's it. The longest the actual slave oscillator will ring (i.e. the longer the convolution kernel) the less harmonic artifacts one will have. Inharmonic aliasing however is handled completely by the quality of the BLIT as the properties of convolution say to us. That's the article. And it doesn't correspond to sines only but pretty much any waveform. Now when I'm talking about connecting this to the first method you describe in your article but _generalized to arbitrary waveforms_ I mean that there is definitely a connection that has to do with taylor's theorem as I described above. So _sine wave was just a proof of concept_! Yours, George Bezerianos > Regards, > Vadim > > -- > Vadim Zavalishin > Senior Software Developer | R&D > > Tel +49-30-611035-0 > Fax +49-30-611035-2600 > > NATIVE INSTRUMENTS GmbH > Schlesische Str. 28 > 10997 Berlin, Germany > http://www.native-instruments.com > > Registergericht: Amtsgericht Charlottenburg > Registernummer: HRB 72458 > UST.-ID.-Nr. DE 20 374 7747 > Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription info, > FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From rbj at audioimagination.com Mon Jun 8 23:17:49 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Mon Jun 8 23:18:01 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <4c23fbf70906081918rf6cd30dqa103c0bdf613fc0f@mail.gmail.com> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077> <4c23fbf70906080548h447263acp403a8f337c05d3f5@mail.gmail.com> <6E309835-DBE2-42B4-8C04-EC0BF8318CFB@audioimagination.com> <4c23fbf70906081918rf6cd30dqa103c0bdf613fc0f@mail.gmail.com> Message-ID: <4521E341-129C-4154-A07A-E07C4B6D3841@audioimagination.com> On Jun 8, 2009, at 10:18 PM, george bezerianos wrote: > On Mon, Jun 8, 2009 at 7:27 PM, robert > bristow-johnson wrote: >> >> now in bloo, George is creating a blit, as best as i can tell, and >> i am not >> sure if you're getting a sinusoid out of it, but if you are, is >> your BLIT >> going through some resonant filter or something? i don't see >> where the >> sin(wt) is coming out of it. >> > > Well, if you convolve a BLIT with a sufficiently long sine wave you > will be approximating a sine fine yup. convolving the BLIT with a sufficiently long sine is, i think, equivalent to passing the BLIT through a sufficiently resonant filter tuned to the same frequency. > - and while you can find a multitude of ways to do that > better the actual BLOO > method is supposed to generalize for _arbitrary_ waveforms. yes, i gathered that too. and since the BLIT is BL, any LTI operation you do to it will result in an output that is likewize BL. > The sine function is used > as an example because of its Cinf discontinuity. As I said in a > previous post while the article > resets the slave oscillator near the sync point, one can get rid of > the harmonics by increasing > the overlapping and thus hard-sync _any_ waveform as the actual > convolution kernel > can be anything. So, the two articles are rather different in terms of > genericity. > > The actual interesting bit as i said in a previous post would be to > actually connect the > higher order BLEP method (generalized for _arbitrary_ waveforms) with > the convolution > BLOO suggests. That would actually add some additional theoretical > justification > and insight, but numerically the method works fine both in terms of > complexity and numerical error. it seems high in complexity. even just generating the BLIT cleanly would take 16 to 32 MACs per sample, i would think. the convolution with the filter with the arbitrary waveform as the IR would cost a bit more. i've known about BLITs and understood how they can be used to drive an appropriate filter to generate virtually arbitrary *and* bandlimited waveforms, but i have always failed to see the advantage over wavetable synthesis in terms of complexity or cost. i know that wavetable synthesis has issues as well. you can't have just a single wavetable for some particular bandlimited waveform because if it has any overtones at all, as you increase the pitch of the note, those overtones will eventually alias. so you need, for a single harmonically rich waveform (let's say a sawtooth, just to have an easy illustration) several wavetables, some with harmonics missing, that are phase locked at the fundamental. you only need to be mixing two of these at a time, but as the note glissandos upward, you crossfade from a wavetable more rich in harmonics to one less rich. but the harmonics that remain are identical in amplitude and phase to the ones in the previous wavetable that has more harmonics. if the wavetable is big enough (like 1024 points), there will almost never be the need to do any more than linear interpolation between the points. for one wavetable, that's 2 table lookups, a subtraction, multiplication, and addition to linearly interpolate. then you have to do it all again with the other wavetable that you're crossfading to. that's much less computation than running a BLIT through a filter which is why i sometimes question the point of it. it's not the first time i have. >> >> i would suggest aiming to approximate >> >> sin( pi/2 * x ) for -1 <= x <= +1 >> ... >> sin( pi/2 * x ) = x * p(x^2) >> ... >> p(x^2) = sin(pi/2*x)/(pi/2*x) * pi/2 = pi/2 * sinc(x/2) -1 >> <= x <= +1 >> >> or >> >> p(x) = pi/2 * sinc( sqrt(x)/2 ) for 0 <= x <= +1 >> >> >> unlike George, i (and nearly all my EE textbooks) define the sinc(x) >> function to have the pi in it: >> >> sinc(x) = sin(pi*x)/(pi*x) > > Correct, however I use pi explicitly when i utilize "my" sinc > definition as you > can see in equation (1). Sorry for the confusion. > i'm probably the one causing confusion since i was the one who's inserting a variation in definition here. it's just that long ago i became convinced that the "EE definition" of the sinc: sinc(x) = sin(pi*x)/(pi*x) was superior to the traditional definition ( sin(x)/x ) for nearly every purpose. so i've become a little bit of a usage and style nazi about it. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From gasmoa at gmail.com Tue Jun 9 00:26:35 2009 From: gasmoa at gmail.com (george bezerianos) Date: Tue Jun 9 00:26:49 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <4521E341-129C-4154-A07A-E07C4B6D3841@audioimagination.com> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077> <4c23fbf70906080548h447263acp403a8f337c05d3f5@mail.gmail.com> <6E309835-DBE2-42B4-8C04-EC0BF8318CFB@audioimagination.com> <4c23fbf70906081918rf6cd30dqa103c0bdf613fc0f@mail.gmail.com> <4521E341-129C-4154-A07A-E07C4B6D3841@audioimagination.com> Message-ID: <4c23fbf70906082126v5a2f876by3f3a2512204ed2f@mail.gmail.com> On Tue, Jun 9, 2009 at 5:17 AM, robert bristow-johnson wrote: > > On Jun 8, 2009, at 10:18 PM, george bezerianos wrote: > >> On Mon, Jun 8, 2009 at 7:27 PM, robert >> bristow-johnson wrote: >>> >>> now in bloo, George is creating a blit, as best as i can tell, and i am >>> not >>> sure if you're getting a sinusoid out of it, but if you are, is your BLIT >>> going through some resonant filter or something? ?i don't see where the >>> sin(wt) is coming out of it. >>> >> >> Well, if you convolve a BLIT with a sufficiently long sine wave you >> will be approximating a sine fine > > yup. ?convolving the BLIT with a sufficiently long sine is, i think, > equivalent to passing the BLIT through a sufficiently resonant filter tuned > to the same frequency. > > >> - and while you can find a multitude of ways to do that >> better the actual BLOO >> method is supposed to generalize for _arbitrary_ waveforms. > > yes, i gathered that too. ?and since the BLIT is BL, any LTI operation you > do to it will result in an output that is likewize BL. > >> The sine function is used >> as an example because of its Cinf discontinuity. As I said in a >> previous post while the article >> resets the slave oscillator near the sync point, one can get rid of >> the harmonics by increasing >> the overlapping and thus hard-sync _any_ waveform as the actual >> convolution kernel >> can be anything. So, the two articles are rather different in terms of >> genericity. >> >> The actual interesting bit as i said in a previous post would be to >> actually connect the >> higher order BLEP method (generalized for _arbitrary_ waveforms) with >> the convolution >> BLOO suggests. That would actually add some additional theoretical >> justification >> and insight, but numerically the method works fine both in terms of >> complexity and numerical error. > > it seems high in complexity. ?even just generating the BLIT cleanly would > take 16 to 32 MACs per sample, i would think. ?the convolution with the > filter with the arbitrary waveform as the IR would cost a bit more. > > i've known about BLITs and understood how they can be used to drive an > appropriate filter to generate virtually arbitrary *and* bandlimited > waveforms, but i have always failed to see the advantage over wavetable > synthesis in terms of complexity or cost. > > i know that wavetable synthesis has issues as well. ?you can't have just a > single wavetable for some particular bandlimited waveform because if it has > any overtones at all, as you increase the pitch of the note, those overtones > will eventually alias. ?so you need, for a single harmonically rich waveform > (let's say a sawtooth, just to have an easy illustration) several > wavetables, some with harmonics missing, that are phase locked at the > fundamental. ?you only need to be mixing two of these at a time, but as the > note glissandos upward, you crossfade from a wavetable more rich in > harmonics to one less rich. ?but the harmonics that remain are identical in > amplitude and phase to the ones in the previous wavetable that has more > harmonics. ?if the wavetable is big enough (like 1024 points), there will > almost never be the need to do any more than linear interpolation between > the points. ?for one wavetable, that's 2 table lookups, a subtraction, > multiplication, and addition to linearly interpolate. ?then you have to do > it all again with the other wavetable that you're crossfading to. ?that's > much less computation than running a BLIT through a filter which is why i > sometimes question the point of it. ?it's not the first time i have. > Well, it definitely does not perform better (computationally) than traditional waveform interpolation techniques as it is not the point. The interesting part is that (while we stay in the BLOO convolution setting) when you actually decouple the actual waveform oscillating frequency from the BLIT's you are actually approximating the hard-sync setting fine for any waveform. Consequently, traditional waveform synthesis is a subcase of BLOO when master and slave frequencies are the same. Implementation: I think i can optimise the algorithm down to sick-fast in the current vector architecture context. I would love to speak with code in that respect, i hope i can find some time to elaborate and provide a fully working and ready to use implementation. In the matlab code that comes with the article I use a least squares designed FIR interpolator for the BLIT with 512 phases and a phase length of 8 samples giving a rather satisfying 60db aliasing attenuation. On an AVX supporting processor with an 8-element vector unit that would be just 2 instructions - and if we think Larrabee (and we will be thinking Larrabee soon) complexity goes down to insignificant and one will be able to run whole populations of such oscillators. Still though, in existing architectures (up to SSE4.x, GPUs excluded) it can be very fast still. Embedded is not really my field of expertise, but any arch that supports FIR filtering suits fine, as that's what it essentially is. It has to be noted here that the actual efficiency comes from the fact that a nicely designed band-limited impulse is short enough so that we don?t perform traditional convolution but we optimise all the zeros between each impulse in the BLIT away - that's the main motivation behind it. A rather pleasant side-effect of the method though, that would also make it rather attractive for embedded systems is while short convolution kernels (like the case presented in the article where the slave oscillator rings not more than the master frequency dictates) is that inharmonic aliasing is always attenuated by the BLIT's specification - so we always have a harmonic output which makes it still useful musically. Take for example the sine case: As one can see from the matlab code, by restricting the slave length to that of the master oscillator period we don't really get a "pure" sine even when master and slave have the same frequencies. Instead what we get is an sine rich in (attenuated) overtones that though can still hard-sync with the aliasing always down to the BLIT interpolator's specification. Put a filter after and you have a nice bass-synth oscillator (and not only). So it's pretty much usable if one drops the need for one-to-one correspondence with the continuous-time case. However if one goes for the latter the kernel's length has to be increased. That said, to my eyes the numerical, implementational and generic qualities of the technique surpass everything I've seen so far in the hard-sync context. And, oh god, I _cannot_ get the connection with Taylor's theorem out of my mind! (with respect to the higher order BLEP generalization and how this is connected). I have the feeling it's going deep but not sure yet. >>> >>> i would suggest aiming to approximate >>> >>> ? sin( pi/2 * x ) ? ?for ? ?-1 <= x <= +1 >>> > ... >>> >>> ? sin( pi/2 * x ) = ?x * p(x^2) >>> > ... >>> >>> ? p(x^2) = sin(pi/2*x)/(pi/2*x) * pi/2 = pi/2 * sinc(x/2) ? ? -1 <= x <= >>> +1 >>> >>> or >>> >>> ? p(x) = pi/2 * sinc( sqrt(x)/2 ) ? ? ?for ?0 <= x <= +1 >>> >>> >>> unlike George, i (and nearly all my EE textbooks) define the sinc(x) >>> function to have the pi in it: >>> >>> ? sinc(x) = sin(pi*x)/(pi*x) >> >> Correct, however I use pi explicitly when i utilize "my" sinc definition >> as you >> can see in equation (1). Sorry for the confusion. >> > > i'm probably the one causing confusion since i was the one who's inserting a > variation in definition here. > > it's just that long ago i became convinced that the "EE definition" of the > sinc: > > ? sinc(x) = sin(pi*x)/(pi*x) > > was superior to the traditional definition ( sin(x)/x ) for nearly every > purpose. ?so i've become a little bit of a usage and style nazi about it. > Heh, no prob. Also Wikipedia is clear about it these days so I'll stick to the pi*x version as long as it's called normalized. Yours, George Bezerianos > -- > > 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 > linkshttp://music.columbia.edu/cmc/music-dsphttp://music.columbia.edu/mailman/listinfo/music-dsp > From vadim.zavalishin at native-instruments.de Tue Jun 9 06:00:04 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Tue Jun 9 06:00:21 2009 Subject: [music-dsp] Name for the integrator replacement technique In-Reply-To: <518fe7b20906081508u54da7475wddd44a47feefb6d5@mail.gmail.com> References: <518fe7b20906081508u54da7475wddd44a47feefb6d5@mail.gmail.com> Message-ID: <23A84EE969BE4DE1BF120BC9F536DF0D@nibln01077> > "structure preserving transform" I had the same idea last evening, but then I thought it invokes false associations with linear algebra, so it felt to me more confusing than TPT. > or "filter structure preserving transform" That is probably a little too long > > "graph preserving transform"? Somehow I don't like it too much, but maybe it's just me. Anyway, it seems pretty much everyone is happy with the TPT. Actually, I had second thoughts about George's suggestion SFPT. If we want to get more specific, then we can say "signal flow preserving bilinear transform" or SFP BLT :-) One can also write "SFP transform". Alternatively it could be TP BLT and "TP transform" or simply TPT. In this respect I don't have any strong preference anymore, except that TPT is still shorter, sounds more intuitive (at least to me), also the article speaks about "preserving the topology". Also everyone already more or less agreed on TPT, so unless there are strong complaints, maybe we can stick with TPT? Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From vadim.zavalishin at native-instruments.de Tue Jun 9 06:12:35 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Tue Jun 9 06:12:46 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <6E309835-DBE2-42B4-8C04-EC0BF8318CFB@audioimagination.com> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077><4c23fbf70906080548h447263acp403a8f337c05d3f5@mail.gmail.com> <6E309835-DBE2-42B4-8C04-EC0BF8318CFB@audioimagination.com> Message-ID: <45A3ED37C6FD4A02BD8918F8EF60541A@nibln01077> > in SineSyncRC, Vadim is using a quite long polynomial of |x| to > approximate a sine function over a period (and i presume he's driving > that with a sawtooth function coming out of a phase-accumulator that > defines the phase of the waveform). > > are my understandings reasonably correct? That's correct, but that's a technicality, and doesn't explicitly belong to the method. In fact SineSyncRC is using only the third of the methods described in SineSync.pdf (frequency modulation), as I thought it's the most complicated one to implement. Anyway, I needed some sine function with enough precision, that's all. > > about Vadim's method, that's fine and good, but i think you're throwing > *much* more polynomial at it to get an acceptable synthesized sine wave. Frankly speaking I didn't care too much, as the implementation was done for the proof of concept/demonstration purposes only. > sin(x) is a completely odd-symmetry, so any decent polynomial > approximation would be odd-symmetry (and odd-order). if you factor out > the x, and express as > > sin( pi/2 * x ) = x * p(x^2) Good point. > unlike George, i (and nearly all my EE textbooks) define the sinc(x) > function to have the pi in it: > > sinc(x) = sin(pi*x)/(pi*x) > > that is the polynomial that you want coefficients for (after determining > the order necessary). you might be surprized to see how good of a fit > you get for merely a 2nd or 3rd-order approximation to the > sinc(sqrt(x)/2) function. don't use Taylor series, but try to be more > optimal in getting the coefficients. least-squares would be good, in > this case, but the Remes Exchange algorithm would work also. I was reluctant to use Remez because of the derivative (1st and higher order) discontinuities on the ends, and I wasn't immediately sure that adding explicit constraints on the derivatives will actually work or produce good results. As the absolutely best approximation wasn't my goal anyway, I thought I'd simply use Hermite. Actually, I guess one can use a Hermite-like approach with your idea as well. Anyway, I think your ideas are very valuable for building an optimal sine approximation. Thank you. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From vadim.zavalishin at native-instruments.de Tue Jun 9 06:29:14 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Tue Jun 9 06:29:27 2009 Subject: [music-dsp] Name of delay-free loop technique In-Reply-To: <000d01c9e884$b65c5000$0201a8c0@mooncode> References: <002401c9d7d1$0aee5ce0$0201a8c0@mooncode><56BDCC96E6B94AF5BC7DF68F893A63C1@nibln01077><001201c9d8a6$2f916bc0$0201a8c0@mooncode><001201c9dca5$332d6f60$0201a8c0@mooncode><86DBA60A6D954C829C23571C46248EFE@nibln01077><029244E7BAD549C78B29E3DAB113FC06@nibln01077><000a01c9e21b$441cc3e0$0201a8c0@mooncode><003b01c9e383$904dab80$0201a8c0@mooncode> <000d01c9e884$b65c5000$0201a8c0@mooncode> Message-ID: <3C6F181C0CF441569186A2D2550FF0DC@nibln01077> >> Except that you have introduced a different time scale, where >> t_end=infinity occurs before y[n] (or at the same time). > > I thought of this as happening outside true time. A matter of > taste, I guess. Right. Your way is simpler to understand, mine is more "formally correct". > >>> Do you know any analog devices, besides perhaps >>> oscillators, that routinely operate that way? Have you >>> generally found it sufficient to solve the system as if linear >>> and then saturate the result? >> >> Of course generally it's not sufficient. > > I have a feeling you've answered a different question than I > intended -- have you mostly been satisfied with the cheap > results? Matter of taste :-) I really think one should try to get an own judgement in this case. Often the results are reasonably acceptable, but if I were to use it in a piece of synth software, I'd carefully experiment. > >> Instantaneously unstable cases >> will correspond to the horizontally-reverted graph of >> g*tanh(x-ky), where the graph's steepness (derivative) must >> exceed 1, in which case the system "wants" to go into the >> opposite direction of the intersection of the h(y)=y-s and the >> nonlinearity's tangent line (I think). > > I can't quite picture it. Tangent line where -- at the steepest > point? At the point where y is equal to the current output value. > And by "in the opposite direction of", do you mean "away > from" the intersection? Right > I'd guess you do because that > interpretation does make the selection unique; namely, the > solution jumps from one outside branch of the multivalued inverse > function to the other as soon as the input enters the latter's > support. Is that what you're saying? I can't really picture what you mean by the support of the multivalued inverse function branch here. I have some guesses, but can you be more specific, which function do you mean? Also I assume you mean the domain rather than support (although I'm not too good at English terminology here)? Anyway, what makes the selection unique - is the forced continuity of the output value by the lowpass filter, which allows to determine the direction in which the value is going to "move". Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From vadim.zavalishin at native-instruments.de Tue Jun 9 06:35:41 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Tue Jun 9 06:35:57 2009 Subject: [music-dsp] Re: music-dsp Digest, Vol 66, Issue 17 In-Reply-To: References: <20090608140020.9AFFE974C01@music.columbia.edu> Message-ID: <7145063BEA794D60B9A0EEC1743F9DEE@nibln01077> >time Tn = 0..w (w is for one full period of samples, gradient could be >longer also) >X1 = Tn*e^j(wt+theta) >X2 = (1-Tn)e^j(wt+rho) >X3 = X1 + X2 <-- simple vector addition > >Note! This can be much improved by using a sigmoid function for the >amplitude gradient, >instead of plain linear gradient (that is used with B-splines). This >should produce a kind of spiral on the complex plane. That's what I did in my article. Except that a different approach is used for smoothing. So in a way, it's already tried, there's also a Reaktor Core demo ensemble :-) It would be interesting to compare other smoothing approaches though. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From vadim.zavalishin at native-instruments.de Tue Jun 9 06:48:02 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Tue Jun 9 06:48:14 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <4c23fbf70906081940m71f424d3oe24efdb102370a09@mail.gmail.com> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077><4c23fbf70906080548h447263acp403a8f337c05d3f5@mail.gmail.com><39846A9B4047463EBC4741838DB002EB@nibln01077><4c23fbf70906080659u48af2fdexd04596bc03b137b2@mail.gmail.com><59F0D1E3E5534153B03D414EF177B32F@nibln01077> <4c23fbf70906081940m71f424d3oe24efdb102370a09@mail.gmail.com> Message-ID: <12DDE2537CE045309D862EA1A0B3FED8@nibln01077> > I'm talking _only_ about the BLEP generalization - the rest I don't > remember having > seen anywhere. > > http://www.kvraudio.com/forum/viewtopic.php?t=235913&highlight=bloo Oh, I remember that discussion. I guess that was also what motivated me to write the article in the first place, treating the subject more formally and describing other approaches besides multiple BLEPs. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From vadim.zavalishin at native-instruments.de Tue Jun 9 06:55:30 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Tue Jun 9 06:55:44 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <4521E341-129C-4154-A07A-E07C4B6D3841@audioimagination.com> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077><4c23fbf70906080548h447263acp403a8f337c05d3f5@mail.gmail.com><6E309835-DBE2-42B4-8C04-EC0BF8318CFB@audioimagination.com><4c23fbf70906081918rf6cd30dqa103c0bdf613fc0f@mail.gmail.com> <4521E341-129C-4154-A07A-E07C4B6D3841@audioimagination.com> Message-ID: > yes, i gathered that too. and since the BLIT is BL, any LTI operation > you do to it will result in an output that is likewize BL. What's difficult for me to intuitively understand there, is that convolution with BLIT in the discrete-time domain doesn't guarantee the "correct bandlimitness". In fact one can consider any discrete-time signal as "technically bandlimited", since after going through the DAC the sound will be definitely bandlimited. What is important is whether the "technically bandlimited" signal is identical to what we expect. E.g. an aliasing sawtooth sound at the speaker output is still bandlimited, however it is bandlimited in an undesired way, that's why we complain. In this respect I personally fail to see how "correctly" the signals produced by BLOO will be bandlimited, as it seems to me that the method should introduce certain artifacts. Ideally I'd like to see a comparison of an ideal continuous-time spectrum against a spectrum restored from the discrete time signal. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From gasmoa at gmail.com Tue Jun 9 07:39:57 2009 From: gasmoa at gmail.com (george bezerianos) Date: Tue Jun 9 07:40:14 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077> <4c23fbf70906080548h447263acp403a8f337c05d3f5@mail.gmail.com> <6E309835-DBE2-42B4-8C04-EC0BF8318CFB@audioimagination.com> <4c23fbf70906081918rf6cd30dqa103c0bdf613fc0f@mail.gmail.com> <4521E341-129C-4154-A07A-E07C4B6D3841@audioimagination.com> Message-ID: <4c23fbf70906090439v1fafa59fkae9feaa29aa5da0f@mail.gmail.com> On Tue, Jun 9, 2009 at 12:55 PM, Vadim Zavalishin wrote: >> yes, i gathered that too. ?and since the BLIT is BL, any LTI ?operation >> you do to it will result in an output that is likewize BL. > > What's difficult for me to intuitively understand there, is that convolution > with BLIT in the discrete-time domain doesn't guarantee the "correct > bandlimitness". In fact one can consider any discrete-time signal as > "technically bandlimited", since after going through the DAC the sound will > be definitely bandlimited. What is important is whether the "technically > bandlimited" signal is identical to what we expect. E.g. an aliasing > sawtooth sound at the speaker output is still bandlimited, however it is > bandlimited in an undesired way, that's why we complain. > > In this respect I personally fail to see how "correctly" the signals > produced by BLOO will be bandlimited, as it seems to me that the method > should introduce certain artifacts. Ideally I'd like to see a comparison of > an ideal continuous-time spectrum against a spectrum restored from the > discrete time signal. > I'm not sure why you fail to understand this considering it's convolution. As for how to remove artifacts and approximate the continuous-time case read my response to RBJ's post. If you need a specific formula, there's not one at the moment unfortunately, as this involves me completing the theory and i dont have really the time right now. Seriously. Read my post please. L8r, George Bezerianos > Regards, > Vadim > > -- > Vadim Zavalishin > Senior Software Developer | R&D > > Tel +49-30-611035-0 > Fax +49-30-611035-2600 > > NATIVE INSTRUMENTS GmbH > Schlesische Str. 28 > 10997 Berlin, Germany > http://www.native-instruments.com > > Registergericht: Amtsgericht Charlottenburg > Registernummer: HRB 72458 > UST.-ID.-Nr. DE 20 374 7747 > Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription info, > FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From vadim.zavalishin at native-instruments.de Tue Jun 9 07:51:37 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Tue Jun 9 07:51:55 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <4c23fbf70906090439v1fafa59fkae9feaa29aa5da0f@mail.gmail.com> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077><4c23fbf70906080548h447263acp403a8f337c05d3f5@mail.gmail.com><6E309835-DBE2-42B4-8C04-EC0BF8318CFB@audioimagination.com><4c23fbf70906081918rf6cd30dqa103c0bdf613fc0f@mail.gmail.com><4521E341-129C-4154-A07A-E07C4B6D3841@audioimagination.com> <4c23fbf70906090439v1fafa59fkae9feaa29aa5da0f@mail.gmail.com> Message-ID: <3207FD2039D14A71BD7357AD0FA4B121@nibln01077> >I'm not sure why you fail to understand this considering it's convolution. Because, if I understand your article correctly (still feels brain-damaging to me, I wonder whether there's a simpler way to express the same), you are already modifying the sampled signal in a somewhat arbitrary way prior to the convolution. The arbitrariness is in the fact that you are taking a bandlimited *periodic* signal and windowing it with an almost-rectangular window (slightly trapezoid on one side). That should distort the signal spectrum (intuitively, consider that a single period of a bandlimited periodic signal is no more bandlimited). Then you are putting the pieces back, but in a different way. All that in the discrete time. During that transformation the "correct bandlimitedness" is destroyed at the moment of windowing. How much it is restored by later operations - I have no idea. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From gasmoa at gmail.com Tue Jun 9 08:03:53 2009 From: gasmoa at gmail.com (george bezerianos) Date: Tue Jun 9 08:04:22 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <3207FD2039D14A71BD7357AD0FA4B121@nibln01077> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077> <4c23fbf70906080548h447263acp403a8f337c05d3f5@mail.gmail.com> <6E309835-DBE2-42B4-8C04-EC0BF8318CFB@audioimagination.com> <4c23fbf70906081918rf6cd30dqa103c0bdf613fc0f@mail.gmail.com> <4521E341-129C-4154-A07A-E07C4B6D3841@audioimagination.com> <4c23fbf70906090439v1fafa59fkae9feaa29aa5da0f@mail.gmail.com> <3207FD2039D14A71BD7357AD0FA4B121@nibln01077> Message-ID: <4c23fbf70906090503m78b70fafi74a9569b7221344f@mail.gmail.com> On Tue, Jun 9, 2009 at 1:51 PM, Vadim Zavalishin wrote: >> I'm not sure why you fail to understand this considering it's convolution. > > Because, if I understand your article correctly (still feels brain-damaging > to me, I wonder whether there's a simpler way to express the same), you are > already modifying the sampled signal in a somewhat arbitrary way prior to > the convolution. > The reason i direct you to my posts is that the article is outdated. Pasting from a response to a post of yours above: Ok I'll try to rephrase it as clear as i can. We have a BLIT tuned at the master oscillator frequency. We now _convolve_ that BLIT with the actual slave oscillator output. That's it. The longest the actual slave oscillator will ring (i.e. the longer the convolution kernel) the less harmonic artifacts one will have. This works and you can verify yourself. The theoretical and precise reason behind it at the moment are not clear to me either, as the amount of overlapping increase it demands - it's the theoretical part I'm talking about and needs to be done. > The arbitrariness is in the fact that you are taking a bandlimited > *periodic* signal and windowing it with an almost-rectangular window > (slightly trapezoid on one side). That should distort the signal spectrum > (intuitively, consider that a single period of a bandlimited periodic signal > is no more bandlimited). Then you are putting the pieces back, but in a > different way. All that in the discrete time. During that transformation the > "correct bandlimitedness" is destroyed at the moment of windowing. How much > it is restored by later operations - I have no idea. > I will either remove or correct the article at some point. I ask your attention to what i present here. As for the artifacts are not _that_ destructive as i describe earlier. Now work. ;) L8r, George Bezerianos > Regards, > Vadim > > -- > Vadim Zavalishin > Senior Software Developer | R&D > > Tel +49-30-611035-0 > Fax +49-30-611035-2600 > > NATIVE INSTRUMENTS GmbH > Schlesische Str. 28 > 10997 Berlin, Germany > http://www.native-instruments.com > > Registergericht: Amtsgericht Charlottenburg > Registernummer: HRB 72458 > UST.-ID.-Nr. DE 20 374 7747 > Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription info, > FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From vadim.zavalishin at native-instruments.de Tue Jun 9 08:16:00 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Tue Jun 9 08:16:11 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <4c23fbf70906090503m78b70fafi74a9569b7221344f@mail.gmail.com> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077><4c23fbf70906080548h447263acp403a8f337c05d3f5@mail.gmail.com><6E309835-DBE2-42B4-8C04-EC0BF8318CFB@audioimagination.com><4c23fbf70906081918rf6cd30dqa103c0bdf613fc0f@mail.gmail.com><4521E341-129C-4154-A07A-E07C4B6D3841@audioimagination.com><4c23fbf70906090439v1fafa59fkae9feaa29aa5da0f@mail.gmail.com><3207FD2039D14A71BD7357AD0FA4B121@nibln01077> <4c23fbf70906090503m78b70fafi74a9569b7221344f@mail.gmail.com> Message-ID: >> Because, if I understand your article correctly (still feels >> brain-damaging >> to me, I wonder whether there's a simpler way to express the same), you >> are >> already modifying the sampled signal in a somewhat arbitrary way prior to >> the convolution. >> > > The reason i direct you to my posts is that the article is outdated. > Pasting from a response to a post of yours above: > > Ok I'll try to rephrase it as clear as i can. We have a BLIT tuned at > the master > oscillator frequency. We now _convolve_ that BLIT with the actual > slave oscillator > output. That's it. The longest the actual slave oscillator will ring > (i.e. the longer the > convolution kernel) the less harmonic artifacts one will have. I understand that by convolving with BLIT you get a bandlimited signal. What I don't understand is how one can estimate the amount of spectrum distortion caused by the arbitrary modification. This is the most important question in regards to BLOO for me (actually, numerically computed examples will do as well). Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From gasmoa at gmail.com Tue Jun 9 08:16:29 2009 From: gasmoa at gmail.com (george bezerianos) Date: Tue Jun 9 08:16:49 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <4c23fbf70906090503m78b70fafi74a9569b7221344f@mail.gmail.com> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077> <4c23fbf70906080548h447263acp403a8f337c05d3f5@mail.gmail.com> <6E309835-DBE2-42B4-8C04-EC0BF8318CFB@audioimagination.com> <4c23fbf70906081918rf6cd30dqa103c0bdf613fc0f@mail.gmail.com> <4521E341-129C-4154-A07A-E07C4B6D3841@audioimagination.com> <4c23fbf70906090439v1fafa59fkae9feaa29aa5da0f@mail.gmail.com> <3207FD2039D14A71BD7357AD0FA4B121@nibln01077> <4c23fbf70906090503m78b70fafi74a9569b7221344f@mail.gmail.com> Message-ID: <4c23fbf70906090516j71f17d9el83c1456449f5ebe1@mail.gmail.com> Briefly, the longer the slave oscillator will ring the better approximation of the waveform you will have and thus the harmonic artifacts will be progressively attenuated at a point that they fall under the specification of the BLIT interpolator and thus you don't really have to do it any more (or you could use a masking model to save some length). This is waveform dependent - actually it seems that the length it has to ring depends on the Cn continuity of the waveform just like the order of BLEP generalization depends on the that as well!!! And _this_ is the analogy to Taylor's theorem. On Tue, Jun 9, 2009 at 2:03 PM, george bezerianos wrote: > On Tue, Jun 9, 2009 at 1:51 PM, Vadim > Zavalishin wrote: >>> I'm not sure why you fail to understand this considering it's convolution. >> >> Because, if I understand your article correctly (still feels brain-damaging >> to me, I wonder whether there's a simpler way to express the same), you are >> already modifying the sampled signal in a somewhat arbitrary way prior to >> the convolution. >> > > The reason i direct you to my posts is that the article is outdated. > Pasting from a response to a post of yours above: > > Ok I'll try to rephrase it as clear as i can. We have ?a BLIT tuned at > the master > oscillator frequency. We now _convolve_ that BLIT with the actual > slave oscillator > output. That's it. The longest the actual slave oscillator will ring > (i.e. the longer the > convolution kernel) the less harmonic artifacts one will have. > > This works and you can verify yourself. The theoretical and precise > reason behind it at the moment are not clear to me either, as the amount > of overlapping increase it demands - it's the theoretical part I'm talking > about and needs to be done. > >> The arbitrariness is in the fact that you are taking a bandlimited >> *periodic* signal and windowing it with an almost-rectangular window >> (slightly trapezoid on one side). That should distort the signal spectrum >> (intuitively, consider that a single period of a bandlimited periodic signal >> is no more bandlimited). Then you are putting the pieces back, but in a >> different way. All that in the discrete time. During that transformation the >> "correct bandlimitedness" is destroyed at the moment of windowing. How much >> it is restored by later operations - I have no idea. >> > > I will either remove or correct the article at some point. I ask your attention > to what i present here. As for the artifacts are not _that_ > destructive as i describe > earlier. > > Now work. ;) > > L8r, > > George Bezerianos > >> Regards, >> Vadim >> >> -- >> Vadim Zavalishin >> Senior Software Developer | R&D >> >> Tel +49-30-611035-0 >> Fax +49-30-611035-2600 >> >> NATIVE INSTRUMENTS GmbH >> Schlesische Str. 28 >> 10997 Berlin, Germany >> http://www.native-instruments.com >> >> Registergericht: Amtsgericht Charlottenburg >> Registernummer: HRB 72458 >> UST.-ID.-Nr. DE 20 374 7747 >> Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic >> >> -- >> dupswapdrop -- the music-dsp mailing list and website: subscription info, >> FAQ, source code archive, list archive, book reviews, dsp links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp >> > From vadim.zavalishin at native-instruments.de Tue Jun 9 08:26:53 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Tue Jun 9 08:27:06 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <4c23fbf70906090516j71f17d9el83c1456449f5ebe1@mail.gmail.com> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077><4c23fbf70906080548h447263acp403a8f337c05d3f5@mail.gmail.com><6E309835-DBE2-42B4-8C04-EC0BF8318CFB@audioimagination.com><4c23fbf70906081918rf6cd30dqa103c0bdf613fc0f@mail.gmail.com><4521E341-129C-4154-A07A-E07C4B6D3841@audioimagination.com><4c23fbf70906090439v1fafa59fkae9feaa29aa5da0f@mail.gmail.com><3207FD2039D14A71BD7357AD0FA4B121@nibln01077><4c23fbf70906090503m78b70fafi74a9569b7221344f@mail.gmail.com> <4c23fbf70906090516j71f17d9el83c1456449f5ebe1@mail.gmail.com> Message-ID: >Briefly, the longer the slave oscillator will ring the better approximation >of >the waveform you will have and thus the harmonic artifacts >will be progressively attenuated at a point that they fall under the >specification >of the BLIT interpolator and thus you don't really have to do it any more >(or you could use a masking model to save some length). Maybe there's some misunderstanding. Assume the interpolator is infinitely long (ideal case). How much is the spectrum going to be distorted in this case? That's my question. I'm not asking about the effects of time-limiting the sinc function. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From gasmoa at gmail.com Tue Jun 9 08:36:17 2009 From: gasmoa at gmail.com (george bezerianos) Date: Tue Jun 9 08:36:28 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077> <6E309835-DBE2-42B4-8C04-EC0BF8318CFB@audioimagination.com> <4c23fbf70906081918rf6cd30dqa103c0bdf613fc0f@mail.gmail.com> <4521E341-129C-4154-A07A-E07C4B6D3841@audioimagination.com> <4c23fbf70906090439v1fafa59fkae9feaa29aa5da0f@mail.gmail.com> <3207FD2039D14A71BD7357AD0FA4B121@nibln01077> <4c23fbf70906090503m78b70fafi74a9569b7221344f@mail.gmail.com> <4c23fbf70906090516j71f17d9el83c1456449f5ebe1@mail.gmail.com> Message-ID: <4c23fbf70906090536x3b423fcay22b3e6016913d5d7@mail.gmail.com> On Tue, Jun 9, 2009 at 2:26 PM, Vadim Zavalishin wrote: >> Briefly, the longer the slave oscillator will ring the better >> approximation of >> the waveform you will have and thus the harmonic artifacts >> will be progressively attenuated at a point that they fall under the >> specification >> of the BLIT interpolator and thus you don't really have to do it any more >> (or you could use a masking model to save some length). > > Maybe there's some misunderstanding. > > Assume the interpolator is infinitely long (ideal case). How much is the > spectrum going to be distorted in this case? That's my question. I'm not > asking about the effects of time-limiting the sinc function. > Uhm, I'm not talking about time-limiting the sinc function here but the time the slave oscillator will output. The BLIT interpolation is there in any setting and it provides it's attenuation as always producing ...well, a bandlimited impulse train ;). Now you filter this BLIT with the actual output of the slave oscillator (after reset). So consider the slave oscillator's output just an FIR filter. And let's take for example a sine slave oscillator for the sake of the conversation. Now, an infinitely long sine has a delayed (in frequency domain) impulse as a frequency response. However, a windowed period of a sine has a big fat lobe as a frequency response centered at where the impulse would be in the infinitely long case. _This_ causes the harmonics from the BLIT to leak - we have to shrink that lobe and the best way of course is to give our sine some space in time. This generalizes analogously to arbitary waveforms. > Regards, > Vadim > > -- > Vadim Zavalishin > Senior Software Developer | R&D > > Tel +49-30-611035-0 > Fax +49-30-611035-2600 > > NATIVE INSTRUMENTS GmbH > Schlesische Str. 28 > 10997 Berlin, Germany > http://www.native-instruments.com > > Registergericht: Amtsgericht Charlottenburg > Registernummer: HRB 72458 > UST.-ID.-Nr. DE 20 374 7747 > Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription info, > FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From vadim.zavalishin at native-instruments.de Tue Jun 9 08:40:42 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Tue Jun 9 08:40:58 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <4c23fbf70906090536x3b423fcay22b3e6016913d5d7@mail.gmail.com> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077><6E309835-DBE2-42B4-8C04-EC0BF8318CFB@audioimagination.com><4c23fbf70906081918rf6cd30dqa103c0bdf613fc0f@mail.gmail.com><4521E341-129C-4154-A07A-E07C4B6D3841@audioimagination.com><4c23fbf70906090439v1fafa59fkae9feaa29aa5da0f@mail.gmail.com><3207FD2039D14A71BD7357AD0FA4B121@nibln01077><4c23fbf70906090503m78b70fafi74a9569b7221344f@mail.gmail.com><4c23fbf70906090516j71f17d9el83c1456449f5ebe1@mail.gmail.com> <4c23fbf70906090536x3b423fcay22b3e6016913d5d7@mail.gmail.com> Message-ID: <496643AF7AE64774BBA6CE1DB2CCF18A@nibln01077> > Now you filter this BLIT with the actual output of the slave > oscillator (after reset). > So consider the slave oscillator's output just an FIR filter. And > let's take for example > a sine slave oscillator for the sake of the conversation. Now, an > infinitely long > sine has a delayed (in frequency domain) impulse as a frequency response. > However, a windowed period of a sine has a big fat lobe as a frequency > response centered at > where the impulse would be in the infinitely long case. _This_ causes > the harmonics > from the BLIT to leak - we have to shrink that lobe and the best way > of course is > to give our sine some space in time. This generalizes analogously to > arbitary waveforms. Right, but how can we give our sine some space in time in the context of hard-syncing? The window size is pretty much fixed to the period of the master oscillator, isn't it? Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From gasmoa at gmail.com Tue Jun 9 08:48:21 2009 From: gasmoa at gmail.com (george bezerianos) Date: Tue Jun 9 08:48:35 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <496643AF7AE64774BBA6CE1DB2CCF18A@nibln01077> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077> <4521E341-129C-4154-A07A-E07C4B6D3841@audioimagination.com> <4c23fbf70906090439v1fafa59fkae9feaa29aa5da0f@mail.gmail.com> <3207FD2039D14A71BD7357AD0FA4B121@nibln01077> <4c23fbf70906090503m78b70fafi74a9569b7221344f@mail.gmail.com> <4c23fbf70906090516j71f17d9el83c1456449f5ebe1@mail.gmail.com> <4c23fbf70906090536x3b423fcay22b3e6016913d5d7@mail.gmail.com> <496643AF7AE64774BBA6CE1DB2CCF18A@nibln01077> Message-ID: <4c23fbf70906090548g1dca3c3u6aaeaf7bfbdf3824@mail.gmail.com> On Tue, Jun 9, 2009 at 2:40 PM, Vadim Zavalishin wrote: >> Now you filter this BLIT with the actual output of the slave >> oscillator (after reset). >> So consider the slave oscillator's output just an FIR filter. And >> let's take for example >> a sine slave oscillator for the sake of the conversation. Now, an >> infinitely long >> sine has a delayed (in frequency domain) impulse ?as a frequency response. >> However, a windowed period of a sine has a big fat lobe as a frequency >> response centered at >> where the impulse would be in the infinitely long case. _This_ causes >> the harmonics >> from the BLIT to leak - we have to shrink that lobe and the best way >> of course is >> to give our sine some space in time. This generalizes analogously to >> arbitary waveforms. > > Right, but how can we give our sine some space in time in the context of > hard-syncing? The window size is pretty much fixed to the period of the > master oscillator, isn't it? > That's what erroneously the article suggests - and that's why it's outdated. We have to let it ring more and of course increase overlapping and complexity, but with hugely better numerical accuracy than the generalized BLEP method. And it's really not that bad since with FIR interpolator for the BLIT is very vectorizable as i also describe in an earlier post. Now, the pseudo-C++ code i have in the article should make more sense to people also (it also hints some additional optimizations). However a good outcome is that even if you don't let the slave ring more you still get a harmonic output that doesn't alias because our BLIT takes care of that (that could be useful). Yours, George Bezerianos > Regards, > Vadim > > -- > Vadim Zavalishin > Senior Software Developer | R&D > > Tel +49-30-611035-0 > Fax +49-30-611035-2600 > > NATIVE INSTRUMENTS GmbH > Schlesische Str. 28 > 10997 Berlin, Germany > http://www.native-instruments.com > > Registergericht: Amtsgericht Charlottenburg > Registernummer: HRB 72458 > UST.-ID.-Nr. DE 20 374 7747 > Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription info, > FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From gasmoa at gmail.com Tue Jun 9 08:55:05 2009 From: gasmoa at gmail.com (george bezerianos) Date: Tue Jun 9 08:55:28 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <4c23fbf70906090548g1dca3c3u6aaeaf7bfbdf3824@mail.gmail.com> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077> <4c23fbf70906090439v1fafa59fkae9feaa29aa5da0f@mail.gmail.com> <3207FD2039D14A71BD7357AD0FA4B121@nibln01077> <4c23fbf70906090503m78b70fafi74a9569b7221344f@mail.gmail.com> <4c23fbf70906090516j71f17d9el83c1456449f5ebe1@mail.gmail.com> <4c23fbf70906090536x3b423fcay22b3e6016913d5d7@mail.gmail.com> <496643AF7AE64774BBA6CE1DB2CCF18A@nibln01077> <4c23fbf70906090548g1dca3c3u6aaeaf7bfbdf3824@mail.gmail.com> Message-ID: <4c23fbf70906090555j55f05323q2eb3cffb08657a54@mail.gmail.com> And in case I didn't make it clear, the master frequency is completely determined by the frequency of the BLIT, you don't have to "reset" the slave when a new impulse from the BLIT kicks in - that's what i thought first and i wrote the article like it is; instead you just let the old one ring and start a new one with the new (bandlimited) impulse. Yours, George Bezerianos On Tue, Jun 9, 2009 at 2:48 PM, george bezerianos wrote: > On Tue, Jun 9, 2009 at 2:40 PM, Vadim > Zavalishin wrote: >>> Now you filter this BLIT with the actual output of the slave >>> oscillator (after reset). >>> So consider the slave oscillator's output just an FIR filter. And >>> let's take for example >>> a sine slave oscillator for the sake of the conversation. Now, an >>> infinitely long >>> sine has a delayed (in frequency domain) impulse ?as a frequency response. >>> However, a windowed period of a sine has a big fat lobe as a frequency >>> response centered at >>> where the impulse would be in the infinitely long case. _This_ causes >>> the harmonics >>> from the BLIT to leak - we have to shrink that lobe and the best way >>> of course is >>> to give our sine some space in time. This generalizes analogously to >>> arbitary waveforms. >> >> Right, but how can we give our sine some space in time in the context of >> hard-syncing? The window size is pretty much fixed to the period of the >> master oscillator, isn't it? >> > > That's what erroneously the article suggests - and that's why it's outdated. > We have to let it ring more and of course increase overlapping and complexity, > but with hugely better numerical accuracy than the generalized BLEP method. > And it's really not that bad since with FIR interpolator for the BLIT > is very vectorizable > as i also describe in an earlier post. > > Now, the pseudo-C++ code i have in the article should make more sense > to people also > (it also hints some additional optimizations). > > However a good outcome is that even if you don't let the slave ring > more you still > get a harmonic output that doesn't alias because our BLIT takes care > of that (that could be useful). > > Yours, > > George Bezerianos > >> Regards, >> Vadim >> >> -- >> Vadim Zavalishin >> Senior Software Developer | R&D >> >> Tel +49-30-611035-0 >> Fax +49-30-611035-2600 >> >> NATIVE INSTRUMENTS GmbH >> Schlesische Str. 28 >> 10997 Berlin, Germany >> http://www.native-instruments.com >> >> Registergericht: Amtsgericht Charlottenburg >> Registernummer: HRB 72458 >> UST.-ID.-Nr. DE 20 374 7747 >> Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic >> >> -- >> dupswapdrop -- the music-dsp mailing list and website: subscription info, >> FAQ, source code archive, list archive, book reviews, dsp links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp >> > From vadim.zavalishin at native-instruments.de Tue Jun 9 08:59:26 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Tue Jun 9 08:59:40 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <4c23fbf70906090548g1dca3c3u6aaeaf7bfbdf3824@mail.gmail.com> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077><4521E341-129C-4154-A07A-E07C4B6D3841@audioimagination.com><4c23fbf70906090439v1fafa59fkae9feaa29aa5da0f@mail.gmail.com><3207FD2039D14A71BD7357AD0FA4B121@nibln01077><4c23fbf70906090503m78b70fafi74a9569b7221344f@mail.gmail.com><4c23fbf70906090516j71f17d9el83c1456449f5ebe1@mail.gmail.com><4c23fbf70906090536x3b423fcay22b3e6016913d5d7@mail.gmail.com><496643AF7AE64774BBA6CE1DB2CCF18A@nibln01077> <4c23fbf70906090548g1dca3c3u6aaeaf7bfbdf3824@mail.gmail.com> Message-ID: <02716B6F03CE4A3E85A5911110B9A5F8@nibln01077> >That's what erroneously the article suggests - and that's why it's >outdated. >We have to let it ring more and of course increase overlapping and >complexity, >but with hugely better numerical accuracy than the generalized BLEP method. How exactly do you plan to let it ring more? I think that's pretty much the key question, before one can make any statements about accuracy. Did you already describe it in some posts (I admit I only quickly glanced through a few of your postings, so I might have missed it)? >However a good outcome is that even if you don't let the slave ring >more you still >get a harmonic output that doesn't alias because our BLIT takes care >of that (that could be useful). Whether it's aliasing or not is arguable. Of course there is no explicit sampling of continuous-time signals involved, but you can still produce wrong frequencies (which may coincide with the existing ones), similarly to how e.g. discrete-time waveshapers do. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From gasmoa at gmail.com Tue Jun 9 09:05:06 2009 From: gasmoa at gmail.com (george bezerianos) Date: Tue Jun 9 09:05:22 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <02716B6F03CE4A3E85A5911110B9A5F8@nibln01077> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077> <4c23fbf70906090439v1fafa59fkae9feaa29aa5da0f@mail.gmail.com> <3207FD2039D14A71BD7357AD0FA4B121@nibln01077> <4c23fbf70906090503m78b70fafi74a9569b7221344f@mail.gmail.com> <4c23fbf70906090516j71f17d9el83c1456449f5ebe1@mail.gmail.com> <4c23fbf70906090536x3b423fcay22b3e6016913d5d7@mail.gmail.com> <496643AF7AE64774BBA6CE1DB2CCF18A@nibln01077> <4c23fbf70906090548g1dca3c3u6aaeaf7bfbdf3824@mail.gmail.com> <02716B6F03CE4A3E85A5911110B9A5F8@nibln01077> Message-ID: <4c23fbf70906090605r15619d96p7af1892228576076@mail.gmail.com> On Tue, Jun 9, 2009 at 2:59 PM, Vadim Zavalishin wrote: >> That's what erroneously the article suggests - and that's why it's >> outdated. >> We have to let it ring more and of course increase overlapping and >> complexity, >> but with hugely better numerical accuracy than the generalized BLEP >> method. > > How exactly do you plan to let it ring more? I think that's pretty much the > key question, before one can make any statements about accuracy. Did you > already describe it in some posts (I admit I only quickly glanced through a > few of your postings, so I might have missed it)? > Umm, just let it ring in its original (slave) frequency like you would do with a normal oscillator. >> However a good outcome is that even if you don't let the slave ring >> more you still >> get a harmonic output that doesn't alias because our BLIT takes care >> of that (that could be useful). > > Whether it's aliasing or not is arguable. Of course there is no explicit > sampling of continuous-time signals involved, but you can still produce > wrong frequencies (which may coincide with the existing ones), similarly to > how e.g. discrete-time waveshapers do. > No, the BLIT, assuming it's bandlimited correctly, will only have overtones over the fundamental and not below. Now, how many of the ones over the fundamental will leak depends entirely on the filtering from the slave output which is handled as just discussed. Yours, George Bezerianos > Regards, > Vadim > > -- > Vadim Zavalishin > Senior Software Developer | R&D > > Tel +49-30-611035-0 > Fax +49-30-611035-2600 > > NATIVE INSTRUMENTS GmbH > Schlesische Str. 28 > 10997 Berlin, Germany > http://www.native-instruments.com > > Registergericht: Amtsgericht Charlottenburg > Registernummer: HRB 72458 > UST.-ID.-Nr. DE 20 374 7747 > Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription info, > FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From vadim.zavalishin at native-instruments.de Tue Jun 9 09:10:42 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Tue Jun 9 09:10:53 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <4c23fbf70906090605r15619d96p7af1892228576076@mail.gmail.com> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077><4c23fbf70906090439v1fafa59fkae9feaa29aa5da0f@mail.gmail.com><3207FD2039D14A71BD7357AD0FA4B121@nibln01077><4c23fbf70906090503m78b70fafi74a9569b7221344f@mail.gmail.com><4c23fbf70906090516j71f17d9el83c1456449f5ebe1@mail.gmail.com><4c23fbf70906090536x3b423fcay22b3e6016913d5d7@mail.gmail.com><496643AF7AE64774BBA6CE1DB2CCF18A@nibln01077><4c23fbf70906090548g1dca3c3u6aaeaf7bfbdf3824@mail.gmail.com><02716B6F03CE4A3E85A5911110B9A5F8@nibln01077> <4c23fbf70906090605r15619d96p7af1892228576076@mail.gmail.com> Message-ID: <57B491FB2BF34D8C99D47AEAF4941B5A@nibln01077> >> How exactly do you plan to let it ring more? I think that's pretty much >> the >> key question, before one can make any statements about accuracy. Did you >> already describe it in some posts (I admit I only quickly glanced through >> a >> few of your postings, so I might have missed it)? >> > > Umm, just let it ring in its original (slave) frequency like you would do > with a normal oscillator. You mean infinitely? Then how does this correspond to hard-syncing? I don't really understand. > No, the BLIT, assuming it's bandlimited correctly, will only have > overtones > over the fundamental and not below. Now, how many of the ones over > the fundamental will leak depends entirely on the filtering from the slave > output which is handled as just discussed. I think it depends on the effects of windowing of the slave, rather than filtering. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From gasmoa at gmail.com Tue Jun 9 09:21:41 2009 From: gasmoa at gmail.com (george bezerianos) Date: Tue Jun 9 09:21:56 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <57B491FB2BF34D8C99D47AEAF4941B5A@nibln01077> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077> <4c23fbf70906090503m78b70fafi74a9569b7221344f@mail.gmail.com> <4c23fbf70906090516j71f17d9el83c1456449f5ebe1@mail.gmail.com> <4c23fbf70906090536x3b423fcay22b3e6016913d5d7@mail.gmail.com> <496643AF7AE64774BBA6CE1DB2CCF18A@nibln01077> <4c23fbf70906090548g1dca3c3u6aaeaf7bfbdf3824@mail.gmail.com> <02716B6F03CE4A3E85A5911110B9A5F8@nibln01077> <4c23fbf70906090605r15619d96p7af1892228576076@mail.gmail.com> <57B491FB2BF34D8C99D47AEAF4941B5A@nibln01077> Message-ID: <4c23fbf70906090621l50f74587r2783770f0ba154ae@mail.gmail.com> On Tue, Jun 9, 2009 at 3:10 PM, Vadim Zavalishin wrote: >>> How exactly do you plan to let it ring more? I think that's pretty much >>> the >>> key question, before one can make any statements about accuracy. Did you >>> already describe it in some posts (I admit I only quickly glanced through >>> a >>> few of your postings, so I might have missed it)? >>> >> >> Umm, just let it ring in its original (slave) frequency like you would do >> with a normal oscillator. > > You mean infinitely? Then how does this correspond to hard-syncing? I don't > really understand. > Not infinitely, just long enough - how long apparently depends on the Cn discontinuity. You can check yourself that it _does_ work. I conjecture that it has to do with Taylor's Theorem because of the analogy i described quite some times in previous posts (it's a good time now that you know what I'm talking about to go through them). >> No, the BLIT, assuming it's bandlimited correctly, will only have >> overtones >> over the fundamental and not below. Now, how many of the ones over >> the fundamental will leak depends entirely on the filtering from the slave >> output which is handled as just discussed. > > I think it depends on the effects of windowing of the slave, rather than > filtering. > I'm not sure what you mean with "filtering" here. If you mean instead "rather than making it longer", then, yes, windowing will possibly make it better but only until some point - there's a chance you're fiddling with the actual harmonic structure of the waveform this way which will deviate further from the wanted result. Yours, George Bezerianos > Regards, > Vadim > > -- > Vadim Zavalishin > Senior Software Developer | R&D > > Tel +49-30-611035-0 > Fax +49-30-611035-2600 > > NATIVE INSTRUMENTS GmbH > Schlesische Str. 28 > 10997 Berlin, Germany > http://www.native-instruments.com > > Registergericht: Amtsgericht Charlottenburg > Registernummer: HRB 72458 > UST.-ID.-Nr. DE 20 374 7747 > Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription info, > FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From vadim.zavalishin at native-instruments.de Tue Jun 9 09:26:13 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Tue Jun 9 09:26:26 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <4c23fbf70906090621l50f74587r2783770f0ba154ae@mail.gmail.com> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077><4c23fbf70906090503m78b70fafi74a9569b7221344f@mail.gmail.com><4c23fbf70906090516j71f17d9el83c1456449f5ebe1@mail.gmail.com><4c23fbf70906090536x3b423fcay22b3e6016913d5d7@mail.gmail.com><496643AF7AE64774BBA6CE1DB2CCF18A@nibln01077><4c23fbf70906090548g1dca3c3u6aaeaf7bfbdf3824@mail.gmail.com><02716B6F03CE4A3E85A5911110B9A5F8@nibln01077><4c23fbf70906090605r15619d96p7af1892228576076@mail.gmail.com><57B491FB2BF34D8C99D47AEAF4941B5A@nibln01077> <4c23fbf70906090621l50f74587r2783770f0ba154ae@mail.gmail.com> Message-ID: <0213B97264524FEFBBAF5765BF886CCB@nibln01077> > Not infinitely, just long enough - how long apparently depends on the > Cn discontinuity. > You can check yourself that it _does_ work. I conjecture that it has > to do with Taylor's Theorem because of the analogy i described quite some > times in previous posts (it's a good time now that you know what > I'm talking about to go through them). Yes, but how does this relate to emulating the hard-syncing, if the pieces of the slave waveform are much longer than the master period? Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From gasmoa at gmail.com Tue Jun 9 09:35:47 2009 From: gasmoa at gmail.com (george bezerianos) Date: Tue Jun 9 09:36:03 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <0213B97264524FEFBBAF5765BF886CCB@nibln01077> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077> <4c23fbf70906090536x3b423fcay22b3e6016913d5d7@mail.gmail.com> <496643AF7AE64774BBA6CE1DB2CCF18A@nibln01077> <4c23fbf70906090548g1dca3c3u6aaeaf7bfbdf3824@mail.gmail.com> <02716B6F03CE4A3E85A5911110B9A5F8@nibln01077> <4c23fbf70906090605r15619d96p7af1892228576076@mail.gmail.com> <57B491FB2BF34D8C99D47AEAF4941B5A@nibln01077> <4c23fbf70906090621l50f74587r2783770f0ba154ae@mail.gmail.com> <0213B97264524FEFBBAF5765BF886CCB@nibln01077> Message-ID: <4c23fbf70906090635m786de0e1y62158ed2b9b610ee@mail.gmail.com> On Tue, Jun 9, 2009 at 3:26 PM, Vadim Zavalishin wrote: >> Not infinitely, just long enough - how long apparently depends on the >> Cn discontinuity. >> You can check yourself that it _does_ work. I conjecture that it has >> to do with Taylor's Theorem because of the analogy i described quite some >> times in previous posts (it's a good time now that you know what >> I'm talking about to go through them). > > Yes, but how does this relate to emulating the hard-syncing, if the pieces > of the slave waveform are much longer than the master period? > By letting the BLIT (master) having a different frequency from the slave. The (_not infinite_) slave's output frequency response will have some lobes centered at the waveform's overtones which will let additional harmonics from the BLIT leaking - this creates the harmonic leakage we experience with hard-sync. Note that the slave has to ring a _specific_ (currently undefined) amount of time, an infinite one would produce zero output at the moment that master and slave frequencies have no longer integer ratio. I suspect the amount of time the slave has to ring could be calculated in terms of numbers of period with respect to the discontinuity order - but i might be wrong there. Yours, George Bezerianos > Regards, > Vadim > > -- > Vadim Zavalishin > Senior Software Developer | R&D > > Tel +49-30-611035-0 > Fax +49-30-611035-2600 > > NATIVE INSTRUMENTS GmbH > Schlesische Str. 28 > 10997 Berlin, Germany > http://www.native-instruments.com > > Registergericht: Amtsgericht Charlottenburg > Registernummer: HRB 72458 > UST.-ID.-Nr. DE 20 374 7747 > Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription info, > FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From brian at absyn.com Tue Jun 9 09:36:37 2009 From: brian at absyn.com (Brian Clevinger) Date: Tue Jun 9 09:37:25 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <4c23fbf70906090548g1dca3c3u6aaeaf7bfbdf3824@mail.gmail.com> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077> <4521E341-129C-4154-A07A-E07C4B6D3841@audioimagination.com> <4c23fbf70906090439v1fafa59fkae9feaa29aa5da0f@mail.gmail.com> <3207FD2039D14A71BD7357AD0FA4B121@nibln01077> <4c23fbf70906090503m78b70fafi74a9569b7221344f@mail.gmail.com> <4c23fbf70906090516j71f17d9el83c1456449f5ebe1@mail.gmail.com> <4c23fbf70906090536x3b423fcay22b3e6016913d5d7@mail.gmail.com> <496643AF7AE64774BBA6CE1DB2CCF18A@nibln01077> <4c23fbf70906090548g1dca3c3u6aaeaf7bfbdf3824@mail.gmail.com> Message-ID: <7A2B789A-9E14-405F-96FA-5BFDFF3EB070@absyn.com> Maybe I am misunderstanding you, but it sounds like a type of granular synthesis. By allowing the slave(s) to ring and overlap you will get frequency dependent phase cancellation/reinforcement. It's a musically interesting effect, but it's different from syncing. But that depends on how much the ringing overlaps, maybe if it's short enough you won't get too much phase cancellation. Perhaps what you're describing is similar to Xavier Rodet's FOF technique. Brian > On Tue, Jun 9, 2009 at 2:40 PM, Vadim > Zavalishin wrote: >>> Now you filter this BLIT with the actual output of the slave >>> oscillator (after reset). >>> So consider the slave oscillator's output just an FIR filter. And >>> let's take for example >>> a sine slave oscillator for the sake of the conversation. Now, an >>> infinitely long >>> sine has a delayed (in frequency domain) impulse as a frequency >>> response. >>> However, a windowed period of a sine has a big fat lobe as a >>> frequency >>> response centered at >>> where the impulse would be in the infinitely long case. _This_ >>> causes >>> the harmonics >>> from the BLIT to leak - we have to shrink that lobe and the best way >>> of course is >>> to give our sine some space in time. This generalizes analogously to >>> arbitary waveforms. >> >> Right, but how can we give our sine some space in time in the >> context of >> hard-syncing? The window size is pretty much fixed to the period of >> the >> master oscillator, isn't it? >> > > That's what erroneously the article suggests - and that's why it's > outdated. > We have to let it ring more and of course increase overlapping and > complexity, > but with hugely better numerical accuracy than the generalized BLEP > method. > And it's really not that bad since with FIR interpolator for the BLIT > is very vectorizable > as i also describe in an earlier post. > > Now, the pseudo-C++ code i have in the article should make more sense > to people also > (it also hints some additional optimizations). > > However a good outcome is that even if you don't let the slave ring > more you still > get a harmonic output that doesn't alias because our BLIT takes care > of that (that could be useful). > > Yours, > > George Bezerianos > >> Regards, >> Vadim >> >> -- >> Vadim Zavalishin >> Senior Software Developer | R&D >> >> Tel +49-30-611035-0 >> Fax +49-30-611035-2600 >> >> NATIVE INSTRUMENTS GmbH >> Schlesische Str. 28 >> 10997 Berlin, Germany >> http://www.native-instruments.com >> >> Registergericht: Amtsgericht Charlottenburg >> Registernummer: HRB 72458 >> UST.-ID.-Nr. DE 20 374 7747 >> Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic >> >> -- >> dupswapdrop -- the music-dsp mailing list and website: subscription >> info, >> FAQ, source code archive, list archive, book reviews, dsp links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp >> > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book > reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From vadim.zavalishin at native-instruments.de Tue Jun 9 09:43:27 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Tue Jun 9 09:43:45 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <7A2B789A-9E14-405F-96FA-5BFDFF3EB070@absyn.com> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077><4521E341-129C-4154-A07A-E07C4B6D3841@audioimagination.com><4c23fbf70906090439v1fafa59fkae9feaa29aa5da0f@mail.gmail.com><3207FD2039D14A71BD7357AD0FA4B121@nibln01077><4c23fbf70906090503m78b70fafi74a9569b7221344f@mail.gmail.com><4c23fbf70906090516j71f17d9el83c1456449f5ebe1@mail.gmail.com><4c23fbf70906090536x3b423fcay22b3e6016913d5d7@mail.gmail.com><496643AF7AE64774BBA6CE1DB2CCF18A@nibln01077><4c23fbf70906090548g1dca3c3u6aaeaf7bfbdf3824@mail.gmail.com> <7A2B789A-9E14-405F-96FA-5BFDFF3EB070@absyn.com> Message-ID: <241571D7265C48098AFB97BFB4A1B66B@nibln01077> > Maybe I am misunderstanding you, but it sounds like a type of granular > synthesis. By allowing the slave(s) to ring and overlap you will get > frequency dependent phase cancellation/reinforcement. It's a musically > interesting effect, but it's different from syncing. But that depends on > how much the ringing overlaps, maybe if it's short enough you won't get > too much phase cancellation. That's exactly my point. Also if the "ringing" is "short enough", then you get strong spectrum distortion due to windowing, if it's long then it's not syncing. Or, I must be missing something as well. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From gasmoa at gmail.com Tue Jun 9 09:45:52 2009 From: gasmoa at gmail.com (george bezerianos) Date: Tue Jun 9 09:46:08 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <7A2B789A-9E14-405F-96FA-5BFDFF3EB070@absyn.com> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077> <4c23fbf70906090439v1fafa59fkae9feaa29aa5da0f@mail.gmail.com> <3207FD2039D14A71BD7357AD0FA4B121@nibln01077> <4c23fbf70906090503m78b70fafi74a9569b7221344f@mail.gmail.com> <4c23fbf70906090516j71f17d9el83c1456449f5ebe1@mail.gmail.com> <4c23fbf70906090536x3b423fcay22b3e6016913d5d7@mail.gmail.com> <496643AF7AE64774BBA6CE1DB2CCF18A@nibln01077> <4c23fbf70906090548g1dca3c3u6aaeaf7bfbdf3824@mail.gmail.com> <7A2B789A-9E14-405F-96FA-5BFDFF3EB070@absyn.com> Message-ID: <4c23fbf70906090645v30b9120dr4143d867271df49d@mail.gmail.com> On Tue, Jun 9, 2009 at 3:36 PM, Brian Clevinger wrote: > Maybe I am misunderstanding you, but it sounds like a type of granular > synthesis. By allowing the slave(s) to ring and overlap you will get > frequency dependent phase cancellation/reinforcement. It's a musically > interesting effect, but it's different from syncing. But that depends on how > much the ringing overlaps, maybe if it's short enough you won't get too much > phase cancellation. > > Perhaps what you're describing is similar to Xavier Rodet's FOF technique. > You're not misunderstanding at all! In actuality, I was trying to correctly (that is deterministically) bandlimit granular synthesis when it stroke me that the hard sync can be dealt like that as well! It's definitely nothing fancy and I'm sure one can find many similar techniques! It's just that i hadn't seen one treating the hard-sync problem like that. Yours, George Bezerianos > Brian > > > >> On Tue, Jun 9, 2009 at 2:40 PM, Vadim >> Zavalishin wrote: >>>> >>>> Now you filter this BLIT with the actual output of the slave >>>> oscillator (after reset). >>>> So consider the slave oscillator's output just an FIR filter. And >>>> let's take for example >>>> a sine slave oscillator for the sake of the conversation. Now, an >>>> infinitely long >>>> sine has a delayed (in frequency domain) impulse ?as a frequency >>>> response. >>>> However, a windowed period of a sine has a big fat lobe as a frequency >>>> response centered at >>>> where the impulse would be in the infinitely long case. _This_ causes >>>> the harmonics >>>> from the BLIT to leak - we have to shrink that lobe and the best way >>>> of course is >>>> to give our sine some space in time. This generalizes analogously to >>>> arbitary waveforms. >>> >>> Right, but how can we give our sine some space in time in the context of >>> hard-syncing? The window size is pretty much fixed to the period of the >>> master oscillator, isn't it? >>> >> >> That's what erroneously the article suggests - and that's why it's >> outdated. >> We have to let it ring more and of course increase overlapping and >> complexity, >> but with hugely better numerical accuracy than the generalized BLEP >> method. >> And it's really not that bad since with FIR interpolator for the BLIT >> is very vectorizable >> as i also describe in an earlier post. >> >> Now, the pseudo-C++ code i have in the article should make more sense >> to people also >> (it also hints some additional optimizations). >> >> However a good outcome is that even if you don't let the slave ring >> more you still >> get a harmonic output that doesn't alias because our BLIT takes care >> of that (that could be useful). >> >> Yours, >> >> George Bezerianos >> >>> Regards, >>> Vadim >>> >>> -- >>> Vadim Zavalishin >>> Senior Software Developer | R&D >>> >>> Tel +49-30-611035-0 >>> Fax +49-30-611035-2600 >>> >>> NATIVE INSTRUMENTS GmbH >>> Schlesische Str. 28 >>> 10997 Berlin, Germany >>> http://www.native-instruments.com >>> >>> Registergericht: Amtsgericht Charlottenburg >>> Registernummer: HRB 72458 >>> UST.-ID.-Nr. DE 20 374 7747 >>> Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic >>> >>> -- >>> dupswapdrop -- the music-dsp mailing list and website: subscription info, >>> FAQ, source code archive, list archive, book reviews, dsp links >>> http://music.columbia.edu/cmc/music-dsp >>> http://music.columbia.edu/mailman/listinfo/music-dsp >>> >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, source code archive, list archive, book reviews, >> dsp links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp >> > > -- > dupswapdrop -- the music-dsp mailing list and website:subscription info, > FAQ, source code archive, list archive, book reviews, dsp > linkshttp://music.columbia.edu/cmc/music-dsphttp://music.columbia.edu/mailman/listinfo/music-dsp > From gasmoa at gmail.com Tue Jun 9 09:48:06 2009 From: gasmoa at gmail.com (george bezerianos) Date: Tue Jun 9 09:48:16 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <241571D7265C48098AFB97BFB4A1B66B@nibln01077> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077> <3207FD2039D14A71BD7357AD0FA4B121@nibln01077> <4c23fbf70906090503m78b70fafi74a9569b7221344f@mail.gmail.com> <4c23fbf70906090516j71f17d9el83c1456449f5ebe1@mail.gmail.com> <4c23fbf70906090536x3b423fcay22b3e6016913d5d7@mail.gmail.com> <496643AF7AE64774BBA6CE1DB2CCF18A@nibln01077> <4c23fbf70906090548g1dca3c3u6aaeaf7bfbdf3824@mail.gmail.com> <7A2B789A-9E14-405F-96FA-5BFDFF3EB070@absyn.com> <241571D7265C48098AFB97BFB4A1B66B@nibln01077> Message-ID: <4c23fbf70906090648u16782bb4v6d1e1b346c666027@mail.gmail.com> On Tue, Jun 9, 2009 at 3:43 PM, Vadim Zavalishin wrote: > > >> Maybe I am misunderstanding you, but it sounds like a type of granular >> synthesis. By allowing the slave(s) to ring and overlap you will get >> frequency dependent phase cancellation/reinforcement. It's a musically >> interesting effect, but it's different from syncing. But that depends ?on >> how much the ringing overlaps, maybe if it's short enough you won't ?get too >> much phase cancellation. > > That's exactly my point. Also if the "ringing" is "short enough", then you > get strong spectrum distortion due to windowing, if it's long then it's not > syncing. > > Or, I must be missing something as well. > Well, the correct length of the ringing is currently an open question and i hardly have the time ;( Yours, George Bezerianos > Regards, > Vadim > > -- > Vadim Zavalishin > Senior Software Developer | R&D > > Tel +49-30-611035-0 > Fax +49-30-611035-2600 > > NATIVE INSTRUMENTS GmbH > Schlesische Str. 28 > 10997 Berlin, Germany > http://www.native-instruments.com > > Registergericht: Amtsgericht Charlottenburg > Registernummer: HRB 72458 > UST.-ID.-Nr. DE 20 374 7747 > Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription info, > FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From brian at absyn.com Tue Jun 9 10:00:06 2009 From: brian at absyn.com (Brian Clevinger) Date: Tue Jun 9 10:00:32 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <4c23fbf70906090645v30b9120dr4143d867271df49d@mail.gmail.com> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077> <4c23fbf70906090439v1fafa59fkae9feaa29aa5da0f@mail.gmail.com> <3207FD2039D14A71BD7357AD0FA4B121@nibln01077> <4c23fbf70906090503m78b70fafi74a9569b7221344f@mail.gmail.com> <4c23fbf70906090516j71f17d9el83c1456449f5ebe1@mail.gmail.com> <4c23fbf70906090536x3b423fcay22b3e6016913d5d7@mail.gmail.com> <496643AF7AE64774BBA6CE1DB2CCF18A@nibln01077> <4c23fbf70906090548g1dca3c3u6aaeaf7bfbdf3824@mail.gmail.com> <7A2B789A-9E14-405F-96FA-5BFDFF3EB070@absyn.com> <4c23fbf70906090645v30b9120dr4143d867271df49d@mail.gmail.com> Message-ID: This is an interesting idea, but it's not really sync anymore. The effect is pretty similar to playing an oscillator into a comb filter, with the frequency of the comb filter being the frequency of the slave oscillator. You'll get frequency dependent peaks and notches. But that's not what happens with an analog synth. Best, Brian > On Tue, Jun 9, 2009 at 3:36 PM, Brian Clevinger > wrote: >> Maybe I am misunderstanding you, but it sounds like a type of >> granular >> synthesis. By allowing the slave(s) to ring and overlap you will get >> frequency dependent phase cancellation/reinforcement. It's a >> musically >> interesting effect, but it's different from syncing. But that >> depends on how >> much the ringing overlaps, maybe if it's short enough you won't get >> too much >> phase cancellation. >> >> Perhaps what you're describing is similar to Xavier Rodet's FOF >> technique. >> > > You're not misunderstanding at all! In actuality, I was trying to > correctly (that is > deterministically) bandlimit granular synthesis when it stroke me > that the > hard sync can be dealt like that as well! It's definitely nothing > fancy and > I'm sure one can find many similar techniques! It's just that i > hadn't seen > one treating the hard-sync problem like that. > > Yours, > > George Bezerianos > >> Brian >> >> >> >>> On Tue, Jun 9, 2009 at 2:40 PM, Vadim >>> Zavalishin wrote: >>>>> >>>>> Now you filter this BLIT with the actual output of the slave >>>>> oscillator (after reset). >>>>> So consider the slave oscillator's output just an FIR filter. And >>>>> let's take for example >>>>> a sine slave oscillator for the sake of the conversation. Now, an >>>>> infinitely long >>>>> sine has a delayed (in frequency domain) impulse as a frequency >>>>> response. >>>>> However, a windowed period of a sine has a big fat lobe as a >>>>> frequency >>>>> response centered at >>>>> where the impulse would be in the infinitely long case. _This_ >>>>> causes >>>>> the harmonics >>>>> from the BLIT to leak - we have to shrink that lobe and the best >>>>> way >>>>> of course is >>>>> to give our sine some space in time. This generalizes >>>>> analogously to >>>>> arbitary waveforms. >>>> >>>> Right, but how can we give our sine some space in time in the >>>> context of >>>> hard-syncing? The window size is pretty much fixed to the period >>>> of the >>>> master oscillator, isn't it? >>>> >>> >>> That's what erroneously the article suggests - and that's why it's >>> outdated. >>> We have to let it ring more and of course increase overlapping and >>> complexity, >>> but with hugely better numerical accuracy than the generalized BLEP >>> method. >>> And it's really not that bad since with FIR interpolator for the >>> BLIT >>> is very vectorizable >>> as i also describe in an earlier post. >>> >>> Now, the pseudo-C++ code i have in the article should make more >>> sense >>> to people also >>> (it also hints some additional optimizations). >>> >>> However a good outcome is that even if you don't let the slave ring >>> more you still >>> get a harmonic output that doesn't alias because our BLIT takes care >>> of that (that could be useful). >>> >>> Yours, >>> >>> George Bezerianos >>> >>>> Regards, >>>> Vadim >>>> >>>> -- >>>> Vadim Zavalishin >>>> Senior Software Developer | R&D >>>> >>>> Tel +49-30-611035-0 >>>> Fax +49-30-611035-2600 >>>> >>>> NATIVE INSTRUMENTS GmbH >>>> Schlesische Str. 28 >>>> 10997 Berlin, Germany >>>> http://www.native-instruments.com >>>> >>>> Registergericht: Amtsgericht Charlottenburg >>>> Registernummer: HRB 72458 >>>> UST.-ID.-Nr. DE 20 374 7747 >>>> Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic >>>> >>>> -- >>>> dupswapdrop -- the music-dsp mailing list and website: >>>> subscription info, >>>> FAQ, source code archive, list archive, book reviews, dsp links >>>> http://music.columbia.edu/cmc/music-dsp >>>> http://music.columbia.edu/mailman/listinfo/music-dsp >>>> >>> -- >>> dupswapdrop -- the music-dsp mailing list and website: >>> subscription info, FAQ, source code archive, list archive, book >>> reviews, >>> dsp links >>> http://music.columbia.edu/cmc/music-dsp >>> http://music.columbia.edu/mailman/listinfo/music-dsp >>> >> >> -- >> dupswapdrop -- the music-dsp mailing list and website:subscription >> info, >> FAQ, source code archive, list archive, book reviews, dsp >> linkshttp://music.columbia.edu/cmc/music-dsphttp://music.columbia.edu/mailman/listinfo/music-dsp >> > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book > reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From gasmoa at gmail.com Tue Jun 9 10:57:57 2009 From: gasmoa at gmail.com (george bezerianos) Date: Tue Jun 9 10:58:11 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077> <4c23fbf70906090503m78b70fafi74a9569b7221344f@mail.gmail.com> <4c23fbf70906090516j71f17d9el83c1456449f5ebe1@mail.gmail.com> <4c23fbf70906090536x3b423fcay22b3e6016913d5d7@mail.gmail.com> <496643AF7AE64774BBA6CE1DB2CCF18A@nibln01077> <4c23fbf70906090548g1dca3c3u6aaeaf7bfbdf3824@mail.gmail.com> <7A2B789A-9E14-405F-96FA-5BFDFF3EB070@absyn.com> <4c23fbf70906090645v30b9120dr4143d867271df49d@mail.gmail.com> Message-ID: <4c23fbf70906090757j6f0c350bq2a5e1abb91fe1ff1@mail.gmail.com> On Tue, Jun 9, 2009 at 4:00 PM, Brian Clevinger wrote: > This is an interesting idea, but it's not really sync anymore. The effect is > pretty similar to playing an oscillator into a comb filter, with the > frequency of the comb filter being the frequency of the slave oscillator. > You'll get frequency dependent ?peaks and notches. But that's not what > happens with an analog synth. > But the length of the slave oscillator will definitely depend on the master frequency which is not the case of your example where i assume the comb filter's IR length is not varying depending on the input oscillator's frequency - in our case the slave oscillator _has to end at the same phase as the sync point suggests_: that means we can only extend in terms of number of periods. The motivation behind that is that the method (as in the article) behaves as not wanted (harmonic leakage) when the slave oscillator's frequency is not much higher than the master's - if between two resets the slave rings many periods the harmonic artifacts are much less we have a very good approximation of the arbitrary waveform sync as one can easily check. Problems begin when the slave oscillator drops in frequency and approaches that of the master. And thinking about it it makes more sense now and we can check the intuition: * find that slave oscillator frequency (f_sl) >> master oscillator frequency ( f_ms) such that the harmonics are attenuated sufficiently (in our case when they fall under the BLIT interpolator's threshold). * 1 / f_sl is the minimum number of periods the slave oscillator has to ring in order for the harmonics to stay down there. We _have_ sync since the final phase of the slave oscillator is consistent with the reset point, we extend only in terms of periods and we set a minimum amount! I think we're there! Please feedback! Yours, George Bezerianos > Best, > Brian > > >> On Tue, Jun 9, 2009 at 3:36 PM, Brian Clevinger wrote: >>> >>> Maybe I am misunderstanding you, but it sounds like a type of granular >>> synthesis. By allowing the slave(s) to ring and overlap you will get >>> frequency dependent phase cancellation/reinforcement. It's a musically >>> interesting effect, but it's different from syncing. But that depends on >>> how >>> much the ringing overlaps, maybe if it's short enough you won't get too >>> much >>> phase cancellation. >>> >>> Perhaps what you're describing is similar to Xavier Rodet's FOF >>> technique. >>> >> >> You're not misunderstanding at all! In actuality, I was trying to >> correctly (that is >> deterministically) bandlimit granular synthesis when it stroke me that the >> hard sync can be dealt like that as well! It's definitely nothing fancy >> and >> I'm sure one can find many similar techniques! It's just that i hadn't >> seen >> one treating the hard-sync problem like that. >> >> Yours, >> >> George Bezerianos >> >>> Brian >>> >>> >>> >>>> On Tue, Jun 9, 2009 at 2:40 PM, Vadim >>>> Zavalishin wrote: >>>>>> >>>>>> Now you filter this BLIT with the actual output of the slave >>>>>> oscillator (after reset). >>>>>> So consider the slave oscillator's output just an FIR filter. And >>>>>> let's take for example >>>>>> a sine slave oscillator for the sake of the conversation. Now, an >>>>>> infinitely long >>>>>> sine has a delayed (in frequency domain) impulse ?as a frequency >>>>>> response. >>>>>> However, a windowed period of a sine has a big fat lobe as a frequency >>>>>> response centered at >>>>>> where the impulse would be in the infinitely long case. _This_ causes >>>>>> the harmonics >>>>>> from the BLIT to leak - we have to shrink that lobe and the best way >>>>>> of course is >>>>>> to give our sine some space in time. This generalizes analogously to >>>>>> arbitary waveforms. >>>>> >>>>> Right, but how can we give our sine some space in time in the context >>>>> of >>>>> hard-syncing? The window size is pretty much fixed to the period of the >>>>> master oscillator, isn't it? >>>>> >>>> >>>> That's what erroneously the article suggests - and that's why it's >>>> outdated. >>>> We have to let it ring more and of course increase overlapping and >>>> complexity, >>>> but with hugely better numerical accuracy than the generalized BLEP >>>> method. >>>> And it's really not that bad since with FIR interpolator for the BLIT >>>> is very vectorizable >>>> as i also describe in an earlier post. >>>> >>>> Now, the pseudo-C++ code i have in the article should make more sense >>>> to people also >>>> (it also hints some additional optimizations). >>>> >>>> However a good outcome is that even if you don't let the slave ring >>>> more you still >>>> get a harmonic output that doesn't alias because our BLIT takes care >>>> of that (that could be useful). >>>> >>>> Yours, >>>> >>>> George Bezerianos >>>> >>>>> Regards, >>>>> Vadim >>>>> >>>>> -- >>>>> Vadim Zavalishin >>>>> Senior Software Developer | R&D >>>>> >>>>> Tel +49-30-611035-0 >>>>> Fax +49-30-611035-2600 >>>>> >>>>> NATIVE INSTRUMENTS GmbH >>>>> Schlesische Str. 28 >>>>> 10997 Berlin, Germany >>>>> http://www.native-instruments.com >>>>> >>>>> Registergericht: Amtsgericht Charlottenburg >>>>> Registernummer: HRB 72458 >>>>> UST.-ID.-Nr. DE 20 374 7747 >>>>> Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic >>>>> >>>>> -- >>>>> dupswapdrop -- the music-dsp mailing list and website: subscription >>>>> info, >>>>> FAQ, source code archive, list archive, book reviews, dsp links >>>>> http://music.columbia.edu/cmc/music-dsp >>>>> http://music.columbia.edu/mailman/listinfo/music-dsp >>>>> >>>> -- >>>> dupswapdrop -- the music-dsp mailing list and website: >>>> subscription info, FAQ, source code archive, list archive, book reviews, >>>> dsp links >>>> http://music.columbia.edu/cmc/music-dsp >>>> http://music.columbia.edu/mailman/listinfo/music-dsp >>>> >>> >>> -- >>> dupswapdrop -- the music-dsp mailing list and website:subscription info, >>> FAQ, source code archive, list archive, book reviews, dsp >>> >>> linkshttp://music.columbia.edu/cmc/music-dsphttp://music.columbia.edu/mailman/listinfo/music-dsp >>> >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, source code archive, list archive, book reviews, >> dsp links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp >> > > -- > dupswapdrop -- the music-dsp mailing list and website:subscription info, > FAQ, source code archive, list archive, book reviews, dsp > linkshttp://music.columbia.edu/cmc/music-dsphttp://music.columbia.edu/mailman/listinfo/music-dsp > From vadim.zavalishin at native-instruments.de Tue Jun 9 11:14:52 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Tue Jun 9 11:15:11 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <4c23fbf70906090757j6f0c350bq2a5e1abb91fe1ff1@mail.gmail.com> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077><4c23fbf70906090503m78b70fafi74a9569b7221344f@mail.gmail.com><4c23fbf70906090516j71f17d9el83c1456449f5ebe1@mail.gmail.com><4c23fbf70906090536x3b423fcay22b3e6016913d5d7@mail.gmail.com><496643AF7AE64774BBA6CE1DB2CCF18A@nibln01077><4c23fbf70906090548g1dca3c3u6aaeaf7bfbdf3824@mail.gmail.com><7A2B789A-9E14-405F-96FA-5BFDFF3EB070@absyn.com><4c23fbf70906090645v30b9120dr4143d867271df49d@mail.gmail.com> <4c23fbf70906090757j6f0c350bq2a5e1abb91fe1ff1@mail.gmail.com> Message-ID: >We _have_ sync since the final phase of the slave oscillator is >consistent with the reset point, we extend only in terms of periods >and we set a minimum amount! > >I think we're there! Please feedback! The sync in the classical sense, is when you have a continuously sounding single slave oscillator and it's phase is reset periodically by the master oscillator. No overlapping. Calling anything else sync is a terminological thing, you probably might if you have a reason to, but it's not the classical meaning. Now in that respect a discrete-time algorithm can be said to implement the sync, if it produces an output identical to the continuous-time sync (except for bandlimiting). Of course, as it is common is DSP, certain spectral deviations (aliasing) may be acceptable, but the goal is still as previously defined. What you are doing (if I'm understanding it correctly), as Brian pointed out, probably falls more under the category of granular synthesis. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From gasmoa at gmail.com Tue Jun 9 11:20:18 2009 From: gasmoa at gmail.com (george bezerianos) Date: Tue Jun 9 11:20:36 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <4c23fbf70906090757j6f0c350bq2a5e1abb91fe1ff1@mail.gmail.com> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077> <4c23fbf70906090516j71f17d9el83c1456449f5ebe1@mail.gmail.com> <4c23fbf70906090536x3b423fcay22b3e6016913d5d7@mail.gmail.com> <496643AF7AE64774BBA6CE1DB2CCF18A@nibln01077> <4c23fbf70906090548g1dca3c3u6aaeaf7bfbdf3824@mail.gmail.com> <7A2B789A-9E14-405F-96FA-5BFDFF3EB070@absyn.com> <4c23fbf70906090645v30b9120dr4143d867271df49d@mail.gmail.com> <4c23fbf70906090757j6f0c350bq2a5e1abb91fe1ff1@mail.gmail.com> Message-ID: <4c23fbf70906090820j20af40ecof4cd83fb3f2fe96e@mail.gmail.com> And yes! In case the period calculated with the aforementioned algorithm is fractional we just sync the final phase of the slave accordingly. That is we only modify the length of the slave oscillator in the interval [1/f_sl 1/f_sl+1]. Where f_sl is calculated as with the previous algorithm. Yours, George Bezerianos On Tue, Jun 9, 2009 at 4:57 PM, george bezerianos wrote: > On Tue, Jun 9, 2009 at 4:00 PM, Brian Clevinger wrote: >> This is an interesting idea, but it's not really sync anymore. The effect is >> pretty similar to playing an oscillator into a comb filter, with the >> frequency of the comb filter being the frequency of the slave oscillator. >> You'll get frequency dependent ?peaks and notches. But that's not what >> happens with an analog synth. >> > > But the length of the slave oscillator will definitely depend on the > master frequency which is not the case of your example where i assume > the comb filter's IR length is not varying depending on the input > oscillator's frequency - in our case the slave oscillator _has to end > at the same phase as the sync point suggests_: that means we can only > extend in terms of number of periods. The motivation behind that is > that the method (as in the article) behaves as not wanted (harmonic > leakage) when the slave oscillator's frequency is not much higher than > the master's - if between two resets the slave rings many periods the > harmonic artifacts are much less we have a very good approximation of > the arbitrary waveform sync as one can easily check. Problems begin > when the slave oscillator drops in frequency and approaches that of > the master. And thinking about it it makes more sense now and we can > check the intuition: > > * find that slave oscillator frequency (f_sl) >> master oscillator > frequency ( f_ms) such that the harmonics are attenuated sufficiently > (in our case when they fall under the BLIT interpolator's threshold). > * 1 / f_sl is the minimum number of periods the slave oscillator has > to ring in order for the harmonics to stay down there. > > We _have_ sync since the final phase of the slave oscillator is > consistent with the reset point, we extend only in terms of periods > and we set a minimum amount! > > I think we're there! Please feedback! > > Yours, > > George Bezerianos > >> Best, >> Brian >> >> >>> On Tue, Jun 9, 2009 at 3:36 PM, Brian Clevinger wrote: >>>> >>>> Maybe I am misunderstanding you, but it sounds like a type of granular >>>> synthesis. By allowing the slave(s) to ring and overlap you will get >>>> frequency dependent phase cancellation/reinforcement. It's a musically >>>> interesting effect, but it's different from syncing. But that depends on >>>> how >>>> much the ringing overlaps, maybe if it's short enough you won't get too >>>> much >>>> phase cancellation. >>>> >>>> Perhaps what you're describing is similar to Xavier Rodet's FOF >>>> technique. >>>> >>> >>> You're not misunderstanding at all! In actuality, I was trying to >>> correctly (that is >>> deterministically) bandlimit granular synthesis when it stroke me that the >>> hard sync can be dealt like that as well! It's definitely nothing fancy >>> and >>> I'm sure one can find many similar techniques! It's just that i hadn't >>> seen >>> one treating the hard-sync problem like that. >>> >>> Yours, >>> >>> George Bezerianos >>> >>>> Brian >>>> >>>> >>>> >>>>> On Tue, Jun 9, 2009 at 2:40 PM, Vadim >>>>> Zavalishin wrote: >>>>>>> >>>>>>> Now you filter this BLIT with the actual output of the slave >>>>>>> oscillator (after reset). >>>>>>> So consider the slave oscillator's output just an FIR filter. And >>>>>>> let's take for example >>>>>>> a sine slave oscillator for the sake of the conversation. Now, an >>>>>>> infinitely long >>>>>>> sine has a delayed (in frequency domain) impulse ?as a frequency >>>>>>> response. >>>>>>> However, a windowed period of a sine has a big fat lobe as a frequency >>>>>>> response centered at >>>>>>> where the impulse would be in the infinitely long case. _This_ causes >>>>>>> the harmonics >>>>>>> from the BLIT to leak - we have to shrink that lobe and the best way >>>>>>> of course is >>>>>>> to give our sine some space in time. This generalizes analogously to >>>>>>> arbitary waveforms. >>>>>> >>>>>> Right, but how can we give our sine some space in time in the context >>>>>> of >>>>>> hard-syncing? The window size is pretty much fixed to the period of the >>>>>> master oscillator, isn't it? >>>>>> >>>>> >>>>> That's what erroneously the article suggests - and that's why it's >>>>> outdated. >>>>> We have to let it ring more and of course increase overlapping and >>>>> complexity, >>>>> but with hugely better numerical accuracy than the generalized BLEP >>>>> method. >>>>> And it's really not that bad since with FIR interpolator for the BLIT >>>>> is very vectorizable >>>>> as i also describe in an earlier post. >>>>> >>>>> Now, the pseudo-C++ code i have in the article should make more sense >>>>> to people also >>>>> (it also hints some additional optimizations). >>>>> >>>>> However a good outcome is that even if you don't let the slave ring >>>>> more you still >>>>> get a harmonic output that doesn't alias because our BLIT takes care >>>>> of that (that could be useful). >>>>> >>>>> Yours, >>>>> >>>>> George Bezerianos >>>>> >>>>>> Regards, >>>>>> Vadim >>>>>> >>>>>> -- >>>>>> Vadim Zavalishin >>>>>> Senior Software Developer | R&D >>>>>> >>>>>> Tel +49-30-611035-0 >>>>>> Fax +49-30-611035-2600 >>>>>> >>>>>> NATIVE INSTRUMENTS GmbH >>>>>> Schlesische Str. 28 >>>>>> 10997 Berlin, Germany >>>>>> http://www.native-instruments.com >>>>>> >>>>>> Registergericht: Amtsgericht Charlottenburg >>>>>> Registernummer: HRB 72458 >>>>>> UST.-ID.-Nr. DE 20 374 7747 >>>>>> Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic >>>>>> >>>>>> -- >>>>>> dupswapdrop -- the music-dsp mailing list and website: subscription >>>>>> info, >>>>>> FAQ, source code archive, list archive, book reviews, dsp links >>>>>> http://music.columbia.edu/cmc/music-dsp >>>>>> http://music.columbia.edu/mailman/listinfo/music-dsp >>>>>> >>>>> -- >>>>> dupswapdrop -- the music-dsp mailing list and website: >>>>> subscription info, FAQ, source code archive, list archive, book reviews, >>>>> dsp links >>>>> http://music.columbia.edu/cmc/music-dsp >>>>> http://music.columbia.edu/mailman/listinfo/music-dsp >>>>> >>>> >>>> -- >>>> dupswapdrop -- the music-dsp mailing list and website:subscription info, >>>> FAQ, source code archive, list archive, book reviews, dsp >>>> >>>> linkshttp://music.columbia.edu/cmc/music-dsphttp://music.columbia.edu/mailman/listinfo/music-dsp >>>> >>> -- >>> dupswapdrop -- the music-dsp mailing list and website: >>> subscription info, FAQ, source code archive, list archive, book reviews, >>> dsp links >>> http://music.columbia.edu/cmc/music-dsp >>> http://music.columbia.edu/mailman/listinfo/music-dsp >>> >> >> -- >> dupswapdrop -- the music-dsp mailing list and website:subscription info, >> FAQ, source code archive, list archive, book reviews, dsp >> linkshttp://music.columbia.edu/cmc/music-dsphttp://music.columbia.edu/mailman/listinfo/music-dsp >> > From gasmoa at gmail.com Tue Jun 9 11:37:18 2009 From: gasmoa at gmail.com (george bezerianos) Date: Tue Jun 9 11:37:33 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077> <4c23fbf70906090536x3b423fcay22b3e6016913d5d7@mail.gmail.com> <496643AF7AE64774BBA6CE1DB2CCF18A@nibln01077> <4c23fbf70906090548g1dca3c3u6aaeaf7bfbdf3824@mail.gmail.com> <7A2B789A-9E14-405F-96FA-5BFDFF3EB070@absyn.com> <4c23fbf70906090645v30b9120dr4143d867271df49d@mail.gmail.com> <4c23fbf70906090757j6f0c350bq2a5e1abb91fe1ff1@mail.gmail.com> Message-ID: <4c23fbf70906090837o6f5d0b24n54ea5e7428f23784@mail.gmail.com> On Tue, Jun 9, 2009 at 5:14 PM, Vadim Zavalishin wrote: >> We _have_ sync since the final phase of the slave oscillator is >> consistent with the reset point, we extend only in terms of periods >> and we set a minimum amount! >> >> I think we're there! Please feedback! > > The sync in the classical sense, is when you have a continuously sounding > single slave oscillator and it's phase is reset periodically by the master > oscillator. No overlapping. Calling anything else sync is a terminological > thing, you probably might if you have a reason to, but it's not the > classical meaning. Heh, instead of sticking with terminology I would check the algorithm i just spit out - it should take 5 minutes in Reaktor wouldn't it? Now in that respect a discrete-time algorithm can be said > to implement the sync, if it produces an output identical to the > continuous-time sync (except for bandlimiting). Of course, as it is common > is DSP, certain spectral deviations (aliasing) may be acceptable, but the > goal is still as previously defined. > > What you are doing (if I'm understanding it correctly), as Brian pointed > out, probably falls more under the category of granular synthesis. > I don't know how to interpret the fact that you ignore the most significant parts of my posts anymore. I just provided an algorithm that is actually far from just granular synthesis and a rather specific formula to calculate the length of the slave oscillator. It also shows that overlapping occurs only _under_ a specific frequency - for sufficiently higher slave oscillator frequency than the master the syncing happens where you would expect it to and as it is already pointed out in the article. But as i just conceived it I found a problem: we need a way to extend by one whole period smoothly without changing the ending phase point - this requires some interpolation between 2 duplicates of the slave oscillator (that _both_ end at the same phase that's dictated by the sync point) that have exactly one period in length difference - and that's how one should extend the periods. Hopefully period. ;) Yours, George Bezerianos > Regards, > Vadim > > -- > Vadim Zavalishin > Senior Software Developer | R&D > > Tel +49-30-611035-0 > Fax +49-30-611035-2600 > > NATIVE INSTRUMENTS GmbH > Schlesische Str. 28 > 10997 Berlin, Germany > http://www.native-instruments.com > > Registergericht: Amtsgericht Charlottenburg > Registernummer: HRB 72458 > UST.-ID.-Nr. DE 20 374 7747 > Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription info, > FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From martin.eisenberg at udo.edu Tue Jun 9 11:48:01 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Tue Jun 9 11:45:39 2009 Subject: [music-dsp] Name of delay-free loop technique References: <002401c9d7d1$0aee5ce0$0201a8c0@mooncode><56BDCC96E6B94AF5BC7DF68F893A63C1@nibln01077><001201c9d8a6$2f916bc0$0201a8c0@mooncode><001201c9dca5$332d6f60$0201a8c0@mooncode><86DBA60A6D954C829C23571C46248EFE@nibln01077><029244E7BAD549C78B29E3DAB113FC06@nibln01077><000a01c9e21b$441cc3e0$0201a8c0@mooncode><003b01c9e383$904dab80$0201a8c0@mooncode><000d01c9e884$b65c5000$0201a8c0@mooncode> <3C6F181C0CF441569186A2D2550FF0DC@nibln01077> Message-ID: <007401c9e919$b01b4080$0201a8c0@mooncode> Vadim Zavalishin wrote: >>> Instantaneously unstable cases >>> will correspond to the horizontally-reverted graph of >>> g*tanh(x-ky), where the graph's steepness (derivative) must >>> exceed 1, in which case the system "wants" to go into the >>> opposite direction of the intersection of the h(y)=y-s and >>> the nonlinearity's tangent line (I think). >> I'd guess you do because that >> interpretation does make the selection unique; namely, the >> solution jumps from one outside branch of the multivalued >> inverse function to the other as soon as the input enters the >> latter's support. Is that what you're saying? > > I can't really picture what you mean by the support of the > multivalued inverse function branch here. I have some guesses, > but can you be more specific, which function do you mean? The equation to be solved can be rewritten to isolate x as an explicit function of y, and we basically seek the inverse of that (which, as you note, generally has no closed form). In the present case the function is not injective and the inverse relation is the union of three functions with restricted domains (yes, that's the word). I asked because I remember reading, and you seem to be saying too, that such dynamical systems evolve continuously as long as possible and only jump to another branch of the inverse relation when the current branch ceases to exist, at which point only one solution candidate remains. Does your description at the top imply that behavior? Martin From vadim.zavalishin at native-instruments.de Tue Jun 9 11:58:37 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Tue Jun 9 11:58:52 2009 Subject: [music-dsp] Name of delay-free loop technique In-Reply-To: <007401c9e919$b01b4080$0201a8c0@mooncode> References: <002401c9d7d1$0aee5ce0$0201a8c0@mooncode><56BDCC96E6B94AF5BC7DF68F893A63C1@nibln01077><001201c9d8a6$2f916bc0$0201a8c0@mooncode><001201c9dca5$332d6f60$0201a8c0@mooncode><86DBA60A6D954C829C23571C46248EFE@nibln01077><029244E7BAD549C78B29E3DAB113FC06@nibln01077><000a01c9e21b$441cc3e0$0201a8c0@mooncode><003b01c9e383$904dab80$0201a8c0@mooncode><000d01c9e884$b65c5000$0201a8c0@mooncode><3C6F181C0CF441569186A2D2550FF0DC@nibln01077> <007401c9e919$b01b4080$0201a8c0@mooncode> Message-ID: <447609066BA049579EDAED086F0E582D@nibln01077> > > I asked because I remember reading, and you seem to be saying > too, that such dynamical systems evolve continuously as long as > possible and only jump to another branch of the inverse relation > when the current branch ceases to exist, at which point only one > solution candidate remains. Does your description at the top > imply that behavior? I don't think so. I also don't think I said anything like that. The choice rule is not based on the idea of the "current branch ceasing to exist", at least not explicitly. Maybe there is some equivalence to that, but I doubt it. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From vadim.zavalishin at native-instruments.de Tue Jun 9 12:00:23 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Tue Jun 9 12:00:37 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <4c23fbf70906090837o6f5d0b24n54ea5e7428f23784@mail.gmail.com> References: <0EFCCB1E97774447AA27CB0B147376E3@nibln01077><4c23fbf70906090536x3b423fcay22b3e6016913d5d7@mail.gmail.com><496643AF7AE64774BBA6CE1DB2CCF18A@nibln01077><4c23fbf70906090548g1dca3c3u6aaeaf7bfbdf3824@mail.gmail.com><7A2B789A-9E14-405F-96FA-5BFDFF3EB070@absyn.com><4c23fbf70906090645v30b9120dr4143d867271df49d@mail.gmail.com><4c23fbf70906090757j6f0c350bq2a5e1abb91fe1ff1@mail.gmail.com> <4c23fbf70906090837o6f5d0b24n54ea5e7428f23784@mail.gmail.com> Message-ID: <55098C310C4149FC9DC1146744782DA2@nibln01077> > Heh, instead of sticking with terminology I would check the algorithm > i just spit out - it should take 5 minutes in Reaktor wouldn't it? I agree, your work is interesting, but aside from syncing possibilities, it lies somewhat outside of my main music DSP interests (that was also the reason I was so picky about the sync part). Building a Reaktor prototype would probably take more than 5 minutes even if I had a full understanding of your algorithm (although that totally depends on the blocks which are already available). > I don't know how to interpret the fact that you ignore the most > significant parts of my posts anymore. I guess the significance is a personal issue here. As I wrote my main interests in respect to your work are related to the emulation of the analog sync. This should not be taken as if I think your work has no value, it's simply not lying within my immediate field of interest. > I just provided an algorithm > that is actually far from just granular synthesis and a rather > specific formula to calculate the length of the slave oscillator. It > also shows that overlapping occurs only _under_ a specific frequency - > for sufficiently higher slave oscillator frequency than the master the > syncing happens where you would expect it to and as it is already > pointed out in the article. It is not uncommon to have the frequency of the slave oscillator close to the one of the master. In that respect I don't know how to take that "only" in "only under a specific frequency". Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From vadim.zavalishin at native-instruments.de Tue Jun 9 12:11:19 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Tue Jun 9 12:11:33 2009 Subject: [music-dsp] Name of delay-free loop technique In-Reply-To: <007401c9e919$b01b4080$0201a8c0@mooncode> References: <002401c9d7d1$0aee5ce0$0201a8c0@mooncode><56BDCC96E6B94AF5BC7DF68F893A63C1@nibln01077><001201c9d8a6$2f916bc0$0201a8c0@mooncode><001201c9dca5$332d6f60$0201a8c0@mooncode><86DBA60A6D954C829C23571C46248EFE@nibln01077><029244E7BAD549C78B29E3DAB113FC06@nibln01077><000a01c9e21b$441cc3e0$0201a8c0@mooncode><003b01c9e383$904dab80$0201a8c0@mooncode><000d01c9e884$b65c5000$0201a8c0@mooncode><3C6F181C0CF441569186A2D2550FF0DC@nibln01077> <007401c9e919$b01b4080$0201a8c0@mooncode> Message-ID: <773883D88A634A95B8C667510346899C@nibln01077> > I asked because I remember reading, and you seem to be saying > too, that such dynamical systems evolve continuously as long as > possible and only jump to another branch of the inverse relation > when the current branch ceases to exist, at which point only one > solution candidate remains. Does your description at the top > imply that behavior? An additional thought: I'm not sure the thing you mentioned about the dynamic systems is fully applicable here. Particularly since the starting value of y is not satisfying the equations. That might be different should we have been analysing "instantenous feedback" in a continuous time system *with continuous input signal and parameters*, but again I wouldn't be sure. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From martin.eisenberg at udo.edu Tue Jun 9 12:17:27 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Tue Jun 9 12:14:48 2009 Subject: [music-dsp] Ripple specification for Chebyshev Type I Low Shelf? References: <794796.53796.qm@web58202.mail.re3.yahoo.com> Message-ID: <007c01c9e91d$cb960620$0201a8c0@mooncode> Vinnie wrote: > When ripple exceeds the gain I just want to set the ripple > equal to the gain. When gain and ripple are too similar the response can't really be said to be "close" to the gain anymore. That's why Orfanidis talks about reducing ripple (bringing G and Gb closer together) if G approaches G0 in section 7. > what do I do when both the gain and the ripple are 0 dB > (i.e. the identity filter)? Generate no roots at all. This should result in setting coefficients that produce the identity exactly. Martin From martin.eisenberg at udo.edu Tue Jun 9 12:56:48 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Tue Jun 9 12:54:15 2009 Subject: [music-dsp] Name of delay-free loop technique References: <002401c9d7d1$0aee5ce0$0201a8c0@mooncode><56BDCC96E6B94AF5BC7DF68F893A63C1@nibln01077><001201c9d8a6$2f916bc0$0201a8c0@mooncode><001201c9dca5$332d6f60$0201a8c0@mooncode><86DBA60A6D954C829C23571C46248EFE@nibln01077><029244E7BAD549C78B29E3DAB113FC06@nibln01077><000a01c9e21b$441cc3e0$0201a8c0@mooncode><003b01c9e383$904dab80$0201a8c0@mooncode><000d01c9e884$b65c5000$0201a8c0@mooncode><3C6F181C0CF441569186A2D2550FF0DC@nibln01077><007401c9e919$b01b4080$0201a8c0@mooncode> <447609066BA049579EDAED086F0E582D@nibln01077> Message-ID: <002c01c9e923$4d20eb60$0201a8c0@mooncode> Vadim Zavalishin wrote: >> I asked because I remember reading, and you seem to be >> saying too, that such dynamical systems evolve continuously >> as long as possible and only jump to another branch of the >> inverse relation when the current branch ceases to exist, at >> which point only one solution candidate remains. Does your >> description at the top imply that behavior? > > I don't think so. I also don't think I said anything like > that. What kind of continuity have you referred to in this quote--? >>> Anyway, what makes the selection unique - is the forced >>> continuity of the output value by the lowpass filter, which >>> allows to determine the direction in which the value is going >>> to "move". I believe that's basically the argument in the literature I alluded to but can't locate at the moment, regarding why the hysteresis loop is traversed one way around and not the other. > An additional thought: I'm not sure the thing you mentioned > about the dynamic systems is fully applicable here. > Particularly since the starting value of y is not satisfying > the equations. That's a problem discretization always brings about, isn't it? In a linear system, y[n-1] won't satisfy the recurrence at n either without rendering the system unrelated to the original dynamics. > That might be different should we have been analysing > "instantenous feedback" in a continuous time system > *with continuous input signal and parameters*, but again I > wouldn't be sure. Well, you've been the one to emphasize faithfulness to the continuous-time behavior. I'm just trying to see whether your reasoning might lead to unphysical results. Martin From thevinn at yahoo.com Tue Jun 9 13:42:06 2009 From: thevinn at yahoo.com (Vinnie) Date: Tue Jun 9 13:42:24 2009 Subject: [music-dsp] Prewarping formula for bandpass transformation? Message-ID: <519218.20181.qm@web58202.mail.re3.yahoo.com> I added a normalization structure (containing angular frequency and target gain) to my analog prototypes. For a low pass prototype, normalizing angular frequency w=0 since that is where we expect unity gain (the cascade computes a scale factor from the filter response at w). For the low shelf, angular frequency w=kPi for the same reason (the shelf moves up and down at w=0 on a low shelf). In order to generalize filter transformations (which by the way is coming along excellently as per Martin's suggestion to allow infinities to be represented in lists of s-plane roots), the transformation needs to not only transform the s-plane roots but also the normalization information. For a low pass to low pass, w'=w. For high pass, w'=PI-w. But what do we do about the band pass? I'm using a traditional band pass transformation. I have a formula but it is hard coded to find the geometric mean of the corner frequencies. This works great for a regular band pass filter but it fails for the case of a peaking/eq filter - the eq filter is contructed by using a band-pass transformation on a low shelf prototype. So what I am looking for is a formula that will transform the frequency in the original analog prototype (low shelf in this case, with w=pi) into a new location where I can sample the filter. Thanks! From mailbjl at yahoo.com Tue Jun 9 14:26:02 2009 From: mailbjl at yahoo.com (Brent Lehman) Date: Tue Jun 9 14:26:15 2009 Subject: [music-dsp] Prewarping formula for bandpass transformation? Message-ID: <234933.44719.qm@web51710.mail.re2.yahoo.com> I don't know if this helps with your normalization needs, but I do know that you can turn a lowpass into a bandpass by multiplying the coefficients by cosine values. If the coefficients of a filter are c[k] and the response is C(w), the response of 2*cos(kf)*c[k] will be something like C(w+f)+C(w-f). In the case of a lowpass, where you had one peak at w=0, now you have peaks at w=-f and w=+f. --- On Tue, 6/9/09, Vinnie wrote: > From: Vinnie > Subject: [music-dsp] Prewarping formula for bandpass transformation? > To: music-dsp@music.columbia.edu > Date: Tuesday, June 9, 2009, 10:42 AM > > I added a normalization structure (containing angular > frequency and target gain) to my analog prototypes. For a > low pass prototype, normalizing angular frequency w=0 since > that is where we expect unity gain (the cascade computes a > scale factor from the filter response at w). > > For the low shelf, angular frequency w=kPi for the same > reason (the shelf moves up and down at w=0 on a low shelf). > > In order to generalize filter transformations (which by the > way is coming along excellently as per Martin's suggestion > to allow infinities to be represented in lists of s-plane > roots), the transformation needs to not only transform the > s-plane roots but also the normalization information. > > For a low pass to low pass, w'=w. For high pass, w'=PI-w. > But what do we do about the band pass? I'm using a > traditional band pass transformation. I have a formula but > it is hard coded to find the geometric mean of the corner > frequencies. This works great for a regular band pass filter > but it fails for the case of a peaking/eq filter - the eq > filter is contructed by using a band-pass transformation on > a low shelf prototype. > > So what I am looking for is a formula that will transform > the frequency in the original analog prototype (low shelf in > this case, with w=pi) into a new location where I can sample > the filter. > > Thanks! > > > > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, > book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From andy at korgrd.com Tue Jun 9 14:32:43 2009 From: andy at korgrd.com (Andy Leary) Date: Tue Jun 9 14:32:59 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <20090609042659.CCFD597F295@music.columbia.edu> References: <20090609042659.CCFD597F295@music.columbia.edu> Message-ID: <62C47C79-95F0-4985-9B4A-237F3F11646B@korgrd.com> On Jun 8, 2009, at 9:26 PM, robert bristow-johnson wrote: > > i've known about BLITs and understood how they can be used to drive > an appropriate filter to generate virtually arbitrary *and* > bandlimited waveforms, but i have always failed to see the advantage > over wavetable synthesis in terms of complexity or cost. > ...... that's > much less computation than running a BLIT through a filter which is > why i > sometimes question the point of it. it's not the first time i have. For Hard Sync, BLEP type implementations give the best sounding results for the fewest cycles that I have found. If you are trying to do FM with "analog" waveforms and if you want hard sync, wavetable isn't going to work without adding BLEPs anyway. If all you want is a band limited sawtooth and you don't need sync, then wavetable is fine, but simple BLEP related optimizations make this case relatively cheap. That being said.... there's some cool things left to do with wavetable yet..... :-) Andy Leary andy@korgrd.com From andy at korgrd.com Tue Jun 9 14:39:24 2009 From: andy at korgrd.com (Andy Leary) Date: Tue Jun 9 14:39:49 2009 Subject: [music-dsp] Re: music-dsp Digest, Vol 66, Issue 28 In-Reply-To: <20090609042659.CCFD597F295@music.columbia.edu> References: <20090609042659.CCFD597F295@music.columbia.edu> Message-ID: <90CC3E56-128B-4C07-8E48-501AD97D94FA@korgrd.com> On Jun 8, 2009, at 9:26 PM, robert bristow-johnson wrote: > > i've known about BLITs and understood how they can be used to drive > an appropriate filter to generate virtually arbitrary *and* > bandlimited waveforms, but i have always failed to see the advantage > over wavetable synthesis in terms of complexity or cost. > ...... that's > much less computation than running a BLIT through a filter which is > why i > sometimes question the point of it. it's not the first time i have. For Hard Sync, BLEP type implementations give the best sounding results for the fewest cycles that I have found. If you are trying to do FM with "analog" waveforms and if you want hard sync, wavetable isn't going to work without adding BLEPs anyway. If all you want is a band limited sawtooth and you don't need sync, then wavetable is fine, but simple BLEP related optimizations make this case relatively cheap. That being said.... there's some cool things left to do with wavetable yet..... :-) Andy Leary andy@korgrd.com From thevinn at yahoo.com Tue Jun 9 15:23:53 2009 From: thevinn at yahoo.com (Vinnie) Date: Tue Jun 9 15:24:04 2009 Subject: [music-dsp] DspFilters open-source library v0.8.5 Message-ID: <519798.7862.qm@web58201.mail.re3.yahoo.com> "A Collection of Useful C++ Classes for Digital Signal Processing" Updated to version 0.8.5 available here (MIT license): In order to move forward with this library I had to learn the math behind each filter so I could re-implement it to have the features and properties I wanted. The generation of poles and zeroes has been mostly re-written, and the method of construction changed so no more 'pilfered code' (*cough* Martin). I was able to rewrite the low pass and low shelf analog prototypes to generate poles and zeroes entirely in the s-domain. This was as per Martin's suggestion of allowing positive and negative infinity as representations for the roots. Thanks to this feature, it was possible to completely generalize the construction of digital filters. It works with the following template: template struct Filter : ... Where Proto is the analog prototype. Currently Butter, ButterShelf, ChebyI, ChebyIShelf, ChebyII, ChebyIIShelf, and Elliptic are defined. Trans is the transformation, one of LowPass, HighPass, BandPass, or BandStop. This means that the addition of new filters is as easy as designing the analog prototype in terms of poles and zeroes (allowing infinity and negative infinity as defined values), and then adding a few lines to instantiate templates. For example: template struct BesselLowPass : Filter { }; Where Bessel is the low-pass analog prototype and LowPass is a low-pass to low-pass transformation. I am happy with this interface so the class hiearchy is unlikley to change from now on. There is some fine-tuning that needs to be done with filter parameter specification. There are still lots of optimizations, so I will continue to work on this. There is no redudant code or repeated filter formulas anywhere. Each algorithm is neatly encapsulated into a single class and maps directly to IIR concepts. A top down, functional programming model allows the building blocks to be re-assembled in different ways and allowing for full optimizations. And best of all, the library allocates no memory. New filters added: ChebyILowShelf ChebyIHighSelf ChebyIEq ChebyIILowShelf ChebyIIHighSelf ChebyIIEq From thevinn at yahoo.com Tue Jun 9 15:24:34 2009 From: thevinn at yahoo.com (Vinnie) Date: Tue Jun 9 15:24:50 2009 Subject: [music-dsp] Re: DspFilters open-source library v0.8.5 Message-ID: <146476.84765.qm@web58203.mail.re3.yahoo.com> Forgot to include the URL for this: https://sourceforge.net/projects/dspfilterscpp/ From martin.eisenberg at udo.edu Tue Jun 9 16:08:16 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Tue Jun 9 16:05:46 2009 Subject: [music-dsp] Prewarping formula for bandpass transformation? References: <234933.44719.qm@web51710.mail.re2.yahoo.com> Message-ID: <001501c9e93e$0abd6bc0$0201a8c0@mooncode> Brent Lehman wrote: > If the coefficients of a filter are c[k] and the response is > C(w), the response of 2*cos(kf)*c[k] will be something like > C(w+f)+C(w-f). In the case of a lowpass, where you had one > peak at w=0, now you have peaks at w=-f and w=+f. This applies to nonrecursive filters. > From: Vinnie thevinn@yahoo.com >> For a low pass to low pass, w'=w. For high pass, w'=PI-w. >> But what do we do about the band pass? I'm using a >> traditional band pass transformation. Since you prescribe the target peak frequency, what's left to compute? Martin From rbj at audioimagination.com Tue Jun 9 16:25:26 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Tue Jun 9 16:25:41 2009 Subject: [music-dsp] Article: antialiased sine waveform syncing In-Reply-To: <62C47C79-95F0-4985-9B4A-237F3F11646B@korgrd.com> References: <20090609042659.CCFD597F295@music.columbia.edu> <62C47C79-95F0-4985-9B4A-237F3F11646B@korgrd.com> Message-ID: <03B859C7-59DB-4EF6-A318-92491CDAF38E@audioimagination.com> hi Andy, On Jun 9, 2009, at 2:32 PM, Andy Leary wrote: > On Jun 8, 2009, at 9:26 PM, robert bristow-johnson > wrote: >> >> i've known about BLITs and understood how they can be used to drive >> an appropriate filter to generate virtually arbitrary *and* >> bandlimited waveforms, but i have always failed to see the advantage >> over wavetable synthesis in terms of complexity or cost. > >> ...... that's >> much less computation than running a BLIT through a filter which >> is why i >> sometimes question the point of it. it's not the first time i have. > > For Hard Sync, BLEP type implementations give the best sounding > results for the fewest cycles that I have found. If you are trying > to do FM with "analog" waveforms and if you want hard sync, > wavetable isn't going to work without adding BLEPs anyway. well, i'm not so sure how you add BLEPs to wavetable. i understand that the BLEPs (or BLITs) themselves can be stored as wavetables (for different periods with different degrees of overlap). but the end result is a bandlimited period waveform. any bandlimited periodic waveform, even bandlimited hard sync waveforms, can be synchronously sampled (at a large multiple of the fundamental) at a sufficient rate and what results is a wavetable. you can't play that waveform out at much higher pitches than it was originally (because of aliasing) but you *can* have a collection all of the hard sync waveforms (represented as wavetables) of a family that are all bandlimited. those waveforms meant for notes higher up on the keyboard will have fewer harmonics in them than those meant to be lower down. but, for the pitches that the waveforms were meant to be played, if your collection is sufficiently complete, you oughta be able to always have the right waveform (stored in a wavetable) that has all of the harmonics needed up to about the top octave, below Nyquist/2 (if the synth is running at 96 kHz this missing top octave is above 24 kHz and nobody cares about that). this is a "memory expensive" way of doing it, but no more memory costly than sample playback (in fact far less, a complete collection of wavetables for some waveform family would take up far less than a second of sample playback) and the sample playback (and looping) hardware (or optimized alg in a DSP) is readily used for this wavetable playback. the only issue is gracefully switching or cross-fading between wavetables as either the pitch goes up or down or as the slave/master frequency ratio changes. maybe you would have an array of wavetables with one or two per octave on the pitch axis and maybe a dozen or couple dozen along the slave/master ratio axis. how many is that? 100, at most 200? > If all you want is a band limited sawtooth and you don't need sync, > then wavetable is fine, and it's not limited to that. *any* bandlimited harmonic (a.k.a. periodic) waveform can be done simply with wavetable synthesis. evolving the waveform from one version (within a family) to another as the performer plays notes all over the keyboard (perhaps with portamento) or wails on the mod wheel (perhaps changing the slave/ master ratio), that takes a little bit of careful thinking. but not too much. it's quite doable. > but simple BLEP related optimizations make this case relatively cheap. we all know how to integrate a BLIT (with a teeny amount of DC offset related to the ramp rate) to get a bandlimited sawtooth. Eli's paper spells out out a series of BLITs, with different impulse heights can be integrated to get you a hard-sync saw. that can be generalized for any waveform that has (bandlimited) steps and connecting ramps. it involves being able to synthesize each BL impulse at a given starting phase, phase advancement rate, and amplitude and to overlap a bunch of them (i am not sure how many, but it could be 8 or more if these edges in the waveform are close to each other), add the required DC and integrate. but that *has* to be expensive. each BLIT is at least 16 MACs if you need it bandlimited, no? adding up 8 of them is that much more. > That being said.... there's some cool things left to do with > wavetable yet..... > :-) coming from the Wavestation guys, that means something. (BTW, one of my favorite musicians who is also a friend, Happy Rhodes, appears to use her Wavestation over any other synth in her electronic arsenal.) my attitude is, if it's a tone, wavetable can do it and likely cheaper than any other method. with a decent pitch detector and inter-sample interpolator, extracting the wavetable out of any sampled waveform should be a piece of cake. if there are non- harmonic components, simple wavetable can't do it, but perhaps "group additive synthesis" (summing 2 or 3 wavetable oscillators running at somewhat different pitches) can often do it. L8r Andy, -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From martin.eisenberg at udo.edu Tue Jun 9 16:33:44 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Tue Jun 9 16:31:15 2009 Subject: [music-dsp] DspFilters open-source library v0.8.5 References: <519798.7862.qm@web58201.mail.re3.yahoo.com> Message-ID: <002701c9e941$98c408e0$0201a8c0@mooncode> You have code like this: | if( r==negativeInfinity ) { | c=Complex( -1, 0 ); | } else if( r==positiveInfinity ) { | c=Complex( 1, 0 ); | } else // ordinary case First of all, "positiveInfinity" is never generated because your prototyes are lowpass. Second, there is only one infinity in the complex plane (lying equally in any direction) and the (LP-to-LP) BLT maps it to z=-1. The preimage of z=1 is just s=0. So you can simplify the code as follows: // .h typedef Complex Root; extern const Root infinity; // .cpp #include const Root infinity(std::numeric_limits::infinity()); if( r==infinity ) { c=Complex( -1, 0 ); } else // ordinary case Martin From martin.eisenberg at udo.edu Tue Jun 9 16:41:19 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Tue Jun 9 16:38:42 2009 Subject: [music-dsp] DspFilters open-source library v0.8.5 References: <519798.7862.qm@web58201.mail.re3.yahoo.com> Message-ID: <002b01c9e942$a7e6bd80$0201a8c0@mooncode> Vinnie wrote: > template > struct BesselLowPass : Filter > {}; This is nice! The usual name for such a style is "declarative programming", as opposed to "imperative" (which functional and side-effect-based programming both fall under). Martin From thevinn at yahoo.com Tue Jun 9 17:05:29 2009 From: thevinn at yahoo.com (Vinnie) Date: Tue Jun 9 17:05:41 2009 Subject: [music-dsp] Re: Prewarping formula for bandpass transformation? Message-ID: <42667.76396.qm@web58201.mail.re3.yahoo.com> > From: "Martin Eisenberg" > Since you prescribe the target peak frequency, what's left > to compute? For a normal bandpass filter, yes I would calculate the geometric mean of the corner frequencies, sample the magnitude response at that point, and normalize the filter for unity gain there. For Chebyshev Type I we would target a gain of either 1 for odd order, or pow(10,-rippleDb/20) for even order. But I am using the bandpass transformation not only on a low pass analog prototype, but also a low shelf analog prototype, to get a peaking equalizer. In this case, I want to sample the magnitude response at either w=0 (if the center frequency is greater than pi/2) or w=pi (if the center frequency is less than pi/2). Thanks to an excess of generalization and templates, I have no idea if the bandpass transformation is being used on a low pass, or a low shelf. What I did for each analog prototype is to add a normalization parameter set consisting of angular frequency 'w' and target gain 'gain'. For the low pass w=0 and gain=1 or pow(10,-rippleDb/20) depending on the type of filter and order. This is done inside the analog prototype. The transformation object (LowPass, HighPass, BandPass, or BandStop) takes the normalization parameters and performs the necessary transformation. Low pass: w'=w High pass: w'=Pi-w For band stop I use a mild hack. I totally ignore the normalization frequency specified in the analog prototype and use the filter specification center point. If it is less than pi/2 then w=pi. If it is greater than pi/2 then w=0. For band pass I use an even bigger hack. I manually check to see if w=0 and if so, use the geometric mean of the corners (this assumes we are being called to transform a low pass analog prototype). If w=pi then I compare the center point against pi/2 as described above for the band stop. This is the last remnant of non-generic code. It works but it is not pretty and could fail for an unforseen analog prototype. From rbj at audioimagination.com Tue Jun 9 17:37:01 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Tue Jun 9 17:37:16 2009 Subject: [music-dsp] Re: Prewarping formula for bandpass transformation? In-Reply-To: <42667.76396.qm@web58201.mail.re3.yahoo.com> References: <42667.76396.qm@web58201.mail.re3.yahoo.com> Message-ID: On Jun 9, 2009, at 5:05 PM, Vinnie wrote: ... > The transformation object (LowPass, HighPass, BandPass, or > BandStop) takes the normalization parameters and performs the > necessary transformation. > > Low pass: w'=w > High pass: w'=Pi-w > > For band stop I use a mild hack. I totally ignore the normalization > frequency specified in the analog prototype and use the filter > specification center point. If it is less than pi/2 then w=pi. If > it is greater than pi/2 then w=0. > > For band pass I use an even bigger hack. I manually check to see if > w=0 and if so, use the geometric mean of the corners (this assumes > we are being called to transform a low pass analog prototype). If > w=pi then I compare the center point against pi/2 as described > above for the band stop. i just don't think that your HPF, BPF, or BRF transformations are the right ones. at the risk of repeating myself, the following are the textbook mappings for analog prototypes with normalized resonant frequency (or normalized "significant frequency" or "normalized s") to the LPF with normalized s: LPF: s <- s HPF: s <- 1/s BPF: s <- Q*(s + 1/s) BRF: s <- Q/(s + 1/s) when applying Bilinear Transform (which is what causes frequency warping), the bandwidth of the BPF and BRF gets scrunched a little bit as the resonant frequency w0 gets closer to Nyquist. a first- order approximation for prewarping compensation is to increase that analog bandwidth (expressed in octaves or any log frequency) by a factor of w0/sin(w0) before it gets scrunched: 1/Q = 2*sinh( ln(2)/2 * BW * w0/sin(w0) ) where BW is the bandwidth in octaves w0 = 2*pi*f0/Fs and f0 is the resonant frequency in the same units as sampling frequency, Fs. the Bilinear Transform mapping from normalized s to z that accounts for (and fixes) the frequency warping of w0 is: s <- ( 1/tan(w0/2) )*(1 - z^-1)/(1 + z^-1) That's it! if your substitutions are not equivalent to those (or approximately equivalent for the BW to Q mapping), i question if they're correct. just trying to be helpful (but, as i found out at Kurzweil last year, it's difficult to be helpful and simultaneously not heard). -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From thevinn at yahoo.com Tue Jun 9 19:00:43 2009 From: thevinn at yahoo.com (Vinnie) Date: Tue Jun 9 19:00:54 2009 Subject: [music-dsp] Re: DspFilters open-source library Message-ID: <222300.59699.qm@web58202.mail.re3.yahoo.com> > From: "Martin Eisenberg" > This is nice! The usual name for such a style is > "declarative programming", as opposed to "imperative" > (which functional and side-effect-based programming both fall under). Thanks! That is exactly what I was shooting for. The design was inspired by agg (http://www.antigrain.com). > From: robert bristow-johnson > ???s???<-???( > 1/tan(w0/2) )*(1 - z^-1)/(1 + z^-1) Mine is very similar: const Root &r=roots.GetNth(i); // s-plane root CalcT k=tan(w*0.5); c=r*k; // frequency transform c=(1.+c)/(1.-c); // bilinear low-pass xform Here's the high pass transform: const Root &r=roots.GetNth(i); // s-plane root CalcT k=1./tan(w*0.5); c=r*k; // frequency transform c=-(1.+c)/(1.-c); // bilinear high-pass xform > it's difficult to be helpful and simultaneously not heard). I hear you, and I understand each word individually. But to be quite honest, I still don't understand the math fully (!). What I have been doing is a trial and error approach, I take formulas and insert them in various combinations and permutations until they work. I still don't understand what z^-1 is. I mean, I get that it represents the previous sample. But how does that relate to the placement of poles and zeros in the s-plane and digital domain? I am unsure. As you can see, my bilinear transform is slightly different than yours. I use c, you use z^-1. I have 1+c, you have 1-z^-1. Does that mean c=-z^-1? *scratches head* At least we can agree that k=tan(w/2). Well actually, we can't even agree on that! I have tan(w/2) for the low pass and you are using 1/tan(w/2). Which coincidentally is what I use for the high pass transform. I tried using (1-c)/(1+c) (replacing z^-1 with c) in the code, but that didn't work. So I guess c!=z^-1? I tried all combinations of sign changes and what worked was c=(1.+c)/(1.-c). From martin.eisenberg at udo.edu Tue Jun 9 19:06:33 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Tue Jun 9 19:04:02 2009 Subject: [music-dsp] Re: Prewarping formula for bandpass transformation? References: <42667.76396.qm@web58201.mail.re3.yahoo.com> Message-ID: <001401c9e956$f21213a0$0201a8c0@mooncode> Vinnie wrote: > Thanks to an excess of generalization and templates, I have no > idea if the bandpass transformation is being used on a low > pass, or a low shelf. Actually, frequency transformations don't affect normalization. You can find the scale factor inside each prototype class and store it as a single number replacing the Normalization class. Martin From mailbjl at yahoo.com Tue Jun 9 19:04:50 2009 From: mailbjl at yahoo.com (Brent Lehman) Date: Tue Jun 9 19:05:01 2009 Subject: [music-dsp] Prewarping formula for bandpass transformation? Message-ID: <128675.81806.qm@web51702.mail.re2.yahoo.com> > From: Martin Eisenberg > > Brent Lehman wrote: > > > If the coefficients of a filter are c[k] and the response is > > C(w), the response of 2*cos(kf)*c[k] will be something like > > C(w+f)+C(w-f).? In the case of a lowpass, where you had one > > peak at w=0, now you have peaks at w=-f and w=+f. > > This applies to nonrecursive filters. Oh, right. I guess in the general case if SUM{cos(kf) b[k] y[n-k]} = SUM{cos(kf) a[k] x[n-k]} you get the response H(w) = [X(w+f) + X(w-f)] / [Y(w+f) + Y(w-f)] right? You could do something like SUM{exp(ikf) b[k] y1[n-k]} = SUM{exp(ikf) a[k] x[n-k]} y[n] = 2 Re{y1[k]} but even then, now that I think about it, phase cancellation can screw this up. Adding responses together like this can scramble the locations of zeros -- poles less so, I suppose. So never mind. From martin.eisenberg at udo.edu Tue Jun 9 20:58:35 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Tue Jun 9 20:56:05 2009 Subject: [music-dsp] Re: DspFilters open-source library References: <222300.59699.qm@web58202.mail.re3.yahoo.com> Message-ID: <000501c9e966$98cbd140$0201a8c0@mooncode> Vinnie wrote: > I still don't understand what z^-1 is. I mean, I get that it > represents the previous sample. But how does that relate > to the placement of poles and zeros in the s-plane and digital > domain? What's your mathematical level that an explanation can rely on? Martin From vadim.zavalishin at native-instruments.de Wed Jun 10 05:25:40 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Wed Jun 10 05:25:54 2009 Subject: [music-dsp] Name of delay-free loop technique In-Reply-To: <002c01c9e923$4d20eb60$0201a8c0@mooncode> References: <002401c9d7d1$0aee5ce0$0201a8c0@mooncode><56BDCC96E6B94AF5BC7DF68F893A63C1@nibln01077><001201c9d8a6$2f916bc0$0201a8c0@mooncode><001201c9dca5$332d6f60$0201a8c0@mooncode><86DBA60A6D954C829C23571C46248EFE@nibln01077><029244E7BAD549C78B29E3DAB113FC06@nibln01077><000a01c9e21b$441cc3e0$0201a8c0@mooncode><003b01c9e383$904dab80$0201a8c0@mooncode><000d01c9e884$b65c5000$0201a8c0@mooncode><3C6F181C0CF441569186A2D2550FF0DC@nibln01077><007401c9e919$b01b4080$0201a8c0@mooncode><447609066BA049579EDAED086F0E582D@nibln01077> <002c01c9e923$4d20eb60$0201a8c0@mooncode> Message-ID: <3A41B04138E140ACB3854EB72B6428A7@nibln01077> > What kind of continuity have you referred to in this quote--? > >>>> Anyway, what makes the selection unique - is the forced >>>> continuity of the output value by the lowpass filter, which >>>> allows to determine the direction in which the value is going >>>> to "move". The one ensured by the lowpass filter - the output value cannot jump (but it's allowed to move infinitely fast) >> An additional thought: I'm not sure the thing you mentioned >> about the dynamic systems is fully applicable here. >> Particularly since the starting value of y is not satisfying >> the equations. > > That's a problem discretization always brings about, isn't it? In > a linear system, y[n-1] won't satisfy the recurrence at n either > without rendering the system unrelated to the original dynamics. Generally yes, but not necessarily. Depending on the system topology ( :-) ) jumps in the input signal and/or parameters might produce discontinuities in the continuous-time output. > >> That might be different should we have been analysing >> "instantenous feedback" in a continuous time system >> *with continuous input signal and parameters*, but again I >> wouldn't be sure. > > Well, you've been the one to emphasize faithfulness to the > continuous-time behavior. I'm just trying to see whether your > reasoning might lead to unphysical results. For that one needs to compare the performance of the analog prototype system against its discrete-time model. Frankly speaking I didn't explicitly do that, more relying on the intuitive understanding, but I believe that they should be identical, as much as the trapezoidal approximation of the integration (in the BLT) allows. I'm not aware of the specific side effects of the trapezoidal integration ATM, but I believe there might be some. At any rate, I believe the results obtained this way are more reasonable than simple iteration (which fails already if gk>1, which is not so uncommon case), and I also believe they are more reasonable than a simple solution of the feedback equation as discussed. At least one gets a choice rule for the case of multiple solutions. BTW in regards to the intersection of the tangent line with another line - this is just a graphical representation of the local linerization of tanh. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From thevinn at yahoo.com Wed Jun 10 06:32:35 2009 From: thevinn at yahoo.com (Vinnie) Date: Wed Jun 10 06:32:52 2009 Subject: [music-dsp] Re: music-dsp Digest, Vol 66, Issue 46 Message-ID: <899506.39690.qm@web58202.mail.re3.yahoo.com> > From: "Martin Eisenberg" > First of all, "positiveInfinity" is never generated because > your prototyes are lowpass. Second, there is only one infinity > in the complex plane (lying equally in any direction) Whoops ^_^ hey whats wrong with an extra infinity? I changed it, that was a good suggestion thanks. As you can see I am not really c++ stdlib savvy although the numerics do seem worthwhile (didn't know infinity was representable on all platforms). What about what Robert was saying about the prewarping formulas? It seems like I am incorporating those formulas but they have taken on a different form. From thevinn at yahoo.com Wed Jun 10 06:56:16 2009 From: thevinn at yahoo.com (Vinnie) Date: Wed Jun 10 06:56:25 2009 Subject: [music-dsp] Re: DspFilters open-source library Message-ID: <95853.68936.qm@web58203.mail.re3.yahoo.com> > From: "Martin Eisenberg" > What's your mathematical level that an explanation can rely on? Well this is what I know so far. H(s) represents the transfer function of the analog prototype s-plane. The units of frequency extend from 0 to infinity, represented by the real portion of s. The imaginary portion of s reflects the phase. If the transfer function is a rational function A(s)/B(s) then finding the roots of A(s) and B(s) will determine the zeros and poles respectively in the s-plane. I can plod through mathematical texts and most of the time decrypt the expressions for A(s) and B(s). When there are no zeroes I use infinity. As you know once I have the poles and zeros, I'm in business since all that code works. So the problem has been hemmed and hewed down to the analog prototype. I can perform algebra on expressions. I'm a little hazy on the meaning of the transfer function. Is that the complex-valued response of the filter? Why does z^-1 stick its head out? Sometimes authors use a negative exponent for different things (like pow(z,-1) or pow(z,-2). This happened in "High Order Digital Parametric Equalizer Design". This is very confusing. When I transform the s-plane pole I use c' = (1+k*c) / (1-k*c), k=tan(w0/2) This looks different from the formula normally seen in texts: s <- ( 1/tan(w0/2) )*(1 - z^-1)/(1 + z^-1) Does z^-1 correspond to the s-plane pole? It sure looks similar. I mean, there's a 1+z^1 in the denominator. Oh hey, I have 1+c in my numerator. Except that my k is next to the c. Hey lets solve my equation for c: c = (1/k) * (c'-1)/(c'+1), k=tan(w0/2) Well that looks a lot closer! The tangent is in the denominator now. Except that I have c'-1 in the numerator where the bilinear has 1-z^-1 in the numerator. Oh and the denominator is different. Oh well there goes that idea. What was z^-1 again? On a completely unrelated note is there any point to implementing a Bessel analog prototype? I have it mostly working but I am wondering if there are any real use-cases for it. Are there any other interesting transfer functions I could add? From thevinn at yahoo.com Wed Jun 10 08:17:00 2009 From: thevinn at yahoo.com (Vinnie) Date: Wed Jun 10 08:17:09 2009 Subject: [music-dsp] Bessel poles? Message-ID: <124554.90317.qm@web58206.mail.re3.yahoo.com> I've developed a Bessel low-pass analog prototype. For filter order 3 my reverse Bessel polynomial is B(s) = 15 + 15*s + 6*s^2 + s^3 I'm using a root finder to find all s where B(s)=0. The root finder definitely works, I plug the roots back into the equation and the result is sufficiently close to zero (within 1e-15). The resulting filter is similar to a Bessel response but my poles are off by a constant scale factor, according to http://www.rfcafe.com/references/electrical/bessel-poles.htm For example, my poles for order=3 are: (-2.3221) (-1.8389,1.7544) (-1.8389,-1.7544) But according to that page the poles should be (-1.3270) (-1.0509,1.0025) (-1.0509,-1.0025) I know that I am close, my poles are off by a scale factor that varies with order. In this case the factor is 1.75. Maybe this has something to do with the numerator? Isn't the transfer function: H(s) = 15 / ( 15 + 15*s + 6*s^2 + s^3 ) But what does that matter for finding the poles (i.e. roots of B(s))? I don't think it matters since a root is a root regardless of what is in the numerator. From thevinn at yahoo.com Wed Jun 10 08:56:52 2009 From: thevinn at yahoo.com (Vinnie) Date: Wed Jun 10 08:57:14 2009 Subject: [music-dsp] Re: Prewarping formula for bandpass transformation? Message-ID: <233150.35355.qm@web58204.mail.re3.yahoo.com> > From: "Martin Eisenberg" > Actually, frequency transformations don't affect > normalization. You can find the scale factor inside each prototype class > and store it as a single number replacing the Normalization > class. This is true but the normalization is affected by the choice of cutoff frequency. That is why I sample the actual filter response at a well defined location (w=0 for low pass, w=pi for high pass, geometric center for band pass, 0 or pi for band stop depending on the location of the center) and factor the magnitude response into my scaling. The analog prototypes use a fixed frequency omega=1 (I think that is the symbol that Orfanidis uses for analog frequency, right?) to keep formulas simple. So given the analog prototype with a fixed cutoff frequency how do I generate a single number for the normalization? I don't see how, unless I change my prototype to include the cutoff (something currently handled by the Transformation). From martin.eisenberg at udo.edu Wed Jun 10 11:49:35 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Wed Jun 10 11:47:02 2009 Subject: [music-dsp] Re: Prewarping formula for bandpass transformation? References: <233150.35355.qm@web58204.mail.re3.yahoo.com> Message-ID: <000901c9e9e3$11bfcbc0$0201a8c0@mooncode> Vinnie wrote: > From: "Martin Eisenberg" martin.eisenberg@udo.edu >> Actually, frequency transformations don't affect >> normalization. You can find the scale factor inside each >> prototype class and store it as a single number replacing the >> Normalization class. > > This is true but the normalization is affected by the choice > of cutoff frequency. It shouldn't be. Under BLT the response graph is horizontally compressed but the vertical axis remains as it was. For any transfer functions Hd(z) = LP-to-X{Ha(s)}, LP-to-X combining BLT discretization and frequency transformation, the following identities hold: LP: Hd(1) = Ha(0), Hd(-1) = Ha(infinity) HP: Hd(-1) = Ha(0), Hd(1) = Ha(infty) BP: Hd(1) = Hd(-1) = Ha(infty), Hd(exp(j*w_center)) = Ha(0) BS: Hd(1) = Hd(-1) = Ha(0), Hd(exp(j*w_center)) = Ha(infty) All of those are independent of the target critical frequency's actual value -- that translates to a scale factor k on the BLT formula, but 0*k = 0 and infty*k = infty stay put. That said, I understand Robert's doubts about your bandpass transformation. It does look funky compared with the result of solving Orfanidis' eq. 2 for z... > The analog prototypes use a fixed frequency omega=1 (I think > that is the symbol that Orfanidis uses for analog frequency, > right?) to keep formulas simple. w is omega. You mean capital Omega, no? > So given the analog prototype with a fixed cutoff frequency > how do I generate a single number for the normalization? Evaluate the transfer function at s=infty if it's a shelf, at s=0 otherwise (i.e. if it's "selective"), and correct for ripple if need be. More explicitly, you have the TF specified by its roots, Ha(s) = product(i=0..m, s-sz[i]) / product(i=0..n, s-sp[i]). So the normalization for any selective filter is 1/Ha(0) = (-1)^(m+n)*product(sp[0..n])/product(sz[0..m]). A shelf filter will have m = n (for otherwise the treble response would be either zero or unbounded), so the normalization is 1/Ha(infty) = 1, the ratio of leading coefficients (pre ripple in both cases). Martin From martin.eisenberg at udo.edu Wed Jun 10 12:59:58 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Wed Jun 10 12:57:33 2009 Subject: [music-dsp] Re: DspFilters open-source library References: <95853.68936.qm@web58203.mail.re3.yahoo.com> Message-ID: <001901c9e9ec$e9352e20$0201a8c0@mooncode> Vinnie wrote: > Well this is what I know so far. H(s) represents the transfer > function of the analog prototype s-plane. The units of > frequency extend from 0 to infinity, represented by the real > portion of s. The imaginary portion of s reflects the phase. Ahem... no ;) In s = a+j*w, the imaginary part w is frequency. It can be negative too, but we mostly care about filters with a real impulse response and in this case the transfer function is symmetric in frequency, H(conj(s)) = conj(H(s)) -- aka Hermitian symmetry, aka real rational-polynomial coefficients, aka nonreal roots come in conjugate pairs. The real part of s has nothing to do with phase. It is a growth rate or time constant. That's why all poles of H(s) must be in the left half plane for the IR h(t) to be bounded. On the other hand, arg(H(j*w)) (note a=0) is genuinely a signal phase. Actually H(j*w) is the Fourier spectrum of h(t). The reasons to extend the function to the whole s-plane are that the pole-zero representation is economical, manipulable, and connected to the theory of differential equations. Likewise, the discrete-time transfer function connects the DT Fourier spectrum with difference equation theory. > When there are no zeroes I use infinity. Zeros at infinity don't generically exclude finite ones. The point is simply that any rational function with a denominator of higher degree than the numerator must vanish when the function argument diverges. > When I transform the s-plane pole I use > > c' = (1+k*c) / (1-k*c), k=tan(w0/2) > > This looks different from the formula normally seen in texts: > > s <- ( 1/tan(w0/2) )*(1 - z^-1)/(1 + z^-1) You had the right idea, the two formulas are inverses with c = s and c' = z. It's just that the second formula's fraction is augmented by 1/(highest power of z). It is customary to make all exponents nonpositive like that because z itself corresponds to the unit-advance operator in the time domain, which is not causal (uses future data) and thus is one step removed from actual filtering code. But both forms of the fraction are equivalent; it's cosmetics. Indeed, some DSP literature prefers a variable tantamount to 1/z, variously spelling it p, zeta, or even -- z. Thankfully this is rare. Check out these resources: http://earlevel.com/Digital%20Audio/PoleZero.html http://www.jhu.edu/~signals/index.html http://www.wescottdesign.com/articles/zTransform/z-transforms.htm l http://www-ccrma.stanford.edu/~jos/filters/ Martin From xue.wen at elec.qmul.ac.uk Thu Jun 11 07:12:17 2009 From: xue.wen at elec.qmul.ac.uk (Wen X) Date: Thu Jun 11 07:13:23 2009 Subject: [music-dsp] Bessel poles? In-Reply-To: <124554.90317.qm@web58206.mail.re3.yahoo.com> References: <124554.90317.qm@web58206.mail.re3.yahoo.com> Message-ID: <1C8D3DD22D3F4A868BFAA0F80548E0E9@wenmac> If the poles are different then so are the filters. If the poles are related by constant scaling then the filters are related by linear time- (or frequency-) stretch, i.e. they have different bandwidths yet are otherwise the same, in particular if one is Bessel then so is the other. -----Original Message----- From: music-dsp-bounces@music.columbia.edu [mailto:music-dsp-bounces@music.columbia.edu] On Behalf Of Vinnie Sent: 10 June 2009 13:17 To: music-dsp@music.columbia.edu Subject: [music-dsp] Bessel poles? I've developed a Bessel low-pass analog prototype. For filter order 3 my reverse Bessel polynomial is B(s) = 15 + 15*s + 6*s^2 + s^3 I'm using a root finder to find all s where B(s)=0. The root finder definitely works, I plug the roots back into the equation and the result is sufficiently close to zero (within 1e-15). The resulting filter is similar to a Bessel response but my poles are off by a constant scale factor, according to http://www.rfcafe.com/references/electrical/bessel-poles.htm For example, my poles for order=3 are: (-2.3221) (-1.8389,1.7544) (-1.8389,-1.7544) But according to that page the poles should be (-1.3270) (-1.0509,1.0025) (-1.0509,-1.0025) I know that I am close, my poles are off by a scale factor that varies with order. In this case the factor is 1.75. Maybe this has something to do with the numerator? Isn't the transfer function: H(s) = 15 / ( 15 + 15*s + 6*s^2 + s^3 ) But what does that matter for finding the poles (i.e. roots of B(s))? I don't think it matters since a root is a root regardless of what is in the numerator. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp From gberchin at comcast.net Thu Jun 11 07:33:30 2009 From: gberchin at comcast.net (Greg Berchin) Date: Thu Jun 11 07:29:10 2009 Subject: [music-dsp] Re: Bessel poles? In-Reply-To: <20090610125712.2C539998983@music.columbia.edu> References: <20090610125712.2C539998983@music.columbia.edu> Message-ID: Vinnie wrote: >>I've developed a Bessel low-pass analog prototype. For filter order 3 my reverse Bessel polynomial is >> >> B(s) = 15 + 15*s + 6*s^2 + s^3 >> <...> >>For example, my poles for order=3 are: >> (-2.3221) >> (-1.8389,1.7544) >> (-1.8389,-1.7544) >> >>But according to that page the poles should be >> (-1.3270) >> (-1.0509,1.0025) >> (-1.0509,-1.0025) >> >>I know that I am close, my poles are off by a scale factor that varies with order. In this case the factor is 1.75. <...> It depends upon whether you want to find the "natural" frequency of the filter or the -3dB frequency of the filter. For your 3rd-order Bessel filter, "w0" (the natural frequency) equals 15^(1/3) = 2.46621207433047 rad/sec, but "w3dB" (the frequency at which the filter magnitude response is down by 3dB) is 1.75567236868121 rad/sec, according to my notes. If you normalize the filter so that "w3dB=1", then the pole locations should be as stated in the reference. Greg ========================= Everybody has their moment of great opportunity in life. If you happen to miss the one you care about, then everything else in life becomes eerily easy. -- Douglas Adams From thevinn at yahoo.com Thu Jun 11 08:11:08 2009 From: thevinn at yahoo.com (Vinnie) Date: Thu Jun 11 08:11:23 2009 Subject: [music-dsp] Group Delay, Step Response from Cascade? Message-ID: <974444.17895.qm@web58205.mail.re3.yahoo.com> I would like to graph the group delay and step response for a cascade of second order stages (I have all the coefficients). Is this possible and if so, what is the formula? If not, then what do I do? Do I have to perform algebra on the transfer function? Or can it be computed from the poles/zeros after transformation? I'm putting together a small cross platform test app to demonstrate these filters (it uses JUCE). It will be available shortly. Thanks to everyone, especially Martin and Robert! I love you guys! From rbj at audioimagination.com Thu Jun 11 10:51:25 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Thu Jun 11 10:51:50 2009 Subject: [music-dsp] Group Delay, Step Response from Cascade? In-Reply-To: <974444.17895.qm@web58205.mail.re3.yahoo.com> References: <974444.17895.qm@web58205.mail.re3.yahoo.com> Message-ID: <1948D96B-75D5-43B1-B37F-00CAFA488F79@audioimagination.com> On Jun 11, 2009, at 8:11 AM, Vinnie wrote: > > I would like to graph the group delay and step response for a > cascade of second order stages (I have all the coefficients). Is > this possible and if so, what is the formula? > step response is a problem. group delay is easy (just add up the groupd delays for each stage). but with step response, you can't simply do that. for step response, first get your impulse response. to get that for IIR, you have to break your cascade of 2nd-order sections into a "cascode" (that word i have rarely used) of 2nd-order sections. by "cascode", i mean in parallel; the section that have a common input and the output from each is summed. to do *that*, assuming none of the poles of the sections lie directly on top of each other, then you *might* be able to do it automatically (with a computer program) using the Heaviside expansion theorem. this is *not* a small deal. i might suggest getting a good book (or maybe Wikipedia) to tell you about that. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From dfl at alum.mit.edu Thu Jun 11 11:32:05 2009 From: dfl at alum.mit.edu (David Lowenfels) Date: Thu Jun 11 11:32:17 2009 Subject: [music-dsp] OT: DSP texts for sale Message-ID: <15e122ba0906110832k4d8b2e8dy40dc7109ebdb70dd@mail.gmail.com> Hi all, I'm cleaning my closet of textbooks and came across some DSP texts that some of you might be interested in. I'm not so much concerned about making money, but rather having them go to a "good home" where they will be loved :) Discrete-Time Signal Processing (2nd ed) by Oppenheim and Schafer Signals & Systems (2nd ed) by Oppenheim and Willsky A Friendly Guide to Wavelets by Birkh?user Real Sound Synthesis for Interactive Applications (w/CD) by Perry Cook Please contact me off-list if interested. I'm shipping from California, USA. Thanks, David From rbj at audioimagination.com Thu Jun 11 11:46:58 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Thu Jun 11 11:47:13 2009 Subject: [music-dsp] it's not OT: DSP texts for sale In-Reply-To: <15e122ba0906110832k4d8b2e8dy40dc7109ebdb70dd@mail.gmail.com> References: <15e122ba0906110832k4d8b2e8dy40dc7109ebdb70dd@mail.gmail.com> Message-ID: <95A7E412-0806-4539-9DB0-0F12EEA6783A@audioimagination.com> On Jun 11, 2009, at 11:32 AM, David Lowenfels wrote: > Discrete-Time Signal Processing (2nd ed) by Oppenheim and Schafer this is still *the* definitive DSP Bible. no geek should be without it. > Signals & Systems (2nd ed) by Oppenheim and Willsky this is the introductory book to all things Convolutional, Fourier, Laplace, Poles and Holes (errr, i mean Zeros). what you get as a sophomore or junior in Electrical Engineering right after your initial course in basic circuits and the necessary pre-req to Electronics, DSP, Random Processes, Communications, Control Theory, and stuff like that. > A Friendly Guide to Wavelets by Birkh?user > Real Sound Synthesis for Interactive Applications (w/CD) by Perry Cook don't have these two. how much do you want for them? > Please contact me off-list if interested. I'm shipping from > California, USA. media mail is cheep (and slow). -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From thevinn at yahoo.com Thu Jun 11 12:27:02 2009 From: thevinn at yahoo.com (Vinnie) Date: Thu Jun 11 12:27:15 2009 Subject: [music-dsp] New: DspFilters 0.8.6 Message-ID: <647613.48543.qm@web58207.mail.re3.yahoo.com> I am pleased to announce version 0.8.6 of "A Collection of Useful C++ Classes for Digital Signal Processing". The project has been moved: http://code.google.com/p/dspfilterscpp/ You can browse the code directly using SVN. This version includes source code for a JUCE test application that exercises all of the filters. Real time parameter changes are possible, and graphs show gain, phase, response, and poles/zeros. You can build the test application yourself on any platform that supports JUCE, or you can use the pre-built Windows 32-bit executable (available separately on the project site) if you are impatient. Screenshot of the test application: http://img37.imageshack.us/img37/3885/dspjuce.png This library is still not complete, the shelves' ripple and gain specifications don't work quite right, and the filters don't always respect the 3dB point (especially for band pass and band stop). I'm working on it. As always, feedback or constructive criticism is welcomed. From martin.eisenberg at udo.edu Thu Jun 11 12:56:54 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Thu Jun 11 12:54:21 2009 Subject: [music-dsp] Group Delay, Step Response from Cascade? References: <974444.17895.qm@web58205.mail.re3.yahoo.com> <1948D96B-75D5-43B1-B37F-00CAFA488F79@audioimagination.com> Message-ID: <000b01c9eab5$a354e5c0$0201a8c0@mooncode> robert bristow-johnson wrote: > On Jun 11, 2009, at 8:11 AM, Vinnie wrote: >> I would like to graph the group delay and step response for a >> cascade of second order stages (I have all the coefficients). Unless this is for display in a self-contained program, do yourself a favor and pick up a numerical prototyping tool such as http://octave.sourceforge.net/ http://maxima.sourceforge.net/ > for step response, first get your impulse response. What's wrong with the obvious way? Filter an impulse and generate output, tracking local extrema, until the envelope underruns half a pixel height in your chosen vertical resolution. Or predict the effective length from poles and zeros: http://www.acoustics.hut.fi/~vpv/publications/icassp98-impl.htm > by "cascode", i mean in parallel; How did you come up with it? It seems the term has a different established meaning. Martin From rbj at audioimagination.com Thu Jun 11 14:18:24 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Thu Jun 11 14:18:36 2009 Subject: [music-dsp] Group Delay, Step Response from Cascade? In-Reply-To: <000b01c9eab5$a354e5c0$0201a8c0@mooncode> References: <974444.17895.qm@web58205.mail.re3.yahoo.com> <1948D96B-75D5-43B1-B37F-00CAFA488F79@audioimagination.com> <000b01c9eab5$a354e5c0$0201a8c0@mooncode> Message-ID: <8E1D0723-FA92-47AB-B9A0-CF0383A57744@audioimagination.com> On Jun 11, 2009, at 12:56 PM, Martin Eisenberg wrote: > robert bristow-johnson wrote: >> >> for step response, first get your impulse response. > > What's wrong with the obvious way? Filter an impulse and generate > output, tracking local extrema, until the envelope underruns half > a pixel height in your chosen vertical resolution. Or predict the > effective length from poles and zeros: > http://www.acoustics.hut.fi/~vpv/publications/icassp98-impl.htm good idea. why didn't i think of that? (duh) and, as long as what the OP wants is *step* response, he can filter a unit step input. you can do that in the same background process (or maybe it's a foreground process) where the coefficients are calculated, and then while you're at it, you figger out the frequency response and the step response and store those in an array in case the user wants to see it. but i wouldn't calculate frequency response similarly (by sweeping with a slow chirplike sinusoid in the background). i would do frequency response as in http://www.dsprelated.com/showmessage/ 30493/1.php (i can't seem to find the post in Google Groups). what i was thinking regarding step response was something similar (getting it theoretically) but to do that, you need to bust the transfer function into partial fractions, inverse Z-transform each section, and then add it up. >> by "cascode", i mean in parallel; > > How did you come up with it? It seems the term has a different > established meaning. you're right. from Wikipedia: > The word "cascode" is a contraction of the phrase "cascade to cathode". it seems that i came across some electronics or circuits textbook that had, in the realization of higher order transfer functions, used those to words "cascade" vs. "cascode" as formal terms for "series" vs. "parallel". -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From mark.plumbley at elec.qmul.ac.uk Fri Jun 12 07:05:59 2009 From: mark.plumbley at elec.qmul.ac.uk (Mark Plumbley) Date: Fri Jun 12 07:06:36 2009 Subject: [music-dsp] PhD Studentship in Audio-Visual Machine Listening In-Reply-To: <20090611080726.C34D1628C@mailscan3.ncs.mcgill.ca> References: <20090611080726.C34D1628C@mailscan3.ncs.mcgill.ca> Message-ID: <9A6BBBBE2AAD6746A6D961B57357426203800FB0A6@staff-mail2.vpn.elec.qmul.ac.uk> PhD Studentship in Audio-Visual Machine Listening Centre for Digital Music, Queen Mary University of London Applications are invited for a 3-year PhD studentship to undertake research into audio-visual analysis of sound events, with an emphasis on non-speech (music and environmental) sounds. Research in audio and video signal processing has traditionally taken place in different research groups, but audio-visual processing is now increasingly being linked. In speech processing, for example, image processing methods for lip reading can help improve speech recognition performance, particularly in noisy environments. One promising technique for audio-visual analysis of particular interest in this project is "sparse representations", which looks for a representation of an audio or video signal using a small number of non-zero elements, which can then be associated together. The work will form part of a programme of research in "Machine Listening using Sparse Representations", supported by a Leadership Fellowship from the UK Engineering and Physical Sciences Research Council (EPSRC). This is a concerted programme of research aiming to establish machine listening as a key enabling technology to improve our ability to interact with the world. The successful candidate will be based in the Machine Listening lab of the world-leading Centre for Digital Music at Queen Mary University of London, working under the supervision of Prof Mark Plumbley (www.elec.qmul.ac.uk/people/markp). Candidates should have a first or upper second honours degree or equivalent in electronic engineering, mathematical science, physics, statistics, computer science, or allied disciplines, and be able to demonstrate excellent mathematical and programming skills. Research experience in digital signal processing of audio, image and/or video signals is desirable. The studentship is for 3 years (subject to satisfactory progress) starting from 1 September 2009 or as soon as possible thereafter. It includes tuition fees and a tax-free stipend in line with EPSRC recommendations (currently at ?14,940 per annum for the 2008/09 session), and is open to EU (including UK) candidates. For informal enquiries, please contact Prof Mark Plumbley, Queen Mary University of London, Email: mark.plumbley@elec.qmul.ac.uk. How to apply To apply for the PhD studentship please email the following documents to Prof Mark Plumbley: mark.plumbley@elec.qmul.ac.uk: a completed application form, a CV listing all publications, your representative publications in PDF format, two independent reference letters, and other relevant documents as requested (see http://www.eecs.qmul.ac.uk/phd/apply.php). These documents must also be provided in paper form and sent to the Admissions and Recruitment Office (see the application form for address). The closing date for applications is Wednesday 1st July 2009. -- Prof Mark D Plumbley Electronic Engineering & Computer Science (Eng Bldg) Queen Mary University of London Mile End Road, London E1 4NS, UK Tel: +44 (0)20 7882 7518 Fax: +44 (0)20 7882 7997 Email: mark.plumbley@elec.qmul.ac.uk http://www.elec.qmul.ac.uk/people/markp/ From stober at cs.uni-magdeburg.de Fri Jun 12 08:51:42 2009 From: stober at cs.uni-magdeburg.de (Sebastian Stober) Date: Fri Jun 12 08:51:51 2009 Subject: [music-dsp] AMR'09 - Call for Papers - 7th International Workshop on Adaptive Multimedia Retrieval, Madrid, Sept. 24-25, 2009 Message-ID: <4A324F5E.8020503@cs.uni-magdeburg.de> [Apologies if you receive multiple copies] ------------------------------------------------------------------------ *AMR 2009 - 7th International Workshop on Adaptive Multimedia Retrieval* * Deadline for paper submission: July 20, 2009 * ------------------------------------------------------------------------ September 24-25, 2009 Universidad Nacional de Educacion a Distancia, Madrid, spain http://cabrillo.lsi.uned.es/nlp/amr2009/ The main reasons for undesired steps in multimedia search are on the one hand, the users' difficulty in specifying their interests in the form of a well-defined query, and on the other hand, the problem of extracting relevant (semantic) features from the multimedia objects. To improve today's retrieval tools and thus the overall satisfaction of a user, it is necessary to develop new techniques able to support the user in the interactive retrieval process. Currently, especially Multimedia Interaction and Dialogue Management techniques as well as affect detection for multimedia content and others are currently promising research directions. The Adaptive Multimedia Retrieval workshop aims to bring researchers, practitioners and companies with specific focus on existing and novel techniques into the field of multimedia retrieval. The goal of this workshop is therefore to intensify the exchange of ideas, to provide an overview of current activities in this area and to point out connections between multimedia, retrieval and artificial intelligence research communities. ------------------------------------------------------------------------ Topics of interest: ------------------------------------------------------------------------ The workshop focuses especially on researchers that are working on: feature extraction techniques for multimedia, computer linguistic approaches, (dynamic) data analysis methods, interactive machine learning and visualisation methods as well as user interface design. Therefore, contributions to the workshop should focus on, but are not limited to: - Multimedia retrieval systems (for text, image, audio, video and mixed-media) - Theoretical foundations of multimedia retrieval and mining - Intelligent multimedia data modelling, indexing and structure extraction - Adaptive Hypermedia and web based systems - Metadata for multimedia retrieval - Multimedia and multi-modal mining - Semantic content analysis for multimedia - Multimedia Interaction and Dialogue Management - Sentiment Analysis and Affect Detection for Multimedia Content - Soft Computing in Multimedia Information Retrieval - Adaptive query languages - Similarity measures (especially user adaptive measures) - User and preference modelling (including feedback models) - Methods for adaptive data visualisation and user interfaces ------------------------------------------------------------------------ Important Dates: ------------------------------------------------------------------------ July 20th, 2009 Deadline for paper submission August 17th, 2009 Notification of acceptance/rejection September 4th, Final paper submission September 7th, 2009 Early registration deadline ------------------------------------------------------------------------ Submissions: ------------------------------------------------------------------------ Submissions must be original and must not have been submitted for publication elsewhere. Submissions should be formatted according to Springer LNCS style (see http://www.springer.de/comp/lncs/authors.html). Papers should have about 10 pages but should not exceed 15 pages and should be submitted electronically in PDF or postscript format. ------------------------------------------------------------------------ Committee: (cf. http://cabrillo.lsi.uned.es/nlp/amr2009/) ------------------------------------------------------------------------ Program Chairs: Marcin Detyniecki CNRS, LIP6, Paris, France Ana Garcia-Serrano UNED, Spain Andreas Nuernberger University of Magdeburg, Germany * * * Further details can be found on the Web page of the workshop http://cabrillo.lsi.uned.es/nlp/amr2009/ * * * From thevinn at yahoo.com Fri Jun 12 08:57:12 2009 From: thevinn at yahoo.com (Vinnie) Date: Fri Jun 12 08:57:28 2009 Subject: [music-dsp] Re: Group Delay, Step Response from Cascade? Message-ID: <580764.58627.qm@web58208.mail.re3.yahoo.com> > From: "Martin Eisenberg" > Unless this is for display in a self-contained program... What a coincidence, that is EXACTLY why I want the group delay! To graph it in the small test app I added to my library: http://img37.imageshack.us/img37/3885/dspjuce.png (Sources for the filters and test application are here http://code.google.com/p/dspfilterscpp/) I'm on the verge of understanding the z transform. Does any of this make sense: - The group delay is the rate of change (derivative) of phase delay with respect to frequency. - Phase delay of angular frequency w, f(w)=-std::arg(H'(z))/w where z=exp(i*w) and H'(z) is the digital transfer function obtained by the bilinear transform of H(s), the analog transfer function. - H(z) can be recovered from a second order section by inverse z-transforming the time-domain difference equation y(n) generated from the second order section coefficients - For an N-order filter H(z) is the ratio of products of quadratics plus one optional degree-1 polynomial in z (corresponding to a real pole or zero). - The derivative of a ratio of products can be calculated as the sum of the derivatives of each term. Any mistakes in concepts or terminology above? Thanks From rbj at audioimagination.com Sat Jun 13 22:49:31 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sat Jun 13 22:49:50 2009 Subject: [music-dsp] Re: Group Delay, Step Response from Cascade? In-Reply-To: <580764.58627.qm@web58208.mail.re3.yahoo.com> References: <580764.58627.qm@web58208.mail.re3.yahoo.com> Message-ID: <9478ED4C-1068-42A3-8247-EE5175742B96@audioimagination.com> On Jun 12, 2009, at 8:57 AM, Vinnie wrote: > >> From: "Martin Eisenberg" >> Unless this is for display in a self-contained program... > > What a coincidence, that is EXACTLY why I want the group delay! To > graph it in the small test app I added to my library: > http://img37.imageshack.us/img37/3885/dspjuce.png > > (Sources for the filters and test application are here http:// > code.google.com/p/dspfilterscpp/) > > I'm on the verge of understanding the z transform. Does any of this > make sense: > > - The group delay is the rate of change (derivative) of phase delay > with respect to frequency. > like the phase delay it's the *negative* of that derivative w.r.t. *angular* frequency. there's some nice math that helps simplify things and avoids problems due to phase wrapping. > - Phase delay of angular frequency w, f(w)=-std::arg(H'(z))/w where > z=exp(i*w) and H'(z) is the digital transfer function obtained by > the bilinear transform of H(s), the analog transfer function. no matter how H'(z) is obtained (bilinear transform or no), the above is true. make sure that the phase angle is *unwrapped*. > - H(z) can be recovered from a second order section by inverse z- > transforming the time-domain difference equation y(n) generated > from the second order section coefficients and then solving for Y(z)/X(z). (and it's the forward Z-transform, not inverse.) > - For an N-order filter H(z) is the ratio of products of quadratics > plus one optional degree-1 polynomial in z (corresponding to a real > pole or zero). i think you're okay up to here. > - The derivative of a ratio of products can be calculated as the > sum of the derivatives of each term. i wouldn't look at it this way. just like the log-magnitudes (in dB or nepers or whatever log-magnitude units) add when sections are cascaded, the phase angles (in whatever units) also add for cascaded sections. that means the group delay and phase delay add also. > Any mistakes in concepts or terminology above? doing pretty good for not learning this formally in an EE course. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From neolit123 at gmail.com Sun Jun 14 05:04:42 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Sun Jun 14 05:06:20 2009 Subject: [music-dsp] Video lectures on DSP (IIT Delhi) References: <20090611080726.C34D1628C@mailscan3.ncs.mcgill.ca> <9A6BBBBE2AAD6746A6D961B57357426203800FB0A6@staff-mail2.vpn.elec.qmul.ac.uk> Message-ID: <000a01c9eccf$30e5ed10$0201a8c0@LuboPC> [Could be a repost] I was looking for a paper on something and stumbled on these: Prof. S.C Dutta Roy, Department of Electrical Engineering, IIT Delhi 43 - 1 hour lectures on DSP at: http://www.youtube.com/view_play_list?p=9567DFCA3A66F299 Students might find these useful... The marvels of fast internet connections b2b video compression. Lubomir From martin.eisenberg at udo.edu Sun Jun 14 11:36:45 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Sun Jun 14 11:34:06 2009 Subject: [music-dsp] Re: Group Delay, Step Response from Cascade? References: <580764.58627.qm@web58208.mail.re3.yahoo.com> <9478ED4C-1068-42A3-8247-EE5175742B96@audioimagination.com> Message-ID: <001701c9ed05$f0bce360$0201a8c0@mooncode> robert bristow-johnson wrote: > On Jun 12, 2009, at 8:57 AM, Vinnie wrote: >> http://img37.imageshack.us/img37/3885/dspjuce.png It seems "Gain" and "Step Response" show the same graph. That's not right; SR is a time-domain trace. >> - The group delay is the rate of change (derivative) of phase >> delay with respect to frequency. Of phase, not phase delay. Both phi/w and dphi/dw have units of time. > like the phase delay it's the *negative* of that derivative > w.r.t. *angular* frequency. there's some nice math that helps > simplify things and avoids problems due to phase wrapping. And you get there with a minimum of acrobatics if you start out by writing the phase response as imag(ln(H(z))), |z| = 1 instead of the arctan form. Martin From martin.eisenberg at udo.edu Sun Jun 14 11:45:42 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Sun Jun 14 11:43:00 2009 Subject: [music-dsp] Name of delay-free loop technique References: <002401c9d7d1$0aee5ce0$0201a8c0@mooncode><56BDCC96E6B94AF5BC7DF68F893A63C1@nibln01077><001201c9d8a6$2f916bc0$0201a8c0@mooncode><001201c9dca5$332d6f60$0201a8c0@mooncode><86DBA60A6D954C829C23571C46248EFE@nibln01077><029244E7BAD549C78B29E3DAB113FC06@nibln01077><000a01c9e21b$441cc3e0$0201a8c0@mooncode><003b01c9e383$904dab80$0201a8c0@mooncode> Message-ID: <002601c9ed07$2fd65760$0201a8c0@mooncode> Vadim Zavalishin wrote: >> It bothers me that the result is a square wave whenever the >> linearized loop is unstable, overestimating the signal values >> and tone brightness. > > I'm not sure how do you get to the square wave? Are you trying > to apply the "cheap" version to the instantaneously unstable > case? Still I think there should be no square wave, the system > should just stay "clipped" at one of the extremes. True for the ladder filter, but e.g. a loop containing a bandpass, saturator, and feedback gain will oscillate indefinitely when the linearized system would be strictly unstable. However my original concern turns out to be a non-issue as it seems that for the usual filter types, the discrete loop only becomes instantaneously unstable at parameter values so large as to bring the continuous system quite close to flat clipping already. Martin From martin.eisenberg at udo.edu Sun Jun 14 12:13:01 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Sun Jun 14 12:10:17 2009 Subject: [music-dsp] Re: Name for the integrator replacement technique References: <002b01c9e843$ed1e2b40$0201a8c0@mooncode> Message-ID: <003f01c9ed0b$00e80a80$0201a8c0@mooncode> Martin Eisenberg wrote: > Vadim Zavalishin wrote: > >> I was assuming that any real-world analog circuit is >> expressible using integrators, directly corresponding to the >> state-space equations describing the circuit. At any rate, the >> analog reactive elements (capacitors and inductors) >> essentially translate as integrators in block diagrams. > > You mean going from one Kirchhoff quantity to the other? And in > conjunction with an attached resistor, each reactive element > can be presented as an integrator in the more abstract block > diagram for any circuit? Your silence on this would seem to be an affirmation, but I've come to think what I said there doesn't make sense because as a unit, such a subcircuit with a resistor in it would not be an integrator. Please clarify what qualifications lurk in your use of "essentially" above. Martin From neolit123 at gmail.com Sun Jun 14 12:56:29 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Sun Jun 14 12:57:33 2009 Subject: [music-dsp] New: DspFilters 0.8.6 References: <647613.48543.qm@web58207.mail.re3.yahoo.com> Message-ID: <007401c9ed11$194be140$0201a8c0@LuboPC> Hello Vinnie, You can also add the "Butterworth-squared" (LR) to the collection. The only difference from the Butterworth LP / HP would be the -6dB attenuation at Fc. [wikipedia] <- general information http://www.linkwitzlab.com/filters.htm <- original analog design [music-dsp source archive] <- pseudo-code example Lubomir ----- Original Message ----- From: "Vinnie" To: Sent: Thursday, June 11, 2009 7:27 PM Subject: [music-dsp] New: DspFilters 0.8.6 > > I am pleased to announce version 0.8.6 of "A Collection of Useful C++ > Classes for Digital Signal Processing". The project has been moved: > > http://code.google.com/p/dspfilterscpp/ > > You can browse the code directly using SVN. This version includes source > code for a JUCE test application that exercises all of the filters. Real > time parameter changes are possible, and graphs show gain, phase, > response, and poles/zeros. You can build the test application yourself on > any platform that supports JUCE, or you can use the pre-built Windows > 32-bit executable (available separately on the project site) if you are > impatient. > > Screenshot of the test application: > http://img37.imageshack.us/img37/3885/dspjuce.png > > This library is still not complete, the shelves' ripple and gain > specifications don't work quite right, and the filters don't always > respect the 3dB point (especially for band pass and band stop). I'm > working on it. > > As always, feedback or constructive criticism is welcomed. > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From neolit123 at gmail.com Sun Jun 14 13:41:48 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Sun Jun 14 13:42:25 2009 Subject: [music-dsp] Re: Name for the integrator replacement technique References: <002b01c9e843$ed1e2b40$0201a8c0@mooncode> <003f01c9ed0b$00e80a80$0201a8c0@mooncode> Message-ID: <007d01c9ed17$687ad180$0201a8c0@LuboPC> >From my understanding: A resistor on its own or a resistor bridge cannot be considered an integrator, since that in the case of an resistor there is only time-invariable (excluding quantum error) voltage change applied to the signal path i.e. reduction of amplitude. However you can say "integrator resistor", assuming it is part of something else - operational amplifier stage. The delay lines in "digital" block diagrams can be directly related to exponential discharge of reactive, time-variable elements, which require application of Kirchhoff's law - i.e differential calculation. [On name topic]: I took the "network topology" or the use of "prototype network" from here: ---Wiki: Topology (electronics)--- "Strictly speaking, replacing a component with one of an entirely different type is still the same topology. In some contexts, however, these can loosely be described as different topologies. For instance, interchanging inductors and capacitors in a low-pass filter results in a high-pass filter. These might be described as high-pass and low-pass topologies even though the network topology is identical. A more correct term for these classes of object (that is, a network where the type of component is specified but not the absolute value) is prototype network." "Prototype network" links directly to "Prototype filter". However in my language the two words "topology" & "integrator" are not used much, by non-english savvy engineers... "Prototype" partially or just "Base" as a rought translation. Lubomir ----- Original Message ----- From: "Martin Eisenberg" To: "Mailingliste: music-dsp" Sent: Sunday, June 14, 2009 7:13 PM Subject: [music-dsp] Re: Name for the integrator replacement technique > Martin Eisenberg wrote: >> Vadim Zavalishin wrote: >> >>> I was assuming that any real-world analog circuit is >>> expressible using integrators, directly corresponding to the >>> state-space equations describing the circuit. At any rate, the >>> analog reactive elements (capacitors and inductors) >>> essentially translate as integrators in block diagrams. >> >> You mean going from one Kirchhoff quantity to the other? And in >> conjunction with an attached resistor, each reactive element >> can be presented as an integrator in the more abstract block >> diagram for any circuit? > > Your silence on this would seem to be an affirmation, but I've > come to think what I said there doesn't make sense because as a > unit, such a subcircuit with a resistor in it would not be an > integrator. Please clarify what qualifications lurk in your use > of "essentially" above. > > > Martin > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From vadim.zavalishin at native-instruments.de Mon Jun 15 05:01:05 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Mon Jun 15 05:01:27 2009 Subject: [music-dsp] Name of delay-free loop technique In-Reply-To: <002601c9ed07$2fd65760$0201a8c0@mooncode> References: <002401c9d7d1$0aee5ce0$0201a8c0@mooncode><56BDCC96E6B94AF5BC7DF68F893A63C1@nibln01077><001201c9d8a6$2f916bc0$0201a8c0@mooncode><001201c9dca5$332d6f60$0201a8c0@mooncode><86DBA60A6D954C829C23571C46248EFE@nibln01077><029244E7BAD549C78B29E3DAB113FC06@nibln01077><000a01c9e21b$441cc3e0$0201a8c0@mooncode><003b01c9e383$904dab80$0201a8c0@mooncode> <002601c9ed07$2fd65760$0201a8c0@mooncode> Message-ID: <0851C335E179445DA24F0147F2C0427C@nibln01077> >> I'm not sure how do you get to the square wave? Are you trying >> to apply the "cheap" version to the instantaneously unstable >> case? Still I think there should be no square wave, the system >> should just stay "clipped" at one of the extremes. > > True for the ladder filter, but e.g. a loop containing a > bandpass, saturator, and feedback gain will oscillate > indefinitely when the linearized system would be strictly > unstable. However my original concern turns out to be a non-issue > as it seems that for the usual filter types, the discrete loop > only becomes instantaneously unstable at parameter values so > large as to bring the continuous system quite close to flat > clipping already. While I didn't explicitly check this, I would rather expect, that the nonlinearity would "smooth down the corners". I don't think there is an essential difference between LP and BP filters in the feedback loop, as, from the point of the instantaneous feedback, both are representable as gx+s. That is, unless you are using the cheap approach, in which case the infinity is of course clipped to the square wave. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From vadim.zavalishin at native-instruments.de Mon Jun 15 05:10:44 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Mon Jun 15 05:11:00 2009 Subject: [music-dsp] Re: Name for the integrator replacement technique In-Reply-To: <003f01c9ed0b$00e80a80$0201a8c0@mooncode> References: <002b01c9e843$ed1e2b40$0201a8c0@mooncode> <003f01c9ed0b$00e80a80$0201a8c0@mooncode> Message-ID: >> You mean going from one Kirchhoff quantity to the other? And in >> conjunction with an attached resistor, each reactive element >> can be presented as an integrator in the more abstract block >> diagram for any circuit? > > Your silence on this would seem to be an affirmation, but I've > come to think what I said there doesn't make sense because as a > unit, such a subcircuit with a resistor in it would not be an > integrator. Please clarify what qualifications lurk in your use > of "essentially" above. The capacitor's voltage is an integral of the flowing current (scaled by a coefficient). Similarly, the inductor's current is an integral of the applied voltage. The active resistances in the circuit have only algebraic (and not integral/differential) effect, and thus translate as gains/summators (although the translation is not one to one). In other words, the system of equations explicitly describing an electronic circuit, consisting of capacitors, inductors, resistors, and linearized semiconductor elements, contains: - first order differential equations for inductors/capacitors (which translate as integrators) - linear algebraic equations for everything else If we don't linearize semiconductor elements, then nonlinear elements appear. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From vadim.zavalishin at native-instruments.de Mon Jun 15 05:42:30 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Mon Jun 15 05:42:45 2009 Subject: [music-dsp] Re: Name for the integrator replacement technique In-Reply-To: <007d01c9ed17$687ad180$0201a8c0@LuboPC> References: <002b01c9e843$ed1e2b40$0201a8c0@mooncode><003f01c9ed0b$00e80a80$0201a8c0@mooncode> <007d01c9ed17$687ad180$0201a8c0@LuboPC> Message-ID: > The delay lines in "digital" block diagrams can be directly related to > exponential discharge of reactive, time-variable elements, which require > application of Kirchhoff's law - i.e differential calculation. I think the above applies by far not every time. E.g. in a direct form second order filter, I woudn't know how to relate the delay elements to the differential calculation (that is of course, there's an indirect relationship, but they don't translate directly). That's exactly the question of state-variable preservation during discretization of time. On the other hand in TPT we explicitly ensure a direct relationship between the delay elements and the integrators. > > [On name topic]: > I took the "network topology" or the use of "prototype network" from here: > ---Wiki: Topology (electronics)--- > "Strictly speaking, replacing a component with one of an entirely > different type is still the same topology. In some contexts, however, > these can loosely be described as different topologies. For instance, > interchanging inductors and capacitors in a low-pass filter results in a > high-pass filter. These might be described as high-pass and low-pass > topologies even though the network topology is identical. A more correct > term for these classes of object (that is, a network where the type of > component is specified but not the absolute value) is prototype network." > > "Prototype network" links directly to "Prototype filter". > > However in my language the two words "topology" & "integrator" are not > used much, by non-english savvy engineers... > "Prototype" partially or just "Base" as a rought translation. So what do you actually suggest here in regards to naming the technique? (BTW we are talking about an English name, don't we?) Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From douglas at music.columbia.edu Mon Jun 15 07:00:01 2009 From: douglas at music.columbia.edu (douglas repetto) Date: Mon Jun 15 07:00:13 2009 Subject: [music-dsp] [admin] music-dsp FAQ Message-ID: <20090615110001.59AFF9EF11C@music.columbia.edu> Hi, Just a reminder that if you are new to the list you should read the music-dsp FAQ. It contains answers to both technical _and_ adminstrative questions that often come up on the list. If your question appears in the FAQ it is safe to assume that it has been discussed on the list many times in the past, and you should probably have a look through the list archives before posting your question to the list. http://music.columbia.edu/cmc/music-dsp/musicdspFAQ.html Also of interest to new and not-so-new list members: The music-dsp list archives http://music.columbia.edu/cmc/music-dsp/musicdsparchives.html The music-dsp source code archive http://www.musicdsp.org music-dsp books and reviews http://music.columbia.edu/cmc/music-dsp/dspbooks.html All this and more at: http://music.columbia.edu/cmc/music-dsp Hasta la pasta, douglas (this is an automated message sent out on the 1st and 15th of each month) From neolit123 at gmail.com Mon Jun 15 08:00:45 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Mon Jun 15 08:01:42 2009 Subject: [music-dsp] Re: Name for the integrator replacement technique References: <002b01c9e843$ed1e2b40$0201a8c0@mooncode><003f01c9ed0b$00e80a80$0201a8c0@mooncode><007d01c9ed17$687ad180$0201a8c0@LuboPC> Message-ID: <00c201c9edb0$f2c82600$0201a8c0@LuboPC> ----- Original Message ----- From: "Vadim Zavalishin" >> The delay lines in "digital" block diagrams can be directly related to >> exponential discharge of reactive, time-variable elements, which require >> application of Kirchhoff's law - i.e differential calculation. > > I think the above applies by far not every time. E.g. in a direct form > second order filter, I woudn't know how to relate the delay elements to > the differential calculation (that is of course, there's an indirect > relationship, but they don't translate directly). That's exactly the > question of state-variable preservation during discretization of time. On > the other hand in TPT we explicitly ensure a direct relationship between > the delay elements and the integrators. > I guess my statement is partially incorrect as I suggested only the A -> D transition. So, indeed a standard second order digital filter block diagram, does not say much about the original differential calculations in the analogue prototype. So its one way "full" conversation and the other way around is partial in some cases. Basically any methods, ensuring such relations are welcome. I never found a link to any paper regarding the discussed techniques. Could you point me out to one? >> >> [On name topic]: >> I took the "network topology" or the use of "prototype network" from >> here: >> ---Wiki: Topology (electronics)--- >> "Strictly speaking, replacing a component with one of an entirely >> different type is still the same topology. In some contexts, however, >> these can loosely be described as different topologies. For instance, >> interchanging inductors and capacitors in a low-pass filter results in a >> high-pass filter. These might be described as high-pass and low-pass >> topologies even though the network topology is identical. A more correct >> term for these classes of object (that is, a network where the type of >> component is specified but not the absolute value) is prototype network." >> >> "Prototype network" links directly to "Prototype filter". >> >> However in my language the two words "topology" & "integrator" are not >> used much, by non-english savvy engineers... >> "Prototype" partially or just "Base" as a rought translation. > > So what do you actually suggest here in regards to naming the technique? > (BTW we are talking about an English name, don't we?) > Note that I'm not questioning the accuracy of TPT, as it is sufficient naming at _any_ SP level discussions. But still, if one is looking for something slightly (a pinch) more descriptive (to ensure signal processing as the target area), it should be something like NTPT - as network topology-preserving transform. But I cannot insist at all on this one... Alternatively, proposed earlier: "Prototype network transform": Where: Integrator _type_ replacements in the "Prototype network", result in changes in the passband type , while a simple scalling of the values results in changing the target range ? Could be incorrect again as my english terminology (tech talk) could be quite shaky, it seems. Lubomir From neolit123 at gmail.com Mon Jun 15 08:11:04 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Mon Jun 15 08:11:46 2009 Subject: [music-dsp] Video lectures on DSP (IIT Delhi) Message-ID: <00e801c9edb2$5e448440$0201a8c0@LuboPC> ----- Original Message ----- From: "Lubomir I. Ivanov" To: "A discussion list for music-related DSP" Sent: Sunday, June 14, 2009 12:04 PM Subject: Video lectures on DSP (IIT Delhi) > [Could be a repost] > > I was looking for a paper on something and stumbled on these: > > > Prof. S.C Dutta Roy, Department of Electrical Engineering, IIT Delhi > > 43 - 1 hour lectures on DSP at: > > http://www.youtube.com/view_play_list?p=9567DFCA3A66F299 > > Hmm, not sure why I've replied to another message instead of making a new thread. Good lectures. Very well presented... Lubomir From vadim.zavalishin at native-instruments.de Mon Jun 15 08:26:40 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Mon Jun 15 08:26:54 2009 Subject: [music-dsp] Re: Name for the integrator replacement technique In-Reply-To: <00c201c9edb0$f2c82600$0201a8c0@LuboPC> References: <002b01c9e843$ed1e2b40$0201a8c0@mooncode><003f01c9ed0b$00e80a80$0201a8c0@mooncode><007d01c9ed17$687ad180$0201a8c0@LuboPC> <00c201c9edb0$f2c82600$0201a8c0@LuboPC> Message-ID: > I guess my statement is partially incorrect as I suggested only the A -> D > transition. So, indeed a standard second order digital filter block > diagram, does not say much about the original differential calculations in > the analogue prototype. So its one way "full" conversation and the other > way around is partial in some cases. Basically any methods, ensuring such > relations are welcome. I never found a link to any paper regarding the > discussed techniques. Could you point me out to one? http://www.native-instruments.com/index.php?id=dsparticles Mostly it's the first article, although the third one is related to the nonlinearities processing. The second one uses similar technique for frequency scaling in digital domain. The point is that, with a classical approach, even "one way" is not a complete conversion, as the time-variant behavior of the system is not too well preserved. Only the static behavior, described by the transfer function, is more or less converted. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From martin.eisenberg at udo.edu Mon Jun 15 09:43:24 2009 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Mon Jun 15 09:40:47 2009 Subject: [music-dsp] Name of delay-free loop technique References: <002401c9d7d1$0aee5ce0$0201a8c0@mooncode><56BDCC96E6B94AF5BC7DF68F893A63C1@nibln01077><001201c9d8a6$2f916bc0$0201a8c0@mooncode><001201c9dca5$332d6f60$0201a8c0@mooncode><86DBA60A6D954C829C23571C46248EFE@nibln01077><029244E7BAD549C78B29E3DAB113FC06@nibln01077><000a01c9e21b$441cc3e0$0201a8c0@mooncode><003b01c9e383$904dab80$0201a8c0@mooncode><002601c9ed07$2fd65760$0201a8c0@mooncode> <0851C335E179445DA24F0147F2C0427C@nibln01077> Message-ID: <001901c9edbf$45be36c0$0201a8c0@mooncode> Vadim Zavalishin wrote: >> However my original concern turns out to be a non-issue >> as it seems that for the usual filter types, the discrete >> loop only becomes instantaneously unstable at parameter >> values so large as to bring the continuous system >> quite close to flat clipping already. > > While I didn't explicitly check this, I would rather expect, > that the nonlinearity would "smooth down the corners". It does. Nevertheless, the tops get flatter the harder you drive it. Martin From jeremy at n-heptane.com Mon Jun 15 16:03:25 2009 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Mon Jun 15 16:03:41 2009 Subject: [music-dsp] What is the waveform with even harmonics called Message-ID: <87ws7dcliq.wl%jeremy@n-heptane.com> Hello, What is the name of the waveform which has even harmonics which fall off at 6dB/octave? By comparison: sawtooth wave = even + odd harmonics falling off at 6dB/octave square = odd harmonics falling off at 6dB/octave triangle wave = odd harmonics falling off at 12dB/octave You can see what it looks like using this matlab/octave code: # even wave N = 2000; t = ([0:1000] / 1000) * 4 * pi; f = zeros (1,1001); for k = [1,(1:2:N)+1] f = f + sin (k * t) / k; end f = f * 0.88678; plot(t,f) set(gca,'XTick',0:pi/2:4*pi) set(gca,'XTickLabel',{'0','pi/2','pi','3pi/2','2pi','5pi/2','3pi','7pi/2','4pi'}) grid on axis normal Are there any nifty ways to generate this waveform efficiently? thanks! - jeremy From czhenry at gmail.com Mon Jun 15 17:26:37 2009 From: czhenry at gmail.com (Charles Henry) Date: Mon Jun 15 17:26:50 2009 Subject: [music-dsp] What is the waveform with even harmonics called In-Reply-To: <87ws7dcliq.wl%jeremy@n-heptane.com> References: <87ws7dcliq.wl%jeremy@n-heptane.com> Message-ID: <518fe7b20906151426u1a82e1a5k3e2cf887eb3616e9@mail.gmail.com> On Mon, Jun 15, 2009 at 3:03 PM, Jeremy Shaw wrote: > Hello, > > What is the name of the waveform which has even harmonics which fall > off at 6dB/octave? Take the even numbers and divide them by two. Then you have a full harmonic series. So, the even harmonics are just a harmonic series that is one octave higher. It's a sawtooth wave plus a sine one octave down. There's any number of different functions that will be orthogonal to the odd-numbered harmonics, but not as likely that it will be one of these "easy" functions like square, sawtooth, or triangle. > By comparison: > > ?sawtooth wave = even + odd harmonics falling off at 6dB/octave > ?square ? ? ? ?= odd harmonics falling off at 6dB/octave > ?triangle wave = odd harmonics falling off at 12dB/octave > > You can see what it looks like using this matlab/octave code: > > # even wave > N = 2000; > t = ([0:1000] / 1000) * 4 * pi; > f = zeros (1,1001); > for k = [1,(1:2:N)+1] > ?f = f + sin (k * t) / k; > end > f = f * 0.88678; > plot(t,f) > set(gca,'XTick',0:pi/2:4*pi) > set(gca,'XTickLabel',{'0','pi/2','pi','3pi/2','2pi','5pi/2','3pi','7pi/2','4pi'}) > grid on > axis normal > > Are there any nifty ways to generate this waveform efficiently? > > thanks! > - jeremy > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From didid at skynet.be Mon Jun 15 18:04:01 2009 From: didid at skynet.be (Didier Dambrin) Date: Mon Jun 15 18:04:16 2009 Subject: [music-dsp] What is the waveform with even harmonics called In-Reply-To: <87ws7dcliq.wl%jeremy@n-heptane.com> References: <87ws7dcliq.wl%jeremy@n-heptane.com> Message-ID: <6EDD42D750D74346AD66ABABCB6C1996@GOLAMD> I don't see why waveforms would necessarily need a name. IMHO to generate any bandlimited (short) waveform efficiently, an inverse FFT is really the best choice. These days it's very little CPU. Then once you have direct access to harmonics & phases, you forget traditional (named) waveforms and you play with sound in a better way. > Hello, > > What is the name of the waveform which has even harmonics which fall > off at 6dB/octave? > > By comparison: > > sawtooth wave = even + odd harmonics falling off at 6dB/octave > square = odd harmonics falling off at 6dB/octave > triangle wave = odd harmonics falling off at 12dB/octave > > You can see what it looks like using this matlab/octave code: > > # even wave > N = 2000; > t = ([0:1000] / 1000) * 4 * pi; > f = zeros (1,1001); > for k = [1,(1:2:N)+1] > f = f + sin (k * t) / k; > end > f = f * 0.88678; > plot(t,f) > set(gca,'XTick',0:pi/2:4*pi) > set(gca,'XTickLabel',{'0','pi/2','pi','3pi/2','2pi','5pi/2','3pi','7pi/2','4pi'}) > grid on > axis normal > > Are there any nifty ways to generate this waveform efficiently? > > thanks! > - jeremy > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.364 / Virus Database: 270.12.70/2177 - Release Date: 06/15/09 05:54:00 From neolit123 at gmail.com Tue Jun 16 01:25:59 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Tue Jun 16 01:27:21 2009 Subject: [music-dsp] Re: Name for the integrator replacement technique References: <002b01c9e843$ed1e2b40$0201a8c0@mooncode><003f01c9ed0b$00e80a80$0201a8c0@mooncode><007d01c9ed17$687ad180$0201a8c0@LuboPC><00c201c9edb0$f2c82600$0201a8c0@LuboPC> Message-ID: <004601c9ee42$f4c08640$0201a8c0@LuboPC> ----- Original Message ----- From: "Vadim Zavalishin" > http://www.native-instruments.com/index.php?id=dsparticles > > Mostly it's the first article, although the third one is related to the > nonlinearities processing. The second one uses similar technique for > frequency scaling in digital domain. > Thanks for the link to the papers. I will check them out later. > The point is that, with a classical approach, even "one way" is not a > complete conversion, as the time-variant behavior of the system is not too > well preserved. Only the static behavior, described by the transfer > function, is more or less converted. > Yes, of course. The non-linear behaviour of elements like tubes, transistors require more work. Although a lot of people seem happy with the time-invariance the standard digital implementations, others like musicians, call it "warmth" and seem to miss it - in the digital form. Regards Lubomir From vadim.zavalishin at native-instruments.de Tue Jun 16 04:09:43 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Tue Jun 16 04:10:00 2009 Subject: [music-dsp] Re: Name for the integrator replacement technique In-Reply-To: <004601c9ee42$f4c08640$0201a8c0@LuboPC> References: <002b01c9e843$ed1e2b40$0201a8c0@mooncode><003f01c9ed0b$00e80a80$0201a8c0@mooncode><007d01c9ed17$687ad180$0201a8c0@LuboPC><00c201c9edb0$f2c82600$0201a8c0@LuboPC> <004601c9ee42$f4c08640$0201a8c0@LuboPC> Message-ID: <36C0685C330348E6AC25238B0AD1BCEF@nibln01077> >> The point is that, with a classical approach, even "one way" is not a >> complete conversion, as the time-variant behavior of the system is not >> too well preserved. Only the static behavior, described by the transfer >> function, is more or less converted. >> > > Yes, of course. The non-linear behaviour of elements like tubes, > transistors require more work. Although a lot of people seem happy with > the time-invariance the standard digital implementations, others like > musicians, call it "warmth" and seem to miss it - in the digital form. I think there is some misunderstanding. I was referring to time-variant behavior (when the parameters are modulated), rather than what is most commonly implied by nonlinearities (waveshaping). Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From neolit123 at gmail.com Tue Jun 16 06:49:11 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Tue Jun 16 06:49:38 2009 Subject: [music-dsp] Re: Name for the integrator replacement technique References: <002b01c9e843$ed1e2b40$0201a8c0@mooncode><003f01c9ed0b$00e80a80$0201a8c0@mooncode><007d01c9ed17$687ad180$0201a8c0@LuboPC><00c201c9edb0$f2c82600$0201a8c0@LuboPC><004601c9ee42$f4c08640$0201a8c0@LuboPC> <36C0685C330348E6AC25238B0AD1BCEF@nibln01077> Message-ID: <001201c9ee70$189c8af0$0201a8c0@LuboPC> From: "Vadim Zavalishin" >>> The point is that, with a classical approach, even "one way" is not a >>> complete conversion, as the time-variant behavior of the system is not >>> too well preserved. Only the static behavior, described by the transfer >>> function, is more or less converted. >>> >> >> Yes, of course. The non-linear behaviour of elements like tubes, >> transistors require more work. Although a lot of people seem happy with >> the time-invariance the standard digital implementations, others like >> musicians, call it "warmth" and seem to miss it - in the digital form. > > I think there is some misunderstanding. I was referring to time-variant > behavior (when the parameters are modulated), rather than what is most > commonly implied by nonlinearities (waveshaping). > I think I understand, Vadim. :-) Havent checked the papers yet though. I'm going to write something on non-linearities below. --- Here are some thoughts on non-linear modelling. [This could be considered offtopic Read on if you find the subject interesting and please reply in a *new thread*, if you wish to continue this separate discussion.] Its common to say in electronics that a transistor is a non-linear element, in regard of its "wave-shaping" behaviour - or saturation. The other type of non-linear behaviour is what most engineers disregard in dsp designs. In fact all electronic elements (and all things in the world) are non-linear. For example: If we measure a generator of 12 volt direct current with a high resolution oscilloscope, we will not-observe a straight line. If we run perfect 12 volts on the input of a resistor R1, with impedance X ohms the output voltage will not be a constant Y volts. If we put 0 volts in the transistor input, some voltage in the collector, and we measure the voltage in the emitter, there also be values, which change in time. This non-linear behaviour is called fluxuation or flux in electronics (afaik). It is possible to measure this "range of error". As given in the above examples the flux for each element of the circuit _can_ be measured. For the above R1 resistor - implementing it in DSP in the lines of: input = input * 0.0098; It should be: Routput = Rinput * (0.0098 + (random(2)-1)*error_range); ^ Where "error_range" is a very small number (e.x. 10^-6) representing the range in which the error occurs. Another question which can be raised here would be, if the used PRNG random function will provide accurate emulation of the flux for this particular element. Both should be compared with accuracy. Its important to note that once an circuit is switched on it becomes a part of much bigger system, with temperature, moisture and other dependencies. (quantum field theory ?) I love the joke where the engineer claims that a compressor sounds "warmer", 20 minutes after switched on. Well it obviously sounds warmer due to the transformers heating up, but this heat also changes the behaviour in each element due to the composite materials from which its constructed. This also can be implemented in DSP, with some physics and dependencies if wanted, so that "error_range" is not a constant. When it comes down ot accuracy, clean math is perfectly acceptable. However I think the purification of clean math found in DSP *sound effects*, is a definite minus. A question is to what degree an analog system can be accurately modelled and would it be worth it. I think that even if we are modelling error, it may be worth it. Just some ideas... [Again please note that this is offtopic Its from a recent discussion I had with someone.] Lubomir From neolit123 at gmail.com Tue Jun 16 07:15:01 2009 From: neolit123 at gmail.com (Lubomir I. Ivanov) Date: Tue Jun 16 07:15:26 2009 Subject: [music-dsp] Re: Name for the integrator replacement technique References: <002b01c9e843$ed1e2b40$0201a8c0@mooncode><003f01c9ed0b$00e80a80$0201a8c0@mooncode><007d01c9ed17$687ad180$0201a8c0@LuboPC><00c201c9edb0$f2c82600$0201a8c0@LuboPC><004601c9ee42$f4c08640$0201a8c0@LuboPC> <36C0685C330348E6AC25238B0AD1BCEF@nibln01077> Message-ID: <002601c9ee73$b7102c70$0201a8c0@LuboPC> Oops Correction: "resistance X ohms" not impedance.... :) Lubomir From vadim.zavalishin at native-instruments.de Tue Jun 16 07:15:28 2009 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Tue Jun 16 07:15:45 2009 Subject: [music-dsp] Re: Name for the integrator replacement technique In-Reply-To: <001201c9ee70$189c8af0$0201a8c0@LuboPC> References: <002b01c9e843$ed1e2b40$0201a8c0@mooncode><003f01c9ed0b$00e80a80$0201a8c0@mooncode><007d01c9ed17$687ad180$0201a8c0@LuboPC><00c201c9edb0$f2c82600$0201a8c0@LuboPC><004601c9ee42$f4c08640$0201a8c0@LuboPC><36C0685C330348E6AC25238B0AD1BCEF@nibln01077> <001201c9ee70$189c8af0$0201a8c0@LuboPC> Message-ID: <97FC174267434C1AA94CA9B8B200A6B1@nibln01077> > A question is to what degree an analog system can be accurately modelled > and would it be worth it. I think that even if we are modelling error, it > may be worth it. (Without starting a new thread, as I'm not planning on a long discussion) The "analog drift" is probably a good example of that :-) I think quite a number of synths do that. Regards, Vadim -- Vadim Zavalishin Senior Software Developer | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic From nostromo at arkaos.net Wed Jun 17 05:15:24 2009 From: nostromo at arkaos.net (M-.-n) Date: Wed Jun 17 05:15:32 2009 Subject: [music-dsp] What is the waveform with even harmonics called In-Reply-To: <6EDD42D750D74346AD66ABABCB6C1996@GOLAMD> References: <87ws7dcliq.wl%jeremy@n-heptane.com> <6EDD42D750D74346AD66ABABCB6C1996@GOLAMD> Message-ID: <003901c9ef2c$25bd6b20$71384160$@net> Sorry to sound like such a noob, but how do you relate the factors of a FFT that is bound to the sampling rate to one that is related to the harmonic serie of an oscillator running at a non related frequency ? Do you operate at the oscillator frequency and then proceed to resampling in the time domain or is it possible to combine everything in one single operation ? Thanks Marc. -----Original Message----- From: music-dsp-bounces@music.columbia.edu [mailto:music-dsp-bounces@music.columbia.edu] On Behalf Of Didier Dambrin Sent: mardi 16 juin 2009 0:04 To: A discussion list for music-related DSP Subject: Re: [music-dsp] What is the waveform with even harmonics called I don't see why waveforms would necessarily need a name. IMHO to generate any bandlimited (short) waveform efficiently, an inverse FFT is really the best choice. These days it's very little CPU. Then once you have direct access to harmonics & phases, you forget traditional (named) waveforms and you play with sound in a better way. From padawan12 at obiwannabe.co.uk Wed Jun 17 05:50:26 2009 From: padawan12 at obiwannabe.co.uk (padawan12@obiwannabe.co.uk) Date: Wed Jun 17 05:50:40 2009 Subject: [music-dsp] What is the waveform with even harmonics called Message-ID: <25834941.332091245232226057.JavaMail.servlet@kundenserver> It's worth remembering that sometimes in sound synthesis (and other engineering applications) it's the time domain properties of a wave that we are really interested in. For example, as a control waveform (say the sawtooth/phasor used as a display scanline) or if a sound synthesis design despends upon subsequent non-linear stages (waveshaping). In these cases we are interested in the shape, so classical waveform names are really about naming the shape. a. I don't see why waveforms would necessarily need a name. IMHO to generate any bandlimited (short) waveform efficiently, an inverse FFT is really the best choice. These days it's very little CPU. Then once you have direct access to harmonics & phases, you forget traditional (named) waveforms and you play with sound in a better way. > Hello, > > What is the name of the waveform which has even harmonics which fall > off at 6dB/octave? > > By comparison: > > sawtooth wave = even + odd harmonics falling off at 6dB/octave > square = odd harmonics falling off at 6dB/octave > triangle wave = odd harmonics falling off at 12dB/octave > > You can see what it looks like using this matlab/octave code: > > # even wave > N = 2000; > t = ([0:1000] / 1000) * 4 * pi; > f = zeros (1,1001); > for k = [1,(1:2:N)+1] > f = f + sin (k * t) / k; > end > f = f * 0.88678; > plot(t,f) > set(gca,'XTick',0:pi/2:4*pi) > set(gca,'XTickLabel',{'0','pi/2','pi','3pi/2','2pi','5pi/2','3pi','7pi/2','4pi'} ) > grid on > axis normal > > Are there any nifty ways to generate this waveform efficiently? > > thanks! > - jeremy > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.364 / Virus Database: 270.12.70/2177 - Release Date: 06/15/09 05:54:00 -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp From didid at skynet.be Wed Jun 17 06:26:54 2009 From: didid at skynet.be (Didier Dambrin) Date: Wed Jun 17 06:27:19 2009 Subject: [music-dsp] What is the waveform with even harmonics called In-Reply-To: <003901c9ef2c$25bd6b20$71384160$@net> References: <87ws7dcliq.wl%jeremy@n-heptane.com><6EDD42D750D74346AD66ABABCB6C1996@GOLAMD> <003901c9ef2c$25bd6b20$71384160$@net> Message-ID: <9A5987051E464E0EAD628535E3698A73@GOLAMD> You would indeed compute a shape somewhat larger (depending on your interpolation method) than a phase at the samplerate, & resample. The only flaw with this design is if you want to pitchbend, you may have to recompute bandlimited shape. But instead, I'd suggest processing at twice the samplerate, bandlimiting at 1.5 nyquist, leaving you a +-6 semitones pitch bending. > Sorry to sound like such a noob, but how do you relate the factors of a > FFT > that is bound to the sampling rate to one that is related to the harmonic > serie of an oscillator running at a non related frequency ? Do you operate > at the oscillator frequency and then proceed to resampling in the time > domain or is it possible to combine everything in one single operation ? > > Thanks > Marc. > > -----Original Message----- > From: music-dsp-bounces@music.columbia.edu > [mailto:music-dsp-bounces@music.columbia.edu] On Behalf Of Didier Dambrin > Sent: mardi 16 juin 2009 0:04 > To: A discussion list for music-related DSP > Subject: Re: [music-dsp] What is the waveform with even harmonics called > > I don't see why waveforms would necessarily need a name. > > IMHO to generate any bandlimited (short) waveform efficiently, an inverse > FFT is really the best choice. These days it's very little CPU. > > Then once you have direct access to harmonics & phases, you forget > traditional (named) waveforms and you play with sound in a better way. > > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.364 / Virus Database: 270.12.76/2183 - Release Date: 06/17/09 05:53:00 From jchandjr at bellsouth.net Wed Jun 17 08:19:16 2009 From: jchandjr at bellsouth.net (James Chandler Jr) Date: Wed Jun 17 08:19:59 2009 Subject: [music-dsp] What is the waveform with even harmonics called In-Reply-To: <25834941.332091245232226057.JavaMail.servlet@kundenserver> References: <25834941.332091245232226057.JavaMail.servlet@kundenserver> Message-ID: <9F02CA23-E9B0-4714-88D6-68CB9EED2FF3@bellsouth.net> On Jun 17, 2009, at 5:50 AM, padawan12@obiwannabe.co.uk wrote: > It's worth remembering that sometimes in sound synthesis > (and other engineering applications) it's the time domain > properties of a wave that we are really interested in. > > For example, as a control waveform (say the sawtooth/phasor > used as a display scanline) or if a sound synthesis design > despends upon subsequent non-linear stages (waveshaping). > In these cases we are interested in the shape, so classical > waveform names are really about naming the shape. Thanks. Made me think about 'turning the idea inside out'-- I wonder if anyone has explored the mangling of LFO control waveforms via phase shifters? Seems an obvious idea but I don't recall trying it or reading about it. Run the stereotypical triangle or sawtooth LFO thru phase shifting, to scatter the harmonics. The altered modulation time patterns might be interesting. One could even feed the LFO waveform thru an auto- sweeping phase shifter so that the LFO wave shape would continually 'evolve'. James From didid at skynet.be Wed Jun 17 09:45:01 2009 From: didid at skynet.be (Didier Dambrin) Date: Wed Jun 17 09:45:25 2009 Subject: [music-dsp] What is the waveform with even harmonics called In-Reply-To: <25834941.332091245232226057.JavaMail.servlet@kundenserver> References: <25834941.332091245232226057.JavaMail.servlet@kundenserver> Message-ID: <45F1164301674736A3D8A6CC7EBD8A63@GOLAMD> Even there you certainly can't rely on names because what's offered as a sawtooth in synths is quite often not a pure sawtooth, just something that sounds alike. > It's worth remembering that sometimes in sound synthesis > (and other engineering applications) it's the time domain > properties of a wave that we are really interested in. > > For example, as a control waveform (say the sawtooth/phasor > used as a display scanline) or if a sound synthesis design > despends upon subsequent non-linear stages (waveshaping). > In these cases we are interested in the shape, so classical > waveform names are really about naming the shape. > > a. > > > I don't see why waveforms would necessarily need a name. > > IMHO to generate any bandlimited (short) waveform efficiently, an inverse > FFT is really the best choice. These days it's very little CPU. > > Then once you have direct access to harmonics & phases, you forget > traditional (named) waveforms and you play with sound in a better way. > > > > > >> Hello, >> >> What is the name of the waveform which has even harmonics which fall >> off at 6dB/octave? >> >> By comparison: >> >> sawtooth wave = even + odd harmonics falling off at 6dB/octave >> square = odd harmonics falling off at 6dB/octave >> triangle wave = odd harmonics falling off at 12dB/octave >> >> You can see what it looks like using this matlab/octave code: >> >> # even wave >> N = 2000; >> t = ([0:1000] / 1000) * 4 * pi; >> f = zeros (1,1001); >> for k = [1,(1:2:N)+1] >> f = f + sin (k * t) / k; >> end >> f = f * 0.88678; >> plot(t,f) >> set(gca,'XTick',0:pi/2:4*pi) >> > set(gca,'XTickLabel',{'0','pi/2','pi','3pi/2','2pi','5pi/2','3pi','7pi/2','4pi'} > ) >> grid on >> axis normal >> >> Are there any nifty ways to generate this waveform efficiently? >> >> thanks! >> - jeremy >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, source code archive, list archive, book reviews, >> dsp links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp > > > -------------------------------------------------------------------------------- > > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.364 / Virus Database: 270.12.70/2177 - Release Date: 06/15/09 > 05:54:00 > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp > links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.364 / Virus Database: 270.12.76/2183 - Release Date: 06/17/09 05:53:00 From padawan12 at obiwannabe.co.uk Wed Jun 17 10:12:50 2009 From: padawan12 at obiwannabe.co.uk (padawan12@obiwannabe.co.uk) Date: Wed Jun 17 10:13:11 2009 Subject: [music-dsp] What is the waveform with even harmonics called Message-ID: <22926285.39671245247970255.JavaMail.servlet@kundenserver> Even there you certainly can't rely on names because what's offered as a sawtooth in synths is quite often not a pure sawtooth, just something that sounds alike. Absolutely, I seem to remember an 'expansion board' or some kind of ROM I once had for my Roland 1080, nothing but variations on sawtooths from different analogue synthesisers! My distinction is between the sound, and the use, if you like. For instance, when I specify a phasor, there is no subjectivity in that name, it's like invoking a Platonic shape - I expect a perfectly linear unipolar function. The 'ideal' triangle wave is also just that... ideal, and so forth. a. > It's worth remembering that sometimes in sound synthesis > (and other engineering applications) it's the time domain > properties of a wave that we are really interested in. > > For example, as a control waveform (say the sawtooth/phasor > used as a display scanline) or if a sound synthesis design > despends upon subsequent non-linear stages (waveshaping). > In these cases we are interested in the shape, so classical > waveform names are really about naming the shape. > > a. > > > I don't see why waveforms would necessarily need a name. > > IMHO to generate any bandlimited (short) waveform efficiently, an inverse > FFT is really the best choice. These days it's very little CPU. > > Then once you have direct access to harmonics & phases, you forget > traditional (named) waveforms and you play with sound in a better way. > > > > > >> Hello, >> >> What is the name of the waveform which has even harmonics which fall >> off at 6dB/octave? >> >> By comparison: >> >> sawtooth wave = even + odd harmonics falling off at 6dB/octave >> square = odd harmonics falling off at 6dB/octave >> triangle wave = odd harmonics falling off at 12dB/octave >> >> You can see what it looks like using this matlab/octave code: >> >> # even wave >> N = 2000; >> t = ([0:1000] / 1000) * 4 * pi; >> f = zeros (1,1001); >> for k = [1,(1:2:N)+1] >> f = f + sin (k * t) / k; >> end >> f = f * 0.88678; >> plot(t,f) >> set(gca,'XTick',0:pi/2:4*pi) >> > set(gca,'XTickLabel',{'0','pi/2','pi','3pi/2','2pi','5pi/2','3pi','7pi/2','4pi'} > ) >> grid on >> axis normal >> >> Are there any nifty ways to generate this waveform efficiently? >> >> thanks! >> - jeremy >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, source code archive, list archive, book reviews, >> dsp links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp > > > -------------------------------------------------------------------------------- > > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.364 / Virus Database: 270.12.70/2177 - Release Date: 06/15/09 > 05:54:00 > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp > links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.364 / Virus Database: 270.12.76/2183 - Release Date: 06/17/09 05:53:00 -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp From jeremy at n-heptane.com Wed Jun 17 18:39:28 2009 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Wed Jun 17 18:39:42 2009 Subject: [music-dsp] What is the waveform with even harmonics called In-Reply-To: <87ws7dcliq.wl%jeremy@n-heptane.com> References: <87ws7dcliq.wl%jeremy@n-heptane.com> Message-ID: <87skhycwnz.wl%jeremy@n-heptane.com> So, in summary, At first it seems unusual that we have names for simply defined wave forms such as: sawtooth wave = even + odd harmonics falling off at 6dB/octave square = odd harmonics falling off at 6dB/octave triangle wave = odd harmonics falling off at 12dB/octave But that we don't have a counterpart to square and triangle for even harmonics. But, upon further examination it makes more sense. The above waveforms (as well as sine) 1. sound fairly distinct 2. are close to other fairly primative shapes (squares, triangles, circles) 2. are not trivially generated by simple additions of two existing waveforms (ie, not easy to create on a two oscillator synth) The waveform with even harmonics falling off at 6dB/octave has none of these properties: 1. it sounds like a sawtooth with a sine-wave sub-osc an octave down 2. it looks really funny 3. it is trivial to recreate using a normal two oscilator synth And, in fact, when creating the matlab code, my code initially had a bug where it did not include the 'fundamental' frequency, and so I just got out a sawtooth wave. :p As for wanting a name -- it makes it easier to search on google for a waveform that has a name versus one that does not. But, in this case, it seems like a very uninteresting waveform anyway. I was curious about it, because I have seen many people claim that people prefer distortion that provides even order harmonics instead of odd order harmonics. So, it seemed amiss that there was not a common waveform with only even order harmonics... (Actually, I did create a different wave with even order harmonics -- namely the fully-rectified sine wave). Thanks! - jeremy From didid at skynet.be Wed Jun 17 20:38:46 2009 From: didid at skynet.be (Didier Dambrin) Date: Wed Jun 17 20:39:13 2009 Subject: [music-dsp] What is the waveform with even harmonics called In-Reply-To: <87skhycwnz.wl%jeremy@n-heptane.com> References: <87ws7dcliq.wl%jeremy@n-heptane.com> <87skhycwnz.wl%jeremy@n-heptane.com> Message-ID: <129CDFC7DB48432F88BF0BB44BF57B32@GOLAMD> > So, in summary, > > At first it seems unusual that we have names for simply defined wave forms > such as: > > sawtooth wave = even + odd harmonics falling off at 6dB/octave > square = odd harmonics falling off at 6dB/octave > triangle wave = odd harmonics falling off at 12dB/octave > > But that we don't have a counterpart to square and triangle for even > harmonics. But, upon further examination it makes more sense. The > above waveforms (as well as sine) > > 1. sound fairly distinct triangle isn't much interesting, sounds like a slighty saturated sine > 2. are close to other fairly primative shapes (squares, triangles, > circles) that's pretty much the only reason IMHO > 2. are not trivially generated by simple additions of two existing > waveforms (ie, not easy to create on a two oscillator synth) square can be computed out of saws > The waveform with even harmonics falling off at 6dB/octave has none of > these properties: > > 1. it sounds like a sawtooth with a sine-wave sub-osc an octave down > 2. it looks really funny > 3. it is trivial to recreate using a normal two oscilator synth > > And, in fact, when creating the matlab code, my code initially had a > bug where it did not include the 'fundamental' frequency, and so I > just got out a sawtooth wave. :p > > As for wanting a name -- it makes it easier to search on google for a > waveform that has a name versus one that does not. But, in this case, > it seems like a very uninteresting waveform anyway. > > I was curious about it, because I have seen many people claim that > people prefer distortion that provides even order harmonics instead of > odd order harmonics. So, it seemed amiss that there was not a common > waveform with only even order harmonics... > > (Actually, I did create a different wave with even order harmonics -- > namely the fully-rectified sine wave). > > Thanks! > - jeremy > > > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.364 / Virus Database: 270.12.77/2184 - Release Date: 06/17/09 17:55:00 From richarddobson at blueyonder.co.uk Thu Jun 18 04:36:02 2009 From: richarddobson at blueyonder.co.uk (Richard Dobson) Date: Thu Jun 18 04:37:59 2009 Subject: [music-dsp] What is the waveform with even harmonics called In-Reply-To: <129CDFC7DB48432F88BF0BB44BF57B32@GOLAMD> References: <87ws7dcliq.wl%jeremy@n-heptane.com> <87skhycwnz.wl%jeremy@n-heptane.com> <129CDFC7DB48432F88BF0BB44BF57B32@GOLAMD> Message-ID: <4A39FC72.4060701@blueyonder.co.uk> Didier Dambrin wrote: .. > > triangle isn't much interesting, sounds like a slighty saturated sine > But useful: ~very~ important as a modulation source (LFO), and where (as with the other waveforms) the absence of wiggles may often be valuable musically. Waveforms are not just to be listened to directly. As control signals the geometric waveforms have a key role, while all manner of extended exotica (smoothly-varying random waveforms, self-modulated waveforms etc) also matter. Sometimes, classic geometric "perfection" is required; at other times the absence of predictability (or simply a more subtle organic quality) is sought. Richard Dobson From didid at skynet.be Thu Jun 18 08:20:34 2009 From: didid at skynet.be (Didier Dambrin) Date: Thu Jun 18 08:20:59 2009 Subject: [music-dsp] What is the waveform with even harmonics called In-Reply-To: <4A39FC72.4060701@blueyonder.co.uk> References: <87ws7dcliq.wl%jeremy@n-heptane.com> <87skhycwnz.wl%jeremy@n-heptane.com><129CDFC7DB48432F88BF0BB44BF57B32@GOLAMD> <4A39FC72.4060701@blueyonder.co.uk> Message-ID: <3A4A7561460F430FB871D2ADFB3DC4EF@GOLAMD> Yes but as LFO or for other purpose we're talking about something else, you wouldn't want to generate them bandlimited in those cases. Same for FM modulators. >> triangle isn't much interesting, sounds like a slighty saturated sine >> > > > But useful: ~very~ important as a modulation source (LFO), and where (as > with the other waveforms) the absence of wiggles may often be valuable > musically. Waveforms are not just to be listened to directly. As control > signals the geometric waveforms have a key role, while all manner of > extended exotica (smoothly-varying random waveforms, self-modulated > waveforms etc) also matter. Sometimes, classic geometric "perfection" is > required; at other times the absence of predictability (or simply a more > subtle organic quality) is sought. > > Richard Dobson > > > > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.364 / Virus Database: 270.12.77/2184 - Release Date: 06/17/09 17:55:00 From padawan12 at obiwannabe.co.uk Thu Jun 18 08:42:04 2009 From: padawan12 at obiwannabe.co.uk (padawan12@obiwannabe.co.uk) Date: Thu Jun 18 08:42:19 2009 Subject: [music-dsp] What is the waveform with even harmonics called Message-ID: <29817224.180301245328924683.JavaMail.servlet@kundenserver> > Yes but as LFO or for other purpose we're talking about something else Yes, exactly, we are talking about something else: Those cases where time domain features are more significant to an operation than spectra. > you wouldn't want to generate them bandlimited in those cases. Same for FM modulators. Why not? There are cases where a specific shape is required AND a bandlimited spectrum is desirable. Perhaps it's helpful to distinguish 'bandlimited' from 'Fourier (additvely) constructed. All additively constructed signals are bandlimited, but not all bandlimited signals are constructed additively. There are other ways, such as piecewise polynomial construction, that can be shown to give predictable shapes and bandwidths. When used as a modulator, for example as AM in a fast autopanner, the absence of sharp corners avoids clicks (non-bandlimited modulation artifacts), and the shape (say triangle) gives the desired behaviour. As Perl programmers like to say, there's more than one way to do it. :) a. >> triangle isn't much interesting, sounds like a slighty saturated sine >> > > > But useful: ~very~ important as a modulation source (LFO), and where (as > with the other waveforms) the absence of wiggles may often be valuable > musically. Waveforms are not just to be listened to directly. As control > signals the geometric waveforms have a key role, while all manner of > extended exotica (smoothly-varying random waveforms, self-modulated > waveforms etc) also matter. Sometimes, classic geometric "perfection" is > required; at other times the absence of predictability (or simply a more > subtle organic quality) is sought. > > Richard Dobson > > > > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.364 / Virus Database: 270.12.77/2184 - Release Date: 06/17/09 17:55:00 -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp From padawan12 at obiwannabe.co.uk Fri Jun 19 17:04:58 2009 From: padawan12 at obiwannabe.co.uk (Andy Farnell) Date: Fri Jun 19 17:05:21 2009 Subject: [music-dsp] Re: Name for the integrator replacement technique In-Reply-To: <001201c9ee70$189c8af0$0201a8c0@LuboPC> References: <002b01c9e843$ed1e2b40$0201a8c0@mooncode> <003f01c9ed0b$00e80a80$0201a8c0@mooncode> <007d01c9ed17$687ad180$0201a8c0@LuboPC> <00c201c9edb0$f2c82600$0201a8c0@LuboPC> <004601c9ee42$f4c08640$0201a8c0@LuboPC> <36C0685C330348E6AC25238B0AD1BCEF@nibln01077> <001201c9ee70$189c8af0$0201a8c0@LuboPC> Message-ID: <20090619220458.710147e2.padawan12@obiwannabe.co.uk> Increased noise (thermal noise) in the system is one direct effect of the circuit temperature. That's going to come from resistors, especially the old carbon film type. Until op-amps (with high impedance long tailed differential input and the ability to make a very stable loop gain with negative feedback) many transitor circuits relied on precarious 'baising' to place them into a linear range. These kinds of circuits were always pretty unstable with regards to temperature. Some other effects giving the 'charm of analogue' are crossover distortion (bad behaviour for very small signals around zero) and cubic distortion caused where gain stage depends on the amplitude of the signal - usually in output stages where a bad circuit allows current in the collecter to shift the bias point of a transistor. What was interesting about analogue designs is that drift created much more than adding a random number to a digital simulation, it would change the whole behaviour of a circuit. (disclaimer: its a very long time since I built analogue sound circuits, but these are effects I remember - some of them - if deliberately provoked - sounded amazing!) a. On Tue, 16 Jun 2009 13:49:11 +0300 "Lubomir I. Ivanov" wrote: > Well it obviously sounds warmer due to the transformers heating up, but this > heat also changes the behaviour in each element due to the composite > materials from which its constructed. > This also can be implemented in DSP, with some physics and dependencies if > wanted, so that "error_range" is not a constant. -- Use the source From jos at ccrma.stanford.edu Sat Jun 20 16:18:05 2009 From: jos at ccrma.stanford.edu (Julius Smith) Date: Sat Jun 20 16:18:23 2009 Subject: [music-dsp] Position announcement In-Reply-To: <20090619220458.710147e2.padawan12@obiwannabe.co.uk> References: <002b01c9e843$ed1e2b40$0201a8c0@mooncode> <003f01c9ed0b$00e80a80$0201a8c0@mooncode> <007d01c9ed17$687ad180$0201a8c0@LuboPC> <00c201c9edb0$f2c82600$0201a8c0@LuboPC> <004601c9ee42$f4c08640$0201a8c0@LuboPC> <36C0685C330348E6AC25238B0AD1BCEF@nibln01077> <001201c9ee70$189c8af0$0201a8c0@LuboPC> <20090619220458.710147e2.padawan12@obiwannabe.co.uk> Message-ID: <200906202018.n5KKID9S001584@calabash.cc.columbia.edu> [forwarded by request] Please distribute widely. More information and application info are available here: http://www.qub.ac.uk/sites/QUBJobVacancies/ResearchJobs/ -------------------------------------------------------------------- Applications are invited for two Lecturer positions initially funded by an RCUK Academic Fellowship to undertake research in the Sonic Arts Research Centre within the School of Music and Sonic Arts. Post 1 Ref: 09/100980 This is a unique opportunity for a dynamic and ambitious researcher with experience in performance and new technologies, or audio-visual practice and new technologies at postgraduate or postdoctoral level to develop research as part of the diverse programme of work underway at SARC. Post 2 Ref: 09/100981 This is a unique opportunity for a dynamic and ambitious researcher to undertake research in the field of digital signal processing for audio applications. Preference may be given to candidates working in the fields of 3D audio rendering for virtual environments, 3D audio storage and playback, audio streaming and/or perceptual audio coding. The research will form part of the diverse programme of work underway at SARC. Anticipated interview date for both posts: Tuesday 4 August 2009. Salary scale: ?32,458 - ?38,757 per annum (including contribution points). Closing date: 4.00pm, Friday 26 June 2009 for both posts. Please visit our website for further information and to apply online - www.qub.ac.uk/jobs or alternatively contact the Personnel Department, Queen?s University Belfast, BT7 1NN. Telephone (028) 90973044 FAX: (028) 90971040 or e-mail on personnel@qub.ac.uk The University is committed to equality of opportunity and to selection on merit. It therefore welcomes applications from all sections of society and particularly welcomes applications from people with a disability. Julius O. Smith III Prof. of Music and Assoc. Prof. (by courtesy) of Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ From aengus at gmail.com Tue Jun 23 01:23:27 2009 From: aengus at gmail.com (Aengus Martin) Date: Tue Jun 23 01:23:40 2009 Subject: [music-dsp] Corpus for Evaluation of Onset Detection Systems Message-ID: Hi, I sent this question to the DMRN list, but then realised that the Music DSP list might be a better place to ask: Does anyone know of a good corpus of audio with tagged onsets for use in evaluating an onset detection system? I can't seem to find mention in the literature of researchers making their evaluation material available. Thanks, Aengus. From douglas at music.columbia.edu Tue Jun 23 03:26:01 2009 From: douglas at music.columbia.edu (douglas repetto) Date: Tue Jun 23 03:26:08 2009 Subject: [music-dsp] Corpus for Evaluation of Onset Detection Systems In-Reply-To: References: Message-ID: <4A408389.9000907@music.columbia.edu> You might poke around ISMIR: http://www.ismir.net/ douglas Aengus Martin wrote: > Hi, > > I sent this question to the DMRN list, but then realised that the > Music DSP list might be a better place to ask: Does anyone know of a > good corpus of audio with tagged onsets for use in evaluating an onset > detection system? I can't seem to find mention in the literature of > researchers making their evaluation material available. > > Thanks, > > Aengus. > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > -- ............................................... http://artbots.org .....douglas.....irving........................ http://dorkbot.org .......................... http://music.columbia.edu/cmc/music-dsp .......... repetto............. http://music.columbia.edu/organism ........................................ http://douglasrepetto.org From nostromo at arkaos.net Wed Jun 24 04:58:34 2009 From: nostromo at arkaos.net (M-.-n) Date: Wed Jun 24 04:58:23 2009 Subject: [music-dsp] Video lectures on DSP (IIT Delhi) In-Reply-To: <000a01c9eccf$30e5ed10$0201a8c0@LuboPC> References: <20090611080726.C34D1628C@mailscan3.ncs.mcgill.ca> <9A6BBBBE2AAD6746A6D961B57357426203800FB0A6@staff-mail2.vpn.elec.qmul.ac.uk> <000a01c9eccf$30e5ed10$0201a8c0@LuboPC> Message-ID: <008601c9f4a9$f4989320$ddc9b960$@net> BTW, huge thanks for this link. I love it. >43 - 1 hour lectures on DSP at: > >http://www.youtube.com/view_play_list?p=9567DFCA3A66F299 From aengus at am-process.org Wed Jun 24 09:37:19 2009 From: aengus at am-process.org (Aengus Martin) Date: Wed Jun 24 09:37:37 2009 Subject: [music-dsp] Corpus for Evaluation of Onset Detection Systems In-Reply-To: <4A408389.9000907@music.columbia.edu> References: <4A408389.9000907@music.columbia.edu> Message-ID: Looks like a good place to start. Thanks! On Tue, Jun 23, 2009 at 5:26 PM, douglas repetto wrote: > > You might poke around ISMIR: > > http://www.ismir.net/ > > > douglas > > Aengus Martin wrote: >> >> Hi, >> >> I sent this question to the DMRN list, but then realised that the >> Music DSP list might be a better place to ask: Does anyone know of a >> good corpus of audio with tagged onsets for use in evaluating an onset >> detection system? I can't seem to find mention in the literature of >> researchers making their evaluation material available. >> >> Thanks, >> >> Aengus. >> -- >> dupswapdrop -- the music-dsp mailing list and website: subscription info, >> FAQ, source code archive, list archive, book reviews, dsp links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp >> > > -- > ............................................... http://artbots.org > .....douglas.....irving........................ http://dorkbot.org > .......................... http://music.columbia.edu/cmc/music-dsp > .......... repetto............. http://music.columbia.edu/organism > ........................................ http://douglasrepetto.org > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription info, > FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > -- ____________________ www.am-process.org