From douglas at music.columbia.edu Sun Jun 1 00:00:00 2008 From: douglas at music.columbia.edu (douglas repetto) Date: Sun Jun 1 00:00:09 2008 Subject: [music-dsp] [admin] music-dsp FAQ Message-ID: <20080601040000.8B5F328D45468@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 scoofy at inf.elte.hu Sun Jun 1 00:20:48 2008 From: scoofy at inf.elte.hu (Peter Schoffhauzer) Date: Sun Jun 1 00:22:57 2008 Subject: [music-dsp] Paper on bandlimited analog waveform synthesis using FM In-Reply-To: References: Message-ID: <484223A0.3020200@inf.elte.hu> Hi, You can find it here: http://scp.web.elte.hu/papers/synthesis1.pdf Best, Peter Stephen Blinkhorn wrote: > Hi Peter, I just found an old thread on Music-DSP discussing a paper > you wrote regarding synthesizing sawtooth wave forms via FM. I'd love > to read it. Is it available anywhere? > > Thanks, Stephen. > -- > 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 Sun Jun 1 22:35:46 2008 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sun Jun 1 22:36:00 2008 Subject: [music-dsp] Paper on bandlimited analog waveform synthesis using FM Message-ID: <20080602023546.4656C9E7E9@ws6-2.us4.outblaze.com> > ----- Original Message ----- > From: "Peter Schoffhauzer" > To: "A discussion list for music-related DSP" > Subject: Re: [music-dsp] Paper on bandlimited analog waveform synthesis using FM > Date: Sun, 01 Jun 2008 06:20:48 +0200 > > > You can find it here: > http://scp.web.elte.hu/papers/synthesis1.pdf > Peter, thank you for posting this. i'm still looking at it, but can i ask you questions about it a little later? either here or privately, i don't care. the first thing i would say about it after first glance is that i wish the spectrums and spectrografs had their axis labeled (in terms of normalized frequency and time in sample units, i s'pose). the explanation for "exotic" functions that you have for beta and such is still a mystery to me. but i'll get it eventually, i think. thanks. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From scoofy at inf.elte.hu Mon Jun 2 12:13:10 2008 From: scoofy at inf.elte.hu (Peter Schoffhauzer) Date: Mon Jun 2 12:14:56 2008 Subject: [music-dsp] Paper on bandlimited analog waveform synthesis using FM In-Reply-To: <20080602023546.4656C9E7E9@ws6-2.us4.outblaze.com> References: <20080602023546.4656C9E7E9@ws6-2.us4.outblaze.com> Message-ID: <48441C16.8020209@inf.elte.hu> Hi, robert bristow-johnson wrote: >> ----- Original Message ----- >> From: "Peter Schoffhauzer" >> To: "A discussion list for music-related DSP" >> Subject: Re: [music-dsp] Paper on bandlimited analog waveform synthesis using FM >> Date: Sun, 01 Jun 2008 06:20:48 +0200 >> >> >> You can find it here: >> http://scp.web.elte.hu/papers/synthesis1.pdf >> > > Peter, thank you for posting this. i'm still looking at it, but can i ask you questions about it a little later? either here or privately, i don't care. Sure, I'm open for discussion, both here and in private. > the first thing i would say about it after first glance is that i wish the spectrums and spectrografs had their axis labeled (in terms of normalized frequency and time in sample units, i s'pose). the explanation for "exotic" functions that you have for beta and such is still a mystery to me. but i'll get it eventually, i think. Yep, that's one thing I'm not satisfied with either, partly that's the reason why the word "draft" is in the title. Well, this was my first "paper" of this kind, it was more like just learning how to use Latex, instead of actually trying to do something really serious. Well, beta functions were a bit of an experimental. Generally, the higher beta you have, the higher bandwith the osc will have because of the increased modulation. The most elegant would have be to investigate the bandwith formulas and derive a nice beta function from those, but instead I just tried guess some ad hoc forumas, and see what works best. This was satisfactory for my purposes. Finally I didn't work on this method more, because the costs for making the asymmetrical waveform look and sound more like an ideal wave are high, and other waveform generation methods, like mip-mapped linear interpolation suited my needs better. I think recursive FM wave generation may be better suited for systems with very limited amount of memory. Peter From padawan12 at obiwannabe.co.uk Mon Jun 2 12:58:57 2008 From: padawan12 at obiwannabe.co.uk (Andy Farnell) Date: Mon Jun 2 12:59:12 2008 Subject: [music-dsp] Paper on bandlimited analog waveform synthesis using FM In-Reply-To: <48441C16.8020209@inf.elte.hu> References: <20080602023546.4656C9E7E9@ws6-2.us4.outblaze.com> <48441C16.8020209@inf.elte.hu> Message-ID: <20080602175857.0208d661.padawan12@obiwannabe.co.uk> On Mon, 02 Jun 2008 18:13:10 +0200 Peter Schoffhauzer wrote: > I think recursive FM wave > generation may be better suited for systems with very limited amount of > memory. Or more generally, where you just want to avoid doing memory access. An application is to parallelise many sound objects without knowing/caring what thread/core they run on, being able to keep everything in registers becomes rather nice. So a comapct FM blosc is useful, thanks for sharing. For the graphs, I find a combo of Octave + Gnuplot does just about everything I need vis scales/axes/labels and plays nice with LaTeX. a. -- Use the source From rbj at audioimagination.com Mon Jun 2 14:04:18 2008 From: rbj at audioimagination.com (robert bristow-johnson) Date: Mon Jun 2 14:04:35 2008 Subject: [music-dsp] Paper on bandlimited analog waveform synthesis using FM Message-ID: <20080602180418.421B22D0135@ws6-13.us4.outblaze.com> > ----- Original Message ----- > From: "Andy Farnell" > To: "A discussion list for music-related DSP" > Subject: Re: [music-dsp] Paper on bandlimited analog waveform synthesis using FM > Date: Mon, 2 Jun 2008 17:58:57 +0100 > ... > > For the graphs, I find a combo of Octave + Gnuplot does just about > everything I need vis scales/axes/labels and plays nice with LaTeX. > boy, Andy, if you could tell us what you do with Gnuplot, how you use it. i am stuck using a Linux machine, and although i appreciate some of the command-line UNIX tool making ability, i have great trouble in using *other's* tools. and gnuplot was one of them. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From Victor.Lazzarini at nuim.ie Mon Jun 2 14:16:39 2008 From: Victor.Lazzarini at nuim.ie (victor) Date: Mon Jun 2 14:16:52 2008 Subject: [music-dsp] Paper on bandlimited analog waveform synthesis using FM References: <20080602180418.421B22D0135@ws6-13.us4.outblaze.com> Message-ID: <001401c8c4dc$cd8cb8e0$0201a8c0@family> I think what Andy means is that gnuplot is the plotting engine for octave. Works well, for those inclined to matlab-like programming, I was once an user of gnuplot (straight, no octave), but now I am moving into scipy & matplotlib, which suits me, since I like python a lot. Gnuplot was good for simple stuff, but I found it difficult to do more complex stuff. Victor ----- Original Message ----- From: "robert bristow-johnson" To: "A discussion list for music-related DSP" Sent: Monday, June 02, 2008 7:04 PM Subject: Re: [music-dsp] Paper on bandlimited analog waveform synthesis using FM > ----- Original Message ----- > From: "Andy Farnell" > To: "A discussion list for music-related DSP" > > Subject: Re: [music-dsp] Paper on bandlimited analog waveform synthesis > using FM > Date: Mon, 2 Jun 2008 17:58:57 +0100 > ... > > For the graphs, I find a combo of Octave + Gnuplot does just about > everything I need vis scales/axes/labels and plays nice with LaTeX. > boy, Andy, if you could tell us what you do with Gnuplot, how you use it. i am stuck using a Linux machine, and although i appreciate some of the command-line UNIX tool making ability, i have great trouble in using *other's* tools. and gnuplot was one of them. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp From padawan12 at obiwannabe.co.uk Mon Jun 2 15:08:34 2008 From: padawan12 at obiwannabe.co.uk (Andy Farnell) Date: Mon Jun 2 15:08:44 2008 Subject: [music-dsp] Paper on bandlimited analog waveform synthesis using FM In-Reply-To: <20080602180418.421B22D0135@ws6-13.us4.outblaze.com> References: <20080602180418.421B22D0135@ws6-13.us4.outblaze.com> Message-ID: <20080602200834.62b5383a.padawan12@obiwannabe.co.uk> Sure Robert... First I have to agree that both Gnuplot and Octave are hardly "easy" programs. But I suspect most of us DSP coders can get around them. Gnuplot now lives here http://www.gnuplot.info/ And Octave here http://www.gnu.org/software/octave/ Octave, which is basically a free MATLAB, uses Gnuplot as the default visualisation back-end (although you can import other more sophisticated 2D and 3D plotters/renderers) This (not so) frequently asked questions collection is good imho. http://t16web.lanl.gov/Kawano/gnuplot/index-e.html As quick examples I've a few files on my site; http://obiwannabe.co.uk/temp/plotting/plotspec.plt http://obiwannabe.co.uk/temp/plotting/spectrum.dat These first two show the basics. The script file can have any extension, I choose .plt, YMMV. Invoke thus; > gnuplot elasticity-plot.plt, and it will generate a postscript file in plotoutput.ps It shows the basic two column data format in a separate .dat file and the use of xticks (to set arbitrary range) and axes labels. If you want to _generate_ data parametrically in Gnuplot this example shows how to do a simple square root in a normalised range http://obiwannabe.co.uk/temp/plotting/plotsqrt.plt This next pair show how to do horizontal range bars using a four column data set. http://obiwannabe.co.uk/temp/plotting/elasticity-plot.plt http://obiwannabe.co.uk/temp/plotting/elasticity.dat For simple 3D plots this next example shows how to use degree based trig and 3 axis plots with 'set parametric' and 'set angle degree' Uncomment the penultimate line for a sphere example instead. http://obiwannabe.co.uk/temp/plotting/plotcylinder.plt Moving on to Octave/Matlab. The syntax is a bit different. http://obiwannabe.co.uk/temp/plotting/phon-ISO226.m This one demonstrates a plot of ISO226 phon curves which I trivially translated from MATLAB version by Jeff Tackett. Notice that most of the formatting is done through gset commands, although gset is tagged as deprecated so there are 'better' ways. http://obiwannabe.co.uk/temp/plotting/drum.m This one shows a surface plot for modes of a skin. It generates a X-window output so may not work on some systems ... which brings us to ..... http://www.tcptrace.org/jPlot/ Jplot is a Gnuplot-like substitute for x-platform (I hear it works okay with Win). Hope these are useful pointers. a. On Mon, 2 Jun 2008 14:04:18 -0400 "robert bristow-johnson" wrote: > > > ----- Original Message ----- > > From: "Andy Farnell" > > To: "A discussion list for music-related DSP" > > Subject: Re: [music-dsp] Paper on bandlimited analog waveform synthesis using FM > > Date: Mon, 2 Jun 2008 17:58:57 +0100 > > > ... > > > > For the graphs, I find a combo of Octave + Gnuplot does just about > > everything I need vis scales/axes/labels and plays nice with LaTeX. > > > > boy, Andy, if you could tell us what you do with Gnuplot, how you use it. i am stuck using a Linux machine, and although i appreciate some of the command-line UNIX tool making ability, i have great trouble in using *other's* tools. and gnuplot was one of them. > > > -- > > r b-j rbj@audioimagination.com > > "Imagination is more important than knowledge." > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -- Use the source From rbj at audioimagination.com Mon Jun 2 15:10:51 2008 From: rbj at audioimagination.com (robert bristow-johnson) Date: Mon Jun 2 15:11:04 2008 Subject: [music-dsp] Paper on bandlimited analog waveform synthesis using FM Message-ID: <20080602191052.2C923EDE58@ws6-1.us4.outblaze.com> > ----- Original Message ----- > From: victor > To: "A discussion list for music-related DSP" > Subject: Re: [music-dsp] Paper on bandlimited analog waveform synthesis using FM > Date: Mon, 02 Jun 2008 19:16:39 +0100 > > > I think what Andy means is that gnuplot is the plotting > engine for octave. Works well, for those inclined to > matlab-like programming, > > I was once an user of gnuplot (straight, no octave), > but now I am moving into scipy & matplotlib, which > suits me, since I like python a lot. > > Gnuplot was good for simple stuff, but I found it > difficult to do more complex stuff. > okay, if i'm using gnuplot with Octave (and i have plotted things with Octave, the poor man's MATLAB), is there a way to save the plot as a gif or even in a .pdf or something? how i long for the simple "cut-and-paste" days of the 90s. i really feel that we have been moving backwards along the axis of computer utility and simplicity. i could do more with my Mac in the 1990s using system 9.2 than i can do with *anything*, OSX, Windoze, Linux, nowadays. here's a cute U-Tube to spell out what i mean: http://video.google.com/videosearch?q=Mac+vs.+PC+Linux# why is it that computers are getting more sophisticated in design, but devolving in their utility? -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From padawan12 at obiwannabe.co.uk Mon Jun 2 15:14:04 2008 From: padawan12 at obiwannabe.co.uk (Andy Farnell) Date: Mon Jun 2 15:14:14 2008 Subject: [music-dsp] Paper on bandlimited analog waveform synthesis using FM In-Reply-To: <001401c8c4dc$cd8cb8e0$0201a8c0@family> References: <20080602180418.421B22D0135@ws6-13.us4.outblaze.com> <001401c8c4dc$cd8cb8e0$0201a8c0@family> Message-ID: <20080602201404.19cb2dce.padawan12@obiwannabe.co.uk> On Mon, 02 Jun 2008 19:16:39 +0100 victor wrote: > scipy & matplotlib, which > suits me, since I like python a lot. Agreed. IMHO Python will evenually replace/augment most of these tools - it's just more flexible. But there's a lot of MATLAB/Octave code out there and it's ability with matrices/solvers, curve fitting etc will take some time to catch up in Python. So worth learning all of them if you are doing research/papers etc. Octave/MATLAB is more mathematical while scipi is more programmatic I would say. Another wonderful free scientific data tool is R (for statistics). a. -- Use the source From Victor.Lazzarini at nuim.ie Mon Jun 2 15:40:28 2008 From: Victor.Lazzarini at nuim.ie (victor) Date: Mon Jun 2 15:40:49 2008 Subject: [music-dsp] Paper on bandlimited analog waveform synthesis using FM References: <20080602191052.2C923EDE58@ws6-1.us4.outblaze.com> Message-ID: <001101c8c4e8$84f53ba0$0201a8c0@family> On Windows, with gnuplot, you can paste the whole graph onto the clipboard. I guess that might be the same in Linux. But you can print to GIF etc straight from the program (just set the output type) Victor ----- Original Message ----- From: "robert bristow-johnson" To: "A discussion list for music-related DSP" Sent: Monday, June 02, 2008 8:10 PM Subject: Re: [music-dsp] Paper on bandlimited analog waveform synthesis using FM > ----- Original Message ----- > From: victor > To: "A discussion list for music-related DSP" > > Subject: Re: [music-dsp] Paper on bandlimited analog waveform synthesis > using FM > Date: Mon, 02 Jun 2008 19:16:39 +0100 > > > I think what Andy means is that gnuplot is the plotting > engine for octave. Works well, for those inclined to > matlab-like programming, > > I was once an user of gnuplot (straight, no octave), > but now I am moving into scipy & matplotlib, which > suits me, since I like python a lot. > > Gnuplot was good for simple stuff, but I found it > difficult to do more complex stuff. > okay, if i'm using gnuplot with Octave (and i have plotted things with Octave, the poor man's MATLAB), is there a way to save the plot as a gif or even in a .pdf or something? how i long for the simple "cut-and-paste" days of the 90s. i really feel that we have been moving backwards along the axis of computer utility and simplicity. i could do more with my Mac in the 1990s using system 9.2 than i can do with *anything*, OSX, Windoze, Linux, nowadays. here's a cute U-Tube to spell out what i mean: http://video.google.com/videosearch?q=Mac+vs.+PC+Linux# why is it that computers are getting more sophisticated in design, but devolving in their utility? -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp From ebrombaugh1 at cox.net Mon Jun 2 17:09:32 2008 From: ebrombaugh1 at cox.net (Eric Brombaugh) Date: Mon Jun 2 17:09:47 2008 Subject: [music-dsp] Paper on bandlimited analog waveform synthesis using FM In-Reply-To: <20080602191052.2C923EDE58@ws6-1.us4.outblaze.com> References: <20080602191052.2C923EDE58@ws6-1.us4.outblaze.com> Message-ID: <4844618C.8000206@cox.net> robert bristow-johnson wrote: > okay, if i'm using gnuplot with Octave (and i have plotted things with Octave, the poor man's MATLAB), is there a way to save the plot as a gif or even in a .pdf or something? You can dump Octave/Gnuplot output to a variety of formats, including PS (which can then be converted to PDF with the 'ps2pdf' command on Linux). Here's the online man page for it: http://www.gnu.org/software/octave/doc/interpreter/Printing-Plots.html#Printing-Plots I tried this - getting the syntax right was a bit tricky, but try this example: plot(sin(0:0.1:6.3)); print("sine.ps", "-solid", "-landscape", "-color", "-dps"); which generates a Postscript file titled 'sine.ps'. Eric From slehman2 at yahoo.com Mon Jun 2 22:01:14 2008 From: slehman2 at yahoo.com (Scott Lehman) Date: Mon Jun 2 22:01:26 2008 Subject: [music-dsp] Paper on bandlimited analog waveform synthesis using FM In-Reply-To: <4844618C.8000206@cox.net> Message-ID: <775242.58538.qm@web55614.mail.re4.yahoo.com> Not really an answer to the original question, but someone pointed me to Grace as an alternative to Gnuplot a while back. It can export to PDF and svg, though it's only 2D and I don't think it has the same level of integration with Octave. Haven't actually used it myself, but been meaning to give it a shot: http://plasma-gate.weizmann.ac.il/Grace/ Scott --- Eric Brombaugh wrote: > robert bristow-johnson wrote: > > okay, if i'm using gnuplot with Octave (and i have > plotted things with Octave, the poor man's MATLAB), > is there a way to save the plot as a gif or even in > a .pdf or something? > > You can dump Octave/Gnuplot output to a variety of > formats, including PS > (which can then be converted to PDF with the > 'ps2pdf' command on Linux). > Here's the online man page for it: > > http://www.gnu.org/software/octave/doc/interpreter/Printing-Plots.html#Printing-Plots > > I tried this - getting the syntax right was a bit > tricky, but try this > example: > > plot(sin(0:0.1:6.3)); > print("sine.ps", "-solid", "-landscape", "-color", > "-dps"); > > which generates a Postscript file titled 'sine.ps'. > > Eric > -- > dupswapdrop -- the music-dsp mailing list and > website: > subscription info, FAQ, source code archive, list > archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From david.lowenfels at gmail.com Tue Jun 3 19:07:23 2008 From: david.lowenfels at gmail.com (david.lowenfels@gmail.com) Date: Tue Jun 3 19:07:38 2008 Subject: [music-dsp] Paper on bandlimited analog waveform synthesis using FM In-Reply-To: <484223A0.3020200@inf.elte.hu> References: <484223A0.3020200@inf.elte.hu> Message-ID: Hi Peter, Thanks for sharing your paper. When was it written BTW, as there is no date of authorship? I never played with a high shelf compensation filter, that's a neat idea. It would be easier to compare frequency plots if you had a log(f) x- axis. I'm surprised there are not more references, as the basics of this technique have been around for a long time. You should at least cite the original Yamaha patent: US#4249447 (pat2pdf.com comes in handy) Cheers, -David On May 31, 2008, at 9:20 PM, Peter Schoffhauzer wrote: > Hi, > > You can find it here: > http://scp.web.elte.hu/papers/synthesis1.pdf > > Best, > Peter On Jan 17, 2007, at 11:15 PM, David Lowenfels wrote: > I like to call it Recursive Phase Modulation (RPM) > c.f. yamaha patent #4249447, and my 8/22/06 post: > >> From: dfl alum mit edu >> Subject: Re: [music-dsp] different waveforms from a single >> Date: August 22, 2006 11:48:14 AM PDT >> To: music-dsp@music.columbia.edu >> >> My personal favorite for oscillator coolness is Yamaha-flavored >> feedback FM (actually phase modulation): >> >> Take a phasor (naive sawtooth aka wrapped accumulator) and feed it >> into a sine lookup table (linear interpolation is fine). Feed back >> the output with a gain control, and sum it back with the phasor >> before table lookup. >> >> (industry practice is to put a 2-point running average in the >> feedback chain to control wild self-oscillation at nyquist... the >> yammy patent calls it a "hunting filter" ??! ) >> >> No feedback yields a regular sinewave. >> The feedback gain controls the harmonic rolloff slope, kind of like >> a lowpass filter. >> Increasing feedback gain approximates a quasi-bandlimited sawtooth- >> like wave. >> If you square (and invert?) the feedback you get a quasi- >> bandlimited square-like wave. >> >> You can approximate a triangle wave by using the a low feedback >> gain on the square wave. Or just integrate (not sure if it needs to >> be leaky as there should be no DC in the original waveform?) >> Use comb filter tricks on the sawtooth to get PWM, etc. >> >> -David >> >> On Aug 22, 2006, at 2:50 AM, kernel wrote: >> >> >>> I've used it lots for low frequency stuff not necessarily LFOs but >>> low pitched sounds. I'm after something I can use for both >>> regular oscillators and LFOs which provides a wide range of >>> traditional (tri/pulse etc) as well as more unusual waveforms. > > -- > 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 scoofy at inf.elte.hu Wed Jun 4 02:13:17 2008 From: scoofy at inf.elte.hu (Peter Schoffhauzer) Date: Wed Jun 4 02:14:59 2008 Subject: [music-dsp] Paper on bandlimited analog waveform synthesis using FM In-Reply-To: References: <484223A0.3020200@inf.elte.hu> Message-ID: <4846327D.5080106@inf.elte.hu> Hi David, david.lowenfels@gmail.com wrote: > When was it written BTW, as there is no date of authorship? I originally posted about this on this list at 2007. jan 17, so I guess I wrote it the previous days. > I'm surprised there are not more references, as the basics of this > technique have been around for a long time. > You should at least cite the original Yamaha patent: US#4249447 > (pat2pdf.com comes in handy) The reason that there are no references is because most of this is own experimental research. I did not know about the Yamaha paper, I just discovered about it later (actually because you sent it to me if you remember), nor did I know before that they used a similar technique to handle Nyquist-ringing. I just read a few introductory web pages about FM / recursive FM before experimenting, that's all I used. Why would I have cited works that I haven't read and didn't know about? > PS I just was poking around, and found your SilverBox synth. Very nice > sound, congrats! Thanks! Peter From Victor.Lazzarini at nuim.ie Wed Jun 4 11:56:05 2008 From: Victor.Lazzarini at nuim.ie (victor) Date: Wed Jun 4 11:56:14 2008 Subject: [music-dsp] Paper on bandlimited analog waveform synthesis using FM References: <484223A0.3020200@inf.elte.hu> <4846327D.5080106@inf.elte.hu> Message-ID: <003401c8c65b$7f2bce40$0201a8c0@family> Just a small remark, I noticed that in your paper, the phase accumulator goes bipolar from -1 to +1. I suppose it would make your oscillator phase inverse-sine, would it not? I don't think this has any major consequences, I just found it unusual. But did you try playing with the phase to see what difference it makes to the output? Regards Victor > > PS I just was poking around, and found your SilverBox synth. Very nice > > sound, congrats! > > Thanks! > > Peter > > -- > 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 scoofy at inf.elte.hu Wed Jun 4 13:53:40 2008 From: scoofy at inf.elte.hu (Peter Schoffhauzer) Date: Wed Jun 4 13:55:21 2008 Subject: [music-dsp] Paper on bandlimited analog waveform synthesis using FM In-Reply-To: <003401c8c65b$7f2bce40$0201a8c0@family> References: <484223A0.3020200@inf.elte.hu> <4846327D.5080106@inf.elte.hu> <003401c8c65b$7f2bce40$0201a8c0@family> Message-ID: <4846D6A4.4060003@inf.elte.hu> Hi, victor wrote: > Just a small remark, I noticed that in your paper, the > phase accumulator goes bipolar from -1 to +1. Thanks for pointing out to this. I think it doesn't make any difference, and the line phase += 2*w; if (phase >= 1) phase -= 2; could be replaced by phase += w; if (phase >= 1) phase -= 1; > I suppose it would make your oscillator phase inverse-sine, would it > not? No, why would it? > I don't think this has any major consequences, I just found > it unusual. But did you try playing with the phase to see what > difference it makes to the output? Sure. That's what I explain in the paper :) Peter From Victor.Lazzarini at nuim.ie Wed Jun 4 14:31:57 2008 From: Victor.Lazzarini at nuim.ie (victor) Date: Wed Jun 4 14:32:09 2008 Subject: [music-dsp] Paper on bandlimited analog waveform synthesis using FM References: <484223A0.3020200@inf.elte.hu> <4846327D.5080106@inf.elte.hu> <003401c8c65b$7f2bce40$0201a8c0@family> <4846D6A4.4060003@inf.elte.hu> Message-ID: <003f01c8c671$4578d510$0201a8c0@family> I did not read the lot, just glanced at it, so I probably missed the discussion on phase. My comment on being inverse-sine: if I remember it, from your equation, you had something like this x = sin(pi*[phase + mod]) so if say mod is 0, and phase varies from -1 to +1, then your signal starts with a -pi phase at t=0, making it inverse sine? Mind you, this is the equation on page 1, I have not read the code (which might be different). Victor ----- Original Message ----- From: "Peter Schoffhauzer" To: "A discussion list for music-related DSP" Sent: Wednesday, June 04, 2008 6:53 PM Subject: Re: [music-dsp] Paper on bandlimited analog waveform synthesis using FM > Hi, > > victor wrote: >> Just a small remark, I noticed that in your paper, the >> phase accumulator goes bipolar from -1 to +1. > > Thanks for pointing out to this. I think it doesn't make any difference, > and the line > > phase += 2*w; if (phase >= 1) phase -= 2; > > could be replaced by > > phase += w; if (phase >= 1) phase -= 1; > >> I suppose it would make your oscillator phase inverse-sine, would it >> not? > > No, why would it? > > > I don't think this has any major consequences, I just found >> it unusual. But did you try playing with the phase to see what >> difference it makes to the output? > > Sure. That's what I explain in the paper :) > > Peter > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription info, > FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From Victor.Lazzarini at nuim.ie Wed Jun 4 14:41:24 2008 From: Victor.Lazzarini at nuim.ie (victor) Date: Wed Jun 4 14:41:33 2008 Subject: [music-dsp] Paper on bandlimited analog waveform synthesis using FM References: <484223A0.3020200@inf.elte.hu> <4846327D.5080106@inf.elte.hu> <003401c8c65b$7f2bce40$0201a8c0@family> <4846D6A4.4060003@inf.elte.hu> Message-ID: <004601c8c672$9783ae60$0201a8c0@family> Sorry, I just glanced again at the paper and I did not see the discussion about phase. Could you point it out to me? I mean initial phase offset, not phase modulation (which is of course the basis for the technique). Victor > > > I don't think this has any major consequences, I just found >> it unusual. But did you try playing with the phase to see what >> difference it makes to the output? > > Sure. That's what I explain in the paper :) > > Peter > > -- > 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 david.lowenfels at gmail.com Wed Jun 4 15:00:38 2008 From: david.lowenfels at gmail.com (david.lowenfels@gmail.com) Date: Wed Jun 4 15:00:54 2008 Subject: [music-dsp] Re: recursive phase modulation (was:Paper on bandlimited analog waveform synthesis using FM) In-Reply-To: <003f01c8c671$4578d510$0201a8c0@family> References: <484223A0.3020200@inf.elte.hu> <4846327D.5080106@inf.elte.hu> <003401c8c65b$7f2bce40$0201a8c0@family> <4846D6A4.4060003@inf.elte.hu> <003f01c8c671$4578d510$0201a8c0@family> Message-ID: Hi Victor, As I recall, the initial phase or direction of phase does not matter. What is important is that the wave is sinusoidal. It is the phase feedback coefficient that modifies the spectrum. If the phase is backwards, then you just get a backwards waveform. But it has the same spectrum. It's the difference between a rising and falling ramp wave. Not much unless it's a control signal. -David On Jun 4, 2008, at 11:31 AM, victor wrote: > I did not read the lot, just glanced at it, so > I probably missed the discussion on phase. > > My comment on being inverse-sine: if I remember > it, from your equation, you had something like > this > > x = sin(pi*[phase + mod]) > > so if say mod is 0, and phase varies from -1 to +1, > then your signal starts with a -pi phase at t=0, > making it inverse sine? > > Mind you, this is the equation on page 1, I have > not read the code (which might be different). > > Victor From Victor.Lazzarini at nuim.ie Wed Jun 4 15:22:42 2008 From: Victor.Lazzarini at nuim.ie (victor) Date: Wed Jun 4 15:22:53 2008 Subject: [music-dsp] Re: recursive phase modulation (was:Paper on bandlimited analog waveform synthesis using FM) References: <484223A0.3020200@inf.elte.hu> <4846327D.5080106@inf.elte.hu> <003401c8c65b$7f2bce40$0201a8c0@family> <4846D6A4.4060003@inf.elte.hu> <003f01c8c671$4578d510$0201a8c0@family> Message-ID: <008a01c8c678$5c99fd30$0201a8c0@family> It should not matter, but I have to think a little about it... in simple FM, phases matter a little (eg. using cosines instead of sines), you get slightly different spectra. But I have to look this one up. From what I remember the expansion of a sine-based PM feedback set up works out as x(t) = sum{n=1, inf}[ (2/nk) Jn(nk) sin(nwt) ] perhaps by retracing this expansion we could see if there is any significant difference if we are not in the sine phase to start with. Victor ----- Original Message ----- From: To: "A discussion list for music-related DSP" Sent: Wednesday, June 04, 2008 8:00 PM Subject: [music-dsp] Re: recursive phase modulation (was:Paper on bandlimited analog waveform synthesis using FM) > Hi Victor, > As I recall, the initial phase or direction of phase does not matter. > What is important is that the wave is sinusoidal. It is the phase > feedback coefficient that modifies the spectrum. If the phase is > backwards, then you just get a backwards waveform. But it has the same > spectrum. It's the difference between a rising and falling ramp wave. Not > much unless it's a control signal. > > -David > > On Jun 4, 2008, at 11:31 AM, victor wrote: > >> I did not read the lot, just glanced at it, so >> I probably missed the discussion on phase. >> >> My comment on being inverse-sine: if I remember >> it, from your equation, you had something like >> this >> >> x = sin(pi*[phase + mod]) >> >> so if say mod is 0, and phase varies from -1 to +1, >> then your signal starts with a -pi phase at t=0, >> making it inverse sine? >> >> Mind you, this is the equation on page 1, I have >> not read the code (which might be different). >> >> Victor > > -- > 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 earlevel at earlevel.com Wed Jun 4 19:49:23 2008 From: earlevel at earlevel.com (Nigel Redmon) Date: Wed Jun 4 19:49:37 2008 Subject: [music-dsp] Paper on bandlimited analog waveform synthesis using FM In-Reply-To: <20080602191052.2C923EDE58@ws6-1.us4.outblaze.com> References: <20080602191052.2C923EDE58@ws6-1.us4.outblaze.com> Message-ID: <688A61F1-5E21-4ECF-ACA7-B342C0DE52DA@earlevel.com> On Jun 2, 2008, at 12:10 PM, robert bristow-johnson wrote: > okay, if i'm using gnuplot with Octave (and i have plotted things > with Octave, the poor man's MATLAB), is there a way to save the > plot as a gif or even in a .pdf or something? It's been a while, Robert, and I lost my source in a heist 2.5 years ago, but I did the charts for this page in Octave, using AquaTerm, and I don't recall any difficulties. I had been a Mathmatica and MathCad user before, and had used MathCad educational version years before that, but didn't have reasonably up-to-date versions of any of those, so gave Octave a try. As I recall, I didn't feel like running under X11 (I vaguely recall giving it a try and being annoyed, so went with AquaTerm and was more satisfied). But it's been a couple of years, and I can't tell you if that's definitely the way to go these days. taking a quick look I see: "AquaTerm allows you to plot things in OS X without using an X client, such as X11. This has two advantages: * It requires less memory and hard drive space, if you don't have X installed or running already. * The graphs look better, and can be saved as Quartz PDFs." Here's the page I used it on (the sine charts--yes, it did the whole thing, including the legends): http://www.earlevel.com/Digital%20Audio/FFT.html http://aquaterm.sourceforge.net/ From decoy at iki.fi Wed Jun 4 20:34:42 2008 From: decoy at iki.fi (Sampo Syreeni) Date: Wed Jun 4 20:34:56 2008 Subject: [music-dsp] Re: recursive phase modulation (was:Paper on bandlimited analog waveform synthesis using FM) In-Reply-To: References: <484223A0.3020200@inf.elte.hu> <4846327D.5080106@inf.elte.hu> <003401c8c65b$7f2bce40$0201a8c0@family> <4846D6A4.4060003@inf.elte.hu> <003f01c8c671$4578d510$0201a8c0@family> Message-ID: On 2008-06-04, david.lowenfels@gmail.com wrote: > As I recall, the initial phase or direction of phase does not matter. It does not matter when you do steady state analysis. Then you only deal with spectral quantities. It does matter if you mind transients as well, because then you have to mind time as well. -- Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 From richarddobson at blueyonder.co.uk Mon Jun 9 06:16:22 2008 From: richarddobson at blueyonder.co.uk (Richard Dobson) Date: Mon Jun 9 06:18:07 2008 Subject: [music-dsp] High CPU-load processes Message-ID: <484D02F6.4000901@blueyonder.co.uk> Hello all, Apologies for any cross-posting. I am interested to hear of any currently available audio processes (effects, instruments, etc) that are known to be very expensive in CPU terms (e.g. close to or even exceeding 100% load on a modern consumer machine, or where the possible number of simultaneous instances is severely limited); where hardware acceleration using parallel processing (SIMD, general multi-core) might be applicable. I am looking to draw up a list of examples of such processes as background information and context for a research project. Tools used for "high-end" mastering at high sample rates (192KHz etc) are especially of interest. Similarly, tools employing FFTs or comparable block-based processing. I am aware of such things within the domain of 'academic" software (and have even defined such a process myself that needs at least 50Gflops of power to run in real-time at a low sample rate), but am much less aware of what there may be in terms of commercial products that people use and wish could run a lot faster! Richard Dobson From meeloo at meeloo.net Mon Jun 9 06:51:45 2008 From: meeloo at meeloo.net (Sebastien Metrot) Date: Mon Jun 9 06:52:05 2008 Subject: [music-dsp] High CPU-load processes In-Reply-To: <484D02F6.4000901@blueyonder.co.uk> References: <484D02F6.4000901@blueyonder.co.uk> Message-ID: <9F1451F8-BB86-49E5-A4B1-C9403475711F@meeloo.net> You should have a look at convolution based reverbs. Sebastien On 9 juin 08, at 12:16, Richard Dobson wrote: > Hello all, > > > Apologies for any cross-posting. > > I am interested to hear of any currently available audio processes > (effects, instruments, etc) that are known to be very expensive in > CPU terms (e.g. close to or even exceeding 100% load on a modern > consumer machine, or where the possible number of simultaneous > instances is severely limited); where hardware acceleration using > parallel processing (SIMD, general multi-core) might be applicable. > I am looking to draw up a list of examples of such processes as > background information and context for a research project. Tools > used for "high-end" mastering at high sample rates (192KHz etc) are > especially of interest. Similarly, tools employing FFTs or > comparable block-based processing. > > I am aware of such things within the domain of 'academic" software > (and have even defined such a process myself that needs at least > 50Gflops of power to run in real-time at a low sample rate), but am > much less aware of what there may be in terms of commercial products > that people use and wish could run a lot faster! > > > > Richard Dobson > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription > info, FAQ, source code archive, list archive, book reviews, dsp > links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp From vesa.norilo at saunalahti.fi Mon Jun 9 09:55:19 2008 From: vesa.norilo at saunalahti.fi (Vesa Norilo) Date: Mon Jun 9 09:55:29 2008 Subject: [music-dsp] High CPU-load processes In-Reply-To: <484D02F6.4000901@blueyonder.co.uk> References: <484D02F6.4000901@blueyonder.co.uk> Message-ID: <484D3647.2020703@saunalahti.fi> Hi Richard, There's a phase correction tool in Adobe Audition that delays one channel of a stereo track to maximize the correlation between channels. It can run in realtime, but is constrained to a resolution of 1ms. Extending this to subsample accuracy would potentially be a very interesting application and certainly heavy on the CPU. Convolution applications are pretty obvious. In addition to sampled acoustics, a very high fidelity Hilbert transform may be interesting. In the realm of sound synthesis, the application of finite element modeling to soundboards and acoustics is something I believe we will be seeing shortly as CPU power increases. Ray-traced acoustics are also interesting. I've seen a GPU-offloaded raytraced reverb with moving sound sources. Albeit not a commercial product. Adding refraction, diffraction etc. to such an algorithm would give a overlap with FEM. Vesa > Hello all, > > > Apologies for any cross-posting. > > I am interested to hear of any currently available audio processes > (effects, instruments, etc) that are known to be very expensive in CPU > terms (e.g. close to or even exceeding 100% load on a modern consumer > machine, or where the possible number of simultaneous instances is > severely limited); where hardware acceleration using parallel > processing (SIMD, general multi-core) might be applicable. I am > looking to draw up a list of examples of such processes as background > information and context for a research project. Tools used for > "high-end" mastering at high sample rates (192KHz etc) are especially > of interest. Similarly, tools employing FFTs or comparable block-based > processing. > > I am aware of such things within the domain of 'academic" software > (and have even defined such a process myself that needs at least > 50Gflops of power to run in real-time at a low sample rate), but am > much less aware of what there may be in terms of commercial products > that people use and wish could run a lot faster! > > > > Richard Dobson > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription > info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From gogins at pipeline.com Mon Jun 9 10:27:54 2008 From: gogins at pipeline.com (Michael Gogins) Date: Mon Jun 9 10:28:04 2008 Subject: [music-dsp] High CPU-load processes Message-ID: <15937541.1213021674680.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> Yes, I think that more realistic physical models are an obvious candidate for computer power. Tao (physical modeling synthesis via linked springs and masses) isn't commercial, but if could run in real time you could make a pretty cool commercial synthesizer with it. http://web.ukonline.co.uk/taosynth/ Regards, Mike -----Original Message----- >From: Vesa Norilo >Sent: Jun 9, 2008 9:55 AM >To: A discussion list for music-related DSP >Subject: Re: [music-dsp] High CPU-load processes > >Hi Richard, > >There's a phase correction tool in Adobe Audition that delays one >channel of a stereo track to maximize the correlation between channels. >It can run in realtime, but is constrained to a resolution of 1ms. >Extending this to subsample accuracy would potentially be a very >interesting application and certainly heavy on the CPU. > >Convolution applications are pretty obvious. In addition to sampled >acoustics, a very high fidelity Hilbert transform may be interesting. > >In the realm of sound synthesis, the application of finite element >modeling to soundboards and acoustics is something I believe we will be >seeing shortly as CPU power increases. > >Ray-traced acoustics are also interesting. I've seen a GPU-offloaded >raytraced reverb with moving sound sources. Albeit not a commercial >product. Adding refraction, diffraction etc. to such an algorithm would >give a overlap with FEM. > >Vesa >> Hello all, >> >> >> Apologies for any cross-posting. >> >> I am interested to hear of any currently available audio processes >> (effects, instruments, etc) that are known to be very expensive in CPU >> terms (e.g. close to or even exceeding 100% load on a modern consumer >> machine, or where the possible number of simultaneous instances is >> severely limited); where hardware acceleration using parallel >> processing (SIMD, general multi-core) might be applicable. I am >> looking to draw up a list of examples of such processes as background >> information and context for a research project. Tools used for >> "high-end" mastering at high sample rates (192KHz etc) are especially >> of interest. Similarly, tools employing FFTs or comparable block-based >> processing. >> >> I am aware of such things within the domain of 'academic" software >> (and have even defined such a process myself that needs at least >> 50Gflops of power to run in real-time at a low sample rate), but am >> much less aware of what there may be in terms of commercial products >> that people use and wish could run a lot faster! >> >> >> >> 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 > >-- >dupswapdrop -- the music-dsp mailing list and website: >subscription info, FAQ, source code archive, list archive, book reviews, dsp links >http://music.columbia.edu/cmc/music-dsp >http://music.columbia.edu/mailman/listinfo/music-dsp From bogac at bteaudio.com Mon Jun 9 11:17:22 2008 From: bogac at bteaudio.com (Bogac Topaktas) Date: Mon Jun 9 11:17:34 2008 Subject: [music-dsp] High CPU-load processes Message-ID: Non-linear system simulation with Wiener-Volterra approaches. One commercial example is Nebula: http://www.acusticaudio.net/ which can be considered as relatively expensive in CPU terms. In general, any non-linear system simulation can be considered as expensive in CPU terms, at least for today's CPUs (especially when the required degree of simulation accuracy is set too high). Some of the reasons behind this fact are outlined in the following article: "Why So Much DSP?" By Dave Berners http://www.uaudio.com/webzine/2008/april/index2.html Bogac. -----Original message----- From: Richard Dobson richarddobson@blueyonder.co.uk Date: Mon, 09 Jun 2008 02:18:10 -0700 To: A discussion list for music-related DSP music-dsp@music.columbia.edu Subject: [music-dsp] High CPU-load processes > Hello all, > > > Apologies for any cross-posting. > > I am interested to hear of any currently available audio processes > (effects, instruments, etc) that are known to be very expensive in CPU > terms (e.g. close to or even exceeding 100% load on a modern consumer > machine, or where the possible number of simultaneous instances is > severely limited); where hardware acceleration using parallel processing > (SIMD, general multi-core) might be applicable. I am looking to draw up > a list of examples of such processes as background information and > context for a research project. Tools used for "high-end" mastering at > high sample rates (192KHz etc) are especially of interest. Similarly, > tools employing FFTs or comparable block-based processing. > > I am aware of such things within the domain of 'academic" software (and > have even defined such a process myself that needs at least 50Gflops of > power to run in real-time at a low sample rate), but am much less aware > of what there may be in terms of commercial products that people use and > wish could run a lot faster! > > > > Richard Dobson > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From padawan12 at obiwannabe.co.uk Mon Jun 9 11:21:06 2008 From: padawan12 at obiwannabe.co.uk (Andy Farnell) Date: Mon Jun 9 11:21:19 2008 Subject: [music-dsp] High CPU-load processes In-Reply-To: <484D3647.2020703@saunalahti.fi> References: <484D02F6.4000901@blueyonder.co.uk> <484D3647.2020703@saunalahti.fi> Message-ID: <20080609162106.44612ef2.padawan12@obiwannabe.co.uk> On Mon, 09 Jun 2008 16:55:19 +0300 Vesa Norilo wrote: > Ray-traced acoustics are also interesting. I've seen a GPU-offloaded > raytraced reverb with moving sound sources. Albeit not a commercial > product. Adding refraction, diffraction etc. to such an algorithm would > give a overlap with FEM. Very large environmental modelling is a fascinating and useful area where we are always running out of processing power. It has applications in games/VR but also in noise abatement, transport planning etc. Efficient models for absorption, diffraction, refraction (occlusion), scattering, diffusion, ground effects etc... see Angelo Farinas work for more ideas. Most times for games and music production we just fake it with comb filters and so forth, but efficient new approximations are always welcome. I guess the trick, if there is one, is to find a balance between heuristics and FEM (which will always be almost impossible in real time - at least for outdoor scales). -- Use the source From jchandjr at bellsouth.net Mon Jun 9 11:22:01 2008 From: jchandjr at bellsouth.net (James Chandler Jr) Date: Mon Jun 9 11:22:25 2008 Subject: [music-dsp] High CPU-load processes In-Reply-To: <15937541.1213021674680.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> References: <15937541.1213021674680.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> Message-ID: <915E4C81F1044BB19D123D614A3E4B5E@VistaOnMacPro> "Insanely High Quality" time/pitch stretchers can generally run real-time on modern CPU's, at least if you only need to play a stereo mix. But consider if you have a multi-track program with numerous canned-resynthesized audio tracks, derived from high-quality expert instrumental recordings. Each audio track could be in a different original key and tempo, and you want to force all the tracks into the same key and tempo (obviously). I think that really-high-quality time/pitch stretching is still too expensive to do independent time/pitch on many tracks simultaneously, realtime. But perhaps nowadays computers have become fast enough and I didn't discover it yet. jcjr ----- Original Message ----- From: "Michael Gogins" To: "A discussion list for music-related DSP" Sent: Monday, June 09, 2008 10:27 AM Subject: Re: [music-dsp] High CPU-load processes > Yes, I think that more realistic physical models are an obvious candidate for > computer power. > > Tao (physical modeling synthesis via linked springs and masses) isn't > commercial, but if could run in real time you could make a pretty cool > commercial synthesizer with it. > > http://web.ukonline.co.uk/taosynth/ > > Regards, > Mike > > -----Original Message----- >>From: Vesa Norilo >>Sent: Jun 9, 2008 9:55 AM >>To: A discussion list for music-related DSP >>Subject: Re: [music-dsp] High CPU-load processes >> >>Hi Richard, >> >>There's a phase correction tool in Adobe Audition that delays one >>channel of a stereo track to maximize the correlation between channels. >>It can run in realtime, but is constrained to a resolution of 1ms. >>Extending this to subsample accuracy would potentially be a very >>interesting application and certainly heavy on the CPU. >> >>Convolution applications are pretty obvious. In addition to sampled >>acoustics, a very high fidelity Hilbert transform may be interesting. >> >>In the realm of sound synthesis, the application of finite element >>modeling to soundboards and acoustics is something I believe we will be >>seeing shortly as CPU power increases. >> >>Ray-traced acoustics are also interesting. I've seen a GPU-offloaded >>raytraced reverb with moving sound sources. Albeit not a commercial >>product. Adding refraction, diffraction etc. to such an algorithm would >>give a overlap with FEM. >> >>Vesa >>> Hello all, >>> >>> >>> Apologies for any cross-posting. >>> >>> I am interested to hear of any currently available audio processes >>> (effects, instruments, etc) that are known to be very expensive in CPU >>> terms (e.g. close to or even exceeding 100% load on a modern consumer >>> machine, or where the possible number of simultaneous instances is >>> severely limited); where hardware acceleration using parallel >>> processing (SIMD, general multi-core) might be applicable. I am >>> looking to draw up a list of examples of such processes as background >>> information and context for a research project. Tools used for >>> "high-end" mastering at high sample rates (192KHz etc) are especially >>> of interest. Similarly, tools employing FFTs or comparable block-based >>> processing. >>> >>> I am aware of such things within the domain of 'academic" software >>> (and have even defined such a process myself that needs at least >>> 50Gflops of power to run in real-time at a low sample rate), but am >>> much less aware of what there may be in terms of commercial products >>> that people use and wish could run a lot faster! >>> >>> >>> >>> 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 >> >>-- >>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 fwks5029 at mb.infoweb.ne.jp Mon Jun 9 12:43:25 2008 From: fwks5029 at mb.infoweb.ne.jp (kato tatsuya) Date: Mon Jun 9 12:44:09 2008 Subject: [music-dsp] High CPU-load processes References: <20080609135539.EA70229C73AA4@music.columbia.edu> Message-ID: <009001c8ca4f$f04770a0$0201a8c0@CoreCore> Hi ! Now I am also interested in what you are interested. I can quote several techniques for music dsp. 1. Dynamic Convolution Normally , convolution is static . That's not varied by the time-passing or rise and fall of amplitude, or other conditions. Dynamic convolution is dynamic. One of easy implementation is , summation of convovers which inputs diffrently processed audio source. (for example, an input singnal is passing into diffrent limitters , then each outputs are connected into diffrent convolver, and added up.) more tough one, is all taps of impulse response are moving independently. rule of transformation is arbitrarily. I think blind-deconvolution or active-noise-canceler may one of the dynamic convolition. (their rule is gradient mothed, in a lot of cases.) 2. Granular synthesis This is likely the classical synthesis method. But diffrent aspects will be appeared in our ears according to the speeding up of DSP. At high sampling rate, Discontinuous noise , that often happens in the process of granular synthesis, is heaerd more CRISPY to me and to me. because alias is gone into the high frequency. And also phase information of discontinuous point is more meanful. Of cause, granularity is the important character of synthesis, single grain, several grains, 10 of grains, 100 of grains. each granularities provide different feelings to us. 3, Evolutionary Conputation many synthesizers generate different sounds at the same time. But just one or a few of sounds are able to reach our ears. Another sounds are NOT unnecessary, because they provide the variety to survive in the crucial enviroment. The enviroment is usually expressed as the evaluation function, which returns a number for each synthesizers as his score. Only topmost synthesizers can survive, another dead. Deceased synthesizers are born again with similar setting of the surviver. Constraint for parameters of synthesizer, and howto calculate evaluation function, are arbitrarily. It depends on your (or another person's) idea. Tatsuya Kato >I am interested to hear of any currently available audio processes > (effects, instruments, etc) that are known to be very expensive in CPU > terms (e.g. close to or even exceeding 100% load on a modern consumer > machine, or where the possible number of simultaneous instances is > severely limited); where hardware acceleration using parallel processing > (SIMD, general multi-core) might be applicable. I am looking to draw up > a list of examples of such processes as background information and > context for a research project. Tools used for "high-end" mastering at > high sample rates (192KHz etc) are especially of interest. Similarly, > tools employing FFTs or comparable block-based processing. > > I am aware of such things within the domain of 'academic" software (and > have even defined such a process myself that needs at least 50Gflops of > power to run in real-time at a low sample rate), but am much less aware > of what there may be in terms of commercial products that people use and > wish could run a lot faster! > From gogins at pipeline.com Mon Jun 9 13:04:26 2008 From: gogins at pipeline.com (Michael Gogins) Date: Mon Jun 9 13:04:38 2008 Subject: [music-dsp] High CPU-load processes Message-ID: <28971374.1213031067190.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> I agree that evolutionary computation is an important field where parallel processing and computer power make sense. With enough computer power, the synthesizer could evolve instances in the background, and fade them into a mix as they finished mutating and crossing. Then, the user could indicate with the mouse which direction of mutation or which instance was the most satisfactory. If this could be done in real time it might be revolutionary. Regards, Mike -----Original Message----- >From: kato tatsuya >Sent: Jun 9, 2008 12:43 PM >To: music-dsp@music.columbia.edu >Subject: Re: [music-dsp] High CPU-load processes > >Hi ! > >Now I am also interested in what you are interested. > >I can quote several techniques for music dsp. > >1. Dynamic Convolution >Normally , convolution is static . >That's not varied by the time-passing or rise and fall of amplitude, or >other conditions. >Dynamic convolution is dynamic. >One of easy implementation is , summation of convovers which inputs >diffrently processed audio source. >(for example, an input singnal is passing into diffrent limitters , then >each outputs are connected into diffrent convolver, >and added up.) >more tough one, is all taps of impulse response are moving independently. >rule of transformation is arbitrarily. >I think blind-deconvolution or active-noise-canceler may one of the dynamic >convolition. >(their rule is gradient mothed, in a lot of cases.) > >2. Granular synthesis >This is likely the classical synthesis method. >But diffrent aspects will be appeared in our ears according to the speeding >up of DSP. >At high sampling rate, >Discontinuous noise , that often happens in the process of granular >synthesis, >is heaerd more CRISPY to me and to me. >because alias is gone into the high frequency. >And also phase information of discontinuous point is more meanful. > >Of cause, granularity is the important character of synthesis, >single grain, several grains, 10 of grains, 100 of grains. >each granularities provide different feelings to us. > >3, Evolutionary Conputation >many synthesizers generate different sounds at the same time. >But just one or a few of sounds are able to reach our ears. >Another sounds are NOT unnecessary, >because they provide the variety to survive in the crucial enviroment. >The enviroment is usually expressed as the evaluation function, >which returns a number for each synthesizers as his score. >Only topmost synthesizers can survive, another dead. >Deceased synthesizers are born again with similar setting of the surviver. > >Constraint for parameters of synthesizer, and howto calculate evaluation >function, >are arbitrarily. >It depends on your (or another person's) idea. > > >Tatsuya Kato > > > > >>I am interested to hear of any currently available audio processes >> (effects, instruments, etc) that are known to be very expensive in CPU >> terms (e.g. close to or even exceeding 100% load on a modern consumer >> machine, or where the possible number of simultaneous instances is >> severely limited); where hardware acceleration using parallel processing >> (SIMD, general multi-core) might be applicable. I am looking to draw up >> a list of examples of such processes as background information and >> context for a research project. Tools used for "high-end" mastering at >> high sample rates (192KHz etc) are especially of interest. Similarly, >> tools employing FFTs or comparable block-based processing. >> >> I am aware of such things within the domain of 'academic" software (and >> have even defined such a process myself that needs at least 50Gflops of >> power to run in real-time at a low sample rate), but am much less aware >> of what there may be in terms of commercial products that people use and >> wish could run a lot faster! >> >-- >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 decoy at iki.fi Mon Jun 9 13:36:02 2008 From: decoy at iki.fi (Sampo Syreeni) Date: Mon Jun 9 13:36:16 2008 Subject: [music-dsp] High CPU-load processes In-Reply-To: <20080609162106.44612ef2.padawan12@obiwannabe.co.uk> References: <484D02F6.4000901@blueyonder.co.uk> <484D3647.2020703@saunalahti.fi> <20080609162106.44612ef2.padawan12@obiwannabe.co.uk> Message-ID: On 2008-06-09, Andy Farnell wrote: > I guess the trick, if there is one, is to find a balance between > heuristics and FEM (which will always be almost impossible in real > time - at least for outdoor scales). One insight I once got from theoretical rendering work and algebraic multiresolution solvers is that there are systematic ways of breaking down complex PDE's such that you can control the total computational load. In the acoustic case, I'd expect those to take the form of combined FEM, BEM, statistical-modal treatment, ray acoustics and all of the stuff that lives in between, like analytic diffraction models. That ought to keep your code at 100% load for the time to come -- each time you kill one of the specialized models, you'll end up feeding it to FEM. Which is a computational quagmire, of course. ;) -- Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 From decoy at iki.fi Mon Jun 9 13:47:24 2008 From: decoy at iki.fi (Sampo Syreeni) Date: Mon Jun 9 13:47:35 2008 Subject: [music-dsp] High CPU-load processes In-Reply-To: <915E4C81F1044BB19D123D614A3E4B5E@VistaOnMacPro> References: <15937541.1213021674680.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> <915E4C81F1044BB19D123D614A3E4B5E@VistaOnMacPro> Message-ID: On 2008-06-09, James Chandler Jr wrote: > But consider if you have a multi-track program with numerous > canned-resynthesized audio tracks, derived from high-quality expert > instrumental recordings. [...] Multichannel analysis, especially for interchannel correlations (often done with high end multichannel codecs), can also sink just about limitless amounts of cycles. -- Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 From music-dsp at musemagic.com Mon Jun 9 16:03:00 2008 From: music-dsp at musemagic.com (Bob Grove) Date: Mon Jun 9 16:03:11 2008 Subject: [music-dsp] High CPU-load processes In-Reply-To: References: <15937541.1213021674680.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net><915E4C81F1044BB19D123D614A3E4B5E@VistaOnMacPro> Message-ID: <000f01c8ca6b$d2475220$6401a8c0@acer> Question: Let's say one is implementing for concurrent, multi-processor boards, or even something like SSE3/SSE4 (SIMD), the issue with cross-correlation on multiple streams has data dependencies that in my head are going to automatically require semaphores, i.e. pipe stalls and potential issues with data copy, moves. So, are there any papers out there and/or algorithmic modifications, anybody really look at optimizations for Quad/parallel processing boards w.r.t. multi-channel, Pro audio applications from things like x channel soft mixers, equalization, spatialization, 7.1 audio streams, etc.? I never even thought about this until this post popped up. Good post! -----Original Message----- From: Sampo Syreeni [mailto:decoy@iki.fi] Sent: Monday, June 09, 2008 10:47 AM To: A discussion list for music-related DSP Subject: Re: [music-dsp] High CPU-load processes On 2008-06-09, James Chandler Jr wrote: > But consider if you have a multi-track program with numerous > canned-resynthesized audio tracks, derived from high-quality expert > instrumental recordings. [...] Multichannel analysis, especially for interchannel correlations (often done with high end multichannel codecs), can also sink just about limitless amounts of cycles. -- Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp From richarddobson at blueyonder.co.uk Mon Jun 9 17:35:17 2008 From: richarddobson at blueyonder.co.uk (Richard Dobson) Date: Mon Jun 9 17:37:06 2008 Subject: [music-dsp] High CPU-load processes In-Reply-To: References: Message-ID: <484DA215.5080106@blueyonder.co.uk> Thanks everyone for the replies so far (more please!). I am glad it has stimulated some interest. While all the answers so far are very interesting and helpful, I am hoping to find some working examples I can put numbers to - benchmark, etc. The reference to Nebula (acustica audio) is very much on target for me, as it is a product that I can download and try out on different systems in just that way. Especially notable is that in the "pro" version it offers acceleration using Nvidia's CUDA system - this seems to me to be the picture of one very likely future. I am not a mathematician so "Volterra Kernels" is little more than a name to me (though I am clear that it relates pretty closely to "dynamic convolution"), but I do get the impression it is a very good fit to dense multi-core processing, and possibly of its kind a canonical benchmark process for evaluating high-performance parallel and multi-core systems. We (at Bath Uni) have already made some speculative references to Finite Element physical models in some of our work published so far; but until we can get them running on some high-performance parallel hardware it all remains something more speculative than concrete. So any info on current systems employing FEM is especially welcome. Richard Dobson From richarddobson at blueyonder.co.uk Mon Jun 9 20:57:29 2008 From: richarddobson at blueyonder.co.uk (Richard Dobson) Date: Mon Jun 9 20:59:07 2008 Subject: [music-dsp] High CPU-load processes In-Reply-To: <484D3647.2020703@saunalahti.fi> References: <484D02F6.4000901@blueyonder.co.uk> <484D3647.2020703@saunalahti.fi> Message-ID: <484DD179.1070601@blueyonder.co.uk> Vesa Norilo wrote: .. > Ray-traced acoustics are also interesting. I've seen a GPU-offloaded > raytraced reverb with moving sound sources. Albeit not a commercial > product. Do you have any more info about this - name, link, etc? Richard Dobson From xcolwell at gmail.com Mon Jun 9 21:05:08 2008 From: xcolwell at gmail.com (brien colwell) Date: Mon Jun 9 21:05:17 2008 Subject: [music-dsp] High CPU-load processes In-Reply-To: <484DA215.5080106@blueyonder.co.uk> References: <484DA215.5080106@blueyonder.co.uk> Message-ID: <484DD344.7040808@gmail.com> Accurately modelling acoustics could be interesting ... I think you could parallelize that with some magic. Richard Dobson wrote: > Thanks everyone for the replies so far (more please!). I am glad it > has stimulated some interest. While all the answers so far are very > interesting and helpful, I am hoping to find some working examples I > can put numbers to - benchmark, etc. The reference to Nebula (acustica > audio) is very much on target for me, as it is a product that I can > download and try out on different systems in just that way. Especially > notable is that in the "pro" version it offers acceleration using > Nvidia's CUDA system - this seems to me to be the picture of one very > likely future. I am not a mathematician so "Volterra Kernels" is > little more than a name to me (though I am clear that it relates > pretty closely to "dynamic convolution"), but I do get the impression > it is a very good fit to dense multi-core processing, and possibly of > its kind a canonical benchmark process for evaluating high-performance > parallel and multi-core systems. > > We (at Bath Uni) have already made some speculative references to > Finite Element physical models in some of our work published so far; > but until we can get them running on some high-performance parallel > hardware it all remains something more speculative than concrete. So > any info on current systems employing FEM is especially welcome. > > Richard Dobson > > > > > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription > info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From dan.stowell at elec.qmul.ac.uk Tue Jun 10 04:13:11 2008 From: dan.stowell at elec.qmul.ac.uk (Dan Stowell) Date: Tue Jun 10 04:13:33 2008 Subject: [music-dsp] High CPU-load processes In-Reply-To: <484D02F6.4000901@blueyonder.co.uk> References: <484D02F6.4000901@blueyonder.co.uk> Message-ID: <484E3797.4090406@elec.qmul.ac.uk> Hi - Maybe you'd like to consider the "sliding phase vocoder" or "sliding DFT". http://dream.cs.bath.ac.uk/SDFT/SPV-pages.pdf http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1184347 The idea is essentially a DFT whose state is updated once for every audio sample (rather than being calculated from scratch every N samples). Currently it takes a very long time to calculate on a desktop computer, so long as to be impractical, but may in future be a useful high-resolution FT method. HTH Dan Richard Dobson wrote: > Hello all, > > > Apologies for any cross-posting. > > I am interested to hear of any currently available audio processes > (effects, instruments, etc) that are known to be very expensive in CPU > terms (e.g. close to or even exceeding 100% load on a modern consumer > machine, or where the possible number of simultaneous instances is > severely limited); where hardware acceleration using parallel processing > (SIMD, general multi-core) might be applicable. I am looking to draw up > a list of examples of such processes as background information and > context for a research project. Tools used for "high-end" mastering at > high sample rates (192KHz etc) are especially of interest. Similarly, > tools employing FFTs or comparable block-based processing. > > I am aware of such things within the domain of 'academic" software (and > have even defined such a process myself that needs at least 50Gflops of > power to run in real-time at a low sample rate), but am much less aware > of what there may be in terms of commercial products that people use and > wish could run a lot faster! > > > > 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 -- Dan Stowell Centre for Digital Music Queen Mary, University of London Mile End Road, London E1 4NS http://www.elec.qmul.ac.uk/department/staff/research/dans.htm http://www.mcld.co.uk/ From Victor.Lazzarini at nuim.ie Tue Jun 10 04:25:21 2008 From: Victor.Lazzarini at nuim.ie (victor) Date: Tue Jun 10 04:25:31 2008 Subject: [music-dsp] High CPU-load processes References: <484D02F6.4000901@blueyonder.co.uk> <484E3797.4090406@elec.qmul.ac.uk> Message-ID: <000801c8cad3$86128510$0201a8c0@family> Hi Dan, ...Richard is one of the authors of that research. I think he is looking for other applications besides the SPV... Victor ----- Original Message ----- From: "Dan Stowell" To: "A discussion list for music-related DSP" Sent: Tuesday, June 10, 2008 9:13 AM Subject: Re: [music-dsp] High CPU-load processes > Hi - > > Maybe you'd like to consider the "sliding phase vocoder" or "sliding DFT". > http://dream.cs.bath.ac.uk/SDFT/SPV-pages.pdf > http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1184347 > > The idea is essentially a DFT whose state is updated once for every audio > sample (rather than being calculated from scratch every N samples). > Currently it takes a very long time to calculate on a desktop computer, so > long as to be impractical, but may in future be a useful high-resolution > FT method. > > HTH > Dan > > > > Richard Dobson wrote: >> Hello all, >> >> >> Apologies for any cross-posting. >> >> I am interested to hear of any currently available audio processes >> (effects, instruments, etc) that are known to be very expensive in CPU >> terms (e.g. close to or even exceeding 100% load on a modern consumer >> machine, or where the possible number of simultaneous instances is >> severely limited); where hardware acceleration using parallel processing >> (SIMD, general multi-core) might be applicable. I am looking to draw up a >> list of examples of such processes as background information and context >> for a research project. Tools used for "high-end" mastering at high >> sample rates (192KHz etc) are especially of interest. Similarly, tools >> employing FFTs or comparable block-based processing. >> >> I am aware of such things within the domain of 'academic" software (and >> have even defined such a process myself that needs at least 50Gflops of >> power to run in real-time at a low sample rate), but am much less aware >> of what there may be in terms of commercial products that people use and >> wish could run a lot faster! >> >> >> >> 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 > > > -- > Dan Stowell > Centre for Digital Music > Queen Mary, University of London > Mile End Road, London E1 4NS > http://www.elec.qmul.ac.uk/department/staff/research/dans.htm > http://www.mcld.co.uk/ > -- > dupswapdrop -- the music-dsp mailing list and website: subscription info, > FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From Victor.Lazzarini at nuim.ie Tue Jun 10 04:29:07 2008 From: Victor.Lazzarini at nuim.ie (victor) Date: Tue Jun 10 04:29:17 2008 Subject: [music-dsp] High CPU-load processes References: <484D02F6.4000901@blueyonder.co.uk> <484D3647.2020703@saunalahti.fi> <484DD179.1070601@blueyonder.co.uk> Message-ID: <002101c8cad4$0cb1de40$0201a8c0@family> I have a student working with binaural reverb using ray-tracing which is looking expensive to me. Perhaps you might want to talk to him, I can send his e-mail to you privately. Victor ----- Original Message ----- From: "Richard Dobson" To: "A discussion list for music-related DSP" Sent: Tuesday, June 10, 2008 1:57 AM Subject: Re: [music-dsp] High CPU-load processes > Vesa Norilo wrote: > .. >> Ray-traced acoustics are also interesting. I've seen a GPU-offloaded >> raytraced reverb with moving sound sources. Albeit not a commercial >> product. > > Do you have any more info about this - name, link, etc? > > Richard Dobson > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription info, > FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From stephen.blinkhorn at audiospillage.com Tue Jun 10 15:10:21 2008 From: stephen.blinkhorn at audiospillage.com (Stephen Blinkhorn) Date: Tue Jun 10 14:58:32 2008 Subject: [music-dsp] Paper on bandlimited analog waveform synthesis using FM In-Reply-To: <484223A0.3020200@inf.elte.hu> References: <484223A0.3020200@inf.elte.hu> Message-ID: On 31 May 2008, at 22:20, Peter Schoffhauzer wrote: > Hi, > > You can find it here: > http://scp.web.elte.hu/papers/synthesis1.pdf Thanks Peter, Stephen. From stephen.blinkhorn at audiospillage.com Tue Jun 10 15:13:44 2008 From: stephen.blinkhorn at audiospillage.com (Stephen Blinkhorn) Date: Tue Jun 10 15:01:50 2008 Subject: [music-dsp] fast sin(x) function Message-ID: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com> Hi all, I'm looking for a fast sin(x) type function. So far I haven't found anything with the necessary precision for audio work. Any ideas? Thanks, Stephen. From music-dsp at musemagic.com Tue Jun 10 15:32:40 2008 From: music-dsp at musemagic.com (Bob Grove) Date: Tue Jun 10 15:32:55 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com> References: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com> Message-ID: <002901c8cb30$bfdbc920$6401a8c0@acer> Generate a lookup table. Just use Matlab to generate the number of points you want of the sinusoid and the precision (bit depth), you want, output the calculated coefficients [y], ([y] = sin([x])) to a .txt file and do a look up table. You can even format the output in Matlab to whatever language syntax you're pulling the function into. i.e. double y[] = {0.00023459f, 1.439568f, 1.723986f ........ 0.000016892f, 0f}; http://en.wikipedia.org/wiki/Lookup_table Google should have more stuff out there. You might have to do a floor, trunc, %, or max function to index your table depending on what you're doing. If you don't have Matlab, you can also write up a fast python script or a c executable to do the same thing. -----Original Message----- From: Stephen Blinkhorn [mailto:stephen.blinkhorn@audiospillage.com] Sent: Tuesday, June 10, 2008 12:14 PM To: music-dsp Subject: [music-dsp] fast sin(x) function Hi all, I'm looking for a fast sin(x) type function. So far I haven't found anything with the necessary precision for audio work. Any ideas? Thanks, Stephen. -- 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 decoy at iki.fi Tue Jun 10 16:06:17 2008 From: decoy at iki.fi (Sampo Syreeni) Date: Tue Jun 10 16:06:31 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: <002901c8cb30$bfdbc920$6401a8c0@acer> References: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com> <002901c8cb30$bfdbc920$6401a8c0@acer> Message-ID: On 2008-06-10, Bob Grove wrote: > Generate a lookup table. I'd argue against that in today's memory starved environments; today looking something up is often vastly inferior to just calculating it out on the fly. I'd instead crack a book on polynomial approximations, and go piecewise polynomial with an entirely code based approach. Or, then, use one of the better math libraries, which...do that for you. ;) -- Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 From decoy at iki.fi Tue Jun 10 16:09:58 2008 From: decoy at iki.fi (Sampo Syreeni) Date: Tue Jun 10 16:10:10 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: References: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com> <002901c8cb30$bfdbc920$6401a8c0@acer> Message-ID: On 2008-06-10, Sampo Syreeni wrote: > I'd argue against that in today's memory starved environments; [...] (Naturally what I meant there wasn't "memory starved", but "memory bandwidth and/or latency starved". Sorry.) -- Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 From bastian.schnuerle at silberstein.de Tue Jun 10 16:31:23 2008 From: bastian.schnuerle at silberstein.de (bastian.schnuerle) Date: Tue Jun 10 16:31:38 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: References: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com> <002901c8cb30$bfdbc920$6401a8c0@acer> Message-ID: <660D523B-E949-4D1C-A377-B92F592E6A4F@silberstein.de> via complex numbers a + jx .. Am 10.06.2008 um 22:09 schrieb Sampo Syreeni: > On 2008-06-10, Sampo Syreeni wrote: > >> I'd argue against that in today's memory starved environments; [...] > > (Naturally what I meant there wasn't "memory starved", but "memory > bandwidth and/or latency starved". Sorry.) > -- > Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111 > student/math+cs/helsinki university, http://www.iki.fi/~decoy/front > openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 > -- > 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 ebrombaugh1 at cox.net Tue Jun 10 16:32:43 2008 From: ebrombaugh1 at cox.net (Eric Brombaugh) Date: Tue Jun 10 16:32:53 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: References: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com> <002901c8cb30$bfdbc920$6401a8c0@acer> Message-ID: <484EE4EB.2040107@cox.net> Sampo Syreeni wrote: > On 2008-06-10, Sampo Syreeni wrote: > >> I'd argue against that in today's memory starved environments; [...] > > (Naturally what I meant there wasn't "memory starved", but "memory > bandwidth and/or latency starved". Sorry.) Probably depends on what type of processor you're using (desktop vs embedded), how large the LUT is (does it fit in cache on a high-end PC), what kind of FP support you've got and how many iterations of the polynomial it takes to get the required accuracy on your function. Definitely not just a one-size-fits-all type of answer... Eric From didid at skynet.be Tue Jun 10 16:37:45 2008 From: didid at skynet.be (Didier Dambrin) Date: Tue Jun 10 16:38:03 2008 Subject: [music-dsp] fast sin(x) function References: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com><002901c8cb30$bfdbc920$6401a8c0@acer> Message-ID: <006d01c8cb39$d71c4e30$0401a8c0@GOLAMD> I haven't found a (16k values) lookup table vastly inferior. With 16k values you can ommit interpolation & get away with it, and then it's cheap instruction-wise, and the cache does its job. I have a highly optimized SSE1 version that computes 8 sinewaves at once (talking about additive synth use) (it could compute a single sinewave but then you'd have to init your algo with 8x3 sines instead of just 3) which is only a little faster than a lookup table. Only problem, with single float precision it quickly loses precision over time, and then has to be re-initialized (3 costy sines) or you have to process in double precision (only 2x packed). ..but that's to generate tones, not compute random sines, so better first know what he needs a sine for. I just went checking if Intel or AMD finally added something to help low-quality sine computation (that everyone asks for, like FISTTP that they introduced in SSE3, only 10 years too late, god knows why they add a new FPU instruction while they advise SSE even for scalar stuff), saw nothing in SSE4, and saw that the next gen will have the same fight as 3DNow vs SSE. Except that it's now AMD that calls the new one SSE5, and Intel will introduce 'AVX'. And we'll have to guess which one will win. ----- Original Message ----- From: "Sampo Syreeni" To: "A discussion list for music-related DSP" Sent: Tuesday, June 10, 2008 10:06 PM Subject: RE: [music-dsp] fast sin(x) function > On 2008-06-10, Bob Grove wrote: > >> Generate a lookup table. > > I'd argue against that in today's memory starved environments; today > looking something up is often vastly inferior to just calculating it out > on the fly. I'd instead crack a book on polynomial approximations, and > go piecewise polynomial with an entirely code based approach. > > Or, then, use one of the better math libraries, which...do that for you. > ;) > -- > Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111 > student/math+cs/helsinki university, http://www.iki.fi/~decoy/front > openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 > -- > 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 decoy at iki.fi Tue Jun 10 16:50:56 2008 From: decoy at iki.fi (Sampo Syreeni) Date: Tue Jun 10 16:51:09 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: <484EE4EB.2040107@cox.net> References: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com> <002901c8cb30$bfdbc920$6401a8c0@acer> <484EE4EB.2040107@cox.net> Message-ID: On 2008-06-10, Eric Brombaugh wrote: >> (Naturally what I meant there wasn't "memory starved", but "memory >> bandwidth and/or latency starved". Sorry.) > > Probably depends on what type of processor you're using (desktop vs > embedded), how large the LUT is (does it fit in cache on a high-end > PC), what kind of FP support you've got and how many iterations of the > polynomial it takes to get the required accuracy on your function. Quite so, and I'm glad you pointed that out. In the typical desktop processor, the bandwidth problem is heavily aggravated, and so you also rely heavily on the cache design. A LUT might work, or it might not, depending on the eviction policy, cache size, alignment, multitasking conditions and whatnot. On an embedded processor, the gap is still there, but because of dedicated processing features like well-pipelined MAC and compilers that can deal with it, and of course a less-steep incongruity between core and memory cycle lengths, it's less, on these sorts of applications. But it's still there. After that the tradeoff revolves around how fast you can code sin(x) using the existing primitives, and whether your pipeline can hang upto your code without significant stalls. (Special casing easily leads to that, big time, and on the other hand, not special casing your code will easily lead to many iterations beyond the piecewise polynomial scenario.) To me it also sounds the embedded limit is what we're talking about, here. I mean, otherwise you'd use the fast, dedicated, hardware accelerated and/or microcoded, solutions that your average desktop processor already offers. You wouldn't code your own. > Definitely not just a one-size-fits-all type of answer... Again, quite true. I should have said as much myself. -- Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 From decoy at iki.fi Tue Jun 10 16:57:17 2008 From: decoy at iki.fi (Sampo Syreeni) Date: Tue Jun 10 16:57:30 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: <006d01c8cb39$d71c4e30$0401a8c0@GOLAMD> References: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com><002901c8cb30$bfdbc920$6401a8c0@acer> <006d01c8cb39$d71c4e30$0401a8c0@GOLAMD> Message-ID: On 2008-06-10, Didier Dambrin wrote: > I haven't found a (16k values) lookup table vastly inferior. With 16k > values you can ommit interpolation & get away with it, and then it's > cheap instruction-wise, and the cache does its job. It does, but for audio apps, you usually need at least linear interpolation (fast) there, and then you also have to consider what happens when that particular loop interacts not just with the LUT, but with the source and target buffers, any interfacing code, and so on. > I have a highly optimized SSE1 version that computes 8 sinewaves at > once (talking about additive synth use) (it could compute a single > sinewave but then you'd have to init your algo with 8x3 sines instead > of just 3) which is only a little faster than a lookup table. That's just about the description I started with: think about how it'll fare with the next CPU you acquire. The performance penalty is only going to get aggravated. > Only problem, with single float precision it quickly loses precision > over time, and then has to be re-initialized (3 costy sines) or you > have to process in double precision (only 2x packed). Ah. That's a bit different then. A free-running sinusoid oscillator is a completely different beast when compared to a pointwise evaluation of a sin(x) function. Of course the problems are different in both cases. > ..but that's to generate tones, not compute random sines, so better > first know what he needs a sine for. Yes, my point exactly. > I just went checking if Intel or AMD finally added something to help > low-quality sine computation (that everyone asks for, like FISTTP that > they introduced in SSE3, only 10 years too late, god knows why they > add a new FPU instruction while they advise SSE even for scalar > stuff), saw nothing in SSE4, and saw that the next gen will have the > same fight as 3DNow vs SSE. Except that it's now AMD that calls the > new one SSE5, and Intel will introduce 'AVX'. And we'll have to guess > which one will win. Yes. Personally I think they ought to roll out an instruction set somewhere between cordic assistance and dedicated FIR processing. That'd be more or less ideal for oscillator building, at least from the theoretical viewing point. But then, audio isn't such a big priority for the CPU makers. -- Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 From ebrombaugh1 at cox.net Tue Jun 10 17:06:04 2008 From: ebrombaugh1 at cox.net (Eric Brombaugh) Date: Tue Jun 10 17:06:19 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: References: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com><002901c8cb30$bfdbc920$6401a8c0@acer> <006d01c8cb39$d71c4e30$0401a8c0@GOLAMD> Message-ID: <484EECBC.7000702@cox.net> Sampo Syreeni wrote: > > Yes. Personally I think they ought to roll out an instruction set > somewhere between cordic assistance and dedicated FIR processing. That'd > be more or less ideal for oscillator building, at least from the > theoretical viewing point. > > But then, audio isn't such a big priority for the CPU makers. Sadly true. I wonder if the vertex engines in GPUs would be better for audio? They're good for coordinate transforms, so the trig functions are likely to be optimized for speed & parallelism. Eric From rbj at audioimagination.com Tue Jun 10 17:31:13 2008 From: rbj at audioimagination.com (robert bristow-johnson) Date: Tue Jun 10 17:32:03 2008 Subject: [music-dsp] fast sin(x) function Message-ID: <20080610213113.8B027EDEDA@ws6-1.us4.outblaze.com> > ----- Original Message ----- > From: "Sampo Syreeni" > To: "A discussion list for music-related DSP" > Subject: RE: [music-dsp] fast sin(x) function > Date: Tue, 10 Jun 2008 23:06:17 +0300 (EEST) > > > On 2008-06-10, Bob Grove wrote: > > > Generate a lookup table. > > I'd argue against that in today's memory starved environments; today looking > something up is often vastly inferior to just calculating it out on the fly. > I'd instead crack a book on polynomial approximations, and go piecewise > polynomial with an entirely code based approach. rather than just take a truncated Taylor or Maclauren series, i might suggest to optimize the coefficients a little using the Remes Exchange Algorithm (not to be confused with MATLAB's Park-McClellan alg with the name of "remez"). using such, i optimized a finite order power series for a variety of functions and appended the results below. this has been posted to comp.dsp a while ago. if the OP wants a sin() function for the purpose of generating a nice sine wave for sound, then i would also recommend LUT that is large enough that linear interpolation would be good enough. if instead the sin() function is used in control/coefficient generation, then i would suggest using the finite order series below. with the exception of arctan(), there is no division in any of these. should be fast for a DSP. > Or, then, use one of the better math libraries, which...do that for you. ;) log2(1+x) ~= 1.4425449290 * x + -0.7181451002 * x^2 + 0.4575485901 * x^3 + -0.2779042655 * x^4 + 0.1217970128 * x^5 + -0.0258411662 * x^6 0 <= x <= 1 |error| < 2.217e-6 (exact when x=0 and x=1) (about 1/375th of a cent) 2^x ~= 1.0 + 0.6930321187 * x + 0.2413797743 * x^2 + 0.0520323499 * x^3 + 0.0135557571 * x^4 0 <= x <= 1 |error|/(2^x) < 3.340e-6 (exact when x=0 and x=1) (about 1/173rd of a cent) sqrt(x) ~= 0.2286139087 + 1.3027308205 * x + -0.9125353819 * x^2 + 0.5029902702 * x^3 + -0.1217996175 * x^4 1/2 <= x <= 1 |error|/sqrt(x) < 1.076e-5 (exact when x=1 and nearly exact when x=1/2) sin((pi/2)*x) ~= 1.5707963268 * x + -0.6459640619 * x^3 + 0.0796915849 * x^5 + -0.0046768800 * x^7 + 0.0001530302 * x^9 -1 <= x <= 1 (i can't find the max error results, but it's small) arctan(x) ~= x/f(x^2) where f(u) = 1.0 + 0.3328895051 * u + -0.0846792282 * u^2 + 0.0325223264 * u^3 + -0.0074930586 * u^4 -1 <= x <= 1 (can't find the error results here either, but it's small.) -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From didid at skynet.be Tue Jun 10 17:35:19 2008 From: didid at skynet.be (Didier Dambrin) Date: Tue Jun 10 17:35:31 2008 Subject: [music-dsp] fast sin(x) function References: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com><002901c8cb30$bfdbc920$6401a8c0@acer><006d01c8cb39$d71c4e30$0401a8c0@GOLAMD> Message-ID: <002601c8cb41$e1a1a8c0$0401a8c0@GOLAMD> >> I just went checking if Intel or AMD finally added something to help >> low-quality sine computation (that everyone asks for, like FISTTP that >> they introduced in SSE3, only 10 years too late, god knows why they >> add a new FPU instruction while they advise SSE even for scalar >> stuff), saw nothing in SSE4, and saw that the next gen will have the >> same fight as 3DNow vs SSE. Except that it's now AMD that calls the >> new one SSE5, and Intel will introduce 'AVX'. And we'll have to guess >> which one will win. > > Yes. Personally I think they ought to roll out an instruction set > somewhere between cordic assistance and dedicated FIR processing. That'd > be more or less ideal for oscillator building, at least from the > theoretical viewing point. > > But then, audio isn't such a big priority for the CPU makers. > -- Well, Intel & AMD provide DSP-related libraries, with a big part for audio (there's FIR stuff in them). I think everyone should use them but I see 2 problems with them: -they won't work together. Intel probably won't make anything optimized for AMD's, and AMD for Intel. What I'd really like is Intel to partner with nVidia, so that we can see a CUDA-enhanced version of their libraries (at the same time, I can't imagine it'd work well without heavily paralellized versions of their functions, but it would be nice for FFT). It'd be really nice to use a single library, and see it use the fastest resource available. It'd even be future-proof. It should really be some kind of 'OpenDSP', a standard library that would use any kind of DSP chip if present, and have a CPU version of everything for full compatibility. -it would always be block-processing (I mean, no point in calling a function in a DLL if it takes more time to call the function than to process it), and with users wanting smaller & smaller latencies (that they don't even need), it starts to be less interesting to build code in layers of block-processing. There's a sine generator in Intel's IPP btw. Unfortunately not really as fast as it could be. From didid at skynet.be Tue Jun 10 17:42:19 2008 From: didid at skynet.be (Didier Dambrin) Date: Tue Jun 10 17:42:41 2008 Subject: [music-dsp] fast sin(x) function References: <20080610213113.8B027EDEDA@ws6-1.us4.outblaze.com> Message-ID: <005101c8cb42$dbc8f740$0401a8c0@GOLAMD> The biggest problem with those approximations is that you have to wrap/limit your phase yourself, and this can cost CPU depending on how it's done (can you really wrap a float phase at low CPU cost?). While it's really cheap to wrap an integer power of 2 index. >>rather than just take a truncated Taylor or Maclauren series, i might >>suggest to optimize the coefficients a little using the Remes Exchange >>Algorithm (not to be confused with MATLAB's Park-McClellan alg with the >>name of "remez"). using such, i optimized a finite order power series for >>a variety of functions and appended the results below. this has been >>posted to comp.dsp a while ago. From rbj at audioimagination.com Tue Jun 10 18:04:18 2008 From: rbj at audioimagination.com (robert bristow-johnson) Date: Tue Jun 10 18:04:33 2008 Subject: [music-dsp] fast sin(x) function Message-ID: <20080610220418.83CF450C85@ws6-5.us4.outblaze.com> > ----- Original Message ----- > From: "Didier Dambrin" > To: "A discussion list for music-related DSP" > Subject: Re: [music-dsp] fast sin(x) function > Date: Tue, 10 Jun 2008 23:42:19 +0200 > > > The biggest problem with those approximations is that you have to wrap/limit > your phase yourself, as you would for a lookup table also. > and this can cost CPU depending on how it's done (can > you really wrap a float phase at low CPU cost?). While it's really cheap to > wrap an integer power of 2 index. i wouldn't necessarily do it in floating-point. but either way, you can wrap the phase by masking off high-order bits (so that 2*pi is scaled to be some power of 2), convert to float if necessary, and run your fixed or float result though the finite power series. but, again, for generating a signal, i wouldn't do it this way anyway: i would just use a lookup table. but sometimes sin/cos is used for calculation of filter coefs (and then exceeding the domain limits is not going to happen). sometimes it is to evaluate a filter frequency response (and it need not exceed the domain limits). in these cases, you want really good accuracy for down in the bottom 3 or 4 octaves and LUT won't be good enough. but if you want to use it to generate a sin wave, i wouldn't bother with this series stuff. i would use an LUT that is large enough so that linear interpolation between table entries would be good enough. unless memory is not cheap, i wouldn't bother with higher order interpolation. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From music-dsp at musemagic.com Tue Jun 10 18:27:23 2008 From: music-dsp at musemagic.com (Bob Grove) Date: Tue Jun 10 18:27:37 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: <20080610220418.83CF450C85@ws6-5.us4.outblaze.com> References: <20080610220418.83CF450C85@ws6-5.us4.outblaze.com> Message-ID: <002d01c8cb49$27c1c2c0$6401a8c0@acer> You can also do bitwise masking in float, no reason to convert int-float and back, which is computationally expensive, exp in x86 last time I checked. -----Original Message----- From: robert bristow-johnson [mailto:rbj@audioimagination.com] Sent: Tuesday, June 10, 2008 3:04 PM To: A discussion list for music-related DSP Subject: Re: [music-dsp] fast sin(x) function > ----- Original Message ----- > From: "Didier Dambrin" > To: "A discussion list for music-related DSP" > Subject: Re: [music-dsp] fast sin(x) function > Date: Tue, 10 Jun 2008 23:42:19 +0200 > > > The biggest problem with those approximations is that you have to wrap/limit > your phase yourself, as you would for a lookup table also. > and this can cost CPU depending on how it's done (can > you really wrap a float phase at low CPU cost?). While it's really cheap to > wrap an integer power of 2 index. i wouldn't necessarily do it in floating-point. but either way, you can wrap the phase by masking off high-order bits (so that 2*pi is scaled to be some power of 2), convert to float if necessary, and run your fixed or float result though the finite power series. but, again, for generating a signal, i wouldn't do it this way anyway: i would just use a lookup table. but sometimes sin/cos is used for calculation of filter coefs (and then exceeding the domain limits is not going to happen). sometimes it is to evaluate a filter frequency response (and it need not exceed the domain limits). in these cases, you want really good accuracy for down in the bottom 3 or 4 octaves and LUT won't be good enough. but if you want to use it to generate a sin wave, i wouldn't bother with this series stuff. i would use an LUT that is large enough so that linear interpolation between table entries would be good enough. unless memory is not cheap, i wouldn't bother with higher order interpolation. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp From didid at skynet.be Tue Jun 10 18:29:42 2008 From: didid at skynet.be (Didier Dambrin) Date: Tue Jun 10 18:29:58 2008 Subject: [music-dsp] fast sin(x) function References: <20080610220418.83CF450C85@ws6-5.us4.outblaze.com> <002d01c8cb49$27c1c2c0$6401a8c0@acer> Message-ID: <001801c8cb49$7a323120$0401a8c0@GOLAMD> really? how does it work? (& don't you need to pre-check if it's denormalized or negative?) ----- Original Message ----- From: "Bob Grove" To: "'A discussion list for music-related DSP'" Sent: Wednesday, June 11, 2008 12:27 AM Subject: RE: [music-dsp] fast sin(x) function > You can also do bitwise masking in float, no reason to convert int-float > and > back, which is computationally expensive, exp in x86 last time I checked. > > -----Original Message----- > From: robert bristow-johnson [mailto:rbj@audioimagination.com] > Sent: Tuesday, June 10, 2008 3:04 PM > To: A discussion list for music-related DSP > Subject: Re: [music-dsp] fast sin(x) function > > >> ----- Original Message ----- >> From: "Didier Dambrin" >> To: "A discussion list for music-related DSP" > >> Subject: Re: [music-dsp] fast sin(x) function >> Date: Tue, 10 Jun 2008 23:42:19 +0200 >> >> >> The biggest problem with those approximations is that you have to > wrap/limit >> your phase yourself, > > as you would for a lookup table also. > >> and this can cost CPU depending on how it's done (can >> you really wrap a float phase at low CPU cost?). While it's really cheap > to >> wrap an integer power of 2 index. > > i wouldn't necessarily do it in floating-point. but either way, you can > wrap the phase by masking off high-order bits (so that 2*pi is scaled to > be > some power of 2), convert to float if necessary, and run your fixed or > float > result though the finite power series. but, again, for generating a > signal, > i wouldn't do it this way anyway: i would just use a lookup table. > > but sometimes sin/cos is used for calculation of filter coefs (and then > exceeding the domain limits is not going to happen). sometimes it is to > evaluate a filter frequency response (and it need not exceed the domain > limits). in these cases, you want really good accuracy for down in the > bottom 3 or 4 octaves and LUT won't be good enough. > > but if you want to use it to generate a sin wave, i wouldn't bother with > this series stuff. i would use an LUT that is large enough so that linear > interpolation between table entries would be good enough. unless memory > is > not cheap, i wouldn't bother with higher order interpolation. > > > -- > > r b-j rbj@audioimagination.com > > "Imagination is more important than knowledge." > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp > links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp 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. Version: 8.0.100 / Virus Database: 270.2.0/1494 - Release Date: 10/06/2008 07:22 From padawan12 at obiwannabe.co.uk Tue Jun 10 18:34:14 2008 From: padawan12 at obiwannabe.co.uk (Andy Farnell) Date: Tue Jun 10 18:34:29 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com> References: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com> Message-ID: <20080610233414.6a05a7b8.padawan12@obiwannabe.co.uk> I kept this discussion in my bookmarks since it has some interesting thoughts... bit old now but still relevant http://www.devmaster.net/forums/showthread.php?t=5784 On Tue, 10 Jun 2008 13:13:44 -0600 Stephen Blinkhorn wrote: > Hi all, > > I'm looking for a fast sin(x) type function. So far I haven't found > anything with the necessary precision for audio work. Any ideas? > > Thanks, > Stephen. > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -- Use the source From vesa.norilo at saunalahti.fi Tue Jun 10 18:55:04 2008 From: vesa.norilo at saunalahti.fi (Vesa Norilo) Date: Tue Jun 10 18:55:16 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: <001801c8cb49$7a323120$0401a8c0@GOLAMD> References: <20080610220418.83CF450C85@ws6-5.us4.outblaze.com> <002d01c8cb49$27c1c2c0$6401a8c0@acer> <001801c8cb49$7a323120$0401a8c0@GOLAMD> Message-ID: <484F0648.3080602@saunalahti.fi> > really? how does it work? (& don't you need to pre-check if it's > denormalized or negative?) > Floating point mantissa is linear so it's essentially an integer part. Typically you'd choose exponent so that the 24-bit mantissa causes the floating point number to go from 1 to 2 and then substract 1. That substraction could, I guess, also be factored into the power series. IIRC the order of bits is such that often you can deal with wrapping just by incrementing with integer instruction (in SSE there's no mix&match penalty or register move) and masking off some of the lower bits of exponent, where the mantissa will overflow with phase wrapping. Vesa From music-dsp at musemagic.com Tue Jun 10 19:00:15 2008 From: music-dsp at musemagic.com (Bob Grove) Date: Tue Jun 10 19:00:31 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: <001801c8cb49$7a323120$0401a8c0@GOLAMD> References: <20080610220418.83CF450C85@ws6-5.us4.outblaze.com><002d01c8cb49$27c1c2c0$6401a8c0@acer> <001801c8cb49$7a323120$0401a8c0@GOLAMD> Message-ID: <002e01c8cb4d$bf7a1af0$6401a8c0@acer> yes, the 31 (63 double) bit is always the sign bit, just follow the IEEE std. for float, mantissa, exp. bits r bits. -----Original Message----- From: Didier Dambrin [mailto:didid@skynet.be] Sent: Tuesday, June 10, 2008 3:30 PM To: A discussion list for music-related DSP Subject: Re: [music-dsp] fast sin(x) function really? how does it work? (& don't you need to pre-check if it's denormalized or negative?) ----- Original Message ----- From: "Bob Grove" To: "'A discussion list for music-related DSP'" Sent: Wednesday, June 11, 2008 12:27 AM Subject: RE: [music-dsp] fast sin(x) function > You can also do bitwise masking in float, no reason to convert int-float > and > back, which is computationally expensive, exp in x86 last time I checked. > > -----Original Message----- > From: robert bristow-johnson [mailto:rbj@audioimagination.com] > Sent: Tuesday, June 10, 2008 3:04 PM > To: A discussion list for music-related DSP > Subject: Re: [music-dsp] fast sin(x) function > > >> ----- Original Message ----- >> From: "Didier Dambrin" >> To: "A discussion list for music-related DSP" > >> Subject: Re: [music-dsp] fast sin(x) function >> Date: Tue, 10 Jun 2008 23:42:19 +0200 >> >> >> The biggest problem with those approximations is that you have to > wrap/limit >> your phase yourself, > > as you would for a lookup table also. > >> and this can cost CPU depending on how it's done (can >> you really wrap a float phase at low CPU cost?). While it's really cheap > to >> wrap an integer power of 2 index. > > i wouldn't necessarily do it in floating-point. but either way, you can > wrap the phase by masking off high-order bits (so that 2*pi is scaled to > be > some power of 2), convert to float if necessary, and run your fixed or > float > result though the finite power series. but, again, for generating a > signal, > i wouldn't do it this way anyway: i would just use a lookup table. > > but sometimes sin/cos is used for calculation of filter coefs (and then > exceeding the domain limits is not going to happen). sometimes it is to > evaluate a filter frequency response (and it need not exceed the domain > limits). in these cases, you want really good accuracy for down in the > bottom 3 or 4 octaves and LUT won't be good enough. > > but if you want to use it to generate a sin wave, i wouldn't bother with > this series stuff. i would use an LUT that is large enough so that linear > interpolation between table entries would be good enough. unless memory > is > not cheap, i wouldn't bother with higher order interpolation. > > > -- > > r b-j rbj@audioimagination.com > > "Imagination is more important than knowledge." > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp > links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp 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. Version: 8.0.100 / Virus Database: 270.2.0/1494 - Release Date: 10/06/2008 07:22 -- 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 lselden at gmail.com Tue Jun 10 19:40:22 2008 From: lselden at gmail.com (Luke Selden) Date: Tue Jun 10 19:40:39 2008 Subject: [music-dsp] High CPU-load processes In-Reply-To: <484D02F6.4000901@blueyonder.co.uk> References: <484D02F6.4000901@blueyonder.co.uk> Message-ID: <11294100806101640i1cd33190l690d302a177d17d4@mail.gmail.com> The Detrended Fluctuation Algorithm proposed in: http://www.iua.upf.edu/~sstreich/MusicComplexity.html is too computationally expensive to perform real-time. The author mentions that as a limitation to more widespread application... ~luke On Mon, Jun 9, 2008 at 6:16 AM, Richard Dobson wrote: > Hello all, > > > Apologies for any cross-posting. > > I am interested to hear of any currently available audio processes (effects, > instruments, etc) that are known to be very expensive in CPU terms (e.g. > close to or even exceeding 100% load on a modern consumer machine, or where > the possible number of simultaneous instances is severely limited); where > hardware acceleration using parallel processing (SIMD, general multi-core) > might be applicable. I am looking to draw up a list of examples of such > processes as background information and context for a research project. > Tools used for "high-end" mastering at high sample rates (192KHz etc) are > especially of interest. Similarly, tools employing FFTs or comparable > block-based processing. > > I am aware of such things within the domain of 'academic" software (and have > even defined such a process myself that needs at least 50Gflops of power to > run in real-time at a low sample rate), but am much less aware of what there > may be in terms of commercial products that people use and wish could run a > lot faster! > > > > Richard Dobson > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription info, > FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From rbj at audioimagination.com Wed Jun 11 00:22:21 2008 From: rbj at audioimagination.com (robert bristow-johnson) Date: Wed Jun 11 00:22:34 2008 Subject: [music-dsp] High CPU-load processes Message-ID: <20080611042221.28174EDD89@ws6-1.us4.outblaze.com> > ----- Original Message ----- > From: "Luke Selden" > To: "A discussion list for music-related DSP" > Subject: Re: [music-dsp] High CPU-load processes > Date: Tue, 10 Jun 2008 19:40:22 -0400 > > > The Detrended Fluctuation Algorithm proposed in: > http://www.iua.upf.edu/~sstreich/MusicComplexity.html > is too computationally expensive to perform real-time. The author > mentions that as a limitation to more widespread application... > i know that i'm an opinionated person and not always polite, but taking a look at the abstract (i admit i didn't hit the download 1.8 Meg of thesis link), i am not sure at all of the value of it. music goes in, some vector with different quantitative measures of "complexity" (whatever the hell that is) comes out. so what do we do with it? can we use it to ID different musical pieces, perhaps performed by different artists? i guess i don't see what the point is other than academic advancement. curmudgeonly, -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From kaleja at estarcion.com Wed Jun 11 02:22:04 2008 From: kaleja at estarcion.com (Russell Borogove) Date: Wed Jun 11 02:22:15 2008 Subject: [music-dsp] fast sin(x) function References: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com> Message-ID: <003701c8cb8b$77f50c60$c601000a@jaseroque> > I'm looking for a fast sin(x) type function. So far I haven't found > anything with the necessary precision for audio work. Any ideas? What's the necessary precision for your application? Here's a page with a survey of varying cheap methods. http://www.audiomulch.com/~rossb/code/sinusoids/ From d.sbragion at infotecna.it Wed Jun 11 02:49:35 2008 From: d.sbragion at infotecna.it (Denis Sbragion) Date: Wed Jun 11 02:49:54 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com> References: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com> Message-ID: <1135.192.168.1.15.1213166975.squirrel@www.infotecna.lcl> Hello Stephen, On Tue, June 10, 2008 21:13, Stephen Blinkhorn wrote: > I'm looking for a fast sin(x) type function. So far I haven't found > anything with the necessary precision for audio work. Any ideas? don't know if it has been already pointed out, but there's a fast and quite accurate method to generate sin(x) sequences, i.e. not arbitrary values but uniformly spaced values. Here it is a not so fast but easy to understand Octave snippet: ## usage: st = sintable(sv,sd,sn) ## ## Generate a sin table by recurrence ## ## sv: sine start value ## sd: sine delta ## sn: sine number of values function st = sintable(sv,sd,sn); # Initializes the sin array st = zeros(1,sn); # Initializes the sine constants R = sin(sd/2); R = -4 * R * R; S = sin(sv); S = sin(sd) * cos(sv) + (S * (1 - cos(sd))); # Set the first value V = sin(sv); st(1) = V; # Sine generation loop for I = 2:sn S = R * V + S; V = V + S; st(I) = V; endfor endfunction I use this mehtod, translated to C, to generate a huge amount of Blackman windowed lowpass FIR filters, and it turned out to be noticeably faster than direct sin computation. Probably it could be also translated to vector code (SSE or similar) making it even faster. If you need arbitrary values it's quite difficult to beat the standard sin function unless you're ready to accept a lower accuracy. Bye, -- Denis Sbragion InfoTecna Tel: +39 0362 805396, Fax: +39 0362 805404 URL: http://www.infotecna.it From didid at skynet.be Wed Jun 11 05:13:34 2008 From: didid at skynet.be (Didier Dambrin) Date: Wed Jun 11 05:13:42 2008 Subject: [music-dsp] fast sin(x) function References: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com> <1135.192.168.1.15.1213166975.squirrel@www.infotecna.lcl> Message-ID: <005001c8cba3$6d180e60$0401a8c0@GOLAMD> But as I wrote, it quickly loses precision. Check the loss over time with single float accuracy, you'll be amazed. Since you say you're generating huge blocks, make sure you're using double precision. ----- Original Message ----- From: "Denis Sbragion" To: "A discussion list for music-related DSP" Sent: Wednesday, June 11, 2008 8:49 AM Subject: Re: [music-dsp] fast sin(x) function Hello Stephen, On Tue, June 10, 2008 21:13, Stephen Blinkhorn wrote: > I'm looking for a fast sin(x) type function. So far I haven't found > anything with the necessary precision for audio work. Any ideas? don't know if it has been already pointed out, but there's a fast and quite accurate method to generate sin(x) sequences, i.e. not arbitrary values but uniformly spaced values. Here it is a not so fast but easy to understand Octave snippet: ## usage: st = sintable(sv,sd,sn) ## ## Generate a sin table by recurrence ## ## sv: sine start value ## sd: sine delta ## sn: sine number of values function st = sintable(sv,sd,sn); # Initializes the sin array st = zeros(1,sn); # Initializes the sine constants R = sin(sd/2); R = -4 * R * R; S = sin(sv); S = sin(sd) * cos(sv) + (S * (1 - cos(sd))); # Set the first value V = sin(sv); st(1) = V; # Sine generation loop for I = 2:sn S = R * V + S; V = V + S; st(I) = V; endfor endfunction I use this mehtod, translated to C, to generate a huge amount of Blackman windowed lowpass FIR filters, and it turned out to be noticeably faster than direct sin computation. Probably it could be also translated to vector code (SSE or similar) making it even faster. If you need arbitrary values it's quite difficult to beat the standard sin function unless you're ready to accept a lower accuracy. Bye, -- Denis Sbragion InfoTecna Tel: +39 0362 805396, Fax: +39 0362 805404 URL: http://www.infotecna.it -- 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. Version: 8.0.100 / Virus Database: 270.2.0/1495 - Release Date: 10/06/2008 17:11 From d.sbragion at infotecna.it Wed Jun 11 05:34:00 2008 From: d.sbragion at infotecna.it (Denis Sbragion) Date: Wed Jun 11 05:34:25 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: <005001c8cba3$6d180e60$0401a8c0@GOLAMD> References: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com> <1135.192.168.1.15.1213166975.squirrel@www.infotecna.lcl> <005001c8cba3$6d180e60$0401a8c0@GOLAMD> Message-ID: <1874.192.168.1.15.1213176840.squirrel@www.infotecna.lcl> Hello Didier, On Wed, June 11, 2008 11:13, Didier Dambrin wrote: > But as I wrote, it quickly loses precision. Check the loss over time with > single float accuracy, you'll be amazed. Since you say you're generating > huge blocks, make sure you're using double precision. no, I'm not generating huge blocks, I'm generating huge amounts of relatively short FIR filters. In my situation the accuracy is enough for the task, even in single precision arithmetic, but indeed already an order of magnitude below the accuracy of the standard sin function. Don't know if it's enough for Stephen task, Stephen didn't say what is going to do. Furthermore I know that similar recursions are used in FFT routines and that there are methods to get "stable" accuracy without decreasing the performances too much. I remember something like "Buneman recursion". I'm not sure, but may be it could be the right tradeoff between accuracy and speed. Bye, -- Denis Sbragion InfoTecna Tel: +39 0362 805396, Fax: +39 0362 805404 URL: http://www.infotecna.it From stephen.blinkhorn at audiospillage.com Wed Jun 11 16:40:39 2008 From: stephen.blinkhorn at audiospillage.com (Stephen Blinkhorn) Date: Wed Jun 11 16:28:45 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: <20080610213113.8B027EDEDA@ws6-1.us4.outblaze.com> References: <20080610213113.8B027EDEDA@ws6-1.us4.outblaze.com> Message-ID: <7769532B-69C3-4997-BC2C-F667F787CBB8@audiospillage.com> On 10 Jun 2008, at 15:31, robert bristow-johnson wrote: > if the OP wants a sin() function for the purpose of generating a > nice sine wave for sound, then i would also recommend LUT that is > large enough that linear interpolation would be good enough. Okay, for now I'm just using sin(x) I'll have a look at using a LUT. > if instead the sin() function is used in control/coefficient > generation, then i would suggest using the finite order series > below. with the exception of arctan(), there is no division in any > of these. should be fast for a DSP. thanks for these I'll experiment with them later. I am finding that sin(x) functions are cropping up in a variety of places in my work (coefficients etc) as well as cos(x) so I've been on the lookout for something fast and accurate but I have been trying to avoid using lookup tables.. can't say why exactly something just told me to avoid them in certain situations. Oh and I am developing for PowerPC and Intel. Thanks for all the suggestions. Stephen. > > > >> Or, then, use one of the better math libraries, which...do that for >> you. ;) > > > > > log2(1+x) ~= 1.4425449290 * x > + -0.7181451002 * x^2 > + 0.4575485901 * x^3 > + -0.2779042655 * x^4 > + 0.1217970128 * x^5 > + -0.0258411662 * x^6 > > 0 <= x <= 1 |error| < 2.217e-6 (exact when x=0 and x=1) > (about 1/375th of a cent) > > 2^x ~= 1.0 > + 0.6930321187 * x > + 0.2413797743 * x^2 > + 0.0520323499 * x^3 > + 0.0135557571 * x^4 > > 0 <= x <= 1 |error|/(2^x) < 3.340e-6 (exact when x=0 and x=1) > (about 1/173rd of a cent) > > sqrt(x) ~= 0.2286139087 > + 1.3027308205 * x > + -0.9125353819 * x^2 > + 0.5029902702 * x^3 > + -0.1217996175 * x^4 > > 1/2 <= x <= 1 |error|/sqrt(x) < 1.076e-5 > (exact when x=1 and nearly exact when x=1/2) > > > sin((pi/2)*x) ~= 1.5707963268 * x > + -0.6459640619 * x^3 > + 0.0796915849 * x^5 > + -0.0046768800 * x^7 > + 0.0001530302 * x^9 > > -1 <= x <= 1 (i can't find the max error results, but it's small) > > > arctan(x) ~= x/f(x^2) > > where f(u) = 1.0 > + 0.3328895051 * u > + -0.0846792282 * u^2 > + 0.0325223264 * u^3 > + -0.0074930586 * u^4 > > -1 <= x <= 1 (can't find the error results here either, but it's > small.) > > > -- > > r b-j rbj@audioimagination.com > > "Imagination is more important than knowledge." > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book > reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From rbj at audioimagination.com Wed Jun 11 18:29:45 2008 From: rbj at audioimagination.com (robert bristow-johnson) Date: Wed Jun 11 18:30:00 2008 Subject: [music-dsp] fast sin(x) function Message-ID: <20080611222945.9C6FB16ED07@ws6-8.us4.outblaze.com> > ----- Original Message ----- > From: "Stephen Blinkhorn" > To: "A discussion list for music-related DSP" > Subject: Re: [music-dsp] fast sin(x) function > Date: Wed, 11 Jun 2008 14:40:39 -0600 > > > On 10 Jun 2008, at 15:31, robert bristow-johnson wrote: > > > if the OP wants a sin() function for the purpose of generating a nice sine > > wave for sound, then i would also recommend LUT that is large enough that > > linear interpolation would be good enough. > > Okay, for now I'm just using sin(x) I'll have a look at using a LUT. > > > if instead the sin() function is used in control/coefficient generation, > > then i would suggest using the finite order series below. with the > > exception of arctan(), there is no division in any of these. should be > > fast for a DSP. > > thanks for these I'll experiment with them later. I am finding that sin(x) > functions are cropping up in a variety of places in my work (coefficients > etc) that was my intention with these finite-order polynomial approximations. not so much for waveform generation (where i would prefer to use a phase-accumulator and LUT). > as well as cos(x) to do cos(x), try cos(x) = 1 - 2*(sin(x/2))^2 . with a good sin(x) approximation, that should work good. if you're using this cos(x) for filter coef generation or to compute the frequency response curve, then you should express all coef and such formulae in terms of 1-cos(x) instead of cos(x) for numerical reasons (when the frequency is in the bottom 3 octaves, cos(x) is too close to 1.0 that all of the salient information exists in the difference of cos(x) from 1.0, or in the least significant bits, even using floating-point arithmetic.) so you'll see that 1-cos(x) is the same as 2*(sin(x/2))^2, which if you're using floating-point arithmetic, doesn't lose accuracy as x (or 2*pi*f/Fs) gets into the bottom couple octaves. > so I've been on the lookout for something fast and > accurate but I have been trying to avoid using lookup tables.. can't say why > exactly something just told me to avoid them in certain situations. LUT has little discontinuities in the function (or one of its derivatives if some kinda interpolation or spline is used). the power series method, although it has *some* error (if the polynomial order is finite), is completely smooth in the domain where it is spec'ed. no funky discontinuities. > Oh and I am developing for PowerPC and Intel. then maybe division or floating-point is of no extra cost to you. sometimes either or both of those (floating-point and/or division) are expensive in the DSP world. LUT is real cheap in execution cycles (but expensive in terms of memory used). LUT with linear interpolation is a little more costly, these low-order finite series are a little more expensive than simple LUT with linear interp. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From wvum90.5 at gmail.com Wed Jun 11 21:00:31 2008 From: wvum90.5 at gmail.com (Chris Bennett) Date: Wed Jun 11 21:00:51 2008 Subject: [music-dsp] independent phase components Message-ID: <6828E417-47BD-4185-86E7-922DDE666717@gmail.com> hello list i was wondering if anybody was familiar with any sort of analysis or post-processing technique for extracting phase components of a signal. For example, if i have a mixed system with one component that has mostly zero group delay, and another with constant group delay, would there by a way to separate these two ex post facto? thanks! ~cb ------------------------------------------ Christopher Bennett Graduate Fellow Neurosensory Engineering Lab University of Miami c.bennett@umiami.edu From rbj at audioimagination.com Wed Jun 11 22:16:03 2008 From: rbj at audioimagination.com (robert bristow-johnson) Date: Wed Jun 11 22:16:18 2008 Subject: [music-dsp] independent phase components Message-ID: <20080612021603.5006B2F8F4@ws6-3.us4.outblaze.com> > ----- Original Message ----- > From: "Chris Bennett" > To: music-dsp@music.columbia.edu > Subject: [music-dsp] independent phase components > Date: Wed, 11 Jun 2008 21:00:31 -0400 > > > hello list > > i was wondering if anybody was familiar with any sort of analysis or > post-processing technique for extracting phase components of a signal. For > example, if i have a mixed system with one component that has mostly zero > group delay, and another with constant group delay, would there by a way to > separate these two ex post facto? > does one have a reference signal (even if mixed) that we compare to that composite signal you are referring to? otherwize, what exactly is the meaning of "delay" in the composite signal? -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From gwenhwyfaer at gmail.com Wed Jun 11 23:13:52 2008 From: gwenhwyfaer at gmail.com (gwenhwyfaer@gmail.com) Date: Wed Jun 11 23:14:08 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: <20080611222945.9C6FB16ED07@ws6-8.us4.outblaze.com> References: <20080611222945.9C6FB16ED07@ws6-8.us4.outblaze.com> Message-ID: On 11/06/2008, robert bristow-johnson wrote: >> as well as cos(x) > > to do cos(x), try cos(x) = 1 - 2*(sin(x/2))^2 . Any reason why cos(x) = sin(x + pi/2) can't be used? From rbj at audioimagination.com Thu Jun 12 00:06:02 2008 From: rbj at audioimagination.com (robert bristow-johnson) Date: Thu Jun 12 00:06:24 2008 Subject: [music-dsp] fast sin(x) function Message-ID: <20080612040602.61B2C50AC3@ws6-5.us4.outblaze.com> > ----- Original Message ----- > From: gwenhwyfaer@gmail.com > To: "A discussion list for music-related DSP" > Subject: Re: [music-dsp] fast sin(x) function > Date: Thu, 12 Jun 2008 04:13:52 +0100 > > > On 11/06/2008, robert bristow-johnson wrote: > > > > to do cos(x), try cos(x) = 1 - 2*(sin(x/2))^2 . > > Any reason why cos(x) = sin(x + pi/2) can't be used? that's how you would do it for a look-up-table. that power series for sin(pi/2*x) that i listed was good only for |x| <= 1. it fits naturally for cos(pi*x) = 1 - 2*(sin(pi*x/2))^2 if |x| <= 1 (and covers a whole period). adding 1 (which is scaled from your pi/2) to x might put it out of the "good" range. to use it for a whole period sin(pi*x), you need to put in a little "if" statement logic to reflect sin(pi/2*x) about the x values of +1 or -1. but the context i meant was if cos(x) was being evaluated to compute IIR filter coefficients (like in the cookbook). my suggestion is to twist the equations around so that you have 1-cos(x) everywhere instead of cos(x), which can still be accurately represented with a finite word width for very small x. the problem with just cos(x) for what you would get at low frequencies in this use is that all of the salient information is falling off the edge of your word, even if it is floating-point. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From gwenhwyfaer at gmail.com Thu Jun 12 02:47:56 2008 From: gwenhwyfaer at gmail.com (gwenhwyfaer@gmail.com) Date: Thu Jun 12 02:48:12 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: <20080612040602.61B2C50AC3@ws6-5.us4.outblaze.com> References: <20080612040602.61B2C50AC3@ws6-5.us4.outblaze.com> Message-ID: On 12/06/2008, robert bristow-johnson wrote: > that's how you would do it for a look-up-table. that power series for > sin(pi/2*x) that i listed was good only for |x| <= 1. Ah - that explains it. Thanks. From uli.brueggemann at gmail.com Thu Jun 12 03:26:46 2008 From: uli.brueggemann at gmail.com (Uli Brueggemann) Date: Thu Jun 12 03:27:01 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: References: <20080612040602.61B2C50AC3@ws6-5.us4.outblaze.com> Message-ID: <10a58eee0806120026l3c2bf961yca60150a5c99113f@mail.gmail.com> See also http://en.wikipedia.org/wiki/CORDIC and http://myweb.lmu.edu/dmsmith/MComp89.pdf or http://citeseer.ist.psu.edu/smith91fortran.html for other possibilities to compute sin(x) From uli.brueggemann at gmail.com Thu Jun 12 03:37:34 2008 From: uli.brueggemann at gmail.com (Uli Brueggemann) Date: Thu Jun 12 03:37:49 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: <10a58eee0806120026l3c2bf961yca60150a5c99113f@mail.gmail.com> References: <20080612040602.61B2C50AC3@ws6-5.us4.outblaze.com> <10a58eee0806120026l3c2bf961yca60150a5c99113f@mail.gmail.com> Message-ID: <10a58eee0806120037s73dda42eq64ff5125f24b4548@mail.gmail.com> Also worth to read is http://www.devmaster.net/forums/showthread.php?t=5784 On Thu, Jun 12, 2008 at 9:26 AM, Uli Brueggemann wrote: > See also > http://en.wikipedia.org/wiki/CORDIC > and > http://myweb.lmu.edu/dmsmith/MComp89.pdf or > http://citeseer.ist.psu.edu/smith91fortran.html > > for other possibilities to compute sin(x) > From uli.brueggemann at gmail.com Thu Jun 12 04:17:10 2008 From: uli.brueggemann at gmail.com (Uli Brueggemann) Date: Thu Jun 12 04:17:27 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: <10a58eee0806120037s73dda42eq64ff5125f24b4548@mail.gmail.com> References: <20080612040602.61B2C50AC3@ws6-5.us4.outblaze.com> <10a58eee0806120026l3c2bf961yca60150a5c99113f@mail.gmail.com> <10a58eee0806120037s73dda42eq64ff5125f24b4548@mail.gmail.com> Message-ID: <10a58eee0806120117i14d8c992sdb5b803d3ce0dece@mail.gmail.com> ... and some links taken from the mentioned thread at devmaster.net are interesting too: http://www.research.scea.com/gdc2003/fast-math-functions.html and http://fastsine.tripod.com/ Enough to read and to study Uli On Thu, Jun 12, 2008 at 9:37 AM, Uli Brueggemann wrote: > Also worth to read is > http://www.devmaster.net/forums/showthread.php?t=5784 > > > On Thu, Jun 12, 2008 at 9:26 AM, Uli Brueggemann > wrote: >> See also >> http://en.wikipedia.org/wiki/CORDIC >> and >> http://myweb.lmu.edu/dmsmith/MComp89.pdf or >> http://citeseer.ist.psu.edu/smith91fortran.html >> >> for other possibilities to compute sin(x) >> > From laurent.de.soras.m1 at club-internet.fr Thu Jun 12 05:34:05 2008 From: laurent.de.soras.m1 at club-internet.fr (Laurent de Soras [Ohm Force]) Date: Thu Jun 12 05:34:21 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: <005001c8cba3$6d180e60$0401a8c0@GOLAMD> References: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com> <1135.192.168.1.15.1213166975.squirrel@www.infotecna.lcl> <005001c8cba3$6d180e60$0401a8c0@GOLAMD> Message-ID: <4850ED8D.20703@club-internet.fr> Didier Dambrin wrote: > But as I wrote, it quickly loses precision. Check the loss over time with > single float accuracy, you'll be amazed. Since you say you're generating > huge blocks, make sure you're using double precision. A quite stable oscillator, but more expensive (4 mul 4 add ) : Precompute c = cos (phi) s = sin (phi) alpha = 2 * sin^2 (gamma / 2) beta = sin (gamma) Then compute the next pair (c+; s+) from the previous one (c; s) via c+ = c - (alpha * c - beta * s) s+ = s - (alpha * s - beta * c) (from J?rg Arndt, Algorithms for programmers - ideas and source code, p. 402, http://www.jjj.de/fxt/#fxtbook ) -- Laurent de Soras | Ohm Force DSP developer & Software designer | Digital Audio Software http://ldesoras.free.fr | http://www.ohmforce.com From richarddobson at blueyonder.co.uk Thu Jun 12 05:48:17 2008 From: richarddobson at blueyonder.co.uk (Richard Dobson) Date: Thu Jun 12 05:50:03 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: <4850ED8D.20703@club-internet.fr> References: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com> <1135.192.168.1.15.1213166975.squirrel@www.infotecna.lcl> <005001c8cba3$6d180e60$0401a8c0@GOLAMD> <4850ED8D.20703@club-internet.fr> Message-ID: <4850F0E1.4030403@blueyonder.co.uk> The issue I cannot avoid in all these methods is that for the majority of "interesting" sounds, we want the frequency to be time-variable (and for FM at least, variable every sample). The advantage of the iterative method is lost if I have to calculate cos and sin values anyway, each sample! For this the good old table lookup still appears the only efficient method; but I am very keen to learn of any faster alternatives. Richard Dobson Laurent de Soras [Ohm Force] wrote: > Didier Dambrin wrote: >> But as I wrote, it quickly loses precision. Check the loss over time >> with single float accuracy, you'll be amazed. Since you say you're >> generating huge blocks, make sure you're using double precision. > > A quite stable oscillator, but more expensive (4 mul 4 add ) : > > Precompute > > c = cos (phi) > s = sin (phi) > alpha = 2 * sin^2 (gamma / 2) > beta = sin (gamma) > > Then compute the next pair (c+; s+) from the previous one (c; s) via > > c+ = c - (alpha * c - beta * s) > s+ = s - (alpha * s - beta * c) > > (from J?rg Arndt, Algorithms for programmers - ideas and > source code, p. 402, http://www.jjj.de/fxt/#fxtbook ) > > > From didid at skynet.be Thu Jun 12 06:48:08 2008 From: didid at skynet.be (Didier Dambrin) Date: Thu Jun 12 06:48:25 2008 Subject: [music-dsp] fast sin(x) function References: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com> <1135.192.168.1.15.1213166975.squirrel@www.infotecna.lcl><005001c8cba3$6d180e60$0401a8c0@GOLAMD> <4850ED8D.20703@club-internet.fr> Message-ID: <021e01c8cc79$cd61b1a0$0401a8c0@GOLAMD> Interesting, works pretty well. However, while it's a lot better than the other algo in single precision, especially after a lot of iterations, it's still inferior to the other algo in double precision (in my tests). So, since it requires more operations anyway, I'd still suggest the other algo in double precision instead, it would probably be the same speed. (or in single precision in short chunks) ----- Original Message ----- From: "Laurent de Soras [Ohm Force]" To: "A discussion list for music-related DSP" Sent: Thursday, June 12, 2008 11:34 AM Subject: Re: [music-dsp] fast sin(x) function Didier Dambrin wrote: > But as I wrote, it quickly loses precision. Check the loss over time with > single float accuracy, you'll be amazed. Since you say you're generating > huge blocks, make sure you're using double precision. A quite stable oscillator, but more expensive (4 mul 4 add ) : Precompute c = cos (phi) s = sin (phi) alpha = 2 * sin^2 (gamma / 2) beta = sin (gamma) Then compute the next pair (c+; s+) from the previous one (c; s) via c+ = c - (alpha * c - beta * s) s+ = s - (alpha * s - beta * c) (from J?rg Arndt, Algorithms for programmers - ideas and source code, p. 402, http://www.jjj.de/fxt/#fxtbook ) -- Laurent de Soras | Ohm Force DSP developer & Software designer | Digital Audio Software http://ldesoras.free.fr | http://www.ohmforce.com -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG. Version: 8.0.100 / Virus Database: 270.3.0/1499 - Release Date: 12/06/2008 07:13 From didid at skynet.be Thu Jun 12 06:50:45 2008 From: didid at skynet.be (Didier Dambrin) Date: Thu Jun 12 06:51:04 2008 Subject: [music-dsp] fast sin(x) function References: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com> <1135.192.168.1.15.1213166975.squirrel@www.infotecna.lcl><005001c8cba3$6d180e60$0401a8c0@GOLAMD> <4850ED8D.20703@club-internet.fr> Message-ID: <022d01c8cc7a$2adbbf60$0401a8c0@GOLAMD> (however, if one needs double-precision sines, then yes I guess this algo in double precision will be a better choice than the other one in double precision too) > But as I wrote, it quickly loses precision. Check the loss over time with > single float accuracy, you'll be amazed. Since you say you're generating > huge blocks, make sure you're using double precision. A quite stable oscillator, but more expensive (4 mul 4 add ) : Precompute c = cos (phi) s = sin (phi) alpha = 2 * sin^2 (gamma / 2) beta = sin (gamma) Then compute the next pair (c+; s+) from the previous one (c; s) via c+ = c - (alpha * c - beta * s) s+ = s - (alpha * s - beta * c) (from J?rg Arndt, Algorithms for programmers - ideas and source code, p. 402, http://www.jjj.de/fxt/#fxtbook ) -- Laurent de Soras | Ohm Force DSP developer & Software designer | Digital Audio Software http://ldesoras.free.fr | http://www.ohmforce.com -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG. Version: 8.0.100 / Virus Database: 270.3.0/1499 - Release Date: 12/06/2008 07:13 From benjamin at 0ok.de Thu Jun 12 07:09:19 2008 From: benjamin at 0ok.de (Benjamin Rosseaux) Date: Thu Jun 12 07:09:38 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com> References: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com> Message-ID: <485103DF.1040609@0ok.de> Hello, My following FastSIN routine is maybe the right thing for you. The code should be portable easily to C/C++/whatever. I'm using it in my softsynth for my demoscene productions. And i think, the routine could be more optimized, if I had more time for my softsynth. function FastSIN(X:single):single; {$ifdef cpu386}assembler; stdcall;{$endif} const PI0D5:single=PI*0.5; PI2:single=PI*2; PIF:single=PI; DPI2:single=1/(PI*2); SinConst1:single=-2.39e-08; SinConst2:single=2.7526e-06; SinConst3:single=-1.98409e-04; SinConst4:single=8.3333315e-03; SinConst5:single=-1.666666664e-01; {$IFDEF CPU386} asm FLD dword PTR X // X:=abs(frac(((frac(X*DPI2)*PI2)+PI2)*DPI2)*PI2); FLD dword PTR PI2 FXCH ST(1) FPREM FXCH ST(1) FSTP ST(0) FADD dword PTR PI2 FLD dword PTR PI2 FXCH ST(1) FPREM FXCH ST(1) FSTP ST(0) FABS FST dword PTR [ESP-8] // if X>PI0D5 then X:=PI-X; PUSH EAX MOV EAX,dword PTR [ESP-4] CMP EAX,dword PTR PI0D5 JLE @DoNotMirror FLDPI FSUB ST(0),ST(1) FSTP ST(1) @DoNotMirror: POP EAX // ASqr:=sqr(X); FLD ST(0) FMUL ST(0),ST(0) // result:=((((((((((SinConst1*ASqr)+SinConst2)*ASqr)+SinConst3)*ASqr)+SinConst4)*ASqr)+SinConst5)*ASqr)+1)*X; FLD dword PTR SinConst1 FMUL ST(0),ST(1) FADD dword PTR SinConst2 FMUL ST(0),ST(1) FADD dword PTR SinConst3 FMUL ST(0),ST(1) FADD dword PTR SinConst4 FMUL ST(0),ST(1) FADD dword PTR SinConst5 FMUL ST(0),ST(1) FSTP ST(1) FLD1 FADDP ST(1),ST(0) FMUL ST(0),ST(1) FSTP ST(1) end; {$ELSE} var XCasted:longint absolute X; PI0D5Casted:longint absolute PI0D5; ASqr:single; begin X:=abs(frac(((frac(X*DPI2)*PI2)+PI2)*DPI2)*PI2); if XCasted>PI0D5Casted then begin X:=PI-X; end; ASqr:=sqr(X); result:=((((((((((SinConst1*ASqr)+SinConst2)*ASqr)+SinConst3)*ASqr)+SinConst4)*ASqr)+SinConst5)*ASqr)+1)*X; end; {$ENDIF} Benjamin 'BeRo' Rosseaux from the demogroup farbrausch From bogac at bteaudio.com Thu Jun 12 08:40:18 2008 From: bogac at bteaudio.com (Bogac Topaktas) Date: Thu Jun 12 08:40:32 2008 Subject: [music-dsp] fast sin(x) function Message-ID: Another resource: A Guide to Approximations. by Jack G. Ganssle http://www.ganssle.com/approx/approx.pdf www.ganssle.com/approx/sincos.cpp Bogac. >Hi all, > >I'm looking for a fast sin(x) type function. So far I haven't found >anything with the necessary precision for audio work. Any ideas? > >Thanks, >Stephen. From Stefan at stenzel.com Thu Jun 12 09:44:54 2008 From: Stefan at stenzel.com (Stefan Stenzel) Date: Thu Jun 12 09:45:09 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: <485103DF.1040609@0ok.de> References: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com> <485103DF.1040609@0ok.de> Message-ID: <48512856.9040202@Stenzel.com> So what about the simple "fsin" instruction ? Shouldn't this be faster? Stefan Benjamin Rosseaux wrote: > > Hello, > > My following FastSIN routine is maybe the right thing for you. The code > should be portable easily to C/C++/whatever. I'm using it in my > softsynth for my demoscene productions. And i think, the routine could > be more optimized, if I had more time for my softsynth. > > function FastSIN(X:single):single; {$ifdef cpu386}assembler; > stdcall;{$endif} > const PI0D5:single=PI*0.5; > PI2:single=PI*2; > PIF:single=PI; > DPI2:single=1/(PI*2); > SinConst1:single=-2.39e-08; > SinConst2:single=2.7526e-06; > SinConst3:single=-1.98409e-04; > SinConst4:single=8.3333315e-03; > SinConst5:single=-1.666666664e-01; > {$IFDEF CPU386} > asm > FLD dword PTR X > > // X:=abs(frac(((frac(X*DPI2)*PI2)+PI2)*DPI2)*PI2); > FLD dword PTR PI2 > FXCH ST(1) > FPREM > FXCH ST(1) > FSTP ST(0) > FADD dword PTR PI2 > FLD dword PTR PI2 > FXCH ST(1) > FPREM > FXCH ST(1) > FSTP ST(0) > FABS > FST dword PTR [ESP-8] > > // if X>PI0D5 then X:=PI-X; > PUSH EAX > MOV EAX,dword PTR [ESP-4] > CMP EAX,dword PTR PI0D5 > JLE @DoNotMirror > FLDPI > FSUB ST(0),ST(1) > FSTP ST(1) > @DoNotMirror: > POP EAX > > // ASqr:=sqr(X); > FLD ST(0) > FMUL ST(0),ST(0) > > // > result:=((((((((((SinConst1*ASqr)+SinConst2)*ASqr)+SinConst3)*ASqr)+SinConst4)*ASqr)+SinConst5)*ASqr)+1)*X; > > FLD dword PTR SinConst1 > FMUL ST(0),ST(1) > FADD dword PTR SinConst2 > FMUL ST(0),ST(1) > FADD dword PTR SinConst3 > FMUL ST(0),ST(1) > FADD dword PTR SinConst4 > FMUL ST(0),ST(1) > FADD dword PTR SinConst5 > FMUL ST(0),ST(1) > FSTP ST(1) > FLD1 > FADDP ST(1),ST(0) > FMUL ST(0),ST(1) > FSTP ST(1) > end; > {$ELSE} > var XCasted:longint absolute X; > PI0D5Casted:longint absolute PI0D5; > ASqr:single; > begin > X:=abs(frac(((frac(X*DPI2)*PI2)+PI2)*DPI2)*PI2); > if XCasted>PI0D5Casted then begin > X:=PI-X; > end; > ASqr:=sqr(X); > result:=((((((((((SinConst1*ASqr)+SinConst2)*ASqr)+SinConst3)*ASqr)+SinConst4)*ASqr)+SinConst5)*ASqr)+1)*X; > > end; > {$ENDIF} > > Benjamin 'BeRo' Rosseaux > from the demogroup farbrausch > > > -- > 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 benjamin at 0ok.de Thu Jun 12 10:09:33 2008 From: benjamin at 0ok.de (Benjamin Rosseaux) Date: Thu Jun 12 10:09:44 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: <48512856.9040202@Stenzel.com> References: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com> <485103DF.1040609@0ok.de> <48512856.9040202@Stenzel.com> Message-ID: <48512E1D.2050403@0ok.de> No, the fsin FPU opcode is on my Intel Core 2 Duo T7500 ~40% slower than my FastSIN routine. I've benchmarked it. 100000000 iterations, fsin opcode about 5507 milliseconds and my FastSIN about 3370 milliseconds, Benjamin 'BeRo' Rosseaux Stefan Stenzel schrieb: > > So what about the simple "fsin" instruction ? > Shouldn't this be faster? > > Stefan > > Benjamin Rosseaux wrote: >> >> Hello, >> >> My following FastSIN routine is maybe the right thing for you. The >> code should be portable easily to C/C++/whatever. I'm using it in my >> softsynth for my demoscene productions. And i think, the routine >> could be more optimized, if I had more time for my softsynth. >> >> function FastSIN(X:single):single; {$ifdef cpu386}assembler; >> stdcall;{$endif} >> const PI0D5:single=PI*0.5; >> PI2:single=PI*2; >> PIF:single=PI; >> DPI2:single=1/(PI*2); >> SinConst1:single=-2.39e-08; >> SinConst2:single=2.7526e-06; >> SinConst3:single=-1.98409e-04; >> SinConst4:single=8.3333315e-03; >> SinConst5:single=-1.666666664e-01; >> {$IFDEF CPU386} >> asm >> FLD dword PTR X >> >> // X:=abs(frac(((frac(X*DPI2)*PI2)+PI2)*DPI2)*PI2); >> FLD dword PTR PI2 >> FXCH ST(1) >> FPREM >> FXCH ST(1) >> FSTP ST(0) >> FADD dword PTR PI2 >> FLD dword PTR PI2 >> FXCH ST(1) >> FPREM >> FXCH ST(1) >> FSTP ST(0) >> FABS >> FST dword PTR [ESP-8] >> >> // if X>PI0D5 then X:=PI-X; >> PUSH EAX >> MOV EAX,dword PTR [ESP-4] >> CMP EAX,dword PTR PI0D5 >> JLE @DoNotMirror >> FLDPI >> FSUB ST(0),ST(1) >> FSTP ST(1) >> @DoNotMirror: >> POP EAX >> >> // ASqr:=sqr(X); >> FLD ST(0) >> FMUL ST(0),ST(0) >> >> // >> result:=((((((((((SinConst1*ASqr)+SinConst2)*ASqr)+SinConst3)*ASqr)+SinConst4)*ASqr)+SinConst5)*ASqr)+1)*X; >> >> FLD dword PTR SinConst1 >> FMUL ST(0),ST(1) >> FADD dword PTR SinConst2 >> FMUL ST(0),ST(1) >> FADD dword PTR SinConst3 >> FMUL ST(0),ST(1) >> FADD dword PTR SinConst4 >> FMUL ST(0),ST(1) >> FADD dword PTR SinConst5 >> FMUL ST(0),ST(1) >> FSTP ST(1) >> FLD1 >> FADDP ST(1),ST(0) >> FMUL ST(0),ST(1) >> FSTP ST(1) >> end; >> {$ELSE} >> var XCasted:longint absolute X; >> PI0D5Casted:longint absolute PI0D5; >> ASqr:single; >> begin >> X:=abs(frac(((frac(X*DPI2)*PI2)+PI2)*DPI2)*PI2); >> if XCasted>PI0D5Casted then begin >> X:=PI-X; >> end; >> ASqr:=sqr(X); >> result:=((((((((((SinConst1*ASqr)+SinConst2)*ASqr)+SinConst3)*ASqr)+SinConst4)*ASqr)+SinConst5)*ASqr)+1)*X; >> >> end; >> {$ENDIF} >> >> Benjamin 'BeRo' Rosseaux >> from the demogroup farbrausch >> >> >> -- >> 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 stevenpaulcook at tiscali.co.uk Thu Jun 12 11:41:57 2008 From: stevenpaulcook at tiscali.co.uk (Steven Cook) Date: Thu Jun 12 11:46:30 2008 Subject: [music-dsp] fast sin(x) function References: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com> <1135.192.168.1.15.1213166975.squirrel@www.infotecna.lcl> <005001c8cba3$6d180e60$0401a8c0@GOLAMD><4850ED8D.20703@club-internet.fr> <4850F0E1.4030403@blueyonder.co.uk> Message-ID: <001101c8cca3$17e94c00$0200a8c0@studiopc> You can use four 8-bit lookup tables to generate a 16-bit sine as follows: Using the identity: sin(ab) = sin(a) * cos(b) + cos(a) * sin(b) Write the tables: for (int i = 0; i < 256; i++) { double x = PI * 2.0 * (double)i / 256.0; sinTab1[i] = sin (x); cosTab1[i] = cos (x); sinTab2[i] = sin (x / 256.0); cosTab2[i] = cos (x / 256.0); } Generate the sine: double sin16bit (unsigned int phase) // 32-bit phase { unsigned int a = phase >> 24; unsigned int b = (phase >> 16) & 255; return (sinTab1[a] * cosTab2[b] + cosTab1[a] * sinTab2[b]); } You can get a cosine with the same tables. I think there are other methods using more complex identities and more tables. Apologies for any mistakes in the above. Steven Cook. http://www.spcplugins.com/ From pfultz2 at yahoo.com Fri Jun 13 21:53:26 2008 From: pfultz2 at yahoo.com (paul Fultz) Date: Fri Jun 13 21:53:40 2008 Subject: [music-dsp] Digital Clipping Message-ID: <999907.84533.qm@web90604.mail.mud.yahoo.com> I was trying a technique to smooth out the sharp edges in digital clipping to try to reduce aliasing. Now, say given the samples s1, s2 , s3, with the s3 clipping i know that the clipping usually occurs somewhere in between s2 and s3, so i used the numerical derivative of s2 to calculate this clipping point. Then i created a cubic spline curve thats stems from s1 to the clipping point, keeping the derivative of s1 the same, and the derivative of the clipping point set to 0. I then used this cubic spline to calculate s2. However this didnt reduce the aliasing. I thought maybe it didnt because the cubic spline is not bandlimited. So i created a bandlimited spline curve like this: a*sin(m*x) + b*cos(m*x) + c*cos(2*m*x) + d*sin(2*m*x) To calculate these coeffecients i just used matlab where its goes from 0 to x0(the clipping point) where y1=s1 and y2=(1 or -1) depending which side its clipping on, and yy1=derivative at s1, and yy2=0 m = pi/(2*x0); f = a*sin(m*x) + b*cos(m*x) + c*cos(2*m*x) + d*sin(2*m*x); g = diff(f); S = solve(subs(f,0)-y1,subs(f,x0)-y2,subs(g,0)-yy1,subs(g,x0)-yy2,a,b,c,d); Then i do something similar for when it leaves clipping also. However doing all this didnt seem to reduce the aliasing and when the overload is very low the aliasing seems to be worse too using this techinique. any thoughts on ways to improve this or what im doing wrong? Thanks, paul From vesa.norilo at saunalahti.fi Sat Jun 14 10:44:10 2008 From: vesa.norilo at saunalahti.fi (Vesa Norilo) Date: Sat Jun 14 10:44:26 2008 Subject: [music-dsp] Digital Clipping In-Reply-To: <999907.84533.qm@web90604.mail.mud.yahoo.com> References: <999907.84533.qm@web90604.mail.mud.yahoo.com> Message-ID: <4853D93A.5000700@saunalahti.fi> > Then i do something similar for when it leaves > clipping also. > However doing all this didnt seem to reduce the > aliasing and when the overload is very low the > aliasing seems to be worse too using this techinique. > any thoughts on ways to improve this or what im doing > wrong? > Hi Paul, To answer your question directly, there is, I believe, no way to reduce the aliasing distortion caused by clipping. Alias, once happened, can't really be removed. I get the feeling from your post that you'd like to exchange the clipping for soft saturation, which emphasises the lower harmonics more. I believe you could simply use any soft saturation waveshaping on an already clipped signal as long as the soft saturation has a clipping point identical or lower than in your clipped signal. This would "smooth out" the square edges caused by clipping, but would not, I believe, reduce the aliasing. It could however make it sound more pleasant. Then there's clipping restoration which is an entirely different kettle of fish. I believe the common method to de-clip overloaded signal is to assign a certain treshold above which the signal is assumed to be incorrect. For digitally clipped signals, just the minimum and maximum signal values suffice. Then all these "invalid" values are thrown out of the window and some heuristic method is used to guess what the sample values actually were before clipping. An obvious solution would be to fit a lagrange polynomial to the nearest N valid sample points and sample the values of the polynomial for clipped signals. You will need to reduce the output level also since the polynomial will almost certainly exceed the minimum and maximum values. I also seem to remember somebody using a spectral technique to fill out the "holes" in the signal. The details escape me, but I guess one could try to keep the spectral effect of the invalid region as small as possible. Hope this helps, Vesa From uli.brueggemann at gmail.com Sat Jun 14 11:41:48 2008 From: uli.brueggemann at gmail.com (Uli Brueggemann) Date: Sat Jun 14 11:42:03 2008 Subject: [music-dsp] Digital Clipping In-Reply-To: <4853D93A.5000700@saunalahti.fi> References: <999907.84533.qm@web90604.mail.mud.yahoo.com> <4853D93A.5000700@saunalahti.fi> Message-ID: <10a58eee0806140841vdc2be8br5cf0bda475f45d49@mail.gmail.com> Maybe http://www.cutestudio.net/ is worth to look at and to test for declipping? Uli From pfultz2 at yahoo.com Sat Jun 14 19:25:36 2008 From: pfultz2 at yahoo.com (paul Fultz) Date: Sat Jun 14 19:25:49 2008 Subject: [music-dsp] Digital Clipping In-Reply-To: <4853D93A.5000700@saunalahti.fi> Message-ID: <731712.12568.qm@web90602.mail.mud.yahoo.com> Thanks for your reply, well im not trying to reduce the alias after the signal has been clipped(which is what the waveshaping stuff does) instead i have the unclipped version of the signal so there is no need to de-clip it etiher, but what i would like to do is hard clip this signal in a way that would reduce aliasing that is caused, or at least reduce the aliasing into a manageable bandwidth where i would just need to upsample by say 3, or 8 or something like that. I can reduce the aliasing a little bit now by upsampling but to really reduce it more i would need to upsample a lot well over 100, which is not reasonable for real-time processing(since it will be used in conjuction with other processing). I could use waveshaping but i would like the signal to be completly untouched when its not clipping, and then when it is clipping it adds the colorations to the sound. thanks, paul --- Vesa Norilo wrote: > > > Then i do something similar for when it leaves > > clipping also. > > However doing all this didnt seem to reduce the > > aliasing and when the overload is very low the > > aliasing seems to be worse too using this > techinique. > > any thoughts on ways to improve this or what im > doing > > wrong? > > > Hi Paul, > > To answer your question directly, there is, I > believe, no way to reduce > the aliasing distortion caused by clipping. Alias, > once happened, can't > really be removed. I get the feeling from your post > that you'd like to > exchange the clipping for soft saturation, which > emphasises the lower > harmonics more. I believe you could simply use any > soft saturation > waveshaping on an already clipped signal as long as > the soft saturation > has a clipping point identical or lower than in your > clipped signal. > This would "smooth out" the square edges caused by > clipping, but would > not, I believe, reduce the aliasing. It could > however make it sound more > pleasant. > > Then there's clipping restoration which is an > entirely different kettle > of fish. > > I believe the common method to de-clip overloaded > signal is to assign a > certain treshold above which the signal is assumed > to be incorrect. For > digitally clipped signals, just the minimum and > maximum signal values > suffice. > > Then all these "invalid" values are thrown out of > the window and some > heuristic method is used to guess what the sample > values actually were > before clipping. An obvious solution would be to fit > a lagrange > polynomial to the nearest N valid sample points and > sample the values of > the polynomial for clipped signals. You will need to > reduce the output > level also since the polynomial will almost > certainly exceed the minimum > and maximum values. I also seem to remember somebody > using a spectral > technique to fill out the "holes" in the signal. The > details escape me, > but I guess one could try to keep the spectral > effect of the invalid > region as small as possible. > > Hope this helps, > Vesa > > > -- > dupswapdrop -- the music-dsp mailing list and > website: > subscription info, FAQ, source code archive, list > archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From douglas at music.columbia.edu Sun Jun 15 00:00:01 2008 From: douglas at music.columbia.edu (douglas repetto) Date: Sun Jun 15 00:00:14 2008 Subject: [music-dsp] [admin] music-dsp FAQ Message-ID: <20080615040001.30C612AB8015F@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 alex at nextworld.de Sun Jun 15 00:16:21 2008 From: alex at nextworld.de (=?ISO-8859-15?Q?Alexander_Ebersp=E4cher?=) Date: Sun Jun 15 00:16:42 2008 Subject: [music-dsp] Book with math? Message-ID: <48549795.9060101@nextworld.de> Hello list, I want to bring up the old topic of books again. I'd like to ask for a recommendation for a book for my special needs. I'm a graduate physics student, so I'm not afraid of maths. I even prefer doing things I already understood. I want to have another try with VST and similar interfaces, maybe heading for synthesis this time. So, it's definitely music-dsp, though I think that image-processing is interesting as well. I like well structured, comprehensive books that do not lose the applications that come along with every theory. In that case, that might be practical aspects of filter design, for example. Examples and applications are especially appreciated in the field of music-dsp. Might the book by Proakis and Manolakis be worth a look? Or "The Scientist and Engineer's Guide to Digital Signal Processing" by Smith? The latter one misses information on synthesis, maybe the first one as well. I'm glad to read some of your thoughts and recommendations! Regards Alex From douglas at music.columbia.edu Sun Jun 15 00:18:43 2008 From: douglas at music.columbia.edu (douglas repetto) Date: Sun Jun 15 00:18:54 2008 Subject: [music-dsp] Book with math? In-Reply-To: <48549795.9060101@nextworld.de> References: <48549795.9060101@nextworld.de> Message-ID: <48549823.4060700@music.columbia.edu> Lots of reviews here: http://music.columbia.edu/cmc/music-dsp/dspbooks.html And it'd be great if people wanted to send in reviews of newer books... Alexander Ebersp?cher wrote: > Hello list, > > I want to bring up the old topic of books again. I'd like to ask for a > recommendation for a book for my special needs. I'm a graduate physics > student, so I'm not afraid of maths. I even prefer doing things I > already understood. > > I want to have another try with VST and similar interfaces, maybe > heading for synthesis this time. So, it's definitely music-dsp, though I > think that image-processing is interesting as well. > > I like well structured, comprehensive books that do not lose the > applications that come along with every theory. In that case, that might > be practical aspects of filter design, for example. Examples and > applications are especially appreciated in the field of music-dsp. > > Might the book by Proakis and Manolakis be worth a look? Or "The > Scientist and Engineer's Guide to Digital Signal Processing" by Smith? > The latter one misses information on synthesis, maybe the first one as > well. > > I'm glad to read some of your thoughts and recommendations! > > Regards > > Alex > > -- > 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://music.columbia.edu/~douglas From alex at nextworld.de Sun Jun 15 00:32:17 2008 From: alex at nextworld.de (=?ISO-8859-15?Q?Alexander_Ebersp=E4cher?=) Date: Sun Jun 15 00:32:34 2008 Subject: [music-dsp] Book with math? In-Reply-To: <48549823.4060700@music.columbia.edu> References: <48549795.9060101@nextworld.de> <48549823.4060700@music.columbia.edu> Message-ID: <48549B51.203@nextworld.de> douglas repetto wrote: > Lots of reviews here: > > http://music.columbia.edu/cmc/music-dsp/dspbooks.html Thanks, Douglas! I couldn't find that site because the link in the FAQ is broken (http://music.columbia.edu/cmc/music-dsp/musicdspFAQ.html#books links to the wrong directory). Any more thoughts on the topic are appreciated anyway! Regards Alex From douglas at music.columbia.edu Sun Jun 15 00:36:14 2008 From: douglas at music.columbia.edu (douglas repetto) Date: Sun Jun 15 00:36:23 2008 Subject: [music-dsp] Book with math? In-Reply-To: <48549B51.203@nextworld.de> References: <48549795.9060101@nextworld.de> <48549823.4060700@music.columbia.edu> <48549B51.203@nextworld.de> Message-ID: <48549C3E.4090200@music.columbia.edu> Ah! Link fixed, thanks a lot! Alexander Ebersp?cher wrote: > douglas repetto wrote: > >> Lots of reviews here: >> >> http://music.columbia.edu/cmc/music-dsp/dspbooks.html > > Thanks, Douglas! I couldn't find that site because the link in the FAQ > is broken > (http://music.columbia.edu/cmc/music-dsp/musicdspFAQ.html#books links to > the wrong directory). > > Any more thoughts on the topic are appreciated anyway! > > Regards > > Alex > -- > 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://music.columbia.edu/~douglas From douglas at music.columbia.edu Sun Jun 15 00:40:17 2008 From: douglas at music.columbia.edu (douglas repetto) Date: Sun Jun 15 00:40:28 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: References: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com> <002901c8cb30$bfdbc920$6401a8c0@acer> <484EE4EB.2040107@cox.net> Message-ID: <48549D31.7080400@music.columbia.edu> I don't suppose anyone wants to take a crack at summarizing this thread? It's a topic that has come up many times over the years and would be good to have in the FAQ. There's a short entry in the FAQ now (#4 What's a fast, stable, accurate method for sinewave generation?), but this thread has had much more useful info. Anyone? douglas -- ............................................... http://artbots.org .....douglas.....irving........................ http://dorkbot.org .......................... http://music.columbia.edu/cmc/music-dsp .......... repetto............. http://music.columbia.edu/organism ............................... http://music.columbia.edu/~douglas From renick at gmail.com Sun Jun 15 01:17:31 2008 From: renick at gmail.com (Renick Bell) Date: Sun Jun 15 01:17:48 2008 Subject: [music-dsp] Book with math? In-Reply-To: <48549C3E.4090200@music.columbia.edu> References: <48549795.9060101@nextworld.de> <48549823.4060700@music.columbia.edu> <48549B51.203@nextworld.de> <48549C3E.4090200@music.columbia.edu> Message-ID: >> Any more thoughts on the topic are appreciated anyway! This might be what you need: http://ccrma.stanford.edu/~jos/pubs.html -- Renick Bell http://the3rd2nd.com From rbj at audioimagination.com Sun Jun 15 01:53:20 2008 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sun Jun 15 01:53:37 2008 Subject: [music-dsp] Book with math? Message-ID: <20080615055320.8FA0A16EC34@ws6-8.us4.outblaze.com> > ----- Original Message ----- > From: "Alexander Ebersp?cher" > To: music-dsp@music.columbia.edu > Subject: [music-dsp] Book with math? > Date: Sun, 15 Jun 2008 13:46:21 +0930 > > > Hello list, > > I want to bring up the old topic of books again. I'd like to ask for a > recommendation for a book for my special needs. I'm a graduate physics > student, so I'm not afraid of maths. ... > I like well structured, comprehensive books that do not lose the applications > that come along with every theory. In that case, that might be practical > aspects of filter design, for example. Examples and applications are > especially appreciated in the field of music-dsp. > > Might the book by Proakis and Manolakis be worth a look? Or "The Scientist > and Engineer's Guide to Digital Signal Processing" by Smith? The latter one > misses information on synthesis, maybe the first one as well. > > I'm glad to read some of your thoughts and recommendations! about how to do VST API, you'll have to find that out from someone else. about books with math that have something to do with DSP and music/audio, now, since you're a physics grad student, you likely have some appreciation for formalisms. now, this may be speaking under you, but there are some good intro DSP books that have some audio examples in them. they might be useful to you but they are undergrad EE level: Sophicles Orfanidis: Introduction to Signal Processing Ken Steiglitz: A Digital Signal Processing Primer (with Applications to Digital Audio and Computer Music) the still classic formal DSP text for senior/grad level is still "O&S", Oppenheim & Schafer (and recently "Buck"): Discrete-Time Signal Processing (not specific to audio/music at all, but will get you to the bottom of many common DSP issues like formal analysis of design, coefficient quantization, signal quantization (not much in there about dither). some nice books about computer music with some maths: F. Richard Moore: Elements of Computer Music De Poli, et. al: Representations of Musical Signals less mathy, but with useful info: Ken Pohlmann: Principles of Digital Audio (whatever is the latest ed.) Martin Russ: Sound Synthesis and Sampling off the top of my head, i can't think about what i'm missing. being an EE, i found books with titles like "Communications Systems" and such. books like that can show you how readily you can throw around the Fourier Transform and made me a believer in the "unitary" form of the F.T. (defined with "f" instead of "oemga" so the inverse F.T. is qualitatively identical to the forward F.T.). often when i talk to audio heads with a physics or math background (and not EE), these guys like "omega" better than "f" and i dunno how they keep their factors of 2*pi straight when they do manipulations. oh geez, i just thought of the perfect books for you: the last books i had ordered and purchased is Gareth Loy: Musimathics (the mathematical foundations of music) Vols. 1 and 2. get those books, they're very current, they're the books i wish i would have written. now, i think the list is complete. everything else in the lit are the occasional papers that you have to scarf up. and this list. and comp.dsp USENET. so, as a physics student (grad or not), you never took a senior or grad level EE course in DSP? -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From rbj at audioimagination.com Sun Jun 15 02:05:48 2008 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sun Jun 15 02:06:03 2008 Subject: [music-dsp] fast sin(x) function Message-ID: <20080615060548.C191F2F8FC@ws6-3.us4.outblaze.com> > ----- Original Message ----- > From: "douglas repetto" > To: "A discussion list for music-related DSP" > Subject: Re: [music-dsp] fast sin(x) function > Date: Sun, 15 Jun 2008 00:40:17 -0400 > > > > I don't suppose anyone wants to take a crack at summarizing this thread? It's > a topic that has come up many times over the years and would be good to have > in the FAQ. There's a short entry in the FAQ now (#4 What's a fast, stable, > accurate method for sinewave generation?), but this thread has had much more > useful info. > > Anyone? i'm finding that i suddenly have more spare time than i would have expected a week ago (credit to Hal Chamberlin). maybe i could do it. for "sine wave *generation*", (a more specific task than "fast sin(x) function"), there are a few/couple techniques not mentioned in this thread (yet), that i might toss in. some will come outa similar discussions we had at comp.dsp. if no objections, gimme a coupla daze. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From rbj at audioimagination.com Sun Jun 15 02:18:05 2008 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sun Jun 15 02:18:20 2008 Subject: [music-dsp] Book with math? Message-ID: <20080615061805.D1C6516EC3F@ws6-8.us4.outblaze.com> > ----- Original Message ----- > From: "Renick Bell" > To: "A discussion list for music-related DSP" > Subject: Re: [music-dsp] Book with math? > Date: Sun, 15 Jun 2008 14:17:31 +0900 > > > >> Any more thoughts on the topic are appreciated anyway! > > This might be what you need: > > http://ccrma.stanford.edu/~jos/pubs.html > good idea! JOS is always good. along similar lines is this pdf from Davide Rocchesso, "Introduction to Sound Processing" http://profs.sci.univr.it/~rocchess/SP/sp.pdf -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From padawan12 at obiwannabe.co.uk Sun Jun 15 02:50:09 2008 From: padawan12 at obiwannabe.co.uk (Andy Farnell) Date: Sun Jun 15 02:50:12 2008 Subject: [music-dsp] Book with math? In-Reply-To: <20080615055320.8FA0A16EC34@ws6-8.us4.outblaze.com> References: <20080615055320.8FA0A16EC34@ws6-8.us4.outblaze.com> Message-ID: <20080615075009.1e50ae44.padawan12@obiwannabe.co.uk> Good list. Some related texts I like (especially for a physics dude) Harry F Olson - Music, Physics and Engineering (old but still groovy) Elmore and Heald - Physics of waves (Not exactly sound related, but great foundations) Perry Cook - Real time sound synthesis for interactive apps (Everyday sound synthesis - my kind of thing :) Dave Benson - Music, a mathematical offering (Lots of interesting stuff for musicians) Miller Puckette - Theory and Techniques of electronic music (quite extensive - good tricks) Eduardo Miranda - Computer sound design (very light) My book is off to the printers in a few weeks. Quite light on code and eqs, practical approach to physics based sound design with dataflow - more info later :) a. On Sun, 15 Jun 2008 01:53:20 -0400 "robert bristow-johnson" wrote: > > > ----- Original Message ----- > > From: "Alexander Ebersp?cher" > > To: music-dsp@music.columbia.edu > > Subject: [music-dsp] Book with math? > > Date: Sun, 15 Jun 2008 13:46:21 +0930 > > > > > > Hello list, > > > > I want to bring up the old topic of books again. I'd like to ask for a > > recommendation for a book for my special needs. I'm a graduate physics > > student, so I'm not afraid of maths. > ... > > I like well structured, comprehensive books that do not lose the applications > > that come along with every theory. In that case, that might be practical > > aspects of filter design, for example. Examples and applications are > > especially appreciated in the field of music-dsp. > > > > Might the book by Proakis and Manolakis be worth a look? Or "The Scientist > > and Engineer's Guide to Digital Signal Processing" by Smith? The latter one > > misses information on synthesis, maybe the first one as well. > > > > I'm glad to read some of your thoughts and recommendations! > > about how to do VST API, you'll have to find that out from someone else. > > about books with math that have something to do with DSP and music/audio, > > now, since you're a physics grad student, you likely have some appreciation for formalisms. now, this may be speaking under you, but there are some good intro DSP books that have some audio examples in them. they might be useful to you but they are undergrad EE level: > > Sophicles Orfanidis: Introduction to Signal Processing > Ken Steiglitz: A Digital Signal Processing Primer (with Applications > to Digital Audio and Computer Music) > > the still classic formal DSP text for senior/grad level is still "O&S", > Oppenheim & Schafer (and recently "Buck"): Discrete-Time Signal Processing > (not specific to audio/music at all, but will get you to the bottom of many common DSP issues like formal analysis of design, coefficient quantization, signal quantization (not much in there about dither). > > some nice books about computer music with some maths: > F. Richard Moore: Elements of Computer Music > De Poli, et. al: Representations of Musical Signals > > less mathy, but with useful info: > Ken Pohlmann: Principles of Digital Audio (whatever is the latest ed.) > Martin Russ: Sound Synthesis and Sampling > > off the top of my head, i can't think about what i'm missing. being an EE, i found books with titles like "Communications Systems" and such. books like that can show you how readily you can throw around the Fourier Transform and made me a believer in the "unitary" form of the F.T. (defined with "f" instead of "oemga" so the inverse F.T. is qualitatively identical to the forward F.T.). often when i talk to audio heads with a physics or math background (and not EE), these guys like "omega" better than "f" and i dunno how they keep their factors of 2*pi straight when they do manipulations. > > oh geez, i just thought of the perfect books for you: the last books i had ordered and purchased is > > Gareth Loy: Musimathics (the mathematical foundations of music) Vols. 1 and 2. > > get those books, they're very current, they're the books i wish i would have written. > > now, i think the list is complete. everything else in the lit are the occasional papers that you have to scarf up. and this list. and comp.dsp USENET. > > so, as a physics student (grad or not), you never took a senior or grad level EE course in DSP? > > -- > > r b-j rbj@audioimagination.com > > "Imagination is more important than knowledge." > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -- Use the source From bastian.schnuerle at silberstein.de Sun Jun 15 03:10:37 2008 From: bastian.schnuerle at silberstein.de (bastian.schnuerle) Date: Sun Jun 15 03:10:50 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: <48549D31.7080400@music.columbia.edu> References: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com> <002901c8cb30$bfdbc920$6401a8c0@acer> <484EE4EB.2040107@cox.net> <48549D31.7080400@music.columbia.edu> Message-ID: how ? Am 15.06.2008 um 06:40 schrieb douglas repetto: > > I don't suppose anyone wants to take a crack at summarizing this > thread? It's a topic that has come up many times over the years and > would be good to have in the FAQ. There's a short entry in the FAQ > now (#4 What's a fast, stable, accurate method for sinewave > generation?), but this thread has had much more useful info. > > Anyone? > > douglas > > -- > ............................................... http://artbots.org > .....douglas.....irving........................ http://dorkbot.org > .......................... http://music.columbia.edu/cmc/music-dsp > .......... repetto............. http://music.columbia.edu/organism > ............................... http://music.columbia.edu/~douglas > > -- > dupswapdrop -- the music-dsp mailing list and website: subscription > info, FAQ, source code archive, list archive, book reviews, dsp > links http://music.columbia.edu/cmc/music-dsp http:// > music.columbia.edu/mailman/listinfo/music-dsp From bogac at bteaudio.com Sun Jun 15 08:39:35 2008 From: bogac at bteaudio.com (Bogac Topaktas) Date: Sun Jun 15 08:39:53 2008 Subject: [music-dsp] Digital Clipping Message-ID: <9953a85a216a63cb55f29c61e24d8189@bteaudio.com> Hi Paul, If you can afford upsampling in your application and do know the exact bandwidth expansion caused by your waveshaper then you can eliminate aliasing by: upsampling_by_the_required_amount-->waveshaping-->downsampling_by_the_required_amount For instance, if you are employing cubic soft-clipper as waveshaper then the bandwidth expansion is limited to a factor of three.Therefore you need to upsample by -at least- a factor of three in order to avoid aliasing: http://ccrma.stanford.edu/~jos/pasp/Cubic_Soft_Clipper_I.html For more information, see: http://ccrma.stanford.edu/~jos/pasp/Memoryless_Nonlinearities.html http://ccrma.stanford.edu/~jos/pasp/Practical_Advice.html Bogac. -----Original message----- From: paul Fultz pfultz2@yahoo.com Date: Sat, 14 Jun 2008 15:26:02 -0700 To: A discussion list for music-related DSP music-dsp@music.columbia.edu Subject: Re: [music-dsp] Digital Clipping > Thanks for your reply, well im not trying to reduce > the alias after the signal has been clipped(which is > what the waveshaping stuff does) instead i have the > unclipped version of the signal so there is no need to > de-clip it etiher, but what i would like to do is hard > clip this signal in a way that would reduce aliasing > that is caused, or at least reduce the aliasing into a > manageable bandwidth where i would just need to > upsample by say 3, or 8 or something like that. I can > reduce the aliasing a little bit now by upsampling but > to really reduce it more i would need to upsample a > lot well over 100, which is not reasonable for > real-time processing(since it will be used in > conjuction with other processing). I could use > waveshaping but i would like the signal to be > completly untouched when its not clipping, and then > when it is clipping it adds the colorations to the > sound. > thanks, > paul > --- Vesa Norilo wrote: > > > > > > Then i do something similar for when it leaves > > > clipping also. > > > However doing all this didnt seem to reduce the > > > aliasing and when the overload is very low the > > > aliasing seems to be worse too using this > > techinique. > > > any thoughts on ways to improve this or what im > > doing > > > wrong? > > > > > Hi Paul, > > > > To answer your question directly, there is, I > > believe, no way to reduce > > the aliasing distortion caused by clipping. Alias, > > once happened, can't > > really be removed. I get the feeling from your post > > that you'd like to > > exchange the clipping for soft saturation, which > > emphasises the lower > > harmonics more. I believe you could simply use any > > soft saturation > > waveshaping on an already clipped signal as long as > > the soft saturation > > has a clipping point identical or lower than in your > > clipped signal. > > This would "smooth out" the square edges caused by > > clipping, but would > > not, I believe, reduce the aliasing. It could > > however make it sound more > > pleasant. > > > > Then there's clipping restoration which is an > > entirely different kettle > > of fish. > > > > I believe the common method to de-clip overloaded > > signal is to assign a > > certain treshold above which the signal is assumed > > to be incorrect. For > > digitally clipped signals, just the minimum and > > maximum signal values > > suffice. > > > > Then all these "invalid" values are thrown out of > > the window and some > > heuristic method is used to guess what the sample > > values actually were > > before clipping. An obvious solution would be to fit > > a lagrange > > polynomial to the nearest N valid sample points and > > sample the values of > > the polynomial for clipped signals. You will need to > > reduce the output > > level also since the polynomial will almost > > certainly exceed the minimum > > and maximum values. I also seem to remember somebody > > using a spectral > > technique to fill out the "holes" in the signal. The > > details escape me, > > but I guess one could try to keep the spectral > > effect of the invalid > > region as small as possible. > > > > Hope this helps, > > Vesa > > > > > > -- > > dupswapdrop -- the music-dsp mailing list and > > website: > > subscription info, FAQ, source code archive, list > > archive, book reviews, dsp links > > http://music.columbia.edu/cmc/music-dsp > > http://music.columbia.edu/mailman/listinfo/music-dsp > > > > > > > -- > 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 akbutler at tiscali.co.uk Sun Jun 15 10:06:02 2008 From: akbutler at tiscali.co.uk (andy butler) Date: Sun Jun 15 10:06:01 2008 Subject: [music-dsp] Digital Clipping In-Reply-To: <20080615124005.764BD2AD7EFBD@music.columbia.edu> References: <20080615124005.764BD2AD7EFBD@music.columbia.edu> Message-ID: <485521CA.3050709@tiscali.co.uk> > > For instance, if you are employing cubic soft-clipper as waveshaper then the bandwidth expansion > is limited to a factor of three.Therefore you need to upsample by -at least- a factor of three in order > to avoid aliasing: > > http://ccrma.stanford.edu/~jos/pasp/Cubic_Soft_Clipper_I.html ..but the soft Clipper here is a discontinuous function. Wouldn't that make the 3 factor somewhat overoptimistic? andy butler From mattijs at arttech.nl Sun Jun 15 10:40:52 2008 From: mattijs at arttech.nl (Mattijs Kneppers) Date: Sun Jun 15 10:41:12 2008 Subject: [music-dsp] AMDF shortcuts for SOLA time stretching? Message-ID: <411441.40959.qm@web50103.mail.re2.yahoo.com> Hi, I'm new on this list, and happy to read the interesting discussions that are going on here (although I'll have to acquaint myself with some of the jargon). I just finished a time stretching implementation, more or less PSOLA, that you might be interested in. I think the quality comes close to the zplane stuff. You can find it here, it is done in MaxMSP 5 and it's open source: http://www.cycling74.com/twiki/bin/view/Share/MattijsKneppers Best, Mattijs ----- Original Message ---- > From: James Chandler Jr > To: A discussion list for music-related DSP > Sent: Wednesday, April 23, 2008 7:26:37 AM > Subject: Re: [music-dsp] AMDF shortcuts for SOLA time stretching? > > Hi Ross > > I look at all local maxima, both positive and negative. Autocorr of all peaks > against all other peaks (within the max/min autocorr time limits) seems to give > 'the very worst matches' along with 'the very best matches'. A very bad score > might happen when doing correlation between a positive peak and a negative peak > about 1.5 wave periods distant, or whatever. > > Quality-scaling of the array of AMDF values is a simple formula which > incorporates the very worst score found, so it is nice to find the really bad > ones along with the good scores. > > //high-level check after calculating an array of AMDF scores in a time slice > BestBeatPeriodicity := (AutoCorrMaxVal - AutoCorrMinVal) / AutoCorrMaxVal; > if BestBeatPeriodicity < 0.7 then //don't mess with bad periodicity loops > goto Skip1; //nothing to see here folks, move along > > Using peaks 'seemed like a good idea at the time'. I think the reasons not to > use zero-crossings, were mostly: > > 1. If a file contains low level noise, perhaps the low-level noise would > modulate the locations of zero crossings more than it would modulate the > locations of loud peaks. > > Viewing wave-animations or oscilloscope traces of some instruments, you see > higher harmonics 'rippling' or 'slip-sliding' across the tops of lower > harmonics. This can modulate the peak locations, but I think it is far more > likely to modulate zero crossing locations. > > 2. More importantly, some signals have significant long-duration DC shifts, > usually near note-on locations. Notorious on Guitar or Electric Bass, though it > can also be seen in Vocals or Sax, whatever. > > For instance, a guitar note can get DC-shifted A LOT for ahile after the > beginning of the note. This plays hob with zero-crossing locations, but does not > > significantly affect the time-location of the local peaks. Even if an aggressive > > note-on 'bottom peak' happened to get shifted above the zero line, you still can > > detect the time location of a severely-shifted 'bottom peak' by marching thru > the samples and marking all slope reversals. > > Long ago I tried getting rid of transient DC shifts with sharp hipass filters, > to make zero-crossing detection better. But that didn't help much if at all. If > anything, it caused note-ons to have a 'double bounce' in DC level, making it > worse. > > === > > The nonrealtime beat detection provides some luxuries that would be difficult in > > a realtime plugin that never knows what is coming next. > > This code has an analysis option for 'fine-tuning' the short-loop detection, > once the best 'gross' locations are found. The fine-tune option is used for only > > some instrument types. Given the best-scoring 'gross' short-loops, it will do > AMDF sample-by-sample over a time range of +/- 1 semitone, to find if there is a > > better score in the vicinity of that 'best score'. > > I expected this fine-tune option to be most useful with instruments using pretty > > short autocorr ranges, such as Sax. Strangely enough, the fine-tune short-loop > discovery was fairly useless for short-autocorr range mono instruments, but a > noticeable improvement for long-autocorr range chord instruments such as > acoustic guitar. Not expected, since a short-loop on a chord is several > milliseconds, and one might not expect a change of a couple of samples' distance > > to matter much. > > Debug-watching the fine-tune loop, it looked like perhaps 20 percent of short > loops would get modified from the 'gross detection length', and typically only > by one or two samples. It seems surprising that the 'gross peaks' distance is so > > frequently near optimum. > > === > > In previous programs, for time-domain pitch detection or stretching, I would > start at some anchor point, and do a loop of autocorrelation or AMDF at semitone > > distances (to save compute time). Perhaps 24 autocorrelations for a distance of > 2 octaves. Then I would do a second fine-tune loop for +/- 0.5 semitone, > sample-by-sample, centered on the best gross score. > > That didn't work any better than the current method of just comparing all peaks > to all other peaks, and the peak cross-correlation perhaps runs faster. > > === > > If a note lasts a long time, maybe one second or more, the current > CompareAllPeaksAgainstAllOtherPeaks, requires a potentially big temporary score > array. > > For instance, if you wanted to accomodate an array of a max of 1001 peak > locations (lots of peaks in a long note), then a fully-filled out array of > cross-correlations, I think, would be a triangular number-- (n^2 + n) / 2. So > for 1001 peaks, a fully-populated cross-correlation array would need 501501 > elements? > > But since there are max and min autocorr distance limits, and the > cross-correlation array doesn't have to be fully populated, it isn't quite that > bad. > > Set some debug values to fire if I ran out of array space, and in practical > usage, the array of peak locations had to be inched up to 8000 to 'never fail' > on very long notes. But a cross-correlation array size of 500,000 elements > turned out big enough to never fail in practice. Perhaps it could be > significantly smaller than that, but I got tired of fiddling with it. > > jcjr > > ----- Original Message ----- > From: "Ross Bencina" > To: "A discussion list for music-related DSP" > Sent: Tuesday, April 22, 2008 6:41 AM > Subject: Re: [music-dsp] AMDF shortcuts for SOLA time stretching? > > > > Thanks for your usual generosity in sharing all the interesting details James, > > > I didn't find that tedious at all. > > > > I found the "Good Short Loops" bit especially interesting.. I'm still not sure > > > how you find it easier to find peaks instead of zero crossings for > > autocorrelation anchor points. When you say 'peaks' do you mean all local > > maxima? or maximum point between adjacent zero crossings? Is your resoning > > that the peaks provide a larger set of potential anchor points to work with? > > > > Best wishes > > > > Ross. > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp > links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From sts.nitrogen at gmail.com Sun Jun 15 18:17:15 2008 From: sts.nitrogen at gmail.com (Michael Bourgeous) Date: Sun Jun 15 18:17:31 2008 Subject: [music-dsp] Digital Clipping In-Reply-To: <999907.84533.qm@web90604.mail.mud.yahoo.com> References: <999907.84533.qm@web90604.mail.mud.yahoo.com> Message-ID: <8e4fc8270806151517xffdfbfdxaf2e0c918e211224@mail.gmail.com> On Fri, Jun 13, 2008 at 7:53 PM, paul Fultz wrote: > I was trying a technique to smooth out the sharp edges > in digital clipping to try to reduce aliasing. Now, > say given the samples s1, s2 , s3, with the s3 > clipping i know that the clipping usually occurs > somewhere in between s2 and s3, so i used the > numerical derivative of s2 to calculate this clipping > point. Then i created a cubic spline curve thats stems > from s1 to the clipping point, keeping the derivative > of s1 the same, and the derivative of the clipping > point set to 0. I then used this cubic spline to > calculate s2. However this didnt reduce the aliasing. > I thought maybe it didnt because the cubic spline is > not bandlimited. So i created a bandlimited spline > curve like this: > > a*sin(m*x) + b*cos(m*x) + c*cos(2*m*x) + d*sin(2*m*x) > > To calculate these coeffecients i just used matlab > where its goes from 0 to x0(the clipping point) where > y1=s1 and > y2=(1 or -1) depending which side its clipping on, and > yy1=derivative at s1, and yy2=0 > m = pi/(2*x0); > f = a*sin(m*x) + b*cos(m*x) + c*cos(2*m*x) + > d*sin(2*m*x); > g = diff(f); > S = > solve(subs(f,0)-y1,subs(f,x0)-y2,subs(g,0)-yy1,subs(g,x0)-yy2,a,b,c,d); > > Then i do something similar for when it leaves > clipping also. > However doing all this didnt seem to reduce the > aliasing and when the overload is very low the > aliasing seems to be worse too using this techinique. > any thoughts on ways to improve this or what im doing > wrong? > Thanks, > paul > If it's soft clipping you're looking for, I've used a piecewise soft clipping function before that worked quite well. Below a certain threshold I use the original value, but above that threshold I use an asymptotic function such as a hyperbola. That way signals that aren't near clipping will be unaltered, and signals that are near clipping will only be minimally altered. If you know that the input signal will never exceed a certain value, then you can use a polynomial, sine, or other function that intersects with the transition point, has a slope of one at that point, and has an output of 1 for your known maximum input. For example, below an absolute sample value of 0.75 * full scale, the original signal is passed (i.e. y = x). Above that threshold, a hyperbolic function with a horizontal asymptote of 1 is used, adjusted so that it has a slope of 1 at the transition point from linear to hyperbolic. I don't know if the technique has a name as I didn't research it before I wrote the code, but I'm sure that others have done something similar. You may also just want to try using an ordinary lookahead compressor/limiter to bring down the peaks and bring up the rest of the signal. Mike Bourgeous From douglas at music.columbia.edu Sun Jun 15 18:23:30 2008 From: douglas at music.columbia.edu (douglas repetto) Date: Sun Jun 15 18:23:48 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: References: <17A70B22-0808-4E37-BCBC-4D986D2F4E38@audiospillage.com> <002901c8cb30$bfdbc920$6401a8c0@acer> <484EE4EB.2040107@cox.net> <48549D31.7080400@music.columbia.edu> Message-ID: <48559662.8090702@music.columbia.edu> If you're interested in contributing to the FAQ or book reviews or any other part of the site, simply send me some text in an email and I'll add it. If you have a little extra time you can send it as html in the same format as the existing entries. Andy Farnell and r b-j are tackling the sine generation FAQ! douglas bastian.schnuerle wrote: > how ? > > Am 15.06.2008 um 06:40 schrieb douglas repetto: > >> >> I don't suppose anyone wants to take a crack at summarizing this >> thread? It's a topic that has come up many times over the years and >> would be good to have in the FAQ. There's a short entry in the FAQ now >> (#4 What's a fast, stable, accurate method for sinewave generation?), >> but this thread has had much more useful info. >> >> Anyone? >> >> douglas >> >> -- >> ............................................... http://artbots.org >> .....douglas.....irving........................ http://dorkbot.org >> .......................... http://music.columbia.edu/cmc/music-dsp >> .......... repetto............. http://music.columbia.edu/organism >> ............................... http://music.columbia.edu/~douglas >> >> -- >> dupswapdrop -- the music-dsp mailing list and website: subscription >> info, FAQ, source code archive, list archive, book reviews, dsp links >> http://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 > -- ............................................... http://artbots.org .....douglas.....irving........................ http://dorkbot.org .......................... http://music.columbia.edu/cmc/music-dsp .......... repetto............. http://music.columbia.edu/organism ............................... http://music.columbia.edu/~douglas From bogac at bteaudio.com Sun Jun 15 19:31:34 2008 From: bogac at bteaudio.com (Bogac Topaktas) Date: Sun Jun 15 19:31:51 2008 Subject: [music-dsp] Digital Clipping Message-ID: <50967d869c5df17e97be084299da0b01@bteaudio.com> > .but the soft Clipper here is a discontinuous function. > > Wouldn't that make the 3 factor somewhat overoptimistic? Sure. My "-at least-" emphasis was referring to that optimism. -----Original message----- From: andy butler akbutler@tiscali.co.uk Date: Sun, 15 Jun 2008 06:06:08 -0700 To: music-dsp@music.columbia.edu Subject: Re: [music-dsp] Digital Clipping > > > > For instance, if you are employing cubic soft-clipper as waveshaper then the bandwidth expansion > > is limited to a factor of three.Therefore you need to upsample by -at least- a factor of three in order > > to avoid aliasing: > > > > http://ccrma.stanford.edu/~jos/pasp/Cubic_Soft_Clipper_I.html > > .but the soft Clipper here is a discontinuous function. > > Wouldn't that make the 3 factor somewhat overoptimistic? > > > > andy butler > > > > > -- > 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 rossb-lists at audiomulch.com Sun Jun 15 23:59:32 2008 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Mon Jun 16 00:00:05 2008 Subject: [music-dsp] Digital Clipping References: <50967d869c5df17e97be084299da0b01@bteaudio.com> Message-ID: <013301c8cf65$62dc4b30$0400a8c0@rossmacbook> Yeah.. I agree, this clipper is not a cubic function, it's a piecewise function of which the middle segment is cubic. In my experiments you need 16x oversampling to avoid significant aliasing with this particular clipping function. Cheers Ross. ----- Original Message ----- From: "Bogac Topaktas" To: "A discussion list for music-related DSP" Sent: Monday, June 16, 2008 9:31 AM Subject: Re: [music-dsp] Digital Clipping >> .but the soft Clipper here is a discontinuous function. >> >> Wouldn't that make the 3 factor somewhat overoptimistic? > > Sure. My "-at least-" emphasis was referring to that optimism. > > > -----Original message----- > From: andy butler akbutler@tiscali.co.uk > Date: Sun, 15 Jun 2008 06:06:08 -0700 > To: music-dsp@music.columbia.edu > Subject: Re: [music-dsp] Digital Clipping > >> > >> > For instance, if you are employing cubic soft-clipper as waveshaper >> > then the bandwidth expansion >> > is limited to a factor of three.Therefore you need to upsample by -at >> > least- a factor of three in order >> > to avoid aliasing: >> > >> > http://ccrma.stanford.edu/~jos/pasp/Cubic_Soft_Clipper_I.html >> >> .but the soft Clipper here is a discontinuous function. >> >> Wouldn't that make the 3 factor somewhat overoptimistic? >> >> >> >> andy butler >> >> >> >> >> -- >> 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 rossb-lists at audiomulch.com Mon Jun 16 00:18:40 2008 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Mon Jun 16 00:19:05 2008 Subject: [music-dsp] Book with math? References: <20080615055320.8FA0A16EC34@ws6-8.us4.outblaze.com> Message-ID: <014a01c8cf68$0fa725e0$0400a8c0@rossmacbook> robert bristow-johnson wrote: >oh geez, i just thought of the perfect books for you: the last books i had >ordered and purchased is > >Gareth Loy: Musimathics (the mathematical foundations of music) Vols. 1 >and 2. That's really interesting Robert, I was considering buying these but read a review recently (in JAES perhaps) which gave me the impression of "5 points for trying, but really not very helpful if you don't know this stuff already." Can you say a bit more about this series? or give some insight into what the strengths of these books are over the others you mentioned? (and I know, slightly OT, but) would they be helpful to people without formal grad-level mathematics training? To the OP: Not really "books with math" compared to the EE books previously mentioned, but a few more pragmatic suggestions you might like to check out from the local university library: Roads, C. Ed.1992 The Music Machine. MIT Press. M. V. Mathews and J. R. Pierce, Eds. 1989 Current Directions in Computer Music Research. MIT Press. U. Zoelzer, Ed. 2002 Dafx: Digital Audio Effects. John Wiley & Sons, Inc. All of the above are worth owning (imho) and the first two can usually be picked up cheaply second hand on bookfinder.com. Best wishes Ross. From padawan12 at obiwannabe.co.uk Mon Jun 16 00:48:27 2008 From: padawan12 at obiwannabe.co.uk (Andy Farnell) Date: Mon Jun 16 00:48:27 2008 Subject: [music-dsp] Book with math? In-Reply-To: <014a01c8cf68$0fa725e0$0400a8c0@rossmacbook> References: <20080615055320.8FA0A16EC34@ws6-8.us4.outblaze.com> <014a01c8cf68$0fa725e0$0400a8c0@rossmacbook> Message-ID: <20080616054827.35c2cb52.padawan12@obiwannabe.co.uk> No one's mentioned Dodge and Jerse "Computer Music" yet? It's old now, but used to be essential reading on most music tech degrees. There's no paperback and it's dead expensive :( (perhaps this thread could become a music-dsp bibliography ? ) On Mon, 16 Jun 2008 14:18:40 +1000 "Ross Bencina" wrote: > robert bristow-johnson wrote: > >oh geez, i just thought of the perfect books for you: the last books i had > >ordered and purchased is > > > >Gareth Loy: Musimathics (the mathematical foundations of music) Vols. 1 > >and 2. > > That's really interesting Robert, I was considering buying these but read a > review recently (in JAES perhaps) which gave me the impression of "5 points > for trying, but really not very helpful if you don't know this stuff > already." Can you say a bit more about this series? or give some insight > into what the strengths of these books are over the others you mentioned? > (and I know, slightly OT, but) would they be helpful to people without > formal grad-level mathematics training? > > > To the OP: Not really "books with math" compared to the EE books previously > mentioned, but a few more pragmatic suggestions you might like to check out > from the local university library: > > Roads, C. Ed.1992 The Music Machine. MIT Press. > > M. V. Mathews and J. R. Pierce, Eds. 1989 Current Directions in Computer > Music Research. MIT Press. > > U. Zoelzer, Ed. 2002 Dafx: Digital Audio Effects. John Wiley & Sons, Inc. > > All of the above are worth owning (imho) and the first two can usually be > picked up cheaply second hand on bookfinder.com. > > Best wishes > > Ross. > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -- Use the source From douglas at music.columbia.edu Mon Jun 16 00:56:28 2008 From: douglas at music.columbia.edu (douglas repetto) Date: Mon Jun 16 00:56:36 2008 Subject: [music-dsp] Book with math? In-Reply-To: <20080616054827.35c2cb52.padawan12@obiwannabe.co.uk> References: <20080615055320.8FA0A16EC34@ws6-8.us4.outblaze.com> <014a01c8cf68$0fa725e0$0400a8c0@rossmacbook> <20080616054827.35c2cb52.padawan12@obiwannabe.co.uk> Message-ID: <4855F27C.7050808@music.columbia.edu> Andy Farnell wrote: > > No one's mentioned Dodge and Jerse "Computer Music" yet? > > It's old now, but used to be essential reading on most music > tech degrees. There's no paperback and it's dead expensive :( > > (perhaps this thread could become a music-dsp bibliography ? ) It'd be great to fold all of these into the book reviews page. Lots of the entries aren't really reviews anyway, just mentions of relevant texts. Many of the texts that have been mentioned are already listed. I'll try to go through and add the new ones this week. douglas -- ............................................... http://artbots.org .....douglas.....irving........................ http://dorkbot.org .......................... http://music.columbia.edu/cmc/music-dsp .......... repetto............. http://music.columbia.edu/organism ............................... http://music.columbia.edu/~douglas From richarddobson at blueyonder.co.uk Mon Jun 16 04:24:20 2008 From: richarddobson at blueyonder.co.uk (Richard Dobson) Date: Mon Jun 16 04:26:20 2008 Subject: [music-dsp] Book with math? In-Reply-To: <20080616054827.35c2cb52.padawan12@obiwannabe.co.uk> References: <20080616054827.35c2cb52.padawan12@obiwannabe.co.uk> Message-ID: <48562334.6040204@blueyonder.co.uk> Andy Farnell wrote: > > > No one's mentioned Dodge and Jerse "Computer Music" yet? > > It's old now, but used to be essential reading on most music > tech degrees. There's no paperback and it's dead expensive :( > Its in a second edition (1997 or so): there is a paperback and it is only expensive-ish. Try this: http://www.amazon.co.uk/Computer-Music-Charles-Dodge/dp/0028646827 Richard Dobson From d.sbragion at infotecna.it Mon Jun 16 08:45:04 2008 From: d.sbragion at infotecna.it (Denis Sbragion) Date: Mon Jun 16 08:45:27 2008 Subject: [music-dsp] [ANN] DRC 3.0.0 Message-ID: <2997.192.168.1.15.1213620304.squirrel@www.infotecna.lcl> Hello, DRC 3.0.0 is out and available at the usual place: http://drc-fir.sourceforge.net/ Here are the change notes: A new method for the computation of an optimized psychoacoustic target response, based on the spectral envelope of the corrected impulse response, has been introduced. Bye, -- Denis Sbragion InfoTecna Tel: +39 0362 805396, Fax: +39 0362 805404 URL: http://www.infotecna.it From rrsounds at aol.com Mon Jun 16 09:43:15 2008 From: rrsounds at aol.com (David Reaves) Date: Mon Jun 16 09:43:42 2008 Subject: [music-dsp] Book with math? In-Reply-To: <20080616124544.3B0EB2B2AABF3@music.columbia.edu> References: <20080616124544.3B0EB2B2AABF3@music.columbia.edu> Message-ID: <3823D87C-B8B7-47E8-B95F-2B5D2C19C4D5@aol.com> I'm a fan of Udo Z?lzer's two books: "Digital Audio Signal Processing" and "DAFX: Digital Audio Effects" These, too, are quite expensive, but in my line of work, they are indispensable. The DAFX book goes into quite a bit of detail concerning non-linear soft clipping and tube distortion effects, and the math behind them. Kind Regards, David David P. Reaves, III TransLanTech Sound, LLC Home of the Award-winning "Ariane Sequel" Digital Audio Leveler On Mon, 16 Jun 2008 05:48:27 +0100 Andy Farnell wrote: > > No one's mentioned Dodge and Jerse "Computer Music" yet? > > It's old now, but used to be essential reading on most music > tech degrees. There's no paperback and it's dead expensive :( > > (perhaps this thread could become a music-dsp bibliography ? ) From alex at nextworld.de Mon Jun 16 12:54:29 2008 From: alex at nextworld.de (=?ISO-8859-15?Q?Alexander_Ebersp=E4cher?=) Date: Mon Jun 16 12:54:45 2008 Subject: [music-dsp] Book with math? In-Reply-To: <20080615055320.8FA0A16EC34@ws6-8.us4.outblaze.com> References: <20080615055320.8FA0A16EC34@ws6-8.us4.outblaze.com> Message-ID: <48569AC5.60905@nextworld.de> robert bristow-johnson wrote: > about how to do VST API, you'll have to find that out from someone else. I did some simple VST stuff years ago, that won't be the biggest problem. >often when i talk to audio heads with a physics or math background (and not EE), these guys like "omega" better than "f" and i dunno how they keep their factors of 2*pi straight when they do manipulations. Well, I think I've seen every possible form of the FT so far ;) Even in physics that may differ from textbook to textbook. I'd say, as long as you do it consistently, everything is fine. > oh geez, i just thought of the perfect books for you: the last books i had ordered and purchased is > > Gareth Loy: Musimathics (the mathematical foundations of music) Vols. 1 and 2. I've got the same question as Ross has on these books: can these books bring any benefit to people that already have a good background in maths/sound/music? > so, as a physics student (grad or not), you never took a senior or grad level EE course in DSP? No, it just didn't happen. Maybe I can do something like this next semester, but anyway, I like to read a good book. Beside that, thanks everyone for your suggestions. I will go through these and see what the library has to offer for me! Regards Alex From ristoh at extern.uio.no Mon Jun 16 14:11:43 2008 From: ristoh at extern.uio.no (Risto Holopainen) Date: Mon Jun 16 14:11:59 2008 Subject: [music-dsp] Book with math? In-Reply-To: <48549823.4060700@music.columbia.edu> References: <48549795.9060101@nextworld.de> <48549823.4060700@music.columbia.edu> Message-ID: <47716.80.213.138.220.1213639903.squirrel@webmail.uio.no> James W. Beauchamp (Ed) (2007). Analysis, Synthesis, and Perception of Musical Sounds: The Sound of Music (Modern Acoustics and Signal Processing) Springer. This book starts with a detailed introduction to the phase vocoder, and is probably unique in the way it combines a practical discussion of dsp / audio programming with psycoacoustic research. There are lots of interesting results of timbre studies using multidimensional scaling, constant Q filter banks, spectral matching of FM and wavetable synthesis, and so on. Assumes basic knowledge of the usual DSP stuff, but is over all quite accessibly written. Risto > > Lots of reviews here: > > http://music.columbia.edu/cmc/music-dsp/dspbooks.html > > > And it'd be great if people wanted to send in reviews of newer books... > From gcoleman at iua.upf.edu Tue Jun 17 05:21:10 2008 From: gcoleman at iua.upf.edu (Graham Coleman) Date: Tue Jun 17 05:21:25 2008 Subject: [music-dsp] mix parameters by example? Message-ID: <975fddbd0806170221i30c7ce54ne9f0cebf37dde194@mail.gmail.com> Greetings! Does anybody know of any previous work or implementations that try to transfer or resynthesize, on new multitrack inputs, the "album effect" of a mix or mastered recording? Maybe by estimating parameters of compressors, gains, eqs, etc? I can swear that I've seen the idea before but can't remember from where... best, Graham Coleman From cm at cmorrow.com Tue Jun 17 07:41:28 2008 From: cm at cmorrow.com (cm@cmorrow.com) Date: Tue Jun 17 07:41:12 2008 Subject: [music-dsp] mix parameters by example? In-Reply-To: <975fddbd0806170221i30c7ce54ne9f0cebf37dde194@mail.gmail.com> References: <975fddbd0806170221i30c7ce54ne9f0cebf37dde194@mail.gmail.com> Message-ID: <1560387088-1213702859-cardhu_decombobulator_blackberry.rim.net-2103868164-@bxe107.bisx.prod.on.blackberry> Suggest u look at the software specs of hardware device like the popular POD or older Finalizer. As well look at plugins for standard platforms like Protools, DP etc., Live. In these dj days, specs of playback systems are macro dsp shifters and worth analysing to enter the discussion of style/period/demographic. Mp3 players w earphone are tastemaking d/a processors. Sample and analyse same, resolve as a set of preferences and create a mastering tool. Sent via BlackBerry from T-Mobile -----Original Message----- From: "Graham Coleman" Date: Tue, 17 Jun 2008 11:21:10 To:music-ir@ircam.fr, music-dsp@music.columbia.edu Subject: [music-dsp] mix parameters by example? Greetings! Does anybody know of any previous work or implementations that try to transfer or resynthesize, on new multitrack inputs, the "album effect" of a mix or mastered recording? Maybe by estimating parameters of compressors, gains, eqs, etc? I can swear that I've seen the idea before but can't remember from where... best, Graham Coleman -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp From bogac at bteaudio.com Tue Jun 17 07:58:49 2008 From: bogac at bteaudio.com (Bogac Topaktas) Date: Tue Jun 17 07:59:03 2008 Subject: [music-dsp] mix parameters by example? Message-ID: <1b5b0a68cd4e7116bee541d07fc834f1@bteaudio.com> Hi Graham, Do you mean some sort of automated mastering processor? If so, on the equalization side there is Har-Bal: http://www.har-bal.com/ http://www.soundonsound.com/sos/mar04/articles/harbal.htm Bogac. -----Original message----- From: "Graham Coleman" gcoleman@iua.upf.edu Date: Tue, 17 Jun 2008 01:21:35 -0700 To: music-ir@ircam.fr Subject: [music-dsp] mix parameters by example? > Greetings! > > Does anybody know of any previous work or implementations that try to > transfer or resynthesize, on new multitrack inputs, the "album effect" > of a mix or mastered recording? Maybe by estimating parameters of > compressors, gains, eqs, etc? > > I can swear that I've seen the idea before but can't remember from where... > > best, > > Graham Coleman > -- > 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 lanceboyle at qwest.net Wed Jun 18 00:04:41 2008 From: lanceboyle at qwest.net (Jerry) Date: Wed Jun 18 00:05:04 2008 Subject: [music-dsp] Digital Clipping In-Reply-To: <10a58eee0806140841vdc2be8br5cf0bda475f45d49@mail.gmail.com> References: <999907.84533.qm@web90604.mail.mud.yahoo.com> <4853D93A.5000700@saunalahti.fi> <10a58eee0806140841vdc2be8br5cf0bda475f45d49@mail.gmail.com> Message-ID: <676BFC21-CA03-44FC-9408-4086303354A0@qwest.net> On Jun 14, 2008, at 8:41 AM, Uli Brueggemann wrote: > Maybe http://www.cutestudio.net/ is worth to look at and to test > for declipping? > > Uli > -- > This looks like a remarkable piece of work--they actually claim to undo severe clipping to something resembling the original. Does anyone know how it sounds? Does anyone know how it works? The only clue that I could find is that it uses "advanced heuristics." Jerry From lanceboyle at qwest.net Wed Jun 18 00:10:21 2008 From: lanceboyle at qwest.net (Jerry) Date: Wed Jun 18 00:10:35 2008 Subject: [music-dsp] Book with math? In-Reply-To: <20080615075009.1e50ae44.padawan12@obiwannabe.co.uk> References: <20080615055320.8FA0A16EC34@ws6-8.us4.outblaze.com> <20080615075009.1e50ae44.padawan12@obiwannabe.co.uk> Message-ID: I'm not extremely familiar with this book, but it's free (PDF) and just might hit the OP's fancy. It's all about the music but also the DSP and physics. Jerry On Jun 14, 2008, at 11:50 PM, Andy Farnell wrote: > Dave Benson - Music, a mathematical offering (Lots of interesting > stuff > for musicians) From padawan12 at obiwannabe.co.uk Wed Jun 18 00:23:03 2008 From: padawan12 at obiwannabe.co.uk (Andy Farnell) Date: Wed Jun 18 00:22:56 2008 Subject: [music-dsp] Digital Clipping In-Reply-To: <676BFC21-CA03-44FC-9408-4086303354A0@qwest.net> References: <999907.84533.qm@web90604.mail.mud.yahoo.com> <4853D93A.5000700@saunalahti.fi> <10a58eee0806140841vdc2be8br5cf0bda475f45d49@mail.gmail.com> <676BFC21-CA03-44FC-9408-4086303354A0@qwest.net> Message-ID: <20080618052303.16f103aa.padawan12@obiwannabe.co.uk> My guess would be some variation on linear predictive analysis and some very clever high order interpolation. In _theory_ there's information missing so it shouldn't sound that great. But I've learned never to say never in DSP, who would have forseen MP3 encoding and polyphonic transcription 15 years ago? On Tue, 17 Jun 2008 21:04:41 -0700 Jerry wrote: > > On Jun 14, 2008, at 8:41 AM, Uli Brueggemann wrote: > > > Maybe http://www.cutestudio.net/ is worth to look at and to test > > for declipping? > > > > Uli > > -- > > > This looks like a remarkable piece of work--they actually claim to > undo severe clipping to something resembling the original. Does > anyone know how it sounds? Does anyone know how it works? The only > clue that I could find is that it uses "advanced heuristics." > > Jerry > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -- Use the source From uli.brueggemann at gmail.com Wed Jun 18 02:19:54 2008 From: uli.brueggemann at gmail.com (Uli Brueggemann) Date: Wed Jun 18 02:20:09 2008 Subject: [music-dsp] Digital Clipping In-Reply-To: <676BFC21-CA03-44FC-9408-4086303354A0@qwest.net> References: <999907.84533.qm@web90604.mail.mud.yahoo.com> <4853D93A.5000700@saunalahti.fi> <10a58eee0806140841vdc2be8br5cf0bda475f45d49@mail.gmail.com> <676BFC21-CA03-44FC-9408-4086303354A0@qwest.net> Message-ID: <10a58eee0806172319t759de130t5f8c0adc6157b74d@mail.gmail.com> On Wed, Jun 18, 2008 at 6:04 AM, Jerry wrote: > This looks like a remarkable piece of work--they actually claim to undo > severe clipping to something resembling the original. Does anyone know how > it sounds? Does anyone know how it works? The only clue that I could find is > that it uses "advanced heuristics." > > Jerry > See section How It Works at http://www.cutestudio.net/data/products/audio/declip/index.php Uli From padawan12 at obiwannabe.co.uk Wed Jun 18 12:16:29 2008 From: padawan12 at obiwannabe.co.uk (Andy Farnell) Date: Wed Jun 18 12:16:47 2008 Subject: [music-dsp] Digital Clipping In-Reply-To: <10a58eee0806172319t759de130t5f8c0adc6157b74d@mail.gmail.com> References: <999907.84533.qm@web90604.mail.mud.yahoo.com> <4853D93A.5000700@saunalahti.fi> <10a58eee0806140841vdc2be8br5cf0bda475f45d49@mail.gmail.com> <676BFC21-CA03-44FC-9408-4086303354A0@qwest.net> <10a58eee0806172319t759de130t5f8c0adc6157b74d@mail.gmail.com> Message-ID: <20080618171629.3fa3bbda.padawan12@obiwannabe.co.uk> Cheers Uli, A geat bit of heuristic programming with incremental improvement and some audaciously practical ideas. Love it. On Wed, 18 Jun 2008 08:19:54 +0200 "Uli Brueggemann" wrote: > On Wed, Jun 18, 2008 at 6:04 AM, Jerry wrote: > > This looks like a remarkable piece of work--they actually claim to undo > > severe clipping to something resembling the original. Does anyone know how > > it sounds? Does anyone know how it works? The only clue that I could find is > > that it uses "advanced heuristics." > > > > Jerry > > > > See section How It Works at > http://www.cutestudio.net/data/products/audio/declip/index.php > > Uli > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -- Use the source From sts.nitrogen at gmail.com Thu Jun 19 03:18:38 2008 From: sts.nitrogen at gmail.com (Michael Bourgeous) Date: Thu Jun 19 03:18:53 2008 Subject: [music-dsp] Digital Clipping In-Reply-To: <10a58eee0806172319t759de130t5f8c0adc6157b74d@mail.gmail.com> References: <999907.84533.qm@web90604.mail.mud.yahoo.com> <4853D93A.5000700@saunalahti.fi> <10a58eee0806140841vdc2be8br5cf0bda475f45d49@mail.gmail.com> <676BFC21-CA03-44FC-9408-4086303354A0@qwest.net> <10a58eee0806172319t759de130t5f8c0adc6157b74d@mail.gmail.com> Message-ID: <8e4fc8270806190018v6cf6b099j8c7dd8e5f0465f84@mail.gmail.com> On Wed, Jun 18, 2008 at 12:19 AM, Uli Brueggemann wrote: > See section How It Works at > http://www.cutestudio.net/data/products/audio/declip/index.php > > Uli It looks like cutestudio.net's domain registration expired just as I was reading about it. Hopefully the site comes back up soon; I was just about to listen to the sound samples. Mike Bourgeous From lanceboyle at qwest.net Fri Jun 20 00:32:15 2008 From: lanceboyle at qwest.net (Jerry) Date: Fri Jun 20 00:32:27 2008 Subject: [music-dsp] Digital Clipping In-Reply-To: <20080618052303.16f103aa.padawan12@obiwannabe.co.uk> References: <999907.84533.qm@web90604.mail.mud.yahoo.com> <4853D93A.5000700@saunalahti.fi> <10a58eee0806140841vdc2be8br5cf0bda475f45d49@mail.gmail.com> <676BFC21-CA03-44FC-9408-4086303354A0@qwest.net> <20080618052303.16f103aa.padawan12@obiwannabe.co.uk> Message-ID: On Jun 17, 2008, at 9:23 PM, Andy Farnell wrote: > who would > have forseen MP3 encoding ... 15 years ago? Uh, you can read about it here ;) http://en.wikipedia.org/wiki/MP3 Jerry From padawan12 at obiwannabe.co.uk Fri Jun 20 00:39:56 2008 From: padawan12 at obiwannabe.co.uk (Andy Farnell) Date: Fri Jun 20 00:40:14 2008 Subject: [music-dsp] Digital Clipping In-Reply-To: References: <999907.84533.qm@web90604.mail.mud.yahoo.com> <4853D93A.5000700@saunalahti.fi> <10a58eee0806140841vdc2be8br5cf0bda475f45d49@mail.gmail.com> <676BFC21-CA03-44FC-9408-4086303354A0@qwest.net> <20080618052303.16f103aa.padawan12@obiwannabe.co.uk> Message-ID: <20080620053956.109cc568.padawan12@obiwannabe.co.uk> 1991 doesn't seem like > 15 years ago. Does anyone else get that? :) On Thu, 19 Jun 2008 21:32:15 -0700 Jerry wrote: > > On Jun 17, 2008, at 9:23 PM, Andy Farnell wrote: > > > who would > > have forseen MP3 encoding ... 15 years ago? > > Uh, you can read about it here ;) > http://en.wikipedia.org/wiki/MP3 > > Jerry > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -- Use the source From lanceboyle at qwest.net Fri Jun 20 01:04:11 2008 From: lanceboyle at qwest.net (Jerry) Date: Fri Jun 20 01:04:22 2008 Subject: [music-dsp] Digital Clipping In-Reply-To: <20080620053956.109cc568.padawan12@obiwannabe.co.uk> References: <999907.84533.qm@web90604.mail.mud.yahoo.com> <4853D93A.5000700@saunalahti.fi> <10a58eee0806140841vdc2be8br5cf0bda475f45d49@mail.gmail.com> <676BFC21-CA03-44FC-9408-4086303354A0@qwest.net> <20080618052303.16f103aa.padawan12@obiwannabe.co.uk> <20080620053956.109cc568.padawan12@obiwannabe.co.uk> Message-ID: Yeah--it's kind of a problem. Jerry On Jun 19, 2008, at 9:39 PM, Andy Farnell wrote: > > 1991 doesn't seem like > 15 years ago. > > Does anyone else get that? :) > > > > On Thu, 19 Jun 2008 21:32:15 -0700 > Jerry wrote: > >> >> On Jun 17, 2008, at 9:23 PM, Andy Farnell wrote: >> >>> who would >>> have forseen MP3 encoding ... 15 years ago? >> >> Uh, you can read about it here ;) >> http://en.wikipedia.org/wiki/MP3 >> >> Jerry >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, source code archive, list archive, book >> reviews, dsp links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp > > > -- > Use the source > -- > 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 mark.plumbley at elec.qmul.ac.uk Fri Jun 20 07:57:57 2008 From: mark.plumbley at elec.qmul.ac.uk (Mark Plumbley) Date: Fri Jun 20 07:59:16 2008 Subject: [music-dsp] Deadline Extended to 4 July: CFP: ICArn International Workshop 2008 Message-ID: <3399496864F99445B051FD9556FF3B6F01219C5F@staff-mail1.vpn.elec.qmul.ac.uk> Call for Papers *** DEADLINE EXTENDED TO 4 July 2008 *** ICA Research Network International Workshop 25-26 September, 2008, Liverpool, U.K. www.icarn.org The ICA Research Network is sponsored by the Engineering and Physical Sciences Research Council (EPSRC) in the U.K., and is aimed at improving communications in the area of Blind Source Separation (BSS) and Independent Component Analysis (ICA). The 2008 ICA Research Network Workshop will be held at the University of Liverpool covering the latest developments and techniques in the area of source separation and ICA. Submissions from international participants are most welcome. Topics The workshop will feature keynote addresses and technical presentations (oral and poster), which will be included in the registration. Papers are solicited on topics in the area of source separation or ICA, including but not limited to: Algorithms and Architectures (Non-linear ICA, Probabilistic Models, Sparse Coding, etc), Theory (Optimization, Complex Methods, Time-Frequency Representations, etc), Applications (Audio, Bio-Informatics, Biomedical Engineering, Communications, Finance, Image Processing, Psychology, etc), and novel methods (compressed sensing, non-negative matrix factorization). A special feature of this workshop will be a special poster session where authors will have the opportunity to present their current work in progress. Authors should indicate their preference at the submission stage and submit short papers. Full Paper Submission Procedure Prospective authors are invited to submit camera-ready papers of no more than four A4-size pages in the PDF format. Please use the template and the electronic submission procedure described at the workshop homepage (www.icarn.org). At least one author of each accepted paper must undertake to attend the workshop. Prospective authors can seek clarification using the email address icarnw08@liverpool.ac.uk. Accepted papers will be published in a bound volume. Authors of the most innovative papers will be invited to submit substantially extended and updated versions of their papers for further review and possible publication in the IET Signal Processing journal. There will be one Best Student Paper Award for the best paper presented at the workshop by a student. Registration costs will include attendance in all the sessions, a copy of the bound proceedings, mid-morning and mid-afternoon refreshments as well as buffet lunches on both days, and the Workshop dinner on the evening of 25 September 2008. Important Dates/Deadlines Submission of papers : 4 July, 2008 (extended) Notification of acceptance : 24 July, 2008 Submission of camera-ready accepted paper : 14 August, 2008 Early registration and author registration : 14 August, 2008 Final date for registration : 08 September, 2008 Workshop : 25-26 September, 2008 Website: www.icarn.org Chair A K Nandi Vice-Chair X Zhu Organising Committee A K Nandi X Zhu W Al-Nuaimy M E Davies J Gao M D Plumbley Programme Committee National P Baxter M E Davies R Everson C Fyfe M Girolami C J James A K Nandi M D Plumbley S Sanei X Zhu International J F Cardoso A Cichocki P Comon C Jutten E Oja P Smaragdis -- Dr Mark D Plumbley Centre for Digital Music Department of Electronic Engineering 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 mark.plumbley at elec.qmul.ac.uk Fri Jun 20 07:59:17 2008 From: mark.plumbley at elec.qmul.ac.uk (Mark Plumbley) Date: Fri Jun 20 08:00:16 2008 Subject: [music-dsp] Deadline Extended to 4 July: CFP: ICArn International Workshop 2008 Message-ID: <3399496864F99445B051FD9556FF3B6F01219C60@staff-mail1.vpn.elec.qmul.ac.uk> Dear List, The submission deadline for this workshop (esp for those of you working in e.g. musical audio signal separation) has been extended to 4 July. Best wishes, Mark Plumbley ----------------------------------------------------------------------- Call for Papers *** DEADLINE EXTENDED TO 4 July 2008 *** ICA Research Network International Workshop 25-26 September, 2008, Liverpool, U.K. www.icarn.org The ICA Research Network is sponsored by the Engineering and Physical Sciences Research Council (EPSRC) in the U.K., and is aimed at improving communications in the area of Blind Source Separation (BSS) and Independent Component Analysis (ICA). The 2008 ICA Research Network Workshop will be held at the University of Liverpool covering the latest developments and techniques in the area of source separation and ICA. Submissions from international participants are most welcome. Topics The workshop will feature keynote addresses and technical presentations (oral and poster), which will be included in the registration. Papers are solicited on topics in the area of source separation or ICA, including but not limited to: Algorithms and Architectures (Non-linear ICA, Probabilistic Models, Sparse Coding, etc), Theory (Optimization, Complex Methods, Time-Frequency Representations, etc), Applications (Audio, Bio-Informatics, Biomedical Engineering, Communications, Finance, Image Processing, Psychology, etc), and novel methods (compressed sensing, non-negative matrix factorization). A special feature of this workshop will be a special poster session where authors will have the opportunity to present their current work in progress. Authors should indicate their preference at the submission stage and submit short papers. Full Paper Submission Procedure Prospective authors are invited to submit camera-ready papers of no more than four A4-size pages in the PDF format. Please use the template and the electronic submission procedure described at the workshop homepage (www.icarn.org). At least one author of each accepted paper must undertake to attend the workshop. Prospective authors can seek clarification using the email address icarnw08@liverpool.ac.uk. Accepted papers will be published in a bound volume. Authors of the most innovative papers will be invited to submit substantially extended and updated versions of their papers for further review and possible publication in the IET Signal Processing journal. There will be one Best Student Paper Award for the best paper presented at the workshop by a student. Registration costs will include attendance in all the sessions, a copy of the bound proceedings, mid-morning and mid-afternoon refreshments as well as buffet lunches on both days, and the Workshop dinner on the evening of 25 September 2008. Important Dates/Deadlines Submission of papers : 4 July, 2008 (extended) Notification of acceptance : 24 July, 2008 Submission of camera-ready accepted paper : 14 August, 2008 Early registration and author registration : 14 August, 2008 Final date for registration : 08 September, 2008 Workshop : 25-26 September, 2008 Website: www.icarn.org Chair A K Nandi Vice-Chair X Zhu Organising Committee A K Nandi X Zhu W Al-Nuaimy M E Davies J Gao M D Plumbley Programme Committee National P Baxter M E Davies R Everson C Fyfe M Girolami C J James A K Nandi M D Plumbley S Sanei X Zhu International J F Cardoso A Cichocki P Comon C Jutten E Oja P Smaragdis -- Dr Mark D Plumbley Centre for Digital Music Department of Electronic Engineering 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 rbj at audioimagination.com Sat Jun 21 02:33:34 2008 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sat Jun 21 02:33:55 2008 Subject: [music-dsp] fast sin(x) function Message-ID: <20080621063334.A37DE5481E7@ws6-6.us4.outblaze.com> > ----- Original Message ----- > From: "douglas repetto" > To: "A discussion list for music-related DSP" > Subject: Re: [music-dsp] fast sin(x) function > Date: Sun, 15 Jun 2008 18:23:30 -0400 > > bastian.schnuerle wrote: > > how ? > > > > Am 15.06.2008 um 06:40 schrieb douglas repetto: > > > >> > >> I don't suppose anyone wants to take a crack at summarizing this thread? > >> It's a topic that has come up many times over the years and would be good > >> to have in the FAQ. There's a short entry in the FAQ now (#4 What's a > >> fast, stable, accurate method for sinewave generation?), but this thread > >> has had much more useful info. > >> > >> Anyone? > > > If you're interested in contributing to the FAQ or book reviews or any other > part of the site, simply send me some text in an email and I'll add it. If > you have a little extra time you can send it as html in the same format as > the existing entries. > > Andy Farnell and r b-j are tackling the sine generation FAQ! my apologies for the delay in getting back to this. i've had a sorta life-changing event happen in the meantime and have been incommunicado. if this stuff gets into a FAQ, i would recommend or ask that someone copyedit it (merge with what Andy said, make it clearer or more consistent, etc). i hope and think it's accurate enough. ________________________________________________________________ Four sorta different techniques for computing sin(x) will be summarized here. As far as I can tell, there are about two immediate purposes or applications. One is to generate sinusoidal signals; where the argument of the sin(x) function continues to increase without bound and the algorithm doesn't break. The other purpose for evaluating sin(x) (or cos(x)) is simply for that: to evaluate a trancendental function (like exp(x) or log(x) or similar), usually the argument is of limited domain and since sin(x) is periodic, that limited domain can be one period. A music-dsp application of the latter is in coefficient generation for filters or in evaluation of frequency response. ________________________________________________________________ 1. Look Up Table (LUT), often with interpolation. The LUT would contain essentially one period of the sin(x) function. This table could either be created as constant data computed at compile time, or sometimes could be created by an initialization routine: for (n=0; n Message-ID: <02cd01c8d37a$34490290$0800a8c0@rossmacbook> Looks good Robert... To "the Editor": might be worth adding a "see also" for: ``The Second-Order Digital Waveguide Oscillator'', by Julius O. Smith III and Perry R. Cook, Proceedings of the International Computer Music Conference (ICMC-92, San Jose), pp. 150-153, Computer Music Association, October 1992. http://ccrma.stanford.edu/~jos/wgo/ Which compares three methods of recursive sinusoid generation (and I quote): "" 1. the coupled form which is identical to a two-dimensional vector rotation, 2. the modified coupled form, or ``magic circle'' algorithm, which is similar to (1) but has ideal numerical behavior, and 3. the direct-form, second-order, digital resonator with its poles set to the unit circle. "" I'm not whether sure (2) above corresponds to Robert's discussion below. ... As for lookup tables, I'd love to see some discussion of efficient high-resolution modulo phase increment computations. Often 32 bits of phase doesn't provide enough frequency precision for audio applications.. I've been using a double precision float, limiting the range to the LUT length with if() and cast to int using FISTP (on IA32) -- seems like there may be some other (faster?) techniques though, perhaps 64 bit integer phase variables are a practical alternative these days... Cheers Ross. ----- Original Message ----- From: "robert bristow-johnson" To: "A discussion list for music-related DSP" Sent: Saturday, June 21, 2008 4:33 PM Subject: Re: [music-dsp] fast sin(x) function > ----- Original Message ----- > From: "douglas repetto" > To: "A discussion list for music-related DSP" > > Subject: Re: [music-dsp] fast sin(x) function > Date: Sun, 15 Jun 2008 18:23:30 -0400 > > bastian.schnuerle wrote: > > how ? > > > > Am 15.06.2008 um 06:40 schrieb douglas repetto: > > > >> > >> I don't suppose anyone wants to take a crack at summarizing this > >> thread? > >> It's a topic that has come up many times over the years and would be > >> good > >> to have in the FAQ. There's a short entry in the FAQ now (#4 What's a > >> fast, stable, accurate method for sinewave generation?), but this > >> thread > >> has had much more useful info. > >> > >> Anyone? > > > If you're interested in contributing to the FAQ or book reviews or any > other > part of the site, simply send me some text in an email and I'll add it. If > you have a little extra time you can send it as html in the same format as > the existing entries. > > Andy Farnell and r b-j are tackling the sine generation FAQ! my apologies for the delay in getting back to this. i've had a sorta life-changing event happen in the meantime and have been incommunicado. if this stuff gets into a FAQ, i would recommend or ask that someone copyedit it (merge with what Andy said, make it clearer or more consistent, etc). i hope and think it's accurate enough. ________________________________________________________________ Four sorta different techniques for computing sin(x) will be summarized here. As far as I can tell, there are about two immediate purposes or applications. One is to generate sinusoidal signals; where the argument of the sin(x) function continues to increase without bound and the algorithm doesn't break. The other purpose for evaluating sin(x) (or cos(x)) is simply for that: to evaluate a trancendental function (like exp(x) or log(x) or similar), usually the argument is of limited domain and since sin(x) is periodic, that limited domain can be one period. A music-dsp application of the latter is in coefficient generation for filters or in evaluation of frequency response. ________________________________________________________________ 1. Look Up Table (LUT), often with interpolation. The LUT would contain essentially one period of the sin(x) function. This table could either be created as constant data computed at compile time, or sometimes could be created by an initialization routine: for (n=0; n References: <20080621063354.BD0852C063AC4@music.columbia.edu> Message-ID: "robert bristow-johnson" wrote: >2. 2nd order harmonic oscillator. > >This is effectively a 2-pole linear filter with complex conjugate >poles lying directly on the unit circle. I wouldn't call those >poles "stable", but some textbooks call them "marginally stable" or >"critically stable". [snip] > y[n] = 2*cos(w0)*y[n-1] - y[n-2] [snip] >This thing will run forever without the amplitude growing or >decaying. I think that is true for any selected frequency of >oscillation. Roundoff errors in the coefficient 2*cos(w0) result >only in the oscillator frequency being slightly off of the target >frequency. Dunno if such is true for fixed-point and finite >precision (if the roundoff is always toward zero, that would result >always in errors that would reduce amplitude with no hope of errors >that would increase it), but this works fine for even >single-precision floating point. I haven't tried that one, but my experience with the two-instruction complex rotation method y[n].r = dr * y[n-1].r - di * y[n-1].i y[n].i = dr * y[n-1].i + di * y[n-1].r (see http://www.dspguru.com/howto/tech/osc2.htm or http://www.ied.com/~petr/Oscillators.html) was that it worked perfectly, forever and ever in fixed point (at least on the processor I was using), but in floating point you could see it growing or shrinking after a couple of minutes. This was the opposite of what I would have expected. The dspguru article adds a third instruction that serves as kind of an automatic gain control. At any rate, it might be a good idea to do some stress testing of these, especially if you're going to be modifying things on the fly or running any kind of process that controls when the end of the world will occur. Earl The Sound Guy, Inc. http://www.sfxmachine.com From emanuel.landeholm at gmail.com Sat Jun 21 14:11:18 2008 From: emanuel.landeholm at gmail.com (emanuel) Date: Sat Jun 21 14:10:24 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: <20080621063334.A37DE5481E7@ws6-6.us4.outblaze.com> References: <20080621063334.A37DE5481E7@ws6-6.us4.outblaze.com> Message-ID: <1214071878.30954.10.camel@jel-desktop.no-ip.org> rbj wrote > Now a very good question would be "What the hell is the input, x[n]? re. the two-pole resonator. The input is a sampled delta function. The oscillator output is the impulse response of the recurrence relation-defined LTI. In theory you should be able to set x[n] to a (properly sampled) scaled and shifted delta function for any amplitude & phase, but there might be numerical considerations. y[-1] & y[-2] set the frequency of the oscillator. From joost at greenskin.net Sun Jun 22 06:44:36 2008 From: joost at greenskin.net (Joost Schuttelaar) Date: Sun Jun 22 06:44:46 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: <02cd01c8d37a$34490290$0800a8c0@rossmacbook> References: <20080621063334.A37DE5481E7@ws6-6.us4.outblaze.com> <02cd01c8d37a$34490290$0800a8c0@rossmacbook> Message-ID: <624E506F-6055-4DC8-AA28-D4C786236EC1@greenskin.net> On Jun 21, 2008, at 10:38 , Ross Bencina wrote: > As for lookup tables, I'd love to see some discussion of efficient > high-resolution modulo phase increment computations. Often 32 bits > of phase doesn't provide enough frequency precision for audio > applications.. I've been using a double precision float, limiting > the range to the LUT length with if() and cast to int using FISTP > (on IA32) -- seems like there may be some other (faster?) techniques > though, perhaps 64 bit integer phase variables are a practical > alternative these days... I'd be interested in hearing about this as well. I have been using the exact same method as you but it remains one of the more heavy parts of my synthesis algorithms. I'd love to optimize a bit here. I tried to optimize the cast using magic doubles, which isn't much faster. Another way is to use some scary bitmasks: inline unsigned int floatTo23Bits(float x) { float y = x + 1.f; return *((unsigned long *)&y) & 0x7FFFFF; // last 23 bits } inline float sine(float phase) { // assumes SINE_TABLE_LENGTH = 256! // assumes BIG ENDIAN! float fracIndex = phase * (SINE_TABLE_LENGTH); int intIndex = floatTo23Bits(phase) >> (23-8); float perc = fracIndex - intIndex; return sine_table[intIndex] * (1 - perc) + sine_table[intIndex + 1] * perc; } Which performs a bit better but is very scary :) So it might be that 64-bit integer phasors are indeed be a better idea! -- Joost Schuttelaar The Hague, NL From k.s.matheussen at notam02.no Sun Jun 22 07:20:27 2008 From: k.s.matheussen at notam02.no (Kjetil S. Matheussen) Date: Sun Jun 22 07:21:49 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: <624E506F-6055-4DC8-AA28-D4C786236EC1@greenskin.net> References: <20080621063334.A37DE5481E7@ws6-6.us4.outblaze.com> <02cd01c8d37a$34490290$0800a8c0@rossmacbook> <624E506F-6055-4DC8-AA28-D4C786236EC1@greenskin.net> Message-ID: On Sun, 22 Jun 2008, Joost Schuttelaar wrote: > On Jun 21, 2008, at 10:38 , Ross Bencina wrote: > >> As for lookup tables, I'd love to see some discussion of efficient >> high-resolution modulo phase increment computations. Often 32 bits of phase >> doesn't provide enough frequency precision for audio applications.. I've >> been using a double precision float, limiting the range to the LUT length >> with if() and cast to int using FISTP (on IA32) -- seems like there may be >> some other (faster?) techniques though, perhaps 64 bit integer phase >> variables are a practical alternative these days... > > I'd be interested in hearing about this as well. I have been using the exact > same method as you but it remains one of the more heavy parts of my synthesis > algorithms. I'd love to optimize a bit here. > > I tried to optimize the cast using magic doubles, which isn't much faster. > Another way is to use some scary bitmasks: > I found the code below to be about three times faster than just doing a float to int conversion. This was 7 years ago though, on intel, so maybe the processors works differently today. The routine can probably be optimized too, I don't know. I'm not sure how accurate it is either, but at the time I was pretty sure it was more than good enough. #define MAXL (INT_MAX/2) #define L 8192 // Table size #define L2 8192.0f // Table size in float float phase_inc=...; float address=0; float f=0; int finc1=(int)phase_inc; int finc2=(int)((phase_inc-(float)finc1)*MAXL); int f1=(int)f; int f2=(int)(((f-(float)f1)*MAXL)); int address1=(int)address; int address2=(int)((address-(float)address1)*MAXL); for( n=0 ; n=MAXL){ address1++; address2-=MAXL; }else{ if(address2<0){ address1--; address2+=MAXL; } } while ( address1 >= L ) address1 -= L; while ( address1 < 0 ) address1 += L; f1+=finc1; f2+=finc2; if(f2>=MAXL){ f1++; f2-=MAXL; }else{ if(f2<0){ f1--; f2+=MAXL; } } } From k.s.matheussen at notam02.no Sun Jun 22 07:46:03 2008 From: k.s.matheussen at notam02.no (Kjetil S. Matheussen) Date: Sun Jun 22 07:48:08 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: References: <20080621063334.A37DE5481E7@ws6-6.us4.outblaze.com> <02cd01c8d37a$34490290$0800a8c0@rossmacbook> <624E506F-6055-4DC8-AA28-D4C786236EC1@greenskin.net> Message-ID: On Sun, 22 Jun 2008, Kjetil S. Matheussen wrote: > > > On Sun, 22 Jun 2008, Joost Schuttelaar wrote: > >> On Jun 21, 2008, at 10:38 , Ross Bencina wrote: >> >> > As for lookup tables, I'd love to see some discussion of efficient >> > high-resolution modulo phase increment computations. Often 32 bits of >> > phase doesn't provide enough frequency precision for audio >> > applications.. I've been using a double precision float, limiting the >> > range to the LUT length with if() and cast to int using FISTP (on IA32) >> > -- seems like there may be some other (faster?) techniques though, >> > perhaps 64 bit integer phase variables are a practical alternative these >> > days... >> >> I'd be interested in hearing about this as well. I have been using the >> exact same method as you but it remains one of the more heavy parts of my >> synthesis algorithms. I'd love to optimize a bit here. >> >> I tried to optimize the cast using magic doubles, which isn't much faster. >> Another way is to use some scary bitmasks: >> > > > I found the code below to be about three times faster than > just doing a float to int conversion. This was 7 years ago though, > on intel, so maybe the processors works differently today. > > The routine can probably be optimized too, I don't know. > I'm not sure how accurate it is either, but at the > time I was pretty sure it was more than good enough. > Hmm, looking at the routine, it seems to do slightly a little bit else than implementing an oscillator. It's not my code, I only optimized it, so I don't really know what happens. :-). Well, the tecnique is simple enough, just use to integers to replace one float. From andylist at vellocet.com Sun Jun 22 10:17:48 2008 From: andylist at vellocet.com (Andrew Simper) Date: Sun Jun 22 10:18:15 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: References: <20080621063334.A37DE5481E7@ws6-6.us4.outblaze.com> <02cd01c8d37a$34490290$0800a8c0@rossmacbook> <624E506F-6055-4DC8-AA28-D4C786236EC1@greenskin.net> Message-ID: <485E5F0C.9030007@vellocet.com> Depending on the application if you need to evaluate sin quickly to around 2e-9 (-172dB) precision you can use something like: http://www.vellocet.com/dsp/SinApprox/SinApprox.html Here is the psuedo code from the page with the comments removed: double sinapprox (double a) { x = ((a - 0.5) - floor (a - 0.5) - 0.5); x *= 2*Pi/25; sinx = x - (x^3)/6 + (x^5)/120; sinx = 5*sinx - 20*sinx^3 + 16*sinx^5; sinx = 5*sinx - 20*sinx^3 + 16*sinx^5; return sinx; } You can also skip on one of the sin(5*x) identities to save on cpu and get a results accurate to around 4e-5 (-86dB). Sometimes not using table lookup is a useful thing, but I'm pretty sure on most intel chips a small table with linear interp with the use of some symmetries would be quicker. Andy From didid at skynet.be Sun Jun 22 11:54:48 2008 From: didid at skynet.be (Didier Dambrin) Date: Sun Jun 22 11:55:11 2008 Subject: [music-dsp] fast sin(x) function References: <20080621063334.A37DE5481E7@ws6-6.us4.outblaze.com><02cd01c8d37a$34490290$0800a8c0@rossmacbook> <624E506F-6055-4DC8-AA28-D4C786236EC1@greenskin.net> Message-ID: <011201c8d480$4ca567f0$0401a8c0@GOLAMD> In the past I was mostly using 64bit integer phases, but there's an SSE2 block integer convert that can be pretty fast, so you'd pre-convert your phases to integer in chunks. Since you usually have your chunk of double phases that you'd need to convert to integer+fracs for the interpolator, it'd look like this: MOVAPS xmm0,[EAX] // load 2 doubles ADD EDX,8 CVTTPD2DQ xmm1,xmm0 // truncate to int ADD EAX,16 CVTDQ2PD xmm2,xmm1 // back to doubles SUBPD xmm0,xmm2 // compute fracs MOVQ [EDX-8],xmm1 // store integers MOVAPS [EAX-16],xmm0 // store fracs (& I realize I forgot to unroll mine) But I only switched to double float phases for ease of use, not really speed. > On Jun 21, 2008, at 10:38 , Ross Bencina wrote: > >> As for lookup tables, I'd love to see some discussion of efficient >> high-resolution modulo phase increment computations. Often 32 bits >> of phase doesn't provide enough frequency precision for audio >> applications.. I've been using a double precision float, limiting >> the range to the LUT length with if() and cast to int using FISTP >> (on IA32) -- seems like there may be some other (faster?) techniques >> though, perhaps 64 bit integer phase variables are a practical >> alternative these days... > > I'd be interested in hearing about this as well. I have been using the > exact same method as you but it remains one of the more heavy parts of > my synthesis algorithms. I'd love to optimize a bit here. > > I tried to optimize the cast using magic doubles, which isn't much > faster. Another way is to use some scary bitmasks: > > inline unsigned int floatTo23Bits(float x) { > float y = x + 1.f; > return *((unsigned long *)&y) & 0x7FFFFF; // last 23 bits > } > > inline float sine(float phase) { > // assumes SINE_TABLE_LENGTH = 256! > // assumes BIG ENDIAN! > float fracIndex = phase * (SINE_TABLE_LENGTH); > int intIndex = floatTo23Bits(phase) >> (23-8); > float perc = fracIndex - intIndex; > return sine_table[intIndex] * (1 - perc) + sine_table[intIndex + 1] * > perc; > } > > Which performs a bit better but is very scary :) > > So it might be that 64-bit integer phasors are indeed be a better idea! > > -- > > Joost Schuttelaar > The Hague, NL > -- > 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. Version: 8.0.100 / Virus Database: 270.4.1/1512 - Release Date: 21/06/2008 09:27 From didid at skynet.be Sun Jun 22 12:09:31 2008 From: didid at skynet.be (Didier Dambrin) Date: Sun Jun 22 12:10:03 2008 Subject: [music-dsp] fast sin(x) function References: <20080621063334.A37DE5481E7@ws6-6.us4.outblaze.com> <02cd01c8d37a$34490290$0800a8c0@rossmacbook> <624E506F-6055-4DC8-AA28-D4C786236EC1@greenskin.net> <485E5F0C.9030007@vellocet.com> Message-ID: <017601c8d482$5ac4e7f0$0401a8c0@GOLAMD> Your floor should be the slow part, though, if it needs to change the FPU rounding mode. > Depending on the application if you need to evaluate sin quickly to > around 2e-9 (-172dB) precision you can use something like: > > http://www.vellocet.com/dsp/SinApprox/SinApprox.html > > Here is the psuedo code from the page with the comments removed: > > double sinapprox (double a) > { > x = ((a - 0.5) - floor (a - 0.5) - 0.5); > x *= 2*Pi/25; > sinx = x - (x^3)/6 + (x^5)/120; > sinx = 5*sinx - 20*sinx^3 + 16*sinx^5; > sinx = 5*sinx - 20*sinx^3 + 16*sinx^5; > return sinx; > } > > You can also skip on one of the sin(5*x) identities to save on cpu and > get a results accurate to around 4e-5 (-86dB). Sometimes not using table > lookup is a useful thing, but I'm pretty sure on most intel chips a > small table with linear interp with the use of some symmetries would be > quicker. > > Andy > -- > 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. Version: 8.0.100 / Virus Database: 270.4.1/1512 - Release Date: 21/06/2008 09:27 From andylist at vellocet.com Sun Jun 22 14:35:04 2008 From: andylist at vellocet.com (Andrew Simper) Date: Sun Jun 22 14:35:33 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: <017601c8d482$5ac4e7f0$0401a8c0@GOLAMD> References: <20080621063334.A37DE5481E7@ws6-6.us4.outblaze.com> <02cd01c8d37a$34490290$0800a8c0@rossmacbook> <624E506F-6055-4DC8-AA28-D4C786236EC1@greenskin.net> <485E5F0C.9030007@vellocet.com> <017601c8d482$5ac4e7f0$0401a8c0@GOLAMD> Message-ID: <485E9B58.1060100@vellocet.com> Actually x^5 will probably not be that efficient to do how I have written it as well. And what about those divides? Lucky this is pseudo code to explain the algorithm ;-) Andy Didier Dambrin wrote: > Your floor should be the slow part, though, if it needs to change the > FPU rounding mode. > >> Depending on the application if you need to evaluate sin quickly to >> around 2e-9 (-172dB) precision you can use something like: >> >> http://www.vellocet.com/dsp/SinApprox/SinApprox.html >> >> Here is the psuedo code from the page with the comments removed: >> >> double sinapprox (double a) >> { >> x = ((a - 0.5) - floor (a - 0.5) - 0.5); >> x *= 2*Pi/25; >> sinx = x - (x^3)/6 + (x^5)/120; >> sinx = 5*sinx - 20*sinx^3 + 16*sinx^5; >> sinx = 5*sinx - 20*sinx^3 + 16*sinx^5; >> return sinx; >> } >> >> You can also skip on one of the sin(5*x) identities to save on cpu and >> get a results accurate to around 4e-5 (-86dB). Sometimes not using table >> lookup is a useful thing, but I'm pretty sure on most intel chips a >> small table with linear interp with the use of some symmetries would be >> quicker. >> >> Andy >> -- >> 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. > Version: 8.0.100 / Virus Database: 270.4.1/1512 - Release Date: > 21/06/2008 09:27 > > -- > 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 Sun Jun 22 14:40:22 2008 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sun Jun 22 14:40:37 2008 Subject: [music-dsp] fast sin(x) function Message-ID: <20080622184022.D7CE44F514@ws6-5.us4.outblaze.com> > ----- Original Message ----- > From: emanuel > To: "A discussion list for music-related DSP" > Subject: Re: [music-dsp] fast sin(x) function > Date: Sat, 21 Jun 2008 20:11:18 +0200 > > > rbj wrote > > Now a very good question would be "What the hell is the input, x[n]? > re. the two-pole resonator. > > The input is a sampled delta function. no, not in general. if you assume the initial states, y[-1] & y[-2], are both zero (a completely "relaxed" LTI system before n=0), then the input x[n] must be *something* non-zero since nothing else will start up the oscillator. a kronecker delta would be sufficient to start it up, but you would not have sufficient control > The oscillator output is the > impulse response of the recurrence relation-defined LTI. In theory you > should be able to set x[n] to a (properly sampled) scaled and shifted > delta function for any amplitude & phase, but there might be numerical > considerations. if the system is "relaxed", two samples of x[n] are necessary and sufficient to set the amplitude and phase of the oscillation. normally it would be two adjacent samples, say x[0] and x[1], that are non-zero and the rest of x[n] is zero. if, however, you put the same initialization effect into the initial states, y[-1] & y[-2], then x[n] can be identically zero for all n and you can remove it from the difference equation. then there is no input and this thing is simply and appropriately modeled as an oscillator with output, but no input. > y[-1] & y[-2] set the frequency of the oscillator. no, that's not true at all. the sole determinant of oscillation frequency is the 2*cos(w0) coefficient that sets the resonant frequency of the marginally stable IIR filter. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From rbj at audioimagination.com Sun Jun 22 15:00:27 2008 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sun Jun 22 15:00:42 2008 Subject: [music-dsp] fast sin(x) function Message-ID: <20080622190027.AFD289ECDA@ws6-2.us4.outblaze.com> > ----- Original Message ----- > From: "Ross Bencina" > To: "A discussion list for music-related DSP" > Subject: Re: [music-dsp] fast sin(x) function > Date: Sat, 21 Jun 2008 18:38:37 +1000 > > > Looks good Robert... > > To "the Editor": might be worth adding a "see also" for: > ``The Second-Order Digital Waveguide Oscillator'', by Julius O. Smith III and > Perry R. Cook, Proceedings of the International Computer Music Conference > (ICMC-92, San Jose), pp. 150-153, Computer Music Association, October 1992. > http://ccrma.stanford.edu/~jos/wgo/ > > Which compares three methods of recursive sinusoid generation (and I quote): > "" > 1. the coupled form which is identical to a two-dimensional vector rotation, > 2. the modified coupled form, or "magic circle" algorithm, which is similar > to (1) but has ideal numerical behavior, and > 3. the direct-form, second-order, digital resonator with its poles set to the > unit circle. > "" > > I'm not whether sure (2) above corresponds to Robert's discussion below. i have no idea what a "magic circle" algorithm is. your (1) is the quadrature oscillator which i will get into next, and your (3) is the simple oscillator i treated in my section 2. (after the LUT section). > ----- Original Message ----- > From: "Earl Vickers" > To: music-dsp@music.columbia.edu > Subject: Re: [music-dsp] fast sin(x) function > Date: Sat, 21 Jun 2008 06:48:34 -0700 > > > "robert bristow-johnson" wrote: > > > 2. 2nd order harmonic oscillator. > > > > This is effectively a 2-pole linear filter with complex conjugate poles > > lying directly on the unit circle. I wouldn't call those poles "stable", > > but some textbooks call them "marginally stable" or "critically stable". > > [snip] > > > y[n] = 2*cos(w0)*y[n-1] - y[n-2] > > [snip] > ... > > I haven't tried that one, but my experience with the two-instruction complex > rotation method > > y[n].r = dr * y[n-1].r - di * y[n-1].i > y[n].i = dr * y[n-1].i + di * y[n-1].r > yes, this is the quadrature oscillator i alluded to 36 hours ago. i'll get into it with a pretty formal treatment. there's at least 2 ways of looking at it. > (see http://www.dspguru.com/howto/tech/osc2.htm or > http://www.ied.com/~petr/Oscillators.html) > > was that it worked perfectly, forever and ever in fixed point (at least on > the processor I was using), but in floating point you could see it growing or > shrinking after a couple of minutes. This was the opposite of what I would > have expected. it's what i expected (and seen). my mistake with James McCartney was to extend that experience to the simple oscillator that was described as number 2 in my post. but, if your "dr" and "di" do not precisely square and add to 1, the amplitude of the quadrature oscillation will either decay or grow exponentially. > The dspguru article adds a third instruction that serves as kind of an > automatic gain control. yes, something is needed (unlike that simple oscillator that never grows or decays amplitude because the coef multiplying y[n-2] is exactly 1). i will get into that. > At any rate, it might be a good idea to do some > stress testing of these, especially if you're going to be modifying things on > the fly or running any kind of process that controls when the end of the > world will occur. bad things (like amplitude change) happen when you modify the simple one-phase oscillator frequency coefficient on the fly. you need to stuff in new calculated states for y[n-1] and y[n-2] (or, at least for just y[n-2]) to keep the output continuous, same amplitude, but with a new frequency (or phase increment). -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From didid at skynet.be Sun Jun 22 15:17:49 2008 From: didid at skynet.be (Didier Dambrin) Date: Sun Jun 22 15:18:11 2008 Subject: [music-dsp] fast sin(x) function References: <20080621063334.A37DE5481E7@ws6-6.us4.outblaze.com> <02cd01c8d37a$34490290$0800a8c0@rossmacbook> <624E506F-6055-4DC8-AA28-D4C786236EC1@greenskin.net> <485E5F0C.9030007@vellocet.com><017601c8d482$5ac4e7f0$0401a8c0@GOLAMD> <485E9B58.1060100@vellocet.com> Message-ID: <005e01c8d49c$a8eb9fe0$0401a8c0@GOLAMD> Depends, I can imagine a compiler optimizing the divides (or maybe not since it wouldn't have the same precision as a mul) & certainly the ^5, but it probably won't do the floor differently without help. I mean, how to do fast truncation is a question that happens more often than efficient sine computation. > Actually x^5 will probably not be that efficient to do how I have > written it as well. And what about those divides? Lucky this is pseudo > code to explain the algorithm ;-) > > Andy > > Didier Dambrin wrote: >> Your floor should be the slow part, though, if it needs to change the >> FPU rounding mode. >> >>> Depending on the application if you need to evaluate sin quickly to >>> around 2e-9 (-172dB) precision you can use something like: >>> >>> http://www.vellocet.com/dsp/SinApprox/SinApprox.html >>> >>> Here is the psuedo code from the page with the comments removed: >>> >>> double sinapprox (double a) >>> { >>> x = ((a - 0.5) - floor (a - 0.5) - 0.5); >>> x *= 2*Pi/25; >>> sinx = x - (x^3)/6 + (x^5)/120; >>> sinx = 5*sinx - 20*sinx^3 + 16*sinx^5; >>> sinx = 5*sinx - 20*sinx^3 + 16*sinx^5; >>> return sinx; >>> } >>> >>> You can also skip on one of the sin(5*x) identities to save on cpu and >>> get a results accurate to around 4e-5 (-86dB). Sometimes not using table >>> lookup is a useful thing, but I'm pretty sure on most intel chips a >>> small table with linear interp with the use of some symmetries would be >>> quicker. >>> >>> Andy >>> -- >>> 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. >> Version: 8.0.100 / Virus Database: 270.4.1/1512 - Release Date: >> 21/06/2008 09:27 >> >> -- >> 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. Version: 8.0.100 / Virus Database: 270.4.1/1512 - Release Date: 21/06/2008 09:27 From andylist at vellocet.com Sun Jun 22 16:46:40 2008 From: andylist at vellocet.com (Andrew Simper) Date: Sun Jun 22 16:46:52 2008 Subject: [music-dsp] fast sin(x) function In-Reply-To: <005e01c8d49c$a8eb9fe0$0401a8c0@GOLAMD> References: <20080621063334.A37DE5481E7@ws6-6.us4.outblaze.com> <02cd01c8d37a$34490290$0800a8c0@rossmacbook> <624E506F-6055-4DC8-AA28-D4C786236EC1@greenskin.net> <485E5F0C.9030007@vellocet.com><017601c8d482$5ac4e7f0$0401a8c0@GOLAMD> <485E9B58.1060100@vellocet.com> <005e01c8d49c$a8eb9fe0$0401a8c0@GOLAMD> Message-ID: <485EBA30.3060804@vellocet.com> The floor problem can be solved in a variety of ways and it not what I was focussing on since that part is dependant on the use of the sin function and easily replaceable, the important thing is the input has to be -0.5 to 0.5 to the rest of the computation, which I have clearly stated in the comments. Another point which I'll leave for people to sort out themselves is that you should really tweak the /120 to remove the step error at pi. Depending on the application you might be able to put up with a small amount of distortion and use a single fifth order polynomial with constraints that as many derivatives match at the endpoints as possible. I have not evaluated the derivatives of the method I have proposed, but I doubt they match. I just thought that it was cool that two 5th order polynomials can get you a full sin function accurate to -106 dB and it was an interesting approach even if not optimal. BTW Didier, which compiler do you use on mac? gcc can't optimise x/120.0f for you with it's default optimisation settings since this will lose precision. To allow gcc the room to move I have been advised you should use x*(1.0f/120.0f) instead, which since I'm doing pseudo code I have left to the reader since in my opinion it's more useful to clearly express and idea that spoon feed people with the exact code. All the best, Andrew Didier Dambrin wrote: > Depends, I can imagine a compiler optimizing the divides (or maybe not > since it wouldn't have the same precision as a mul) & certainly the > ^5, but it probably won't do the floor differently without help. > I mean, how to do fast truncation is a question that happens more > often than efficient sine computation. > From didid at skynet.be Sun Jun 22 17:36:38 2008 From: didid at skynet.be (Didier Dambrin) Date: Sun Jun 22 17:37:11 2008 Subject: [music-dsp] fast sin(x) function References: <20080621063334.A37DE5481E7@ws6-6.us4.outblaze.com> <02cd01c8d37a$34490290$0800a8c0@rossmacbook> <624E506F-6055-4DC8-AA28-D4C786236EC1@greenskin.net> <485E5F0C.9030007@vellocet.com><017601c8d482$5ac4e7f0$0401a8c0@GOLAMD> <485E9B58.1060100@vellocet.com><005e01c8d49c$a8eb9fe0$0401a8c0@GOLAMD> <485EBA30.3060804@vellocet.com> Message-ID: <002701c8d4b0$0db7a190$0401a8c0@GOLAMD> Ok but my point was, it's all about fast sine computation, so the main goal is speed, so the pseudocode alone is nice to have, but a sine being not extremely slow, it all comes down to little things, like the function call (if not macro), optimizations & truncation. But ok, that truncation isn't necessary if the input is already in the right range, which leads back to my biggest problem with most of those approximations: wrapping the input. (someone had posted a way to do this in integer, though) > The floor problem can be solved in a variety of ways and it not what I > was focussing on since that part is dependant on the use of the sin > function and easily replaceable, the important thing is the input has to > be -0.5 to 0.5 to the rest of the computation, which I have clearly > stated in the comments. > > Another point which I'll leave for people to sort out themselves is that > you should really tweak the /120 to remove the step error at pi. > > Depending on the application you might be able to put up with a small > amount of distortion and use a single fifth order polynomial with > constraints that as many derivatives match at the endpoints as possible. > I have not evaluated the derivatives of the method I have proposed, but > I doubt they match. I just thought that it was cool that two 5th order > polynomials can get you a full sin function accurate to -106 dB and it > was an interesting approach even if not optimal. > > BTW Didier, which compiler do you use on mac? gcc can't optimise Well not only I (almost) never touched a mac, but I don't code in C++ either. The little I know about C++ compilers come from bad experiences with Delphi-made plugins in C++ made hosts. I think that most compilers assume a default FPU mode to rounding to nearest, however while Delphi simply doesn't change the FPU state when doing rounding to nearest, I saw that most C++ compilers do. Delphi won't optimize x/120 either, simply because Delphi's optimization are 100% safe, and *(1/120) may not have the same precision as /120 (as you wrote below). However Delphi's optimizations are safe on both sides, that is, x+1 followed by x+2 won't result in x+3 if x is a single-precision float, because Delphi assumes that the programmer expects the loss of precision of the single-float storage in each line, resulting in a potentially different precision than x+1+2 being done all in 80bit (one would say that Delphi's compiler is crap at float manipulation, however it does optimize the same computation in integer, so I assume that they did that for maximum 'safety'). But I know that there are C++ compilers that will optimize this if it results in more precision (so I guess you're right that it won't optimize /120). > x/120.0f for you with it's default optimisation settings since this will > lose precision. To allow gcc the room to move I have been advised you > should use x*(1.0f/120.0f) instead, which since I'm doing pseudo code I > have left to the reader since in my opinion it's more useful to clearly > express and idea that spoon feed people with the exact code. > > All the best, > > Andrew > > Didier Dambrin wrote: >> Depends, I can imagine a compiler optimizing the divides (or maybe not >> since it wouldn't have the same precision as a mul) & certainly the >> ^5, but it probably won't do the floor differently without help. >> I mean, how to do fast truncation is a question that happens more >> often than efficient sine computation. >> > > -- > 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. Version: 8.0.100 / Virus Database: 270.4.1/1512 - Release Date: 21/06/2008 09:27 From rbj at audioimagination.com Mon Jun 23 00:12:24 2008 From: rbj at audioimagination.com (robert bristow-johnson) Date: Mon Jun 23 00:12:41 2008 Subject: [music-dsp] fast sin(x) function Message-ID: <20080623041224.C99F4200EA@ws6-7.us4.outblaze.com> > ----- Original Message ----- > From: "robert bristow-johnson" > To: "A discussion list for music-related DSP" > Subject: Re: [music-dsp] fast sin(x) function > Date: Sat, 21 Jun 2008 02:33:34 -0400 > > ________________________________________________________________ > > > Four sorta different techniques for computing sin(x) will be summarized > here. As far as I can tell, there are about two immediate purposes or > applications. One is to generate sinusoidal signals; where the argument of > the sin(x) function continues to increase without bound and the algorithm > doesn't break. The other purpose for evaluating sin(x) (or cos(x)) is > simply for that: to evaluate a trancendental function (like exp(x) or log(x) > or similar), usually the argument is of limited domain and since sin(x) is > periodic, that limited domain can be one period. A music-dsp application > of the latter is in coefficient generation for filters or in evaluation of > frequency response. > > ________________________________________________________________ > > 1. Look Up Table (LUT), often with interpolation. > > The LUT would contain essentially one period of the sin(x) function. ... > > ________________________________________________________________ > > 2. 2nd order harmonic oscillator. > > This is effectively a 2-pole linear filter with complex conjugate poles > lying directly on the unit circle. ... > ________________________________________________________________ 3. 2nd order quadrature oscillator. This is essentially what Ross referred to as "the coupled form which is identical to a two-dimensional vector rotation" or what Earl referred to as "the two-instruction complex rotation method". I is 2nd-order (because it has 2 states), but has a different set of difference equations and two real outputs that are 90 degrees out of phase. Also, it turns out that, due to numerical issues, some amplitude control is necessary which was not needed in the simple resonator in the previous section (2). There are two equivalent ways to look at it mathematically. The "complex rotation" perspective is as follows. As in the previous section (2), we define Fs as the sampling frequency, f0 as the sinusoid frequency (measured in the same units as Fs), and the normalized frequency (radians per sample) is w0 = 2*pi*f0/Fs . From the complex POV, v[n] = x[n] + j*y[n] = exp(j*w0*n) where x[n] = Re{ v[n] } = cos(w0*n) y[n] = Im{ v[n] } = sin(w0*n) . The recursion equation (in the complex POV) is v[n+1] = exp(j*w0*(n+1)) = exp(j*w0) * exp(j*w0*n) = exp(j*w0)*v[n] . Since exp(j*w0) = cos(w0) + j*sin(w0) the above complex recursion equation becomes this pair of real-valued recursion equations: x[n+1] = cos(w0)*x[n] - sin(w0)*y[n] y[n+1] = sin(w0)*x[n] + cos(w0)*y[n] Although both coefficients are used twice, there are only two coefficients, cos(w0) and sin(w0), that are both dependent on the oscillator frequency. The above pair of real recursion equations can be independently derived from what we know from real trigonometry: cos(a+b) = cos(a)*cos(b) - sin(a)*sin(b) sin(a+b) = sin(a)*cos(b) + cos(a)*cos(b) where a = w0 and b = w0*n . It's not really independently derived because the above angle addition formulae are needed to derive the derivatives of cos(t) and sin(t) and for Euler to relate that to exp(j*t). It's all the same thing, whether expressed as real or complex. So if we start out with initial states of x[0] = cos(w0*0) = 1 y[0] = sin(w0*0) = 0 those initialized states, plus the pair of real-valued recursion equations are *almost* sufficient to make this quadrature oscillator. Unlike the simple 2nd-order resonator of section (2), there is no natural amplitude control that keeps the amplitude of this quadrature pair of sinusoids from either growing exponentially or decaying exponentially. Theoretically, the two coefficients guiding the process, cos(w0) and sin(w0), square and add to exactly 1. If, due to rounding errors, the two coefficients square and add to something slightly less than one, then the sinusoids of x[n] and y[n] will decay slowly and exponentially to zero. If the two coefficients square and add to something slightly larger than one, they quadrature sinusoids will grow slowly, but expoenentially, without any bound other than that imposed by the finite word size of their digital representation. There are two ways I know of to deal with this practical problem. The simplest solution is to round both coefficients up in magnitude so that they square and add to slightly more than 1. This would cause the quadrature sinusoids to grow slowly and that growth would be checked with saturation applied to the outputs. x[n+1] = clip{ cos(w0)*x[n] - sin(w0)*y[n] } y[n+1] = clip{ sin(w0)*x[n] + cos(w0)*y[n] } where { x if |x| <= 1 clip{ x } = { { sign(x) if |x| > 1 (Again, here the cos(w0) and sin(w0) coefficients are rounded up to less than 1 LSB larger in magnitude than the exact values.) This kind of clipping is built in to most DSPs and can be done with no additional computational cost. The other way of dealing with the amplitude control problem is formally with automatic gain control. Not only are the two coefficients supposed to square and add to 1, so also should the quadrature outputs, x[n] and y[n], square and add to 1. If they square and add to slightly more than 1, we should adjust the amplitude downward. If they square and add to slightly less than 1, then adjust the amplitude higher. The actual amplitude is the square root of the sum of the squares, and dividing by that value resets to one any amplitude that strays from a value of one. But implementing a 1/sqrt(x) function is both costly and unnecessary for this gain adjustment function. The approximation used is: 1/sqrt(u) ~= 3/2 - u/2 (for u approximately 1) Then the modified difference equations come out as: G[n] = 3/2 - ( x[n]^2 + y[n]^2 )/2 x[n+1] = G[n]*( cos(w0)*x[n] - sin(w0)*y[n] ) y[n+1] = G[n]*( sin(w0)*x[n] + cos(w0)*y[n] ) with initial states of x[0] = 1 and y[0] = 0 . Here there is no attempt to round the cos(w0) and sin(w0) coefficients upward (but it wouldn't matter much if one did). This gain adjustment insures that the quadrature output has a complex magnitude of 1 and cannot grow or decay for more than a sample in time without being corrected. ________________________________________________________________ 4. Finite order polynomial approximation to sin(x). (To be coming very soon.) -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From vadim.zavalishin at native-instruments.de Mon Jun 23 05:54:13 2008 From: vadim.zavalishin at native-instruments.de (Vadim Zavalishin) Date: Mon Jun 23 05:53:09 2008 Subject: [music-dsp] New filter design articles (zero-delay feedback etc) Message-ID: <000701c8d517$175a3110$6c02010a@NIBLN00166> Hi everyone This is my first post to the list, although I have been reading it once in a while. I probably would have been quietly reading until now, if not a desire to announce the two articles on filter design published here: http://www.native-instruments.com/index.php?id=dsparticles IMHO :-), at least the first article is covering what should be a key technique in musical digital filter (or LTI system) design, by dealing with the infamous zero-delay feedback problem. The articles have been announced in the DSP forum on kvraudio a while ago, but without much feedback. My take is that they went pretty much unnoticed. Since the primary motivation behind their release was to share those ideas with the audio development community, I'm reannouncing them on music dsp. Maybe they will have a better chance here, or maybe I'm overestimating their value anyway :-) 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 Geschaeftsfuehrer: Daniel Haver, Stephan Schmitt From andylist at vellocet.com Mon Jun 23 06:29:23 2008 From: andylist at vellocet.com (Andrew Simper) Date: Mon Jun 23 06:29:32 2008 Subject: [music-dsp] New filter design articles (zero-delay feedback etc) In-Reply-To: <000701c8d517$175a3110$6c02010a@NIBLN00166> References: <000701c8d517$175a3110$6c02010a@NIBLN00166> Message-ID: <485F7B03.2020605@vellocet.com> Wow, this looks really interesting, thanks for the post. I think most serious dsp people avoid kvr like the plague. I'm sure everyone doing any analog modeling filters will be interested in it eg: me and Antti. I'll give you full feedback once I have digested it properly. Thanks, Andrew Simper Vadim Zavalishin wrote: > Hi everyone > > This is my first post to the list, although I have been reading it > once in a while. > I probably would have been quietly reading until now, if not a desire > to announce the two articles on filter design published here: > > http://www.native-instruments.com/index.php?id=dsparticles > > IMHO :-), at least the first article is covering what should be a key > technique in musical digital filter (or LTI system) design, by dealing > with the infamous zero-delay feedback problem. > > The articles have been announced in the DSP forum on kvraudio a while > ago, but without much feedback. My take is that they went pretty much > unnoticed. Since the primary motivation behind their release was to > share those ideas with the audio development community, I'm > reannouncing them on music dsp. Maybe they will have a better chance > here, or maybe I'm overestimating their value anyway :-) > > Regards, > Vadim > From padawan12 at obiwannabe.co.uk Mon Jun 23 07:02:32 2008 From: padawan12 at obiwannabe.co.uk (Andy Farnell) Date: Mon Jun 23 07:02:36 2008 Subject: [music-dsp] New filter design articles (zero-delay feedback etc) In-Reply-To: <000701c8d517$175a3110$6c02010a@NIBLN00166> References: <000701c8d517$175a3110$6c02010a@NIBLN00166> Message-ID: <20080623120232.03c6ccbe.padawan12@obiwannabe.co.uk> Thanks for sharing these Vadim. The approach to transfer funcs seems very interesting. On Mon, 23 Jun 2008 11:54:13 +0200 "Vadim Zavalishin" wrote: > Hi everyone > > This is my first post to the list, although I have been reading it once in a > while. > I probably would have been quietly reading until now, if not a desire to > announce the two articles on filter design published here: > > http://www.native-instruments.com/index.php?id=dsparticles > > IMHO :-), at least the first article is covering what should be a key > technique in musical digital filter (or LTI system) design, by dealing with > the infamous zero-delay feedback problem. > > The articles have been announced in the DSP forum on kvraudio a while ago, > but without much feedback. My take is that they went pretty much unnoticed. > Since the primary motivation behind their release was to share those ideas > with the audio development community, I'm reannouncing them on music dsp. > Maybe they will have a better chance here, or maybe I'm overestimating their > value anyway :-) > > 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 > Geschaeftsfuehrer: Daniel Haver, Stephan Schmitt > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -- Use the source From huseyin.hacihabiboglu at kcl.ac.uk Mon Jun 23 08:46:00 2008 From: huseyin.hacihabiboglu at kcl.ac.uk (Huseyin Hacihabiboglu) Date: Mon Jun 23 08:46:46 2008 Subject: [music-dsp] PhD Studentship on Multichannel Audio at CDSPR, King's College London Message-ID: PhD Studentship in Electronic Engineering ? Audio Signal Processing Centre for Digital Signal Processing Division of Engineering King?s College London The Centre for Digital Signal Processing in the Division of Engineering, King?s College London, invites applications for PhD students to pursue research in the field of perceptual sound field reconstruction/emulation. The goal of this project is to develop a new technology for multi-channel consumer audio which would significantly improve over existing techniques in terms of realism, the accuracy and stability of the auditory perspective, the size of the sweet listening spot and the persuasiveness of the envelopment experience. Further details about the project can be found at www.kcl.ac.uk/schools/pse/diveng/research/cdspr/zor/ . This project is funded by EPSRC and includes provision for collaboration between the Centre for Digital Signal Processing at King?s College London and the Institute of Sound Recording, University of Surrey. There is one full PhD studentship available which provides for UK/EU fees and additional funding of around ?1,200 per month for living expenses for 36 months. The ideal candidate will possess an MSc in electrical engineering or another relevant area. Knowledge of advanced signal processing techniques and experience with sound field analysis and/or multi- channel audio technologies are essential for effective pursuance of the project. The studentship is available immediately. Candidates should submit a formal application for PhD studies in Electronic Engineering at King?s College London, indicating that they are applying for the EPSRC studentship in Perceptual Sound Field Reconstruction and indicating Dr Cvetkovic as their PhD advisor. An online application form can be found at http://www.kcl.ac.uk/graduate/apply/research.html . Informal enquiries about the project and studentship can be made to Dr Zoran Cvetkovic via e-mail: zoran.cvetkovic@kcl.ac.uk. From theandersoncouncil at gmail.com Wed Jun 25 16:48:11 2008 From: theandersoncouncil at gmail.com (theandersoncouncil@gmail.com) Date: Wed Jun 25 16:48:26 2008 Subject: [music-dsp] [OT] Job Posting: Senior Algorithm Developer/Algorithm Developer @ Audience, Inc. Message-ID: hi, My company, Audience, Inc., has a couple of audio DSP related positions open. (there are other jobs as well, but these are the most appropriate for this list) Senior Algorithm Developer Algorithm Developer http://www.audience.com http://www.audience.com/about_jobs.html "Audience is a voice processor company that enables clear communications anywhere with noise suppression technology based on the intelligence of the human hearing system. The technology is applicable across a broad range of consumer products where voice needs to be intelligible in noisy environments. The company launched its first commercial product into the mobile handset market in 2008. Audience is one of 34 founding member companies of the Open Handset Alliance and the only one with advanced noise suppression technology." Please contact us at jobs@audience.com. Please include the title of the job that you're applying for. We are located in Mountain View, California. Sincerely, -Brian Clark Senior DSP Software Engineer Audience, Inc. Job descriptions below: -------------------------------------------------------------------- Job Title: Senior Algorithm Developer Job Description: A self-motivated Senior Algorithm Developer, the individual would be responsible for developing audio analysis and classification algorithms for speech enhancement. Key Responsibilities: The qualified individual would develop, modify, and implement algorithms for analysis and classification of audio signal streams and computational auditory scene analysis. Key Experience: Algorithm Developer with experience developing audio stream separation or classification (discrimination) algorithms. Acoustic echo canceller (or echo canceller in general). Time-frequency representations (such as wavelet transform). Noise suppression algorithm. Human hearing model applied to speech and audio processing. Demonstrated outstanding ability to perform innovative and significant research in the form of technical papers, theses, or patents. DSP for audio and telecommunications. Experience with adaptive and statistical signal processing. Low level audio feature extraction (e.g. DCT, MFCC). Experience with audio signal processing and auditory modeling. Excellent organizational and communication skills. Strong in Matlab and C programming. Education Requirements PhD or MS in Computer Science, Electrical Engineering, or a related technical field, with strong background in fundamental mathematics. PhD with at least three years experience or MS with ten years experience -------------------------------------------------------------------- Job Title: Algorithm Developer Job Description As a self-motivated Algorithm Developer the individual will analyze and co-develop audio analysis and classification algorithms for speech enhancement with the senior team members. Responsibilities include: Supporting senior team members in developing, modifying, and implementing algorithms on different platforms (Matlab, C floating point, fixed-point and DSP) for analysis and classification of audio signal streams and computational auditory scene analysis. Key Experience Required Analysis and co-development of audio stream separation or classification (discrimination) algorithms, acoustic echo canceller (or echo canceller in general), time-frequency representations (such as wavelet transform), noise suppression algorithm and experience in Human hearing models applied to speech and audio processing. Demonstrated ability to perform algorithm modifications to include fixed-point and DSP constraints without affecting the algorithm performances Experience in optimization of audio performance using automated optimization tools. Ability to suggest improvements for this type of tools DSP for audio and telecommunications Experience in code maintenance, coding standards and version control Ability to specify unit tests and system tests to be used to guarantee the quality of the software integration Strong in Matlab and C programming PhD with at least one year of experience or MS with at least 5 years of experience Education Requirements Required MS in Computer Science, Electrical Engineering, or a related technical field, with strong background in fundamental mathematics Desired PhD in Computer Science, Electrical Engineering, or a related technical field, with strong background in fundamental mathematics Skills & Attributes Excellent organizational and communication skills