From douglas at music.columbia.edu Fri Oct 1 07:00:01 2010 From: douglas at music.columbia.edu (douglas repetto) Date: Fri, 1 Oct 2010 07:00:01 -0400 (EDT) Subject: [music-dsp] [admin] music-dsp FAQ Message-ID: <20101001110001.57D8A340E973@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 theover at tiscali.nl Fri Oct 1 09:31:17 2010 From: theover at tiscali.nl (Theo Verelst) Date: Fri, 01 Oct 2010 15:31:17 +0200 Subject: [music-dsp] measures of noisyness and transientness Message-ID: <4CA5E2A5.5070303@tiscali.nl> I guess everyone is finding out the limitations of the "magic" FFT, c.q. how hard it is to get great musical results like experts... From Victor.Lazzarini at nuim.ie Fri Oct 1 11:25:12 2010 From: Victor.Lazzarini at nuim.ie (Victor Lazzarini) Date: Fri, 01 Oct 2010 16:25:12 +0100 Subject: [music-dsp] [ANN] Linux Audio Conference 2011 Message-ID: <9BF30C5B-C283-4308-AE7E-6035CA7060A7@nuim.ie> Dear Linux Audio developer, user, composer, musician, philosopher and anyone else interested, you are invited to the... Linux Audio Conference 2011 The Open Source Music and Audio Software Conference May 6-8 2011 Music Department, National University of Ireland, Maynooth Maynooth, Co.Kildare, Ireland http://music.nuim.ie As in previous years, we will have a full programme of talks, workshops and music. Two calls will be issued, a Call for Papers (see below) and Call for Music (soon to be announced). Further information will be found in the LAC2011 website (under construction). ================ CALL FOR PAPERS ================= Papers on the following categories (but not limited to them) are now invited for submission: * Ambisonics * Education * Live performance * Audio Hardware Support * Signal Processing * Music Composition * Audio Languages * Sound Synthesis * Audio Plugins * MIDI * Music Production * Linux Kernel * Physical Computing * Interface Design * Linux Distributions * Networked Audio * Video * Games * Media Art * Licensing We very much welcome practical papers resp. software demos ("how I use Linux Audio applications to create my music/media art"). Paper length: 4-8 pages, with abstract (50-100 words) and up to 5 keywords. Language: English. The copyright of the paper remains with the author, but we reserve the right to create printed proceedings from all submitted (and accepted) papers. IMPORTANT DATES: Submission deadline: 15/January 2010 Notification of acceptance: 7/March 2010 Camera-ready papers: 1/April 2010 Queries: Victor Lazzarini, NUI Maynnooth (victor.lazzarini at nuim.ie) From Victor.Lazzarini at nuim.ie Fri Oct 1 11:51:10 2010 From: Victor.Lazzarini at nuim.ie (Victor Lazzarini) Date: Fri, 01 Oct 2010 16:51:10 +0100 Subject: [music-dsp] [ANN] Linux Audio Conference 2011 Message-ID: <8E2D9D92-FE6D-4823-A7BA-22957F40D7FD@nuim.ie> A small correction with regards to the year (2010->2011)... === Dear Linux Audio developer, user, composer, musician, philosopher and anyone else interested, you are invited to the... Linux Audio Conference 2011 The Open Source Music and Audio Software Conference May 6-8 2011 Music Department, National University of Ireland, Maynooth Maynooth, Co.Kildare, Ireland http://music.nuim.ie As in previous years, we will have a full programme of talks, workshops and music. Two calls will be issued, a Call for Papers (see below) and Call for Music (soon to be announced). Further information will be found in the LAC2011 website (under construction). ================ CALL FOR PAPERS ================= Papers on the following categories (but not limited to them) are now invited for submission: * Ambisonics * Education * Live performance * Audio Hardware Support * Signal Processing * Music Composition * Audio Languages * Sound Synthesis * Audio Plugins * MIDI * Music Production * Linux Kernel * Physical Computing * Interface Design * Linux Distributions * Networked Audio * Video * Games * Media Art * Licensing We very much welcome practical papers resp. software demos ("how I use Linux Audio applications to create my music/media art"). Paper length: 4-8 pages, with abstract (50-100 words) and up to 5 keywords. Language: English. The copyright of the paper remains with the author, but we reserve the right to create printed proceedings from all submitted (and accepted) papers. IMPORTANT DATES: Submission deadline: 15/January 2011 Notification of acceptance: 7/March 2011 Camera-ready papers: 1/April 2011 Queries: Victor Lazzarini, NUI Maynnooth (victor.lazzarini at nuim.ie) From kevin.c.dixon at gmail.com Mon Oct 4 05:05:01 2010 From: kevin.c.dixon at gmail.com (Kevin Dixon) Date: Mon, 4 Oct 2010 02:05:01 -0700 Subject: [music-dsp] Changing roll-off slope of Bi-Quad filter Message-ID: I feel like this must have been asked before, but I couldn't find it on the archives. I was wondering what sort of adjustments need to be made to support variable roll-off. After measuring the frequency response of the filters in the audio-eq-cookbook (thanks rbj!), I see they have a 6dB per octave slope. If I want to show an option to my users, for example 6, 12, 24 and maybe 32, what is the best approach to take here? Thanks! -Kevin From richarddobson at blueyonder.co.uk Mon Oct 4 06:22:44 2010 From: richarddobson at blueyonder.co.uk (Richard Dobson) Date: Mon, 04 Oct 2010 11:22:44 +0100 Subject: [music-dsp] Changing roll-off slope of Bi-Quad filter In-Reply-To: References: Message-ID: <4CA9AAF4.4070509@blueyonder.co.uk> On 04/10/2010 10:05, Kevin Dixon wrote: > I feel like this must have been asked before, but I couldn't find it > on the archives. I was wondering what sort of adjustments need to be > made to support variable roll-off. After measuring the frequency > response of the filters in the audio-eq-cookbook (thanks rbj!), I see > they have a 6dB per octave slope. If I want to show an option to my > users, for example 6, 12, 24 and maybe 32, what is the best approach > to take here? Thanks! > > -Kevin > The theoretical maximum slope for a biquad (= 2nd-order filter) is 12dB/Oct - you get 6dB per order. No free lunch - with a bandpass 2nd-order filter the maximum slope is 6dB/Oct each side of the center frequency. To get a steeper slope you need a higher-order filter - e.g. cascaded biquads - with due adjustment of cutoff frequency etc. There are standard design methods for, say, 4th-order filters, which end up with the filter being split up into two biquad sections (mainly to avoid numerical errors). For artistic audio purposes you can probably get away with just configuring a pair of rbj-style biquads in series, and "tweaking" by hand. This site give a good idea of what can be done by plugging and playing with filters: http://www.cim.mcgill.ca/~clark/nordmodularbook/nm_filters.html Note that it will take quite a bit of work to create a filter with a truly variable slope - we are stuck with the 6-12-18-24 steps most of the time. The shape of the slope of a recursive filter (as these are) is severely constrained by the maths (aka laws of physics). To get a precise bespoke shape you are more or less compelled to use a high-order non-recursive (FIR) filter (e.g. via the FFT) where (within limits...) you can "draw" the filter shape you want. Richard Dobson From padawan12 at obiwannabe.co.uk Mon Oct 4 07:32:30 2010 From: padawan12 at obiwannabe.co.uk (Andy Farnell) Date: Mon, 4 Oct 2010 12:32:30 +0100 Subject: [music-dsp] CQ CQ Message-ID: <20101004123230.d09ed418.padawan12@obiwannabe.co.uk> Any list members who are also hams (the RF kind) ?? cheers, Andy -- Andy Farnell From ebrombaugh1 at cox.net Mon Oct 4 10:20:38 2010 From: ebrombaugh1 at cox.net (Eric Brombaugh) Date: Mon, 4 Oct 2010 07:20:38 -0700 Subject: [music-dsp] CQ CQ In-Reply-To: <20101004123230.d09ed418.padawan12@obiwannabe.co.uk> References: <20101004123230.d09ed418.padawan12@obiwannabe.co.uk> Message-ID: <291FF602-FE7E-43E6-9BCC-45CD2C71A89A@cox.net> On Oct 4, 2010, at 4:32 AM, Andy Farnell wrote: > > Any list members who are also hams (the RF kind) ?? Yes, why? Eric (KC7GXA) From cm at cmorrow.com Mon Oct 4 12:13:24 2010 From: cm at cmorrow.com (Charles Morrow) Date: Mon, 4 Oct 2010 12:13:24 -0400 Subject: [music-dsp] CQ CQ In-Reply-To: <291FF602-FE7E-43E6-9BCC-45CD2C71A89A@cox.net> References: <20101004123230.d09ed418.padawan12@obiwannabe.co.uk> <291FF602-FE7E-43E6-9BCC-45CD2C71A89A@cox.net> Message-ID: K2LIS at your service, sir! 73 charlie morrow On Oct 4, 2010, at 10:20 AM, Eric Brombaugh wrote: > On Oct 4, 2010, at 4:32 AM, Andy Farnell wrote: > >> >> Any list members who are also hams (the RF kind) ?? > > Yes, why? > > Eric (KC7GXA) > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, 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 kevin.c.dixon at gmail.com Mon Oct 4 14:29:02 2010 From: kevin.c.dixon at gmail.com (Kevin Dixon) Date: Mon, 4 Oct 2010 11:29:02 -0700 Subject: [music-dsp] Changing roll-off slope of Bi-Quad filter In-Reply-To: <4CA9AAF4.4070509@blueyonder.co.uk> References: <4CA9AAF4.4070509@blueyonder.co.uk> Message-ID: Thanks for the insight. It will be pretty easy for me to chain two together, so 12dB and 24dB will have to be sufficient for my users. Thanks again, -Kevin On Mon, Oct 4, 2010 at 3:22 AM, Richard Dobson wrote: > On 04/10/2010 10:05, Kevin Dixon wrote: >> >> I feel like this must have been asked before, but I couldn't find it >> on the archives. I was wondering what sort of adjustments need to be >> made to support variable roll-off. After measuring the frequency >> response of the filters in the audio-eq-cookbook (thanks rbj!), I see >> they have a 6dB per octave slope. If I want to show an option to my >> users, for example 6, 12, 24 and maybe 32, what is the best approach >> to take here? Thanks! >> >> -Kevin >> > > The theoretical maximum slope for a biquad (= 2nd-order filter) is 12dB/Oct > - you get 6dB per order. No free lunch - with a bandpass 2nd-order filter > the maximum slope is 6dB/Oct each side of the center frequency. ?To get a > steeper slope you need ?a higher-order filter - e.g. cascaded biquads - with > due adjustment of cutoff frequency etc. There are standard design methods > for, say, 4th-order filters, which end up with the filter being split up > into two biquad sections (mainly to avoid numerical errors). For artistic > audio purposes you can probably get away with just configuring a pair of > rbj-style biquads in series, and "tweaking" by hand. > > This site give a good idea of what can be done by plugging and playing with > filters: > > http://www.cim.mcgill.ca/~clark/nordmodularbook/nm_filters.html > > Note that it will take quite a bit of work to create a filter with a truly > variable slope - we are stuck with the 6-12-18-24 steps most of the time. > The shape of the slope of a recursive filter (as these are) is severely > constrained by the maths (aka laws of physics). To get a precise bespoke > shape you are more or less compelled to use a high-order non-recursive (FIR) > filter (e.g. via the FFT) where (within limits...) you can "draw" the filter > shape you want. > > 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 Oct 4 16:59:02 2010 From: padawan12 at obiwannabe.co.uk (Andy Farnell) Date: Mon, 4 Oct 2010 21:59:02 +0100 Subject: [music-dsp] CQ CQ In-Reply-To: References: <20101004123230.d09ed418.padawan12@obiwannabe.co.uk> <291FF602-FE7E-43E6-9BCC-45CD2C71A89A@cox.net> Message-ID: <20101004215902.a7830a1a.padawan12@obiwannabe.co.uk> Good to hear from you all. Thankyou for responding chaps. I have become interested in the subject of data over audio and was sent the following as start point for research and revision of earlier methods. http://xoomer.virgilio.it/ham-radio-manuals/scanning/Digitalsignalsfaq.html At college we studied modems, DTMF, error correcting codes and suchlike, but the above document opens the door to new worlds of knowledge that might be useful and interesting to me. Or maybe not; knowing what not to chase up saves time. May I ask, does anybody know where I can get short example recordings (preferably with decodes) of some traffic in these encoding schemes? In the first place I am just curious what they sound like. The general topic of robust signals through noisy audio bands is on my mind. Back to some older comms texts. I'm okay with the encryption and ECC layers, but curious about novel transport encodings, weird modulation ideas etc, any pointers are welcome. Thanks, Andy On Mon, 4 Oct 2010 12:13:24 -0400 Charles Morrow wrote: > K2LIS at your service, sir! > > 73 > > charlie morrow > > > On Oct 4, 2010, at 10:20 AM, Eric Brombaugh wrote: > > > On Oct 4, 2010, at 4:32 AM, Andy Farnell wrote: > > > >> > >> Any list members who are also hams (the RF kind) ?? > > > > Yes, why? > > > > Eric (KC7GXA) > > > > -- > > dupswapdrop -- the music-dsp mailing list and website: > > subscription info, FAQ, 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 -- Andy Farnell From earlevel at earlevel.com Mon Oct 4 21:27:56 2010 From: earlevel at earlevel.com (Nigel Redmon) Date: Mon, 4 Oct 2010 18:27:56 -0700 Subject: [music-dsp] Changing roll-off slope of Bi-Quad filter In-Reply-To: References: Message-ID: <20C0C288-849D-4CA5-B944-F68BDE6A6DA5@earlevel.com> Hi Kevin, Quick answer off the top of my head, but... You get 6 db/oct per order for a single-corner filter (lowpass, highpass...), so 12 db/oct for a bi-quad. It you want to want to make a variable slope (that is, continuously variable and not just in 6 dB/oct increments), you'll have to spread out the poles to approximate the slope you want (there will be some ripple, dependent on the number of poles. Nigel On Oct 4, 2010, at 2:05 AM, Kevin Dixon wrote: > I feel like this must have been asked before, but I couldn't find it > on the archives. I was wondering what sort of adjustments need to be > made to support variable roll-off. After measuring the frequency > response of the filters in the audio-eq-cookbook (thanks rbj!), I see > they have a 6dB per octave slope. If I want to show an option to my > users, for example 6, 12, 24 and maybe 32, what is the best approach > to take here? Thanks! > > -Kevin From rbj at audioimagination.com Tue Oct 5 00:56:24 2010 From: rbj at audioimagination.com (robert bristow-johnson) Date: Tue, 5 Oct 2010 00:56:24 -0400 Subject: [music-dsp] CQ CQ In-Reply-To: <20101004123230.d09ed418.padawan12@obiwannabe.co.uk> References: <20101004123230.d09ed418.padawan12@obiwannabe.co.uk> Message-ID: <77A61A5C-F83D-4CF4-9863-C5581ACF70BA@audioimagination.com> long ago (in the 60s and early 70s) i was WN0CCA and then WB0CCA . i was a kid. had a Heathkit HW-100 SSB transceiver and a variety of simple wire dipoles and end-fed long wire antennae. hung out mostly at around 75 meters. -- r b-j rbj at audioimagination.com "Imagination is more important than knowledge." From padawan12 at obiwannabe.co.uk Tue Oct 5 04:59:09 2010 From: padawan12 at obiwannabe.co.uk (Andy Farnell) Date: Tue, 5 Oct 2010 09:59:09 +0100 Subject: [music-dsp] CQ CQ In-Reply-To: <77A61A5C-F83D-4CF4-9863-C5581ACF70BA@audioimagination.com> References: <20101004123230.d09ed418.padawan12@obiwannabe.co.uk> <77A61A5C-F83D-4CF4-9863-C5581ACF70BA@audioimagination.com> Message-ID: <20101005095909.6b0ed72a.padawan12@obiwannabe.co.uk> This is where it all started for me with Dobbs http://homepage.ntlworld.com/henry01/ladybird_radio/ladybird_radio.htm ... then to building a CW transmitter from a Practical Electronics or E&WW article on garage door remotes. I was 6 or 7 years old, and managed to make lots of trouble. Miraculously both worked despite having to twist connections together because I wasn't allowed a soldering iron. A few years later the first computers arrived and took over my interest, so I never progressed to getting an operators licence. a. On Tue, 5 Oct 2010 00:56:24 -0400 robert bristow-johnson wrote: > > long ago (in the 60s and early 70s) i was WN0CCA and then WB0CCA . i > was a kid. had a Heathkit HW-100 SSB transceiver and a variety of > simple wire dipoles and end-fed long wire antennae. hung out mostly > at around 75 meters. > > -- > > r b-j rbj at 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 -- Andy Farnell From jchandjr at bellsouth.net Tue Oct 5 09:24:53 2010 From: jchandjr at bellsouth.net (James Chandler Jr) Date: Tue, 5 Oct 2010 09:24:53 -0400 Subject: [music-dsp] Changing roll-off slope of Bi-Quad filter In-Reply-To: <20C0C288-849D-4CA5-B944-F68BDE6A6DA5@earlevel.com> References: <20C0C288-849D-4CA5-B944-F68BDE6A6DA5@earlevel.com> Message-ID: <6ECD3A04-928A-4AFA-9B8C-4787E9316679@bellsouth.net> Wonder if a generic pole-finding algorithm could "automatically" arrange degenerate filters for a variable slope? This reference discusses various pink noise algorithms, and starts out with summary of a couple of digital 3 dB / oct pinking filters from RBJ and Paul Kellet. http://www.firstpr.com.au/dsp/pink-noise/ I'm typically ignorant about it. In old analog appnote books there were typical cookbook circuits of 3 pole degnerate networks supposedly pretty good for 3 dB / oct. Just wondering-- If you can specify a "messed-up" IIR for 3 dB / oct, then maybe there are magic numbers for 1 dB / oct or 5 dB / oct or 11 dB / oct? Dunno if it would be worth the trouble. Only mentioning the possibility. Dunno if it would be easy to add adjustable Q on such odd networks. Dunno much. jcjr On Oct 4, 2010, at 9:27 PM, Nigel Redmon wrote: > Hi Kevin, > > Quick answer off the top of my head, but... You get 6 db/oct per order for a single-corner filter (lowpass, highpass...), so 12 db/oct for a bi-quad. It you want to want to make a variable slope (that is, continuously variable and not just in 6 dB/oct increments), you'll have to spread out the poles to approximate the slope you want (there will be some ripple, dependent on the number of poles. > > Nigel > > > On Oct 4, 2010, at 2:05 AM, Kevin Dixon wrote: >> I feel like this must have been asked before, but I couldn't find it >> on the archives. I was wondering what sort of adjustments need to be >> made to support variable roll-off. After measuring the frequency >> response of the filters in the audio-eq-cookbook (thanks rbj!), I see >> they have a 6dB per octave slope. If I want to show an option to my >> users, for example 6, 12, 24 and maybe 32, what is the best approach >> to take here? Thanks! >> >> -Kevin > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, 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 Tue Oct 5 10:04:45 2010 From: padawan12 at obiwannabe.co.uk (Andy Farnell) Date: Tue, 5 Oct 2010 15:04:45 +0100 Subject: [music-dsp] Changing roll-off slope of Bi-Quad filter In-Reply-To: <6ECD3A04-928A-4AFA-9B8C-4787E9316679@bellsouth.net> References: <20C0C288-849D-4CA5-B944-F68BDE6A6DA5@earlevel.com> <6ECD3A04-928A-4AFA-9B8C-4787E9316679@bellsouth.net> Message-ID: <20101005150445.ec105a18.padawan12@obiwannabe.co.uk> On Tue, 5 Oct 2010 09:24:53 -0400 James Chandler Jr wrote: > Dunno if it would be worth the trouble. Only mentioning the possibility. On the face of it there doesn't seem to be much need in music or other DSP domains. Does anyone see a case I'm missing? But it's something I've often wondered about because there is one rather specific need that comes up in virtual world modelling/procedural audio. It's the case of a distancing filter for propagation loss. As more and more imperfect medium lies between source and listener, it's the slope rather than the cutoff frequency that continuously changes. For static sources it's easliy computed to the nearest 3dB and a filter with the suitable number of stages created. For moving sources something else seems necessary. However, I can think of few sources other than jet planes and racing cars that travel fast and are loud enough to need this. -- Andy Farnell From david.lowenfels at gmail.com Tue Oct 5 11:51:00 2010 From: david.lowenfels at gmail.com (david.lowenfels at gmail.com) Date: Tue, 5 Oct 2010 08:51:00 -0700 Subject: [music-dsp] Changing roll-off slope of Bi-Quad filter In-Reply-To: <20C0C288-849D-4CA5-B944-F68BDE6A6DA5@earlevel.com> References: <20C0C288-849D-4CA5-B944-F68BDE6A6DA5@earlevel.com> Message-ID: <24907196-FB2E-40EF-97F5-2DB8A4D3BF8A@gmail.com> What about crossfading between two filters in serial, with the same cutoff (or perhaps an octave apart for taste)? Intuitively it makes sense to me, but perhaps someone can double check it mathematically or with a spectrum analyzer?) -> 6db/oct -> 12db/oct | | \ / + v 9db/oct ? -> 12db/oct -> 12db/oct | | \ / + v 18db/oct ? -David On Oct 4, 2010, at 6:27 PM, Nigel Redmon wrote: > Hi Kevin, > > Quick answer off the top of my head, but... You get 6 db/oct per order for a single-corner filter (lowpass, highpass...), so 12 db/oct for a bi-quad. It you want to want to make a variable slope (that is, continuously variable and not just in 6 dB/oct increments), you'll have to spread out the poles to approximate the slope you want (there will be some ripple, dependent on the number of poles. > > Nigel > > > On Oct 4, 2010, at 2:05 AM, Kevin Dixon wrote: >> I feel like this must have been asked before, but I couldn't find it >> on the archives. I was wondering what sort of adjustments need to be >> made to support variable roll-off. After measuring the frequency >> response of the filters in the audio-eq-cookbook (thanks rbj!), I see >> they have a 6dB per octave slope. If I want to show an option to my >> users, for example 6, 12, 24 and maybe 32, what is the best approach >> to take here? Thanks! >> >> -Kevin > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, 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 at olofson.net Tue Oct 5 12:31:38 2010 From: david at olofson.net (David Olofson) Date: Tue, 5 Oct 2010 18:31:38 +0200 Subject: [music-dsp] Changing roll-off slope of Bi-Quad filter In-Reply-To: <24907196-FB2E-40EF-97F5-2DB8A4D3BF8A@gmail.com> References: <20C0C288-849D-4CA5-B944-F68BDE6A6DA5@earlevel.com> <24907196-FB2E-40EF-97F5-2DB8A4D3BF8A@gmail.com> Message-ID: <201010051831.38682.david@olofson.net> On Tuesday 05 October 2010, at 17.51.00, david.lowenfels at gmail.com wrote: > What about crossfading between two filters in serial, with the same cutoff > (or perhaps an octave apart for taste)? [...] It "sort of" works, but not in the way you intend, I suspect. What you get is really just the effect of crossfading between two different filters; not the smooth "morph" one would desire. The method is useful in some situations though; I've used it for noise reduction in lab instruments - but that differs a bit from audio processing in terms of requirements and viable shortcuts. -- //David Olofson - Developer, Artist, Open Source Advocate .--- Games, examples, libraries, scripting, sound, music, graphics ---. | http://olofson.net http://kobodeluxe.com http://audiality.org | | http://eel.olofson.net http://zeespace.net http://reologica.se | '---------------------------------------------------------------------' From decoy at iki.fi Tue Oct 5 15:46:01 2010 From: decoy at iki.fi (Sampo Syreeni) Date: Tue, 5 Oct 2010 22:46:01 +0300 (EEST) Subject: [music-dsp] CQ CQ In-Reply-To: <77A61A5C-F83D-4CF4-9863-C5581ACF70BA@audioimagination.com> References: <20101004123230.d09ed418.padawan12@obiwannabe.co.uk> <77A61A5C-F83D-4CF4-9863-C5581ACF70BA@audioimagination.com> Message-ID: On 2010-10-05, robert bristow-johnson wrote: > long ago (in the 60s and early 70s) i was WN0CCA and then WB0CCA . i > was a kid. had a Heathkit HW-100 SSB transceiver and a variety of > simple wire dipoles and end-fed long wire antennae. hung out mostly at > around 75 meters. Hmm. Have you ever applied your DSP knowledge to the design of new digital modes? I mean, in one of our local libertarian meets a few months back I encountered somebody who was relatively knowledgeable about both DSP and radio amateur procedures, yet he totally failed to understand even the basics of the most efficient digital modulation methods of today, like GMSK, especially Trellis coding (as separate from vanilla Viterbi decoding), parallel transform based encodings like OFDM, and much like. In addition it seems few of these advanced modulation methods are being used on amateur bands. Why do you think this is the case? To me it's a complete mystery, because we do have completely free (*even* as in beer) software radio available, both in software and in hardware, via GNU. How on earth is it possible that the amateur digital modes lag so far behind the rest of the industry? As an audio band application, then, I'd really like to build a fully optimized, automated Morse transit. I mean, something which used the international version of morse code in a way which drove the channel to its full capacity given that code, while at the same time being *extraordinarily* close to a rectangular channel as far as frequency goes. That'd obviously call for some heavy duty software radio techniques, involving audio-band DSP, so I *really* wonder why nobody's done that yet. Even on-list. ;) -- Sampo Syreeni, aka decoy - decoy at iki.fi, http://decoy.iki.fi/front +358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 From gmaxwell at gmail.com Tue Oct 5 16:01:53 2010 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Tue, 5 Oct 2010 16:01:53 -0400 Subject: [music-dsp] CQ CQ In-Reply-To: References: <20101004123230.d09ed418.padawan12@obiwannabe.co.uk> <77A61A5C-F83D-4CF4-9863-C5581ACF70BA@audioimagination.com> Message-ID: On Tue, Oct 5, 2010 at 3:46 PM, Sampo Syreeni wrote: > Hmm. Have you ever applied your DSP knowledge to the design of new digital > modes? I mean, in one of our local libertarian meets a few months back I > encountered somebody who was relatively knowledgeable about both DSP and > radio amateur procedures, yet he totally failed to understand even the > basics of the most efficient digital modulation methods of today, like GMSK, > especially Trellis coding (as separate from vanilla Viterbi decoding), > parallel transform based encodings like OFDM, and much like. In addition it > seems few of these advanced modulation methods are being used on amateur > bands. > > Why do you think this is the case? To me it's a complete mystery, because we > do have completely free (*even* as in beer) software radio available, both > in software and in hardware, via GNU. How on earth is it possible that the > amateur digital modes lag so far behind the rest of the industry? [snip] You can't (easily) build it with analog passives, can't buy it in a shiny black box from ICOM... is equal to invisible to many hams in the US. Folks who don't think that way may find http://codec2.org/ interesting. For my own part I've done some interesting stuff with encoded digital audio: http://git.xiph.org/?p=users/greg/gnuradio.git;a=summary though nothing with interesting modulations other than GMSK (GNURadio has pre-existing modules for a lot of things though) > As an audio band application, then, I'd really like to build a fully > optimized, automated Morse transit. I mean, something which used the > international version of morse code in a way which drove the channel to its > full capacity given that code, while at the same time being > *extraordinarily* close to a rectangular channel as far as frequency goes. > That'd obviously call for some heavy duty software radio techniques, > involving audio-band DSP, so I *really* wonder why nobody's done that yet. > Even on-list. ;) Sounds very cool. Though it might also be interesting to evaluate other self-clocking on-off-keying modulation schemes and channel coding schemes to push even more capacity out of the bandlimited on-off keyed channel. Greg Maxwell (NT4TN) From decoy at iki.fi Tue Oct 5 16:22:30 2010 From: decoy at iki.fi (Sampo Syreeni) Date: Tue, 5 Oct 2010 23:22:30 +0300 (EEST) Subject: [music-dsp] Changing roll-off slope of Bi-Quad filter In-Reply-To: <20101005150445.ec105a18.padawan12@obiwannabe.co.uk> References: <20C0C288-849D-4CA5-B944-F68BDE6A6DA5@earlevel.com> <6ECD3A04-928A-4AFA-9B8C-4787E9316679@bellsouth.net> <20101005150445.ec105a18.padawan12@obiwannabe.co.uk> Message-ID: On 2010-10-05, Andy Farnell wrote: > But it's something I've often wondered about because there is one > rather specific need that comes up in virtual world > modelling/procedural audio. Yes. I don't have any reference to show for this, but I seem to remember typical rolloff curves of discrete sources tend to be psychoacoustically factored out, as far as source separation and the following analyses go. I believe this has something to do with the mechanism which evens out notches in the overall frequency response within a reverberant space as well. In case nobody yet answered directly, the asymptotic response curve of any given LTI filter cannot be altered in average, over the whole of its respose range. In general a second order filter designed as a lowpass one will show typical to second order rolloff. This response can be modified by extending the so called "passband", but that sort of thing will come at the expense of ripples within the passband, and it will never change the asymptotic behavior of the slope. The best that could be done there with single-rate filter topologies is to extend the so called "passband" outwards long enough to control the slope over all of audible frequencies, and letting it go to its natural asymptote outside of the audible range. If other slopes are needed, like for an accurate 1/f (pink noise) filter, that would lead to oversampling in one or more forms. In the case of a fixed slope curve, the code could be optimized pretty well since standard, highly efficient rational approximation methods based on e.g. Bade approximation are readily available. But continuous control of the slope within an efficient filter would still necessitate an approximation relying upon nonlinear interpolation between fixed coefficients of some basic LTI topology. That then always means you have to worry about computational cost, and about the dynamic stability of the filter. > For moving sources something else seems necessary. That is a whole other ballgame. Usually we model moving sources via ray-acoustic Doppler effects alone, and then perhaps add a bit of time variant filtering to account for distance attenuation. Most models apply a first or second order filter to account for the distance, independently of the delay. So if you really wanted to do this just right, you'd need three separate and tightly coupled corrections to the model: 1) delay and spectral decay should in fact be coupled, 2) the spectral decay should be of infinite order, to account for the typical 1/f decay, above what second and first order filters can do, and 3) at least at the close range you should model binaural effects, instead of just distance and spectral decay. -- Sampo Syreeni, aka decoy - decoy at iki.fi, http://decoy.iki.fi/front +358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 From earlevel at earlevel.com Tue Oct 5 19:38:12 2010 From: earlevel at earlevel.com (Nigel Redmon) Date: Tue, 5 Oct 2010 16:38:12 -0700 Subject: [music-dsp] Changing roll-off slope of Bi-Quad filter In-Reply-To: <6ECD3A04-928A-4AFA-9B8C-4787E9316679@bellsouth.net> References: <20C0C288-849D-4CA5-B944-F68BDE6A6DA5@earlevel.com> <6ECD3A04-928A-4AFA-9B8C-4787E9316679@bellsouth.net> Message-ID: Hi Jim, I think the problem becomes a lot easier if you can live with a slope that is variable from first order through how ever made orders you want to support (that is, probably something like first through sixth). Starting with the obvious, if you had six first order lowpass sections in series for a sixth-order response and move the cutoff frequency of the last five sections up, you'd move to a first-order lowpass response. It's been a long time since I looked at it, but Electronotes had a variable slope filter design back in the mid- 70's. IIRC, it slid first-order sections out to higher frequencies as a spread to decrease the slope. I'm guessing that they didn't mess with Q. Nigel On Oct 5, 2010, at 6:24 AM, James Chandler Jr wrote: > Wonder if a generic pole-finding algorithm could "automatically" arrange degenerate filters for a variable slope? > > This reference discusses various pink noise algorithms, and starts out with summary of a couple of digital 3 dB / oct pinking filters from RBJ and Paul Kellet. > > http://www.firstpr.com.au/dsp/pink-noise/ > > I'm typically ignorant about it. In old analog appnote books there were typical cookbook circuits of 3 pole degnerate networks supposedly pretty good for 3 dB / oct. > > Just wondering-- If you can specify a "messed-up" IIR for 3 dB / oct, then maybe there are magic numbers for 1 dB / oct or 5 dB / oct or 11 dB / oct? > > Dunno if it would be worth the trouble. Only mentioning the possibility. > > Dunno if it would be easy to add adjustable Q on such odd networks. Dunno much. > > jcjr > > On Oct 4, 2010, at 9:27 PM, Nigel Redmon wrote: > >> Hi Kevin, >> >> Quick answer off the top of my head, but... You get 6 db/oct per order for a single-corner filter (lowpass, highpass...), so 12 db/oct for a bi-quad. It you want to want to make a variable slope (that is, continuously variable and not just in 6 dB/oct increments), you'll have to spread out the poles to approximate the slope you want (there will be some ripple, dependent on the number of poles. >> >> Nigel >> >> >> On Oct 4, 2010, at 2:05 AM, Kevin Dixon wrote: >>> I feel like this must have been asked before, but I couldn't find it >>> on the archives. I was wondering what sort of adjustments need to be >>> made to support variable roll-off. After measuring the frequency >>> response of the filters in the audio-eq-cookbook (thanks rbj!), I see >>> they have a 6dB per octave slope. If I want to show an option to my >>> users, for example 6, 12, 24 and maybe 32, what is the best approach >>> to take here? Thanks! >>> >>> -Kevin >> >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, 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 rrsounds at aol.com Wed Oct 6 01:22:43 2010 From: rrsounds at aol.com (David Reaves) Date: Wed, 6 Oct 2010 07:22:43 +0200 Subject: [music-dsp] Changing roll-off slope of Bi-Quad filter In-Reply-To: References: Message-ID: <3DE22789-F620-44BD-9266-6EACD22133FC@aol.com> It's worth noting that in first-order filters, there is no Q adjustment available. David Reaves On Tue, 5 Oct 2010 16:38:12 -0700, Nigel Redmon wrote: > > > It's been a long time since I looked at it, but Electronotes had a variable slope filter design back in the mid- 70's. IIRC, it slid first-order sections out to higher frequencies as a spread to decrease the slope. I'm guessing that they didn't mess with Q. > > Nigel From earlevel at earlevel.com Wed Oct 6 14:53:01 2010 From: earlevel at earlevel.com (Nigel Redmon) Date: Wed, 6 Oct 2010 11:53:01 -0700 Subject: [music-dsp] Changing roll-off slope of Bi-Quad filter In-Reply-To: <3DE22789-F620-44BD-9266-6EACD22133FC@aol.com> References: <3DE22789-F620-44BD-9266-6EACD22133FC@aol.com> Message-ID: <5A3178BE-59B6-473D-B5A9-548B9ED5D243@earlevel.com> True, though you can still get synth-friendly resonance with a feedback of the whole system (as is done in the Moog ladder approximations), as long as the poles are in the same place. In the case of a variable slope based on single pole filters, there's not an obvious way to do it (maybe with the help of allpass filters, something get a nice phase difference at the "corner" for feedback?). The easy way would be to accept 12 dB/oct as your minimum slope and have the first section be second order. I don't know about the variable-slope filters in use on modular analog gear, but my guess is that people use a conventional filter when they want resonance, and the variable-slope filter when they want variable slope. You could always use the two in parallel, but you may have phase issues (again, maybe fixed via allpass). On Oct 5, 2010, at 10:22 PM, David Reaves wrote: > It's worth noting that in first-order filters, there is no Q adjustment available. From theover at tiscali.nl Wed Oct 6 15:37:30 2010 From: theover at tiscali.nl (Theo Verelst) Date: Wed, 06 Oct 2010 21:37:30 +0200 Subject: [music-dsp] CQ CQ Message-ID: <4CACCFFA.7050104@tiscali.nl> In the late 70s I?d built my own tiny 3 meter FM transmitter, and made bidirectional links with that, that was fun. I could improve the hifi of the radio transmissions considerably by using a analog feedback using a receiver, maybe that could prove interesting for certain digital codings... I suppose the OP means a ham with licence, I studied it a bit (I?m EE) and practiced the letter-names but didn?t get a licence... Of course modem technology is very complicated and theoretically subject of serious EE (univ. in my case) education. I?ve run some of the GnuRadio software which is interesting but of course software, especially when it uses things like FFT will behave different than radio hardware. I mean, I?d find it interesting to know wether a software based receiver could do the same a a good before WOII setup! The Gnu Radio Hardware kit is a touch expensive (as it is for me at the moment), and unfortately the Xilinx FPGA program, containing important parts of the transmitter/receiver dsp reuires more software from Xilinx than the free webpack to instantiate a microblaze processor. I communicated a bit with the guy who makes a block editor for the GR (I did such an idea a long time ago, too) last time I looked he had some stuff working to be useful, on itself an interesting project, using a gigaether connection with e.g. a Linux computer (Fedora runs the sr fine, I tried). Theo Verelst From stefan at space.twc.de Thu Oct 7 07:39:51 2010 From: stefan at space.twc.de (Stefan Westerfeld) Date: Thu, 7 Oct 2010 13:39:51 +0200 Subject: [music-dsp] Sythesizing sines + noise in one IFFT Message-ID: <20101007113951.GA9349@space.twc.de> Hi! I've been performance optimizing the SpectMorph LiveDecoder in the last few weeks (http://space.twc.de/~stefan/spectmorph.php). What I need to do is synthesizing 1024 sample frames which consist of a number of sine waves (typically 100 or more) and a noise spectrum (specified as noise energy in 32 perceptual noise bands). For the sine waves, I construct a spectrum using a blackman harris 92 dB window, which has the advantage that one sine wave only affects 9 spectrum bins (the main lobe of the window); then an inverse FFT (IFFT) produces the desired sine waves. However since the sum of the blackman harris window in the time domain is not 1 when overlap adding the results, I need to rescale the time signal (by the division of cosine window and blackman harris window). The second component, the noise, is produced by randomizing the phases of a spectrum and scaling the 32 bands of the spectrum with the desired energy, and performing IFFT again. Then a time domain window can make this suitable for overlap adding. Profiling tells me that I am spending 40% of all CPU time doing the IFFTs. I need two IFFTs per frame (times 2 for overlap add), since the sine waves need a different post-processing than the noise. I suppose it would be possible to combine those if I convolute the noise spectrum with the blackman harris window transform, but then the convolution would probably take so much CPU usage that the gain of saving one IFFT would be irrelevant. Is there a cheaper way to combine those two IFFTs, so that noise and sines could be synthesized in one IFFT? Cu... Stefan -- Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan From noama at post.tau.ac.il Thu Oct 7 08:09:54 2010 From: noama at post.tau.ac.il (Noam Amir) Date: Thu, 7 Oct 2010 14:09:54 +0200 (Jerusalem Standard Time) Subject: [music-dsp] audibility of phase shifts to higher harmonics Message-ID: hi all, as a long timer lurker, i have a distinct recollection of some posts on the above subject: suppose we synthesize a purely periodic signal and mess with the phase of one or more of the harmonics - is this audible or not? i'd be grateful if anyone can come up with one of those old posts, or any insight into this subject. thanks! noam. From didid at skynet.be Thu Oct 7 08:38:19 2010 From: didid at skynet.be (Didier Dambrin) Date: Thu, 7 Oct 2010 14:38:19 +0200 Subject: [music-dsp] audibility of phase shifts to higher harmonics In-Reply-To: References: Message-ID: <1AB87EFE98824A8BB6B8FAE2AD10D371@GOLAMD> I was in that discussion & I remember I posted demo files (yes it's audible), searching for my name should help. > hi all, > > as a long timer lurker, i have a distinct recollection of some posts on > the above subject: suppose we synthesize a purely periodic signal and mess > with the phase of one or more of the harmonics - is this audible or not? > > i'd be grateful if anyone can come up with one of those old posts, or any > insight into this subject. > > thanks! > noam. > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, 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 gwenhwyfaer at gmail.com Thu Oct 7 09:26:44 2010 From: gwenhwyfaer at gmail.com (Gwenhwyfaer) Date: Thu, 7 Oct 2010 14:26:44 +0100 Subject: [music-dsp] audibility of phase shifts to higher harmonics In-Reply-To: <1AB87EFE98824A8BB6B8FAE2AD10D371@GOLAMD> References: <1AB87EFE98824A8BB6B8FAE2AD10D371@GOLAMD> Message-ID: On 07/10/2010, Didier Dambrin wrote: > I was in that discussion & I remember I posted demo files (yes it's > audible), searching for my name should help. The thread in question is called "A little question about DSP performance", and it spanned from 26 September to 4 October 2009. I posted some source and some results (http://www.isle-of-avalon.co.uk/sawphase.zip) but I couldn't replicate Didier's results, which made me think something else was going on with Didier's demos that he hadn't allowed for (maybe some hidden non-linearity?) From noama at post.tau.ac.il Thu Oct 7 09:51:03 2010 From: noama at post.tau.ac.il (Noam Amir) Date: Thu, 7 Oct 2010 15:51:03 +0200 (Jerusalem Standard Time) Subject: [music-dsp] Phase sensitivity again Message-ID: hi guys, thanks for your reponses. in the meantime i dug up a paper by Moore, defining the Difference Limen Phase, which looks quite interesting. Didier: i searched the archives... found a lot of your posts, but not the right one :-( . any chance you could repost the demo files? thanks, noam. From didid at skynet.be Thu Oct 7 09:53:19 2010 From: didid at skynet.be (Didier Dambrin) Date: Thu, 7 Oct 2010 15:53:19 +0200 Subject: [music-dsp] audibility of phase shifts to higher harmonics In-Reply-To: References: <1AB87EFE98824A8BB6B8FAE2AD10D371@GOLAMD> Message-ID: Checking, your raw audio files seem to replicate what was in my wav, a huge difference between aligned & random phases in a sawtooth. But there was another part of the discussion where we showed how one single harmonic in an aligned saw was audible if its phase was shifted. Since the old discussion I finished my additive synth and started a new one, they both make use of the importance of initial phases. > On 07/10/2010, Didier Dambrin wrote: >> I was in that discussion & I remember I posted demo files (yes it's >> audible), searching for my name should help. > > The thread in question is called "A little question about DSP > performance", and it spanned from 26 September to 4 October 2009. I > posted some source and some results > (http://www.isle-of-avalon.co.uk/sawphase.zip) but I couldn't > replicate Didier's results, which made me think something else was > going on with Didier's demos that he hadn't allowed for (maybe some > hidden non-linearity?) > -- From gsn10 at hotmail.com Thu Oct 7 10:05:48 2010 From: gsn10 at hotmail.com (Scott Nordlund) Date: Thu, 7 Oct 2010 10:05:48 -0400 Subject: [music-dsp] audibility of phase shifts to higher harmonics In-Reply-To: References: Message-ID: > The thread in question is called "A little question about DSP > performance", and it spanned from 26 September to 4 October 2009. I > posted some source and some results > (http://www.isle-of-avalon.co.uk/sawphase.zip) but I couldn't > replicate Didier's results, which made me think something else was > going on with Didier's demos that he hadn't allowed for (maybe some > hidden non-linearity?) I think I can confirm Didier's findings.? I did something completely unrelated that involved chaining large numbers of first order allpass phase shift filters.? The frequency response is demonstrably flat (I was not mixing in the dry signal to obtain a notched response, as you'd expect in a phaser effect) but there is a notable difference in sound, even on steady state tones that have no components outside of the audible spectrum. I think Didier was focusing on a discontinuous phase shift between harmonics, where this was a continuous but extreme phase shift, with similarly audible effect. From didid at skynet.be Thu Oct 7 10:08:00 2010 From: didid at skynet.be (Didier Dambrin) Date: Thu, 7 Oct 2010 16:08:00 +0200 Subject: [music-dsp] Phase sensitivity again In-Reply-To: References: Message-ID: there was this one, first is normal saw, I think the second was the same with the all phases slowly shifted (neighbor harmonic phases still close enough from each other), and the third shows the 22th (or something, quickly checked in a spectrogram) harmonic with its phase shifted, making it stand out. http://forum.image-line.com//files/saw_harmdephasing_163.wav > hi guys, > > thanks for your reponses. in the meantime i dug up a paper by Moore, > defining the Difference Limen Phase, which looks quite interesting. > > Didier: i searched the archives... found a lot of your posts, but not the > right one :-( . any chance you could repost the demo files? > > thanks, > noam. > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From didid at skynet.be Thu Oct 7 10:20:45 2010 From: didid at skynet.be (Didier Dambrin) Date: Thu, 7 Oct 2010 16:20:45 +0200 Subject: [music-dsp] audibility of phase shifts to higher harmonics In-Reply-To: References: Message-ID: <757756BCB88E4D36A92CDF1A27AB2DB7@GOLAMD> Note that I can also hear a slight difference between a saw and an inverted saw through my headphones (HD650), but I would attribute this to the headphones or some non-linearity somewhere, as it's not very logical. But the very audible harmonic isn't weird, and we all know how important the relative phases are, not really for the legibility but for the quality of the sound. I mean if you randomize all the phases of a signal, it's really different. If you slowly shift the phases so that from bottom to top you have a 180deg shift, but only a slight shift between neighbor harmonics, it won't be very audible. So if you only shift one harmonic by a large amount, it's normal that it stands out. I think it stops being noticable outside some window linear in Hz, for example you can randomize the phases of a high-pitched saw, it won't be very audible, because the harmonics are so much apart. Now do the same for a low clicky saw, it's totally different. >Subject: Re: [music-dsp] audibility of phase shifts to higher harmonics > The thread in question is called "A little question about DSP > performance", and it spanned from 26 September to 4 October 2009. I > posted some source and some results > (http://www.isle-of-avalon.co.uk/sawphase.zip) but I couldn't > replicate Didier's results, which made me think something else was > going on with Didier's demos that he hadn't allowed for (maybe some > hidden non-linearity?) I think I can confirm Didier's findings. I did something completely unrelated that involved chaining large numbers of first order allpass phase shift filters. The frequency response is demonstrably flat (I was not mixing in the dry signal to obtain a notched response, as you'd expect in a phaser effect) but there is a notable difference in sound, even on steady state tones that have no components outside of the audible spectrum. I think Didier was focusing on a discontinuous phase shift between harmonics, where this was a continuous but extreme phase shift, with similarly audible effect. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.862 / Virus Database: 271.1.1/3181 - Release Date: 10/06/10 20:34:00 From jchandjr at bellsouth.net Thu Oct 7 10:57:28 2010 From: jchandjr at bellsouth.net (James Chandler Jr) Date: Thu, 7 Oct 2010 10:57:28 -0400 Subject: [music-dsp] audibility of phase shifts to higher harmonics In-Reply-To: <757756BCB88E4D36A92CDF1A27AB2DB7@GOLAMD> References: <757756BCB88E4D36A92CDF1A27AB2DB7@GOLAMD> Message-ID: <592E635E-94C0-4215-BB7B-E70DE3F1A803@bellsouth.net> Scrambling harmonics could change the crest factor? I was messing with allpass filters some years ago and it seemed that simple geometric waves such as a saw, appeared to be the 'most compact' form of that collection of harmonics. I can't make a mathematical proof and maybe it isn't the most compact representation, though cases I tested of shifted harmonics (on geometric waves) always resulted in 'less compact' waves with a higher peak-to-peak amplitude. I may have done something wrong or made the wrong conclusion. If that is an accurate observation, dunno if a change in crest factor would be audible, unless nonlinearities in the playback system or ear result in audible distortion somewhere along the way? Perhaps the same RMS and harmonic content, but with a higher crest factor, could be an audible difference in itself? I don't know. Feeding a higher crest factor into a naturally-distorting, limited-headroom analog voltage controlled filter or analog voltage controlled amplifier could obviously make a difference, because the higher crest factor would cause more distortion in the filter or amp. Maybe there are other explanations if shifted harmonics are audible. Am only mentioning crest factor as a possiblity. James Chandler Jr. On Oct 7, 2010, at 10:20 AM, Didier Dambrin wrote: > Note that I can also hear a slight difference between a saw and an inverted saw through my headphones (HD650), but I would attribute this to the headphones or some non-linearity somewhere, as it's not very logical. > > But the very audible harmonic isn't weird, and we all know how important the relative phases are, not really for the legibility but for the quality of the sound. > I mean if you randomize all the phases of a signal, it's really different. If you slowly shift the phases so that from bottom to top you have a 180deg shift, but only a slight shift between neighbor harmonics, it won't be very audible. So if you only shift one harmonic by a large amount, it's normal that it stands out. I think it stops being noticable outside some window linear in Hz, for example you can randomize the phases of a high-pitched saw, it won't be very audible, because the harmonics are so much apart. Now do the same for a low clicky saw, it's totally different. > > > > > >> Subject: Re: [music-dsp] audibility of phase shifts to higher harmonics > > >> The thread in question is called "A little question about DSP >> performance", and it spanned from 26 September to 4 October 2009. I >> posted some source and some results >> (http://www.isle-of-avalon.co.uk/sawphase.zip) but I couldn't >> replicate Didier's results, which made me think something else was >> going on with Didier's demos that he hadn't allowed for (maybe some >> hidden non-linearity?) > > I think I can confirm Didier's findings. I did something completely > unrelated that involved chaining large numbers of first order allpass > phase shift filters. The frequency response is demonstrably flat (I > was not mixing in the dry signal to obtain a notched response, as > you'd expect in a phaser effect) but there is a notable difference in > sound, even on steady state tones that have no components outside of > the audible spectrum. > > I think Didier was focusing on a discontinuous phase shift between > harmonics, where this was a continuous but extreme phase shift, with > similarly audible effect. > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > > > -------------------------------------------------------------------------------- > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.862 / Virus Database: 271.1.1/3181 - Release Date: 10/06/10 20:34:00 > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From didid at skynet.be Thu Oct 7 11:10:55 2010 From: didid at skynet.be (Didier Dambrin) Date: Thu, 7 Oct 2010 17:10:55 +0200 Subject: [music-dsp] audibility of phase shifts to higher harmonics In-Reply-To: <592E635E-94C0-4215-BB7B-E70DE3F1A803@bellsouth.net> References: <757756BCB88E4D36A92CDF1A27AB2DB7@GOLAMD> <592E635E-94C0-4215-BB7B-E70DE3F1A803@bellsouth.net> Message-ID: > Scrambling harmonics could change the crest factor? I was messing with > allpass filters some years ago and it seemed that simple geometric waves > such as a saw, >appeared to be the 'most compact' form of that collection > of harmonics. I can't make a mathematical proof and maybe it isn't the > most compact representation, >though cases I tested of shifted harmonics > (on geometric waves) always resulted in 'less compact' waves with a higher > peak-to-peak amplitude. true for saw & pulse, but not triangle I believe > I may have done something wrong or made the wrong conclusion. > > If that is an accurate observation, dunno if a change in crest factor > would be audible, unless nonlinearities in the playback system or ear > result in audible distortion somewhere along the way? > > Perhaps the same RMS and harmonic content, but with a higher crest factor, > could be an audible difference in itself? I don't know. > > Feeding a higher crest factor into a naturally-distorting, > limited-headroom analog voltage controlled filter or analog voltage > controlled amplifier could obviously make a difference, because the higher > crest factor would cause more distortion in the filter or amp. > but would the difference be -so- obvious to the ear? And wouldn't it fade out by adapting the level after messing with the phases? And as I wrote, it stops mattering if the neighbor harmonics are too far from each other, it's only when they're close enough. From mike at psychonic.net Thu Oct 7 11:15:35 2010 From: mike at psychonic.net (Mike) Date: Thu, 07 Oct 2010 11:15:35 -0400 Subject: [music-dsp] audibility of phase shifts to higher harmonics In-Reply-To: References: Message-ID: <4CADE417.9020808@psychonic.net> Regarding this phenomenon, one important non-linearity "somewhere" is the cochlea itself. The hair cells only "transmit" for displacements in one direction, essentially doing a half-wave rectification. So it's easy to imagine how changing the phase and even the polarity could sound different. -Mike Shonle > Note that I can also hear a slight difference between a saw and an inverted > saw through my headphones (HD650), but I would attribute this to the > headphones or some non-linearity somewhere, as it's not very logical. From jdb at jboley.com Thu Oct 7 11:31:20 2010 From: jdb at jboley.com (Jon Boley) Date: Thu, 7 Oct 2010 11:31:20 -0400 Subject: [music-dsp] audibility of phase shifts to higher harmonics In-Reply-To: <592E635E-94C0-4215-BB7B-E70DE3F1A803@bellsouth.net> References: <757756BCB88E4D36A92CDF1A27AB2DB7@GOLAMD> <592E635E-94C0-4215-BB7B-E70DE3F1A803@bellsouth.net> Message-ID: When trying to understand the perception, it's helpful to realize that we are essentially listening through lots of bandpass filters. If the phase affects the waveform at the output of one of the filters, the result is probably going to be audible. This is why slowly changing the phase as a function of frequency is not audible, but abruptly changing the phase at one specific frequency can certainly be audible. Also, the narrower your auditory filters (i.e., at low SPLs with healthy outer hair cells in the cochlea), the more likely such an abrupt change is to affect the waveform getting sent to your brain... So it depends on level (aka, nonlinearity) and not everyone is equally susceptible to hearing these phase effects. (Though I think any processing should be designed for those with the best hearing at a range of reasonable levels.) - Jon On Thu, Oct 7, 2010 at 10:57 AM, James Chandler Jr wrote: > Scrambling harmonics could change the crest factor? I was messing with allpass filters some years ago and it seemed that simple geometric waves such as a saw, appeared to be the 'most compact' form of that collection of harmonics. I can't make a mathematical proof and maybe it isn't the most compact representation, though cases I tested of shifted harmonics (on geometric waves) always resulted in 'less compact' waves with a higher peak-to-peak amplitude. > > I may have done something wrong or made the wrong conclusion. > > If that is an accurate observation, dunno if a change in crest factor would be audible, unless nonlinearities in the playback system or ear result in audible distortion somewhere along the way? > > Perhaps the same RMS and harmonic content, but with a higher crest factor, could be an audible difference in itself? I don't know. > > Feeding a higher crest factor into a naturally-distorting, limited-headroom analog voltage controlled filter or analog voltage controlled amplifier could obviously make a difference, because the higher crest factor would cause more distortion in the filter or amp. > > Maybe there are other explanations if shifted harmonics are audible. Am only mentioning crest factor as a possiblity. > > James Chandler Jr. > > On Oct 7, 2010, at 10:20 AM, Didier Dambrin wrote: > >> Note that I can also hear a slight difference between a saw and an inverted saw through my headphones (HD650), but I would attribute this to the headphones or some non-linearity somewhere, as it's not very logical. >> >> But the very audible harmonic isn't weird, and we all know how important the relative phases are, not really for the legibility but for the quality of the sound. >> I mean if you randomize all the phases of a signal, it's really different. If you slowly shift the phases so that from bottom to top you have a 180deg shift, but only a slight shift between neighbor harmonics, it won't be very audible. So if you only shift one harmonic by a large amount, it's normal that it stands out. I think it stops being noticable outside some window linear in Hz, for example you can randomize the phases of a high-pitched saw, it won't be very audible, because the harmonics are so much apart. Now do the same for a low clicky saw, it's totally different. >> >> >> >> >> >>> Subject: Re: [music-dsp] audibility of phase shifts to higher harmonics >> >> >>> The thread in question is called "A little question about DSP >>> performance", and it spanned from 26 September to 4 October 2009. I >>> posted some source and some results >>> (http://www.isle-of-avalon.co.uk/sawphase.zip) but I couldn't >>> replicate Didier's results, which made me think something else was >>> going on with Didier's demos that he hadn't allowed for (maybe some >>> hidden non-linearity?) >> >> I think I can confirm Didier's findings. I did something completely >> unrelated that involved chaining large numbers of first order allpass >> phase shift filters. The frequency response is demonstrably flat (I >> was not mixing in the dry signal to obtain a notched response, as >> you'd expect in a phaser effect) but there is a notable difference in >> sound, even on steady state tones that have no components outside of >> the audible spectrum. >> >> I think Didier was focusing on a discontinuous phase shift between >> harmonics, where this was a continuous but extreme phase shift, with >> similarly audible effect. >> >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, source code archive, list archive, book reviews, dsp links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp >> >> >> -------------------------------------------------------------------------------- >> >> >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 9.0.862 / Virus Database: 271.1.1/3181 - Release Date: 10/06/10 20:34:00 >> >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, source code archive, list archive, book reviews, dsp links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From decoy at iki.fi Thu Oct 7 14:59:40 2010 From: decoy at iki.fi (Sampo Syreeni) Date: Thu, 7 Oct 2010 21:59:40 +0300 (EEST) Subject: [music-dsp] audibility of phase shifts to higher harmonics In-Reply-To: <1AB87EFE98824A8BB6B8FAE2AD10D371@GOLAMD> References: <1AB87EFE98824A8BB6B8FAE2AD10D371@GOLAMD> Message-ID: On 2010-10-07, Didier Dambrin wrote: > I was in that discussion & I remember I posted demo files (yes it's > audible), searching for my name should help. >From what I know, the first results about phase sensitivity were gathered by very long term listening experiments with A/B listening. They indicated that phase didn't seem to be heard. Then there were A/B/X results using very similar stimuli, which seemed to tell that yes, some difference could perhaps be heard, but not at a statistically relevant level. All of these tests were conducted using mixtures of pure sinusoids. Binaural tests told from early on that phase differences from any sustained sinusoid close enogh together could be easily detected. Then there is the separate dichotic pulse literature. That tells us wide band pulses can be easily segregated regardless of phase. Even when the differential, LTI, phase shift of the two channels differs widely. Usually it seems this differentiation is confined to within an ERB or so. But perhaps the most shocking discovery here is that with sufficiently large test sets, 180 degree phase differences can be distinguished at a statistically significant level, monaurally only. That I think was what lead to the periodicity/rectifier models of pitch perception in the first place, long before e.g. missing fundamental kind of phenomena were propertly attributed to the nonlinearity of the cochlear cilia. This is by no means the end of the journey. E.g. not *one* of the current audio codecs takes advantage of what we know about phase effects. -- Sampo Syreeni, aka decoy - decoy at iki.fi, http://decoy.iki.fi/front +358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 From decoy at iki.fi Thu Oct 7 15:09:47 2010 From: decoy at iki.fi (Sampo Syreeni) Date: Thu, 7 Oct 2010 22:09:47 +0300 (EEST) Subject: [music-dsp] audibility of phase shifts to higher harmonics In-Reply-To: <757756BCB88E4D36A92CDF1A27AB2DB7@GOLAMD> References: <757756BCB88E4D36A92CDF1A27AB2DB7@GOLAMD> Message-ID: On 2010-10-07, Didier Dambrin wrote: > Note that I can also hear a slight difference between a saw and an > inverted saw through my headphones (HD650), but I would attribute this > to the headphones or some non-linearity somewhere, as it's not very > logical. No, as I said, this effect can be real as well. It's difficult to know where it comes from without lab grade equipment and very tight tolerance, well designed test conditions. But the best in the field have indeed detected a difference given a 180 degree phase lag. -- Sampo Syreeni, aka decoy - decoy at iki.fi, http://decoy.iki.fi/front +358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 From rbj at audioimagination.com Thu Oct 7 15:41:24 2010 From: rbj at audioimagination.com (robert bristow-johnson) Date: Thu, 7 Oct 2010 15:41:24 -0400 Subject: [music-dsp] audibility of phase shifts to higher harmonics In-Reply-To: References: Message-ID: On Oct 7, 2010, at 8:09 AM, Noam Amir wrote: > as a long timer lurker, i have a distinct recollection of some posts > on the above subject: suppose we synthesize a purely periodic signal > and mess with the phase of one or more of the harmonics - is this > audible or not? > > i'd be grateful if anyone can come up with one of those old posts, > or any insight into this subject. hi Noam. nice to hear from you again. a while ago i posted MATLAB code that created a bandlimited square wave or sawtooth (by adding up a finite set of harmonics) and that allowed the harmonics to be very slightly detuned so that it was equivalent to a changing phase in time. the shape of the waveform changed pretty dramatically, but the sound didn't change much unless you ran it through a non-linear curve. those short files are below. i think it should work with Octave but i haven't tried it with Octave. run the program and listen and judge for yourself. personally, for wavetable synthesis (the most efficient way to synthesize and arbitrary periodic or quasi-periodic waveform), i don't see why anyone would choose to ditch the phase information of the harmonics, but there are those who do. -- r b-j rbj at audioimagination.com "Imagination is more important than knowledge." % % square_phase.m % % a test to see if we can really hear phase changes % in the harmonics of a Nyquist limited square wave. % % (c) 2004 rbj at audioimagination.com % if ~exist('Fs') Fs = 44100 % sample rate, Hz end if ~exist('f0') f0 = 110.25 % fundamental freq, Hz end if ~exist('tone_duration') tone_duration = 2.0 % seconds end if ~exist('change_rate') change_rate = 1.0 % Hz end if ~exist('max_harmonic') max_harmonic = floor((Fs/2)/f0) - 1 end if ~exist('amplitude_factor') amplitude_factor = 0.25 % this just keeps things from clipping end if ~exist('outFile') outFile = 'square_phase.wav' end % make sure we don't uber-Nyquist anything max_harmonic = min(max_harmonic, floor((Fs/2)/f0)-1); t = linspace((-1/4)/f0, tone_duration-(1/4)/f0, Fs*tone_duration+1); detune = change_rate; x = cos(2*pi*f0*t); % start with 1st harmonic n = 3; % continue with 3rd harmonic while (n <= max_harmonic) if ((n-1) == 4*floor((n-1)/4)) % lessee if it's an "even" or "odd" term x = x + (1/n)*cos(2*pi*n*f0*t); else x = x - (1/n)*cos(2*pi*(n*f0+detune)*t); detune = -detune; % comment this line in an see some end % funky intermediate waveforms n = n + 2; % continue with next odd harmonic end x = amplitude_factor*x; % x = sin((pi/2)*x); % toss in a little soft clipping plot(t, x); % see sound(x, Fs); % hear wavwrite(x, Fs, outFile); % remember % % sawtooth_phase.m % % a test to see if we can really hear phase changes % in the harmonics of a Nyquist limited sawtooth wave. % % (c) 2004 rbj at audioimagination.com % if ~exist('Fs') Fs = 44100 % sample rate, Hz end if ~exist('f0') f0 = 110.25 % fundamental freq, Hz end if ~exist('tone_duration') tone_duration = 2.0 % seconds end if ~exist('change_rate') change_rate = 1.0 % Hz end if ~exist('max_harmonic') max_harmonic = floor((Fs/2)/f0) - 1 end if ~exist('amplitude_factor') amplitude_factor = 0.25 % this just keeps things from clipping end if ~exist('outFile') outFile = 'sawtooth_phase.wav' end % make sure we don't uber-Nyquist anything max_harmonic = min(max_harmonic, floor((Fs/2)/f0)-1); t = linspace(0.0, tone_duration, Fs*tone_duration+1); detune = change_rate; x = sin(2*pi*f0*t); % start with 1st harmonic n = 2; % continue with 2nd harmonic while (n <= max_harmonic) if ((n-1) == 2*floor((n-1)/2)) % lessee if it's an even or odd term x = x + (1/n)*sin(2*pi*n*f0*t); else x = x - (1/n)*sin(2*pi*(n*f0+detune)*t); detune = -detune; % comment this line in an see some end % funky intermediate waveforms n = n + 1; % continue with next harmonic end x = amplitude_factor*x; % x = sin((pi/2)*x); % toss in a little soft clipping plot(t, x); % see sound(x, Fs); % hear wavwrite(x, Fs, outFile); % remember From gwenhwyfaer at gmail.com Thu Oct 7 19:45:36 2010 From: gwenhwyfaer at gmail.com (Gwenhwyfaer) Date: Fri, 8 Oct 2010 00:45:36 +0100 Subject: [music-dsp] Phase sensitivity again In-Reply-To: References: Message-ID: On 07/10/2010, Didier Dambrin wrote: > there was this one, first is normal saw, I think the second was the same > with the all phases slowly shifted (neighbor harmonic phases still close > enough from each other), and the third shows the 22th (or something, quickly > checked in a spectrogram) harmonic with its phase shifted, making it stand > out. Of course, when a harmonic phase shifts slowly over time, it's basically the same as saying it's not a perfect harmonic, and our brain reinterprets accordingly. This might be why discontinuous changes in harmonics are more clearly audible than continuous ones. (...unless you're me, apparently.) From didid at skynet.be Thu Oct 7 21:29:08 2010 From: didid at skynet.be (Didier Dambrin) Date: Fri, 8 Oct 2010 03:29:08 +0200 Subject: [music-dsp] Phase sensitivity again In-Reply-To: References: Message-ID: It has never been about shifting over time, I don't know why ppl insist on this as it's a simple experiment. Only the harmonic's initial phase changes. Besides if the harmonic was unpure, you would how much it drifts in pitch by the period of the audible modulation. > On 07/10/2010, Didier Dambrin wrote: >> there was this one, first is normal saw, I think the second was the same >> with the all phases slowly shifted (neighbor harmonic phases still close >> enough from each other), and the third shows the 22th (or something, >> quickly >> checked in a spectrogram) harmonic with its phase shifted, making it >> stand >> out. > > Of course, when a harmonic phase shifts slowly over time, it's > basically the same as saying it's not a perfect harmonic, and our > brain reinterprets accordingly. This might be why discontinuous > changes in harmonics are more clearly audible than continuous ones. > > (...unless you're me, apparently.) > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.862 / Virus Database: 271.1.1/3182 - Release Date: 10/07/10 08:34:00 From didid at skynet.be Thu Oct 7 21:45:43 2010 From: didid at skynet.be (Didier Dambrin) Date: Fri, 8 Oct 2010 03:45:43 +0200 Subject: [music-dsp] Phase sensitivity again In-Reply-To: References: Message-ID: Still about phases, I also remember I posted this recently, the only difference in each pair being the initial phases of the same harmonics, all aligned in the first, all random in the second. Quite useful in a synth. http://forum.image-line.com//files/phases2_102.wav > On 07/10/2010, Didier Dambrin wrote: >> there was this one, first is normal saw, I think the second was the same >> with the all phases slowly shifted (neighbor harmonic phases still close >> enough from each other), and the third shows the 22th (or something, >> quickly >> checked in a spectrogram) harmonic with its phase shifted, making it >> stand >> out. > > Of course, when a harmonic phase shifts slowly over time, it's > basically the same as saying it's not a perfect harmonic, and our > brain reinterprets accordingly. This might be why discontinuous > changes in harmonics are more clearly audible than continuous ones. > > (...unless you're me, apparently.) > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From padawan12 at obiwannabe.co.uk Fri Oct 8 03:04:16 2010 From: padawan12 at obiwannabe.co.uk (Andy Farnell) Date: Fri, 8 Oct 2010 08:04:16 +0100 Subject: [music-dsp] Phase sensitivity again In-Reply-To: References: Message-ID: <20101008080416.e0e866fa.padawan12@obiwannabe.co.uk> I can hear these differences clearly (couldn't hear anything with the previous saw over speakers). Each is processed by a filter or chorus though, which seems to accentuate the phase conditions. Brief first impression: The aligned ones sound focussed like they come from a point, while the randomised ones sound like an uncorrelated extent or volume (ocean waves), kinda as you would expect. Application is possibly for orchestral strings/pads and wind/rain effects to "delocalise" them. Hypothesis: While true that the ear cannot hear different phase arrangements in simply presented static tones, it _can_ make out differences in tones within certain listening contexts. As Sampo identifies this requires a binaural rather than monaural presentation in order for our internal 'decorrelation' brain circuits to work. And as Mike added there are also age/biology differences, as noted by natural 3rd harmonic middle transmission and natural non-linar cochlear structure. a. On Fri, 8 Oct 2010 03:45:43 +0200 "Didier Dambrin" wrote: > Still about phases, I also remember I posted this recently, the only > difference in each pair being the initial phases of the same harmonics, all > aligned in the first, all random in the second. Quite useful in a synth. > > http://forum.image-line.com//files/phases2_102.wav > > > > > On 07/10/2010, Didier Dambrin wrote: > >> there was this one, first is normal saw, I think the second was the same > >> with the all phases slowly shifted (neighbor harmonic phases still close > >> enough from each other), and the third shows the 22th (or something, > >> quickly > >> checked in a spectrogram) harmonic with its phase shifted, making it > >> stand > >> out. > > > > Of course, when a harmonic phase shifts slowly over time, it's > > basically the same as saying it's not a perfect harmonic, and our > > brain reinterprets accordingly. This might be why discontinuous > > changes in harmonics are more clearly audible than continuous ones. > > > > (...unless you're me, apparently.) > > -- > > dupswapdrop -- the music-dsp mailing list and website: > > subscription info, FAQ, 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 -- Andy Farnell From didid at skynet.be Fri Oct 8 03:30:43 2010 From: didid at skynet.be (Didier Dambrin) Date: Fri, 8 Oct 2010 09:30:43 +0200 Subject: [music-dsp] Phase sensitivity again In-Reply-To: <20101008080416.e0e866fa.padawan12@obiwannabe.co.uk> References: <20101008080416.e0e866fa.padawan12@obiwannabe.co.uk> Message-ID: <83041CBEE9414DA2A7C23D39B23A03B6@GOLAMD> sadly that effect is usually more an annoyance, like in timestretching where it's hard to get rid of > > I can hear these differences clearly (couldn't hear > anything with the previous saw over speakers). Each > is processed by a filter or chorus though, which seems > to accentuate the phase conditions. > > Brief first impression: The aligned ones sound focussed > like they come from a point, while the randomised ones > sound like an uncorrelated extent or volume (ocean waves), > kinda as you would expect. Application is possibly for > orchestral strings/pads and wind/rain effects to > "delocalise" them. > > Hypothesis: While true that the ear cannot > hear different phase arrangements in simply > presented static tones, it _can_ make out > differences in tones within certain listening > contexts. As Sampo identifies this requires a > binaural rather than monaural presentation in > order for our internal 'decorrelation' brain > circuits to work. And as Mike added there > are also age/biology differences, as noted > by natural 3rd harmonic middle transmission and > natural non-linar cochlear structure. > > > > a. > > > On Fri, 8 Oct 2010 03:45:43 +0200 > "Didier Dambrin" wrote: > >> Still about phases, I also remember I posted this recently, the only >> difference in each pair being the initial phases of the same harmonics, >> all >> aligned in the first, all random in the second. Quite useful in a synth. >> >> http://forum.image-line.com//files/phases2_102.wav >> >> >> >> > On 07/10/2010, Didier Dambrin wrote: >> >> there was this one, first is normal saw, I think the second was the >> >> same >> >> with the all phases slowly shifted (neighbor harmonic phases still >> >> close >> >> enough from each other), and the third shows the 22th (or something, >> >> quickly >> >> checked in a spectrogram) harmonic with its phase shifted, making it >> >> stand >> >> out. >> > >> > Of course, when a harmonic phase shifts slowly over time, it's >> > basically the same as saying it's not a perfect harmonic, and our >> > brain reinterprets accordingly. This might be why discontinuous >> > changes in harmonics are more clearly audible than continuous ones. >> > >> > (...unless you're me, apparently.) >> > -- >> > dupswapdrop -- the music-dsp mailing list and website: >> > subscription info, FAQ, 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 > > > -- > Andy Farnell > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.862 / Virus Database: 271.1.1/3183 - Release Date: 10/07/10 20:34:00 From padawan12 at obiwannabe.co.uk Fri Oct 8 03:44:08 2010 From: padawan12 at obiwannabe.co.uk (Andy Farnell) Date: Fri, 8 Oct 2010 08:44:08 +0100 Subject: [music-dsp] Phase sensitivity again In-Reply-To: <83041CBEE9414DA2A7C23D39B23A03B6@GOLAMD> References: <20101008080416.e0e866fa.padawan12@obiwannabe.co.uk> <83041CBEE9414DA2A7C23D39B23A03B6@GOLAMD> Message-ID: <20101008084408.80f4f47e.padawan12@obiwannabe.co.uk> It can be useful. Think wider, outside music. For games/virtual world audio, sometimes a decorrelation and delocalisation is exactly what you're after for ambiance (city noise, rushing of wind in forests, rainfall etc) A good phase munging could work much better than a monaural centre pan, which is still the norm in many game audio engines. a. On Fri, 8 Oct 2010 09:30:43 +0200 "Didier Dambrin" wrote: > sadly that effect is usually more an annoyance, like in timestretching where > it's hard to get rid of > > > > > I can hear these differences clearly (couldn't hear > > anything with the previous saw over speakers). Each > > is processed by a filter or chorus though, which seems > > to accentuate the phase conditions. > > > > Brief first impression: The aligned ones sound focussed > > like they come from a point, while the randomised ones > > sound like an uncorrelated extent or volume (ocean waves), > > kinda as you would expect. Application is possibly for > > orchestral strings/pads and wind/rain effects to > > "delocalise" them. > > > > Hypothesis: While true that the ear cannot > > hear different phase arrangements in simply > > presented static tones, it _can_ make out > > differences in tones within certain listening > > contexts. As Sampo identifies this requires a > > binaural rather than monaural presentation in > > order for our internal 'decorrelation' brain > > circuits to work. And as Mike added there > > are also age/biology differences, as noted > > by natural 3rd harmonic middle transmission and > > natural non-linar cochlear structure. > > > > > > > > a. > > > > > > On Fri, 8 Oct 2010 03:45:43 +0200 > > "Didier Dambrin" wrote: > > > >> Still about phases, I also remember I posted this recently, the only > >> difference in each pair being the initial phases of the same harmonics, > >> all > >> aligned in the first, all random in the second. Quite useful in a synth. > >> > >> http://forum.image-line.com//files/phases2_102.wav > >> > >> > >> > >> > On 07/10/2010, Didier Dambrin wrote: > >> >> there was this one, first is normal saw, I think the second was the > >> >> same > >> >> with the all phases slowly shifted (neighbor harmonic phases still > >> >> close > >> >> enough from each other), and the third shows the 22th (or something, > >> >> quickly > >> >> checked in a spectrogram) harmonic with its phase shifted, making it > >> >> stand > >> >> out. > >> > > >> > Of course, when a harmonic phase shifts slowly over time, it's > >> > basically the same as saying it's not a perfect harmonic, and our > >> > brain reinterprets accordingly. This might be why discontinuous > >> > changes in harmonics are more clearly audible than continuous ones. > >> > > >> > (...unless you're me, apparently.) > >> > -- > >> > dupswapdrop -- the music-dsp mailing list and website: > >> > subscription info, FAQ, 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 > > > > > > -- > > Andy Farnell > > -- > > dupswapdrop -- the music-dsp mailing list and website: > > subscription info, FAQ, source code archive, list archive, book reviews, > > dsp links > > http://music.columbia.edu/cmc/music-dsp > > http://music.columbia.edu/mailman/listinfo/music-dsp > > > -------------------------------------------------------------------------------- > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.862 / Virus Database: 271.1.1/3183 - Release Date: 10/07/10 > 20:34:00 > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -- Andy Farnell From gwenhwyfaer at gmail.com Fri Oct 8 03:55:35 2010 From: gwenhwyfaer at gmail.com (Gwenhwyfaer) Date: Fri, 8 Oct 2010 08:55:35 +0100 Subject: [music-dsp] Phase sensitivity again In-Reply-To: References: Message-ID: >> Of course, when a harmonic phase shifts slowly over time, it's >> basically the same as saying it's not a perfect harmonic, and our >> brain reinterprets accordingly. This might be why discontinuous >> changes in harmonics are more clearly audible than continuous ones. > It has never been about shifting over time, I don't know why ppl insist on > this as it's a simple experiment. Only the harmonic's initial phase changes. > Besides if the harmonic was unpure, you would how much it drifts in pitch by > the period of the audible modulation. Ah, I see I've confused you by going onto a related but tangential thought that you didn't manage to follow. Sorry; I tend to do that quite often. From mark.plumbley at elec.qmul.ac.uk Fri Oct 8 07:01:26 2010 From: mark.plumbley at elec.qmul.ac.uk (Mark Plumbley) Date: Fri, 8 Oct 2010 12:01:26 +0100 Subject: [music-dsp] Postdoc Research Assistant: Sparse Representations for Audio Signals Message-ID: <7BA16F8108C17240A4D965D3FC041186016C4A5284@staff-mail2.vpn.elec.qmul.ac.uk> Dear Music DSP, Apologies for cross-posting. Please feel free to redistribute to anyone who may be interested. Best wishes, Mark Plumbley ------------------------------------------------------------------- Postdoctoral Research Assistant: Sparse Representations for Audio Signals Centre for Digital Music Queen Mary University of London Applications are invited for a Postdoctoral Research Assistant to work on the EPSRC project "Machine Listening using Sparse Representations". The aim of this multi-person project is to investigate the automatic analysis and understanding of real-world sounds, using sparse representations and related methods. The purpose of this particular post is to explore and develop underlying theory and efficient algorithms for sparse representations of audio, such as: efficient sparse recovery algorithms; sparse dictionary learning; compressed sensing of audio; application of sparse representations to the analysis of real-world sounds; and (optionally) to investigate parallels between sparse representations and biological processing of audio signals. The project is based in the Centre for Digital Music (C4DM) at Queen Mary, University of London. C4DM is a world-leading multidisciplinary research group in the field of Digital Music & Audio Technology, and is part of the School of Electronic Engineering and Computer Science (EECS). Details about the School can be found at www.eecs.qmul.ac.uk, and about the Centre for Digital Music at www.elec.qmul.ac.uk/digitalmusic. The post is full time for 24 months starting from 1st December 2010 or as soon as possible thereafter. Starting salary will be in the range ?30,229 - ?33,659 per annum inclusive of London Allowance. Benefits include 30 days annual leave, final salary pension scheme and interest-free season ticket loan. Candidates must be able to demonstrate their eligibility to work in the UK in accordance with the Immigration, Asylum and Nationality Act 2006. Where required this may include entry clearance or continued leave to remain under the Points Based Immigration Scheme. Informal enquiries should be addressed to the Prof Mark Plumbley at mark.plumbley at elec.qmul.ac.uk. Details about the School can be found at www.eecs.qmul.ac.uk. Further details and an application form can be found at: www.hr.qmul.ac.uk/vacancies (http://webapps.qmul.ac.uk/hr/vacancies/jobs.php?id=1999). To apply for this position, please email the following documents to Ms Julie Macdonald at applications at eecs.qmul.ac.uk: Completed application form quoting reference number 10371/CE; a CV listing all publications; a pdf of a representative publication and a research statement describing your previous research experience, outlining the relevance to this project. Postal applications should be sent to Ms Julie Macdonald, School of EECS, Queen Mary University of London, Mile End Road, London, E1 4NS. The closing date for applications is 12 noon on Wednesday 27th October 2010. Applications received after this time may not be considered. *Please note that applications will be rejected if they do not include a completed QMUL application form.* Interviews are expected to be held on 11 November 2010. Valuing Diversity & Committed to Equality -- Prof Mark D Plumbley Director, Centre for Digital Music Electronic Engineering & Computer Science (Eng Bldg) Queen Mary University of London Mile End Road, London E1 4NS, UK Tel: +44 (0)20 7882 7518 Fax: +44 (0)20 7882 7997 Email: mark.plumbley at elec.qmul.ac.uk http://www.elec.qmul.ac.uk/people/markp/ From bil at ccrma.Stanford.EDU Fri Oct 8 09:04:02 2010 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Fri, 8 Oct 2010 06:04:02 -0700 Subject: [music-dsp] audibility of phase shifts to higher harmonics Message-ID: <20101008125501.M65680@ccrma.Stanford.EDU> If you vary the initial phases to minimize the peak amplitude, the minimum peak version sounds "raspier" (if there are enough harmonics and so on). I thought this might make a difference if used in FM as the modulating wave (mentioned in https://ccrma.stanford.edu/software/snd/snd/fm.html), but the result was disappointing. That got me interested in what is the minimum peak of (say) n equal amplitude harmonics. Horner and Beauchamp wrote a paper about this in the 90's, and I've followed up with https://ccrma.stanford.edu/software/snd/snd/sndscm.html#peakphasesdoc My initial guess was that you could get below the square root of n, and that's holding up so far. For my aged ears, if I want to hear the difference, n has to be about 60, but surely younger ears could hear it at lower n. In the limit (say 65k harmonics), the all cosine wave is a click, and the minimized peak wave sounds like a seriously damaged attempt at white noise. Two things have always amazed me in this area: how similar the waveforms sound though they look completely different, and how much cancellation you can get in the best case. (By the way, if you simply randomize the initial phases you can around n^.6 or n^.7 -- good, but no where near the best). From spencer.f.russell at gmail.com Sun Oct 10 10:32:49 2010 From: spencer.f.russell at gmail.com (Spencer Russell) Date: Sun, 10 Oct 2010 10:32:49 -0400 Subject: [music-dsp] Live pitch detection In-Reply-To: References: Message-ID: On Wed, Sep 29, 2010 at 1:45 AM, Alexandre Quessy wrote: > Hello everyone, > > I want to write a chromatic tuner. What is the easiest way to do some > live ("realtime") pitch detection? > > I'm much used to using Miller Puckette's [fiddle~] object for Pure > Data. Is there a C/C++ library that provides a similar tool? > As i understand it, fiddle~ has been pretty much completely deprecated in favor of sigmund~ (also by Miller, and more recently released) -spencer From Victor.Lazzarini at nuim.ie Sun Oct 10 12:41:03 2010 From: Victor.Lazzarini at nuim.ie (Victor Lazzarini) Date: Sun, 10 Oct 2010 17:41:03 +0100 Subject: [music-dsp] Live pitch detection In-Reply-To: References: Message-ID: Both of these are open source. You should be able to have a look and use the code in your applicatiom if you are a C programmer. Regards Victor On 10 Oct 2010, at 15:32, Spencer Russell wrote: > On Wed, Sep 29, 2010 at 1:45 AM, Alexandre Quessy > wrote: >> Hello everyone, >> >> I want to write a chromatic tuner. What is the easiest way to do some >> live ("realtime") pitch detection? >> >> I'm much used to using Miller Puckette's [fiddle~] object for Pure >> Data. Is there a C/C++ library that provides a similar tool? >> > > As i understand it, fiddle~ has been pretty much completely deprecated > in favor of sigmund~ (also by Miller, and more recently released) > > -spencer > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, 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 alexandre at quessy.net Sun Oct 10 14:00:05 2010 From: alexandre at quessy.net (Alexandre Quessy) Date: Sun, 10 Oct 2010 14:00:05 -0400 Subject: [music-dsp] Live pitch detection In-Reply-To: References: Message-ID: Hello! 2010/10/10 Victor Lazzarini : > Both of these are open source. You should be able to have a look and use the > code in your applicatiom if you are a C programmer. Yes, but it needs to be hooked to something like RtAudio or Portaudio for the audio input. I was looking at Denemo's source code, and there is some pitch detection going on there. I asked the developers and they used some code from Accordeur, which is a fork in QT of Dan's Tuner. (which is in WX) I'm more into Clutter myself. I don't know how much their code differ, appart from the GUI toolkit. http://sourceforge.net/projects/accordeur/ http://sourceforge.net/projects/danstuner/ > On 10 Oct 2010, at 15:32, Spencer Russell wrote: >> On Wed, Sep 29, 2010 at 1:45 AM, Alexandre Quessy >> wrote: >>> I'm much used to using Miller Puckette's [fiddle~] object for Pure >>> Data. Is there a C/C++ library that provides a similar tool? >> >> As i understand it, fiddle~ has been pretty much completely deprecated >> in favor of sigmund~ (also by Miller, and more recently released) Good to know. Thanks Spencer. I haven't used much Pure Data in the last few months. So, I should either start from sigmund~ or Accordeur. Which should be the easiest? Probably Accordeur. Thanks, -- Alexandre Quessy http://alexandre.quessy.net/ From Victor.Lazzarini at nuim.ie Sun Oct 10 16:03:58 2010 From: Victor.Lazzarini at nuim.ie (Victor Lazzarini) Date: Sun, 10 Oct 2010 21:03:58 +0100 Subject: [music-dsp] Live pitch detection In-Reply-To: References: Message-ID: yes, you would just need to remove the audio processing loop from the PD external and then write a wrapper around it. It should not be that difficult. Victor On 10 Oct 2010, at 19:00, Alexandre Quessy wrote: > Hello! > > 2010/10/10 Victor Lazzarini : >> Both of these are open source. You should be able to have a look >> and use the >> code in your applicatiom if you are a C programmer. > > Yes, but it needs to be hooked to something like RtAudio or Portaudio > for the audio input. > > I was looking at Denemo's source code, and there is some pitch > detection going on there. I asked the developers and they used some > code from Accordeur, which is a fork in QT of Dan's Tuner. (which is > in WX) I'm more into Clutter myself. I don't know how much their code > differ, appart from the GUI toolkit. > > http://sourceforge.net/projects/accordeur/ > http://sourceforge.net/projects/danstuner/ > >> On 10 Oct 2010, at 15:32, Spencer Russell wrote: >>> On Wed, Sep 29, 2010 at 1:45 AM, Alexandre Quessy >> > >>> wrote: >>>> I'm much used to using Miller Puckette's [fiddle~] object for Pure >>>> Data. Is there a C/C++ library that provides a similar tool? >>> >>> As i understand it, fiddle~ has been pretty much completely >>> deprecated >>> in favor of sigmund~ (also by Miller, and more recently released) > > Good to know. Thanks Spencer. I haven't used much Pure Data in the > last few months. > > So, I should either start from sigmund~ or Accordeur. Which should be > the easiest? Probably Accordeur. > > Thanks, > -- > Alexandre Quessy > http://alexandre.quessy.net/ > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, 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 Oct 10 22:52:08 2010 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sun, 10 Oct 2010 22:52:08 -0400 Subject: [music-dsp] Live pitch detection In-Reply-To: References: Message-ID: <5B2B870B-3FDA-4DEE-9AF9-C6E367BA600E@audioimagination.com> if it's all in the time domain (which is what i think it would have to be for it to be used live), i can't imagine generic C code to be too complicated. there would have to be a circular buffer (and if i ever do a circular buffer in C, its length is a power of 2 and i mask the index to make it wrap around) and then whatever the alg does to it. if someone gets this into a simple and clean state where it's pretty much just given a buffer of the last 100 ms of sound and the result is the pitch or fundamental frequency or period length (with fractional sample precision), i would be interested in seeing it. otherwise, for time-domain pitch detection, i generally do something based on the Average Magnitude-squared Difference Function. can be done real-time, but likes to have a 2 period delay, which is not particularly good for low pitches and live settings. i have an idea about how Axon does their 13 ms pitch detection (for the low E string which has a periods possibly as long as 12.1 ms, so telling us what the period length is 1 ms after it completes the very first period is pretty fast, i think). but i have no idea what fiddle~ nor sigmund~ nor Accordeur do mathematically. can anyone fill us in about it? curiously, r b-j On Oct 10, 2010, at 4:03 PM, Victor Lazzarini wrote: > yes, you would just need to remove the audio processing loop from > the PD external and > then write a wrapper around it. It should not be that difficult. > > Victor > On 10 Oct 2010, at 19:00, Alexandre Quessy wrote: > >> Hello! >> >> 2010/10/10 Victor Lazzarini : >>> Both of these are open source. You should be able to have a look >>> and use the >>> code in your applicatiom if you are a C programmer. >> >> Yes, but it needs to be hooked to something like RtAudio or Portaudio >> for the audio input. >> >> I was looking at Denemo's source code, and there is some pitch >> detection going on there. I asked the developers and they used some >> code from Accordeur, which is a fork in QT of Dan's Tuner. (which is >> in WX) I'm more into Clutter myself. I don't know how much their code >> differ, appart from the GUI toolkit. >> >> http://sourceforge.net/projects/accordeur/ >> http://sourceforge.net/projects/danstuner/ >> >>> On 10 Oct 2010, at 15:32, Spencer Russell wrote: >>>> On Wed, Sep 29, 2010 at 1:45 AM, Alexandre Quessy >>> > >>>> wrote: >>>>> I'm much used to using Miller Puckette's [fiddle~] object for Pure >>>>> Data. Is there a C/C++ library that provides a similar tool? >>>> >>>> As i understand it, fiddle~ has been pretty much completely >>>> deprecated >>>> in favor of sigmund~ (also by Miller, and more recently released) >> >> Good to know. Thanks Spencer. I haven't used much Pure Data in the >> last few months. >> >> So, I should either start from sigmund~ or Accordeur. Which should be >> the easiest? Probably Accordeur. >> >> Thanks, >> -- >> Alexandre Quessy >> http://alexandre.quessy.net/ From Victor.Lazzarini at nuim.ie Mon Oct 11 05:24:49 2010 From: Victor.Lazzarini at nuim.ie (Victor Lazzarini) Date: Mon, 11 Oct 2010 10:24:49 +0100 Subject: [music-dsp] Live pitch detection In-Reply-To: <5B2B870B-3FDA-4DEE-9AF9-C6E367BA600E@audioimagination.com> References: <5B2B870B-3FDA-4DEE-9AF9-C6E367BA600E@audioimagination.com> Message-ID: <5031BC3F-9801-45DC-83B9-13A1255ED077@nuim.ie> For fiddle~ there is an article: http://www-crca.ucsd.edu/~tapel/icmc98.pdf I have not looked at the internals of sigmund~, but from its outside appearance, it looks like an improvement on fiddle~, using similar principles, but maybe an enhanced peak-picking and sinusoidal tracking. There is also an excellent paper on the latest DAFx: http://dafx10.iem.at/proceedings/papers/VonDemKnesebeckZoelzer_DAFx10_P102.pdf where different methods are measured against each other. AMDF comes out very well. Regards 'hacking' of sigmund~, in PD the business end of the class is a DSP processing function, which has a loop that iterates over an input vector of samples. This is what needs to be removed and adapted for a standalone application (and any other relevant functions that are called; you will also need to replace the FFT function for one of your own). You will just have to figure out where the output is being banged out and tap it there. Victor On 11 Oct 2010, at 03:52, robert bristow-johnson wrote: > > > if it's all in the time domain (which is what i think it would have > to be for it to be used live), i can't imagine generic C code to be > too complicated. there would have to be a circular buffer (and if i > ever do a circular buffer in C, its length is a power of 2 and i > mask the index to make it wrap around) and then whatever the alg > does to it. > > if someone gets this into a simple and clean state where it's pretty > much just given a buffer of the last 100 ms of sound and the result > is the pitch or fundamental frequency or period length (with > fractional sample precision), i would be interested in seeing it. > > otherwise, for time-domain pitch detection, i generally do something > based on the Average Magnitude-squared Difference Function. can be > done real-time, but likes to have a 2 period delay, which is not > particularly good for low pitches and live settings. i have an idea > about how Axon does their 13 ms pitch detection (for the low E > string which has a periods possibly as long as 12.1 ms, so telling > us what the period length is 1 ms after it completes the very first > period is pretty fast, i think). > > but i have no idea what fiddle~ nor sigmund~ nor Accordeur do > mathematically. can anyone fill us in about it? > > curiously, > > r b-j > > > On Oct 10, 2010, at 4:03 PM, Victor Lazzarini wrote: > >> yes, you would just need to remove the audio processing loop from >> the PD external and >> then write a wrapper around it. It should not be that difficult. >> >> Victor >> On 10 Oct 2010, at 19:00, Alexandre Quessy wrote: >> >>> Hello! >>> >>> 2010/10/10 Victor Lazzarini : >>>> Both of these are open source. You should be able to have a look >>>> and use the >>>> code in your applicatiom if you are a C programmer. >>> >>> Yes, but it needs to be hooked to something like RtAudio or >>> Portaudio >>> for the audio input. >>> >>> I was looking at Denemo's source code, and there is some pitch >>> detection going on there. I asked the developers and they used some >>> code from Accordeur, which is a fork in QT of Dan's Tuner. (which is >>> in WX) I'm more into Clutter myself. I don't know how much their >>> code >>> differ, appart from the GUI toolkit. >>> >>> http://sourceforge.net/projects/accordeur/ >>> http://sourceforge.net/projects/danstuner/ >>> >>>> On 10 Oct 2010, at 15:32, Spencer Russell wrote: >>>>> On Wed, Sep 29, 2010 at 1:45 AM, Alexandre Quessy >>>> > >>>>> wrote: >>>>>> I'm much used to using Miller Puckette's [fiddle~] object for >>>>>> Pure >>>>>> Data. Is there a C/C++ library that provides a similar tool? >>>>> >>>>> As i understand it, fiddle~ has been pretty much completely >>>>> deprecated >>>>> in favor of sigmund~ (also by Miller, and more recently released) >>> >>> Good to know. Thanks Spencer. I haven't used much Pure Data in the >>> last few months. >>> >>> So, I should either start from sigmund~ or Accordeur. Which should >>> be >>> the easiest? Probably Accordeur. >>> >>> Thanks, >>> -- >>> Alexandre Quessy >>> http://alexandre.quessy.net/ > > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, 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 stefan at space.twc.de Mon Oct 11 09:19:02 2010 From: stefan at space.twc.de (Stefan Westerfeld) Date: Mon, 11 Oct 2010 15:19:02 +0200 Subject: [music-dsp] Sythesizing sines + noise in one IFFT In-Reply-To: <4CB24344.4040901@usherbrooke.ca> References: <20101007113951.GA9349@space.twc.de> <4CB24344.4040901@usherbrooke.ca> Message-ID: <20101011131902.GA21104@space.twc.de> Hi! On Sun, Oct 10, 2010 at 06:50:44PM -0400, Jean-Marc Valin wrote: > I think what you want to use is simply a "power complementary" window. > The simplest is the sine window (aka sqrt(hanning)), but you could also > use the Vorbis window which is sin(pi/2 * sin^2(M_PI*x/N)) > > If you apply the same window in the analysis of the sinusoids, then you > end up with no gain compensation required after the IFFT. Similarly, > when you use it for noise synthesis, it works because noise adds up in > the energy domain, so again no need to do any sort of gain adjustment. > I've actually use that technique in the past for a different > application: http://jmvalin.ca/papers/valin_hscma2008.pdf I've read your paper now, but I don't see how I could make it work in my case. If you just analyze a signal composed of a few sines with a window, then of course the spectrum will be convoluted with the window's frequency response, so you can IFFT this, and get the original signal back. But in my case, the analysis process will produce a list of sine signals (with frequency, magnitude and phase), so to resynthesize this, I need to produce the spectrum myself. With windows that have a lengthy frequency response, this will be more expensive than with windows like blackman harris 92, which have a narrow frequency response; I need to reproduce the spectrum, so effectively for each sine component, I add a shifted/rotated version of the window's frequency response to the spectrum. An IFFT yields a windowed version of the sine part of the signal. I rescale this windowed signal (because for overlap-add, I use a cosine window, not blackman harris 92) to get my sine signal. For noise, on the other hand, I just put the right amount of energy in each band, IFFT this, and get a noise time signal. BUT, I need to apply scaling to this noise signal before overlap-add is possible (and the scaling is different from the scaling I need to apply to the sine signal), so I need two IFFTs to do the job, which is the part of the algorithm that I would like to improve. If thats possible at all, that is. Cu... Stefan -- Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan From stefan at space.twc.de Mon Oct 11 09:29:38 2010 From: stefan at space.twc.de (Stefan Westerfeld) Date: Mon, 11 Oct 2010 15:29:38 +0200 Subject: [music-dsp] Sythesizing sines + noise in one IFFT In-Reply-To: <201010102351.51169.david@olofson.net> References: <201010102351.51169.david@olofson.net> Message-ID: <20101011132938.GB21104@space.twc.de> Hi! On Sun, Oct 10, 2010 at 11:51:50PM +0200, David Olofson wrote: > Hi there! > > Seems like I can't post to the list for some reason, so I'm resending this > off-list. > > On Thursday 07 October 2010, at 13.39.51, Stefan Westerfeld > wrote: > > [...] > > > For the sine waves, I construct a spectrum using a blackman harris 92 dB > > > window, which has the advantage that one sine wave only affects 9 spectrum > > > bins (the main lobe of the window); then an inverse FFT (IFFT) produces > > > the desired sine waves. > > [...] > > I'm getting by pretty well with only two (!) bins per sine - but of course, > TANSTAAFL: I have to throw away most of the output from the IFFT, and use only > a window in the middle. > > I've noticed that the errors caused by dropping bins in the reconstruction has > a dramatic effect on the output near the start and end of the time window, but > not so much in the middle - so just using smaller windows drastically reduces > distortion. > > In my current prototype, I'm using a 512 bin IFFT for generating a 64 sample > window every 32'nd output sample (overlapping with a Hann window, so no AM > issues), which sounds good enough for a single pure sine to my ears. > > That's right; I'm only actually using one 8'th of the FFT output...! >From my experience I'd say that you create performance problems if you need larger FFT sizes than the number of output samples. The FFT is O(N log N), which means that if you can only use 1/8 of the FFT output, you are probably more than 8 times slower than an algorithm which uses every sample of the FFT. In my case, I use 1024 value FFTs, and each output value is properly windowed for overlap and add. Yes, you need 9 bins instead of 2, but the error is really small, and it works for every frequency (low freqs as well as high freqs), if you handle cases where bins wrap around the edges of your FFT buffer properly. Cu... Stefan -- Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan From Diemo.Schwarz at ircam.fr Mon Oct 11 10:06:37 2010 From: Diemo.Schwarz at ircam.fr (Diemo Schwarz) Date: Mon, 11 Oct 2010 16:06:37 +0200 Subject: [music-dsp] Sythesizing sines + noise in one IFFT In-Reply-To: <20101011131902.GA21104@space.twc.de> References: <20101007113951.GA9349@space.twc.de> <4CB24344.4040901@usherbrooke.ca> <20101011131902.GA21104@space.twc.de> Message-ID: <4CB319ED.4040306@ircam.fr> You might want to look at the FFT^-1 method: Freed Adrian, Rodet Xavier, Depalle Philippe, Synthesis and Control of Hundreds of Sinusoidal Partials on a Desktop Computer without Custom Hardware. ICSPAT (International Conference on Signal Processing Applications & Technology. San Jos? : 1992 http://articles.ircam.fr/index.php?Action=ShowArticle&IdArticle=14&ViewType=1 ...Diemo On 11.10.10 15:19, Stefan Westerfeld wrote: > Hi! > > On Sun, Oct 10, 2010 at 06:50:44PM -0400, Jean-Marc Valin wrote: >> I think what you want to use is simply a "power complementary" window. >> The simplest is the sine window (aka sqrt(hanning)), but you could also >> use the Vorbis window which is sin(pi/2 * sin^2(M_PI*x/N)) >> >> If you apply the same window in the analysis of the sinusoids, then you >> end up with no gain compensation required after the IFFT. Similarly, >> when you use it for noise synthesis, it works because noise adds up in >> the energy domain, so again no need to do any sort of gain adjustment. >> I've actually use that technique in the past for a different >> application: http://jmvalin.ca/papers/valin_hscma2008.pdf > > I've read your paper now, but I don't see how I could make it work in my case. > If you just analyze a signal composed of a few sines with a window, then of > course the spectrum will be convoluted with the window's frequency response, so > you can IFFT this, and get the original signal back. > > But in my case, the analysis process will produce a list of sine signals (with > frequency, magnitude and phase), so to resynthesize this, I need to produce the > spectrum myself. With windows that have a lengthy frequency response, this will > be more expensive than with windows like blackman harris 92, which have a > narrow frequency response; I need to reproduce the spectrum, so effectively for > each sine component, I add a shifted/rotated version of the window's frequency > response to the spectrum. An IFFT yields a windowed version of the sine part of > the signal. I rescale this windowed signal (because for overlap-add, I use a > cosine window, not blackman harris 92) to get my sine signal. > > For noise, on the other hand, I just put the right amount of energy in each > band, IFFT this, and get a noise time signal. BUT, I need to apply scaling to > this noise signal before overlap-add is possible (and the scaling is different > from the scaling I need to apply to the sine signal), so I need two IFFTs to do > the job, which is the part of the algorithm that I would like to improve. If > thats possible at all, that is. > > Cu... Stefan -- Diemo Schwarz, PhD -- http://diemo.concatenative.net Real-Time Music Interaction Team -- http://imtr.ircam.fr IRCAM - Centre Pompidou -- 1, place Igor-Stravinsky, 75004 Paris, France Phone +33-1-4478-4879 -- Fax +33-1-4478-1540 From xue.wen at elec.qmul.ac.uk Mon Oct 11 10:26:19 2010 From: xue.wen at elec.qmul.ac.uk (xue wen) Date: Mon, 11 Oct 2010 15:26:19 +0100 Subject: [music-dsp] Sythesizing sines + noise in one IFFT In-Reply-To: <20101011131902.GA21104@space.twc.de> References: <20101007113951.GA9349@space.twc.de> <4CB24344.4040901@usherbrooke.ca>, <20101011131902.GA21104@space.twc.de> Message-ID: Actually the spectral convolution you proposed doesn't seem that bad. Spectrum of a BH92 window is 7 point long, real and symmetric - that comes down to 4 real-complex multiplications and 6 complex additions per point if you do convolution, and reduced to 4 real-real multiplications and 6 real additions per point considering spectral symmetry. For comparison, if you do a separate IFFT it'll be 2log2(FFT length) real-real multiplications per point, which goes up to 20 per point for FFT length 1024, plus the usual extra going-ons of any FFT. - ________________________________________ From: music-dsp-bounces at music.columbia.edu [music-dsp-bounces at music.columbia.edu] On Behalf Of Stefan Westerfeld [stefan at space.twc.de] Sent: 11 October 2010 14:19 To: Jean-Marc Valin Cc: music-dsp at music.columbia.edu Subject: Re: [music-dsp] Sythesizing sines + noise in one IFFT Hi! On Sun, Oct 10, 2010 at 06:50:44PM -0400, Jean-Marc Valin wrote: > I think what you want to use is simply a "power complementary" window. > The simplest is the sine window (aka sqrt(hanning)), but you could also > use the Vorbis window which is sin(pi/2 * sin^2(M_PI*x/N)) > > If you apply the same window in the analysis of the sinusoids, then you > end up with no gain compensation required after the IFFT. Similarly, > when you use it for noise synthesis, it works because noise adds up in > the energy domain, so again no need to do any sort of gain adjustment. > I've actually use that technique in the past for a different > application: http://jmvalin.ca/papers/valin_hscma2008.pdf I've read your paper now, but I don't see how I could make it work in my case. If you just analyze a signal composed of a few sines with a window, then of course the spectrum will be convoluted with the window's frequency response, so you can IFFT this, and get the original signal back. But in my case, the analysis process will produce a list of sine signals (with frequency, magnitude and phase), so to resynthesize this, I need to produce the spectrum myself. With windows that have a lengthy frequency response, this will be more expensive than with windows like blackman harris 92, which have a narrow frequency response; I need to reproduce the spectrum, so effectively for each sine component, I add a shifted/rotated version of the window's frequency response to the spectrum. An IFFT yields a windowed version of the sine part of the signal. I rescale this windowed signal (because for overlap-add, I use a cosine window, not blackman harris 92) to get my sine signal. For noise, on the other hand, I just put the right amount of energy in each band, IFFT this, and get a noise time signal. BUT, I need to apply scaling to this noise signal before overlap-add is possible (and the scaling is different from the scaling I need to apply to the sine signal), so I need two IFFTs to do the job, which is the part of the algorithm that I would like to improve. If thats possible at all, that is. Cu... Stefan -- Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp From theover at tiscali.nl Mon Oct 11 20:11:47 2010 From: theover at tiscali.nl (Theo Verelst) Date: Tue, 12 Oct 2010 02:11:47 +0200 Subject: [music-dsp] Sythesizing sines + noise in one IFFT Message-ID: <4CB3A7C3.5020405@tiscali.nl> Ah, it?s still a difficult subject indeed... Think about it that the ft or ifft is usually built on fixed intervals and therefor will have often pretty horrible discontinuity and transient related errors associated with them (even though and ifft on (unchanged) date from an fft also in practice gives the original signal back, assuming enough accuracy), and that is imo regardless of wether you square the spectrum. Also, if you mean to add signals, in principle a well applied ifft (or maybe you just want to add a number of sine waves with the right frequencies instead?, or are you using prefab SSE or so accelerated routines?) is linear in that signals added in the frequency domain will also get added in the ifft resulting time domain. Theo Verelst ------------------------------------------------------------------------- From stefan at space.twc.de Tue Oct 12 05:23:52 2010 From: stefan at space.twc.de (Stefan Westerfeld) Date: Tue, 12 Oct 2010 11:23:52 +0200 Subject: [music-dsp] Sythesizing sines + noise in one IFFT In-Reply-To: References: <20101007113951.GA9349@space.twc.de> <20101011131902.GA21104@space.twc.de> Message-ID: <20101012092352.GA31047@space.twc.de> Hi! Thanks, I think this is the answer I was looking for - I've implemented a simple convolution using normal FPU, just to see how fast it would be, and its about twice as fast as the FFT. However, I assume it will be even faster if I SSEify it (thats the next thing I'll try). So with SSEified convolution, I should be able to get rid of the extra FFT and replace it with something a lot less expensive. It'll take some coding to figure out how much CPU power it'll take all together, but yes, convolution with the real/symmetric BH92 spectrum sounds like the right way to go :-). Cu... Stefan On Mon, Oct 11, 2010 at 03:26:19PM +0100, xue wen wrote: > Actually the spectral convolution you proposed doesn't seem that bad. Spectrum of a BH92 window is 7 point long, real and symmetric - that comes down to 4 real-complex multiplications and 6 complex additions per point if you do convolution, and reduced to 4 real-real multiplications and 6 real additions per point considering spectral symmetry. For comparison, if you do a separate IFFT it'll be 2log2(FFT length) real-real multiplications per point, which goes up to 20 per point for FFT length 1024, plus the usual extra going-ons of any FFT. > > - > ________________________________________ > From: music-dsp-bounces at music.columbia.edu [music-dsp-bounces at music.columbia.edu] On Behalf Of Stefan Westerfeld [stefan at space.twc.de] > Sent: 11 October 2010 14:19 > To: Jean-Marc Valin > Cc: music-dsp at music.columbia.edu > Subject: Re: [music-dsp] Sythesizing sines + noise in one IFFT > > Hi! > > On Sun, Oct 10, 2010 at 06:50:44PM -0400, Jean-Marc Valin wrote: > > I think what you want to use is simply a "power complementary" window. > > The simplest is the sine window (aka sqrt(hanning)), but you could also > > use the Vorbis window which is sin(pi/2 * sin^2(M_PI*x/N)) > > > > If you apply the same window in the analysis of the sinusoids, then you > > end up with no gain compensation required after the IFFT. Similarly, > > when you use it for noise synthesis, it works because noise adds up in > > the energy domain, so again no need to do any sort of gain adjustment. > > I've actually use that technique in the past for a different > > application: http://jmvalin.ca/papers/valin_hscma2008.pdf > > I've read your paper now, but I don't see how I could make it work in my case. > If you just analyze a signal composed of a few sines with a window, then of > course the spectrum will be convoluted with the window's frequency response, so > you can IFFT this, and get the original signal back. > > But in my case, the analysis process will produce a list of sine signals (with > frequency, magnitude and phase), so to resynthesize this, I need to produce the > spectrum myself. With windows that have a lengthy frequency response, this will > be more expensive than with windows like blackman harris 92, which have a > narrow frequency response; I need to reproduce the spectrum, so effectively for > each sine component, I add a shifted/rotated version of the window's frequency > response to the spectrum. An IFFT yields a windowed version of the sine part of > the signal. I rescale this windowed signal (because for overlap-add, I use a > cosine window, not blackman harris 92) to get my sine signal. > > For noise, on the other hand, I just put the right amount of energy in each > band, IFFT this, and get a noise time signal. BUT, I need to apply scaling to > this noise signal before overlap-add is possible (and the scaling is different > from the scaling I need to apply to the sine signal), so I need two IFFTs to do > the job, which is the part of the algorithm that I would like to improve. If > thats possible at all, that is. > > Cu... Stefan > -- > Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, 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 -- Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan From didid at skynet.be Tue Oct 12 05:57:00 2010 From: didid at skynet.be (Didier Dambrin) Date: Tue, 12 Oct 2010 11:57:00 +0200 Subject: [music-dsp] Sythesizing sines + noise in one IFFT In-Reply-To: <20101012092352.GA31047@space.twc.de> References: <20101007113951.GA9349@space.twc.de><20101011131902.GA21104@space.twc.de> <20101012092352.GA31047@space.twc.de> Message-ID: Do you have much knowledge on resynthesis btw? I have an additive synth in progress, not FFT-based so I can easily adapt per-partial pitch/phase, and I'm looking for someone to improve the (ok, but not amazing) resynthesis analysis part. So it's pretty much about building the best spectrogram that the engine will use, knowing the spectrogram holds magnitudes, running pitch offset, but also absolute phases and transient info, using an approach similar to the one of time stretchers. > Hi! > > Thanks, I think this is the answer I was looking for - I've implemented a > simple convolution using normal FPU, just to see how fast it would be, and > its > about twice as fast as the FFT. However, I assume it will be even faster > if I > SSEify it (thats the next thing I'll try). So with SSEified convolution, I > should be able to get rid of the extra FFT and replace it with something a > lot > less expensive. It'll take some coding to figure out how much CPU power > it'll > take all together, but yes, convolution with the real/symmetric BH92 > spectrum > sounds like the right way to go :-). > > Cu... Stefan > > On Mon, Oct 11, 2010 at 03:26:19PM +0100, xue wen wrote: >> Actually the spectral convolution you proposed doesn't seem that bad. >> Spectrum of a BH92 window is 7 point long, real and symmetric - that >> comes down to 4 real-complex multiplications and 6 complex additions per >> point if you do convolution, and reduced to 4 real-real multiplications >> and 6 real additions per point considering spectral symmetry. For >> comparison, if you do a separate IFFT it'll be 2log2(FFT length) >> real-real multiplications per point, which goes up to 20 per point for >> FFT length 1024, plus the usual extra going-ons of any FFT. >> >> - >> From stefan at space.twc.de Thu Oct 14 06:00:23 2010 From: stefan at space.twc.de (Stefan Westerfeld) Date: Thu, 14 Oct 2010 12:00:23 +0200 Subject: [music-dsp] Sythesizing sines + noise in one IFFT In-Reply-To: References: <20101012092352.GA31047@space.twc.de> Message-ID: <20101014100023.GA22596@space.twc.de> Hi! On Tue, Oct 12, 2010 at 11:57:00AM +0200, Didier Dambrin wrote: > Do you have much knowledge on resynthesis btw? > I have an additive synth in progress, not FFT-based so I can easily adapt > per-partial pitch/phase, and I'm looking for someone to improve the (ok, > but not amazing) resynthesis analysis part. So it's pretty much about > building the best spectrogram that the engine will use, knowing the > spectrogram holds magnitudes, running pitch offset, but also absolute > phases and transient info, using an approach similar to the one of time > stretchers. Well, I am not sure if I can consider myself having much knowledge on resynthesis. :-) However I believe that the code I've been working on is a pretty fast implementation of sine synthesis (+ noise) via IFFT. Certainly it should outperform any additive approach, if there are enough partials. You can use the code if you want to (its LGPL), google for SpectMorph, clone the git repo and look at the IFFTSynth class. IFFT sine synthesis is pretty much done, right now I still have to optimize the noise part (to do everything in one FFT). Cu... Stefan -- Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan From didid at skynet.be Thu Oct 14 06:20:20 2010 From: didid at skynet.be (Didier Dambrin) Date: Thu, 14 Oct 2010 12:20:20 +0200 Subject: [music-dsp] Sythesizing sines + noise in one IFFT In-Reply-To: <20101014100023.GA22596@space.twc.de> References: <20101012092352.GA31047@space.twc.de> <20101014100023.GA22596@space.twc.de> Message-ID: <3362498F31824F80B3D09C4C8FA85C04@GOLAMD> Mine isn't based on a noise part, though. My spectrogram stores 6ms per pixel (this could be bigger if done better), and there's roughly 500 partials, it works well to resynthesize noisy stuff. The problems are the same as for a stretcher: phasey effects (reduced by detecting "master peaks" in each spectrogram slice), transient smearing (reduced by detecting transients & snapping to their phases, but this too could be improved). While it works "ok" for natural sounds (not compared to stretchers, but resynthesizers in general), what tells me that my analysis sucks is that it fails badly on synthesized tones. I cared too much about transients, so I picked the best window for that, and it sucks for synthetic tones/sustaining stuff, that's what I'd like to improve. Another idea would be to store "free partial vectors" (that would ideally follow pitch bends better) as opposed to a bitmap spectrogram, but I want the user to edit it normally in an image editor, so I prefer the bitmap approach. > Hi! > > On Tue, Oct 12, 2010 at 11:57:00AM +0200, Didier Dambrin wrote: >> Do you have much knowledge on resynthesis btw? >> I have an additive synth in progress, not FFT-based so I can easily adapt >> per-partial pitch/phase, and I'm looking for someone to improve the (ok, >> but not amazing) resynthesis analysis part. So it's pretty much about >> building the best spectrogram that the engine will use, knowing the >> spectrogram holds magnitudes, running pitch offset, but also absolute >> phases and transient info, using an approach similar to the one of time >> stretchers. > > Well, I am not sure if I can consider myself having much knowledge on > resynthesis. :-) However I believe that the code I've been working on is a > pretty fast implementation of sine synthesis (+ noise) via IFFT. Certainly > it > should outperform any additive approach, if there are enough partials. You > can > use the code if you want to (its LGPL), google for SpectMorph, clone the > git > repo and look at the IFFTSynth class. IFFT sine synthesis is pretty much > done, > right now I still have to optimize the noise part (to do everything in one > FFT). > > Cu... Stefan > -- From douglas at music.columbia.edu Thu Oct 14 07:31:29 2010 From: douglas at music.columbia.edu (douglas repetto) Date: Thu, 14 Oct 2010 07:31:29 -0400 Subject: [music-dsp] Sythesizing sines + noise in one IFFT In-Reply-To: <3362498F31824F80B3D09C4C8FA85C04@GOLAMD> References: <20101012092352.GA31047@space.twc.de> <20101014100023.GA22596@space.twc.de> <3362498F31824F80B3D09C4C8FA85C04@GOLAMD> Message-ID: <4CB6EA11.4020307@music.columbia.edu> SPEAR is a nice example of free partial editing: http://www.klingbeil.com/spear/ douglas On 10/14/10 6:20 AM, Didier Dambrin wrote: > Mine isn't based on a noise part, though. My spectrogram stores 6ms per > pixel (this could be bigger if done better), and there's roughly 500 > partials, it works well to resynthesize noisy stuff. The problems are > the same as for a stretcher: phasey effects (reduced by detecting > "master peaks" in each spectrogram slice), transient smearing (reduced > by detecting transients & snapping to their phases, but this too could > be improved). > While it works "ok" for natural sounds (not compared to stretchers, but > resynthesizers in general), what tells me that my analysis sucks is that > it fails badly on synthesized tones. I cared too much about transients, > so I picked the best window for that, and it sucks for synthetic > tones/sustaining stuff, that's what I'd like to improve. > Another idea would be to store "free partial vectors" (that would > ideally follow pitch bends better) as opposed to a bitmap spectrogram, > but I want the user to edit it normally in an image editor, so I prefer > the bitmap approach. > > >> Hi! >> >> On Tue, Oct 12, 2010 at 11:57:00AM +0200, Didier Dambrin wrote: >>> Do you have much knowledge on resynthesis btw? >>> I have an additive synth in progress, not FFT-based so I can easily >>> adapt >>> per-partial pitch/phase, and I'm looking for someone to improve the (ok, >>> but not amazing) resynthesis analysis part. So it's pretty much about >>> building the best spectrogram that the engine will use, knowing the >>> spectrogram holds magnitudes, running pitch offset, but also absolute >>> phases and transient info, using an approach similar to the one of time >>> stretchers. >> >> Well, I am not sure if I can consider myself having much knowledge on >> resynthesis. :-) However I believe that the code I've been working on >> is a >> pretty fast implementation of sine synthesis (+ noise) via IFFT. >> Certainly it >> should outperform any additive approach, if there are enough partials. >> You can >> use the code if you want to (its LGPL), google for SpectMorph, clone >> the git >> repo and look at the IFFTSynth class. IFFT sine synthesis is pretty >> much done, >> right now I still have to optimize the noise part (to do everything in >> one >> FFT). >> >> Cu... Stefan >> -- > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, 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 didid at skynet.be Thu Oct 14 07:36:44 2010 From: didid at skynet.be (Didier Dambrin) Date: Thu, 14 Oct 2010 13:36:44 +0200 Subject: [music-dsp] Sythesizing sines + noise in one IFFT In-Reply-To: <4CB6EA11.4020307@music.columbia.edu> References: <20101012092352.GA31047@space.twc.de> <20101014100023.GA22596@space.twc.de><3362498F31824F80B3D09C4C8FA85C04@GOLAMD> <4CB6EA11.4020307@music.columbia.edu> Message-ID: I know, I like the concept & usability, but it's kinda deceiving soundwise IMHO > > SPEAR is a nice example of free partial editing: > > http://www.klingbeil.com/spear/ > > > douglas > > > On 10/14/10 6:20 AM, Didier Dambrin wrote: >> Mine isn't based on a noise part, though. My spectrogram stores 6ms per >> pixel (this could be bigger if done better), and there's roughly 500 >> partials, it works well to resynthesize noisy stuff. The problems are >> the same as for a stretcher: phasey effects (reduced by detecting >> "master peaks" in each spectrogram slice), transient smearing (reduced >> by detecting transients & snapping to their phases, but this too could >> be improved). >> While it works "ok" for natural sounds (not compared to stretchers, but >> resynthesizers in general), what tells me that my analysis sucks is that >> it fails badly on synthesized tones. I cared too much about transients, >> so I picked the best window for that, and it sucks for synthetic >> tones/sustaining stuff, that's what I'd like to improve. >> Another idea would be to store "free partial vectors" (that would >> ideally follow pitch bends better) as opposed to a bitmap spectrogram, >> but I want the user to edit it normally in an image editor, so I prefer >> the bitmap approach. >> >> >>> Hi! >>> >>> On Tue, Oct 12, 2010 at 11:57:00AM +0200, Didier Dambrin wrote: >>>> Do you have much knowledge on resynthesis btw? >>>> I have an additive synth in progress, not FFT-based so I can easily >>>> adapt >>>> per-partial pitch/phase, and I'm looking for someone to improve the >>>> (ok, >>>> but not amazing) resynthesis analysis part. So it's pretty much about >>>> building the best spectrogram that the engine will use, knowing the >>>> spectrogram holds magnitudes, running pitch offset, but also absolute >>>> phases and transient info, using an approach similar to the one of time >>>> stretchers. >>> >>> Well, I am not sure if I can consider myself having much knowledge on >>> resynthesis. :-) However I believe that the code I've been working on >>> is a >>> pretty fast implementation of sine synthesis (+ noise) via IFFT. >>> Certainly it >>> should outperform any additive approach, if there are enough partials. >>> You can >>> use the code if you want to (its LGPL), google for SpectMorph, clone >>> the git >>> repo and look at the IFFTSynth class. IFFT sine synthesis is pretty >>> much done, >>> right now I still have to optimize the noise part (to do everything in >>> one >>> FFT). >>> >>> Cu... Stefan >>> -- >> >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, 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 > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.862 / Virus Database: 271.1.1/3195 - Release Date: 10/13/10 20:34:00 From pierre.leveau at audionamix.com Thu Oct 14 09:53:23 2010 From: pierre.leveau at audionamix.com (Pierre Leveau) Date: Thu, 14 Oct 2010 15:53:23 +0200 Subject: [music-dsp] Software / R&D engineer jobs at Audionamix in Paris Message-ID: <4CB70B53.9000604@audionamix.com> (apologies for cross-posting) Hello, Audionamix is hiring two software / R&D engineers in audio processing. One is targeted towards the development of libraries for advanced audio processing, the other towards user interfaces for audio. The detailed positions are described below: http://blog.audionamix.com/index.php/2010/10/08/job-rd-engineer-library-development-in-advanced-audio-dsp/ http://blog.audionamix.com/index.php/2010/10/08/job-rd-engineer-user-interactions-interface-development/ To apply, a CV and a motivation letter have to be sent to jobs at audionamix.com -- Regards, Pierre Leveau, PhD Chief Scientific Officer Phone: +33 1 40 05 52 82 Fax: +33 9 56 70 45 45 Email: pierre.leveau at audionamix.com From avanzini at dei.unipd.it Fri Oct 15 03:22:07 2010 From: avanzini at dei.unipd.it (federico avanzini) Date: Fri, 15 Oct 2010 09:22:07 +0200 Subject: [music-dsp] First call for participation to SMC2011 Message-ID: <4CB8011F.8000106@dei.unipd.it> [Apologies for cross-postings] [Please distribute] 8th Sound and Music Computing Conference, 06-09 July 2011 Department of Information Engineering, University of Padova Conservatorio Cesare Pollini, Padova http://smc2011.smcnetwork.org/ The SMC Conference is the forum for international exchanges around the core interdisciplinary topics of Sound and Music Computing. SMC 2011 will feature lectures, posters/demos, musical/sonic works, and other satellite events. The SMC Summer School will take place just before the Conference and it will aim at giving an opportunity to young researchers interested in the field to learn about some of the core interdisciplinary topics and to share their own experiences with other young researchers ================Important dates================= Deadline for submissions of papers and music: Friday 25 March, 2011 Deadline for applications to Summer School: Friday 25 March, 2011 Notification of acceptance to Summer School: Monday 18 April, 2011 Notification of paper and music acceptances: Friday 6 May, 2011 Deadline for submission of camera-ready papers: Friday 20 May, 2011 SMC 2011 Summer School: Saturday 2 - Tuesday 5 July, 2011 SMC 2011 Satellite Events: Wednesday 6 July, 2011 SMC 2011 Conference: Thursday 07 - Saturday 09 July, 2011 =========================================== The topics to be covered at the Conference are all the core ones in Sound and Music Computing research, and can be grouped into: . Processing of sound and music signals . Understanding and modeling sound and music . Interfaces for sound and music . Assisted sound and music creation ================Call for papers================== SMC 2011 will include paper presentations as both lectures and poster/ demos. We invite submissions examining all the core areas of the Sound and Music Computing field. All submissions will be peer-reviewed according to their novelty, technical content, presentation, and contribution to the overall balance of topics represented at the conference. Paper submissions should have a maximum of 8 pages including figures and references, and a length of 6 pages is strongly encouraged. Accepted papers will be designated to be presented either as posters/demos or as lectures. More details are available at http://smc2011.smcnetwork.org/call_for_participation.htm =========================================== Want to help us promote SMC2011? Insert a SMC2011 banner in your blog or web page (available at http://smc2011.smcnetwork.org/img/banner/), and link it to http://smc2011.smcnetwork.org/ Want to follow and share SMC2011 related news? Join and invite your friends to the SMC2011 facebook fanpage (linked from http://smc2011.smcnetwork.org/news.htm) -- ---------------------------------------- Federico Avanzini, PhD Sound and Music Computing Group Dep. of Information Engineering University of Padova Via Ognissanti 72 I-35129 Padova - ITALY Skype: federico.avanzini Tel: +39 049 827 7856 Fax: +39 049 827 7826 http://smc.dei.unipd.it http://www.dei.unipd.it/~avanzini ---------------------------------------- From douglas at music.columbia.edu Fri Oct 15 07:00:00 2010 From: douglas at music.columbia.edu (douglas repetto) Date: Fri, 15 Oct 2010 07:00:00 -0400 (EDT) Subject: [music-dsp] [admin] music-dsp FAQ Message-ID: <20101015110000.A5AE53584084@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 alan.wolfe at gmail.com Sat Oct 16 18:48:52 2010 From: alan.wolfe at gmail.com (Alan Wolfe) Date: Sat, 16 Oct 2010 15:48:52 -0700 Subject: [music-dsp] ring modulation Message-ID: When you do ring modulation, you are just multiplying 2 sound waves together right? I'm trying to implement this in a synth program where my sound data is in the range of -1 to 1. Should both sound waves be in this range or should the modulation wave be in the range of 0 to 1? thanks! From ebrombaugh1 at cox.net Sat Oct 16 19:00:03 2010 From: ebrombaugh1 at cox.net (Eric Brombaugh) Date: Sat, 16 Oct 2010 16:00:03 -0700 Subject: [music-dsp] ring modulation In-Reply-To: References: Message-ID: <4CBA2E73.2020309@cox.net> On 10/16/2010 03:48 PM, Alan Wolfe wrote: > When you do ring modulation, you are just multiplying 2 sound waves > together right? > > I'm trying to implement this in a synth program where my sound data is > in the range of -1 to 1. > > Should both sound waves be in this range or should the modulation wave > be in the range of 0 to 1? If the modulation wave stays in the range [0:1] then your carrier won't be nulled out. If the modulation wave ranges over [-1:1] then then carrier will be completely suppressed (assuming that the mean value of the modulation wave is 0) and you'll be left with just the sum & difference frequencies from the carrier & modulation. Eric From rbj at audioimagination.com Sat Oct 16 20:12:10 2010 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sat, 16 Oct 2010 20:12:10 -0400 Subject: [music-dsp] ring modulation In-Reply-To: References: Message-ID: <80F2EF3F-59D5-401E-9796-4A71FC365224@audioimagination.com> On Oct 16, 2010, at 6:48 PM, Alan Wolfe wrote: > When you do ring modulation, you are just multiplying 2 sound waves > together right? > > I'm trying to implement this in a synth program where my sound data is > in the range of -1 to 1. > > Should both sound waves be in this range or should the modulation wave > be in the range of 0 to 1? i think a ring modulator is a simple bipolar multiplication. but make sure your sampling rate is more than twice the *sum* of the bandwidths of the two signals. when multiplying two bandlimited signals together, their spectrums are convolved which makes the bandlimit of the result potentially as large as the sum of the bandlimits of each signal. -- r b-j rbj at audioimagination.com "Imagination is more important than knowledge." From stefan at space.twc.de Mon Oct 18 07:51:56 2010 From: stefan at space.twc.de (Stefan Westerfeld) Date: Mon, 18 Oct 2010 13:51:56 +0200 Subject: [music-dsp] Sythesizing sines + noise in one IFFT In-Reply-To: <20101012092352.GA31047@space.twc.de> References: <20101007113951.GA9349@space.twc.de> <20101011131902.GA21104@space.twc.de> <20101012092352.GA31047@space.twc.de> Message-ID: <20101018115156.GA4257@space.twc.de> Hi! I'm finally finished implementing SSE convolution with the blackman harris window response. So now applying the window takes about 4.7 cycles per output sample, whereas the FFT used to take about 20 cycles per output sample. So the new implementation is a lot faster than the old :-), using only one single FFT per buffer to synthesize, instead of two. Cu... Stefan On Tue, Oct 12, 2010 at 11:23:52AM +0200, Stefan Westerfeld wrote: > Thanks, I think this is the answer I was looking for - I've implemented a > simple convolution using normal FPU, just to see how fast it would be, and its > about twice as fast as the FFT. However, I assume it will be even faster if I > SSEify it (thats the next thing I'll try). So with SSEified convolution, I > should be able to get rid of the extra FFT and replace it with something a lot > less expensive. It'll take some coding to figure out how much CPU power it'll > take all together, but yes, convolution with the real/symmetric BH92 spectrum > sounds like the right way to go :-). > > Cu... Stefan > > On Mon, Oct 11, 2010 at 03:26:19PM +0100, xue wen wrote: > > Actually the spectral convolution you proposed doesn't seem that bad. Spectrum of a BH92 window is 7 point long, real and symmetric - that comes down to 4 real-complex multiplications and 6 complex additions per point if you do convolution, and reduced to 4 real-real multiplications and 6 real additions per point considering spectral symmetry. For comparison, if you do a separate IFFT it'll be 2log2(FFT length) real-real multiplications per point, which goes up to 20 per point for FFT length 1024, plus the usual extra going-ons of any FFT. > > > > - > > ________________________________________ > > From: music-dsp-bounces at music.columbia.edu [music-dsp-bounces at music.columbia.edu] On Behalf Of Stefan Westerfeld [stefan at space.twc.de] > > Sent: 11 October 2010 14:19 > > To: Jean-Marc Valin > > Cc: music-dsp at music.columbia.edu > > Subject: Re: [music-dsp] Sythesizing sines + noise in one IFFT > > > > Hi! > > > > On Sun, Oct 10, 2010 at 06:50:44PM -0400, Jean-Marc Valin wrote: > > > I think what you want to use is simply a "power complementary" window. > > > The simplest is the sine window (aka sqrt(hanning)), but you could also > > > use the Vorbis window which is sin(pi/2 * sin^2(M_PI*x/N)) > > > > > > If you apply the same window in the analysis of the sinusoids, then you > > > end up with no gain compensation required after the IFFT. Similarly, > > > when you use it for noise synthesis, it works because noise adds up in > > > the energy domain, so again no need to do any sort of gain adjustment. > > > I've actually use that technique in the past for a different > > > application: http://jmvalin.ca/papers/valin_hscma2008.pdf > > > > I've read your paper now, but I don't see how I could make it work in my case. > > If you just analyze a signal composed of a few sines with a window, then of > > course the spectrum will be convoluted with the window's frequency response, so > > you can IFFT this, and get the original signal back. > > > > But in my case, the analysis process will produce a list of sine signals (with > > frequency, magnitude and phase), so to resynthesize this, I need to produce the > > spectrum myself. With windows that have a lengthy frequency response, this will > > be more expensive than with windows like blackman harris 92, which have a > > narrow frequency response; I need to reproduce the spectrum, so effectively for > > each sine component, I add a shifted/rotated version of the window's frequency > > response to the spectrum. An IFFT yields a windowed version of the sine part of > > the signal. I rescale this windowed signal (because for overlap-add, I use a > > cosine window, not blackman harris 92) to get my sine signal. > > > > For noise, on the other hand, I just put the right amount of energy in each > > band, IFFT this, and get a noise time signal. BUT, I need to apply scaling to > > this noise signal before overlap-add is possible (and the scaling is different > > from the scaling I need to apply to the sine signal), so I need two IFFTs to do > > the job, which is the part of the algorithm that I would like to improve. If > > thats possible at all, that is. > > > > Cu... Stefan > > -- > > Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan > > -- > > dupswapdrop -- the music-dsp mailing list and website: > > subscription info, FAQ, 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 > > -- > Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -- Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan From stefan at space.twc.de Mon Oct 18 08:00:07 2010 From: stefan at space.twc.de (Stefan Westerfeld) Date: Mon, 18 Oct 2010 14:00:07 +0200 Subject: [music-dsp] Sythesizing sines + noise in one IFFT In-Reply-To: <201010111734.20661.david@olofson.net> References: <201010102351.51169.david@olofson.net> <20101011132938.GB21104@space.twc.de> <201010111734.20661.david@olofson.net> Message-ID: <20101018120007.GA4307@space.twc.de> Hi! On Mon, Oct 11, 2010 at 05:34:20PM +0200, David Olofson wrote: > On Monday 11 October 2010, at 15.29.38, Stefan Westerfeld > wrote: > > [...] > > > > In my current prototype, I'm using a 512 bin IFFT for generating a 64 > > > > sample window every 32'nd output sample (overlapping with a Hann window, > > > > so no AM issues), which sounds good enough for a single pure sine to my > > > > ears. > > > > > > > > That's right; I'm only actually using one 8'th of the FFT output...! > > > > > > From my experience I'd say that you create performance problems if you need > > > larger FFT sizes than the number of output samples. The FFT is O(N log N), > > > which means that if you can only use 1/8 of the FFT output, you are > > > probably more than 8 times slower than an algorithm which uses every > > > sample of the FFT. > > That would have to depend on the cost of the extra work you need to do to get > by with a smaller FFT, right? How many sine components can you run with 9 bins > before that becomes more expensive than the FFT? Well, with my codebase, adding one partial to the FFT (with 9 bins) takes about 0.23 cycles. An FFT takes about 20 cycles. If you use an 8 times as large FFT, it will take more than 160 cycles. So 140/.23 = 608 partials are required before using a bigger FFT might be beneficial, but thats assuming that with the bigger approach all per-partial costs disappear. So probably 1000 partials or so are required before a bigger FFT might be faster. In my scenario thats unrealistic, because I only synthesize one instrument voice per FFT, but if you combine many sounds before synthesis this case might occur in real world scenarios. > I'm thinking that for maximum scalability (which is what I'm after; anything > from one sine through many thousands should be handled efficiently), one should > probably use a set of different configurations, ranging from no FFT at all > (time domain oscillator bank) for small numbers of components, via "many" bins > per component, through two or three bins per component for insane numbers of > components. Yes, maybe you may want to implement different algorithms and pick the right one depending on partial count for a general framework. Cu... Stefan -- Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan From alan.wolfe at gmail.com Mon Oct 18 14:42:34 2010 From: alan.wolfe at gmail.com (Alan Wolfe) Date: Mon, 18 Oct 2010 11:42:34 -0700 Subject: [music-dsp] ring modulation In-Reply-To: References: <80F2EF3F-59D5-401E-9796-4A71FC365224@audioimagination.com> Message-ID: Funny enough Robert, I saw this in action. I multiplied to waves together and it looks as though the output is twice the frequency of the input waves. I'm trying to wrap my head around why it is, but i observed it happen at least :P Oh also I found info saying that the modulation wave should be in the range of [0,1] and the carrier wave should be [-1,1] and i do seem to get the intended audio results when doing it that way (although the other way is interesting too!). Thanks everyone (: On Sat, Oct 16, 2010 at 5:19 PM, Alan Wolfe wrote: > I'm a bit of a nooblet could you explain what you mean by that?? Do you mean > not to use frequencies over half my sample rate? > > On Oct 16, 2010 5:12 PM, "robert bristow-johnson" > wrote: > > > On Oct 16, 2010, at 6:48 PM, Alan Wolfe wrote: > >> When you do ring modulation, you are just multipl... > > i think a ring modulator is a simple bipolar multiplication. > > but make sure your sampling rate is more than twice the *sum* of the > bandwidths of the two signals. ?when multiplying two bandlimited signals > together, their spectrums are convolved which makes the bandlimit of the > result potentially as large as the sum of the bandlimits of each signal. > > -- > > r b-j ? ? ? ? ? ? ? ? ?rbj at audioimagination.com > > "Imagination is more important than knowledge." > > > > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code a... From earlevel at earlevel.com Mon Oct 18 15:31:36 2010 From: earlevel at earlevel.com (Nigel Redmon) Date: Mon, 18 Oct 2010 12:31:36 -0700 Subject: [music-dsp] ring modulation In-Reply-To: References: <80F2EF3F-59D5-401E-9796-4A71FC365224@audioimagination.com> Message-ID: <80D24495-73C8-46A2-B8D1-D19090801929@earlevel.com> That's amplitude modulation (AM). "Ring" (from a four-diode ring circuitry used to implement it, IIRC) modulation is a "four quadrant" multiple, as Robert suggested. So, amplitude modulation, if you're a modular-synth guy, is embodied in a VCA; you can use a ring modulator as VCA if you keep the control 0->1. On Oct 18, 2010, at 11:42 AM, Alan Wolfe wrote: > Oh also I found info saying that the modulation wave should be in the > range of [0,1] and the carrier wave should be [-1,1] and i do seem to > get the intended audio results when doing it that way (although the > other way is interesting too!). From alan.wolfe at gmail.com Mon Oct 18 15:45:56 2010 From: alan.wolfe at gmail.com (Alan Wolfe) Date: Mon, 18 Oct 2010 12:45:56 -0700 Subject: [music-dsp] ring modulation In-Reply-To: <80D24495-73C8-46A2-B8D1-D19090801929@earlevel.com> References: <80F2EF3F-59D5-401E-9796-4A71FC365224@audioimagination.com> <80D24495-73C8-46A2-B8D1-D19090801929@earlevel.com> Message-ID: ok so just to make sure I have this is correct... Both ring modulation and amplitude modulation have a carrier signal in the range of [-1,1] that is multiplied by a modulation wave. In amplitude modulation, the modulation wave is in the range of [0,1] In ring modulation, the modulation wave is in the range of [-1,1] On Mon, Oct 18, 2010 at 12:31 PM, Nigel Redmon wrote: > That's amplitude modulation (AM). "Ring" (from a four-diode ring circuitry used to implement it, IIRC) modulation is a "four quadrant" multiple, as Robert suggested. > > So, amplitude modulation, if you're a modular-synth guy, is embodied in a VCA; you can use a ring modulator as VCA if you keep the control 0->1. > > On Oct 18, 2010, at 11:42 AM, Alan Wolfe wrote: >> Oh also I found info saying that the modulation wave should be in the >> range of [0,1] and the carrier wave should be [-1,1] and i do seem to >> get the intended audio results when doing it that way (although the >> other way is interesting too!). > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, 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 Oct 18 16:00:12 2010 From: richarddobson at blueyonder.co.uk (Richard Dobson) Date: Mon, 18 Oct 2010 21:00:12 +0100 Subject: [music-dsp] ring modulation In-Reply-To: References: <80F2EF3F-59D5-401E-9796-4A71FC365224@audioimagination.com> <80D24495-73C8-46A2-B8D1-D19090801929@earlevel.com> Message-ID: <4CBCA74C.1020107@blueyonder.co.uk> On 18/10/2010 20:45, Alan Wolfe wrote: > ok so just to make sure I have this is correct... > > Both ring modulation and amplitude modulation have a carrier signal in > the range of [-1,1] that is multiplied by a modulation wave. > > In amplitude modulation, the modulation wave is in the range of [0,1] > > In ring modulation, the modulation wave is in the range of [-1,1] > Ring modualtion is a bit of a special case in that it is, literally, multiplying two signals together (sample by sample when performed digitally). Of course in most cases one signal is your musical input (Dalek voice etc) and the other is some simple sinusoid; but technically the two signals are of equal status, as are the numbers either side of a multiply sign. Neither is carrier or modulator except in the mind of the operator. They could both be live musical signals, with the usual caveat not to make the result too spectrally overblown. Richard Dobson From alan.wolfe at gmail.com Mon Oct 18 16:05:38 2010 From: alan.wolfe at gmail.com (Alan Wolfe) Date: Mon, 18 Oct 2010 13:05:38 -0700 Subject: [music-dsp] ring modulation In-Reply-To: <4CBCA74C.1020107@blueyonder.co.uk> References: <80F2EF3F-59D5-401E-9796-4A71FC365224@audioimagination.com> <80D24495-73C8-46A2-B8D1-D19090801929@earlevel.com> <4CBCA74C.1020107@blueyonder.co.uk> Message-ID: Totally makes sense Thanks a ton (: On Mon, Oct 18, 2010 at 1:00 PM, Richard Dobson wrote: > On 18/10/2010 20:45, Alan Wolfe wrote: >> >> ok so just to make sure I have this is correct... >> >> Both ring modulation and amplitude modulation have a carrier signal in >> the range of [-1,1] that is multiplied by a modulation wave. >> >> In amplitude modulation, the modulation wave is in the range of [0,1] >> >> In ring modulation, the modulation wave is in the range of [-1,1] >> > > Ring modualtion is a bit of a special case in that it is, literally, > multiplying two signals together (sample by sample when performed > digitally). Of course in most cases one signal is your musical input (Dalek > voice etc) and the other is some simple sinusoid; but technically the two > signals are of equal status, as are the numbers either side of a multiply > sign. Neither is carrier or modulator except in the mind of the operator. > They could both be live musical signals, with the usual caveat not to make > the result too spectrally overblown. > > 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 jchandjr at bellsouth.net Mon Oct 18 16:57:03 2010 From: jchandjr at bellsouth.net (James Chandler Jr) Date: Mon, 18 Oct 2010 16:57:03 -0400 Subject: [music-dsp] ring modulation In-Reply-To: <80D24495-73C8-46A2-B8D1-D19090801929@earlevel.com> References: <80F2EF3F-59D5-401E-9796-4A71FC365224@audioimagination.com> <80D24495-73C8-46A2-B8D1-D19090801929@earlevel.com> Message-ID: <6CE33E35-145B-4A8E-AD43-3E5E210A378F@bellsouth.net> Some VCA circuits were not capable of four quadrant modulation, and some VCAs were capable of the trick. Many or most folks on this list are aware of that, but just wanted to clarify for those who might misunderstand. Some VCA circuits would turn off with "zero control input" and stay turned off with "negative control input". I was impressed back in the old days with the balanced multiplier vca circuits which were smart enough to change from being a non-inverting VCA with positive control input, into being an inverting VCA with negative control input. It was a neat trick in analog. Though, from the perspective of front panel inputs/outputs, the circuits worked like four-quadrant multiplication on ground-referenced AC signals (+/- 1 or whatever)-- The actual internal circuitry would often need offsets and biases and nulling trimmer resistors to do the trick. Sometimes inside the circuit it needed to play tricks to "fool" a two quadrant multiplier into behaving like a four quadrant multiplier. Apologies for being pedantic. James Chandler Jr On Oct 18, 2010, at 3:31 PM, Nigel Redmon wrote: > That's amplitude modulation (AM). "Ring" (from a four-diode ring circuitry used to implement it, IIRC) modulation is a "four quadrant" multiple, as Robert suggested. > > So, amplitude modulation, if you're a modular-synth guy, is embodied in a VCA; you can use a ring modulator as VCA if you keep the control 0->1. > > On Oct 18, 2010, at 11:42 AM, Alan Wolfe wrote: >> Oh also I found info saying that the modulation wave should be in the >> range of [0,1] and the carrier wave should be [-1,1] and i do seem to >> get the intended audio results when doing it that way (although the >> other way is interesting too!). > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From rbj at audioimagination.com Mon Oct 18 19:06:32 2010 From: rbj at audioimagination.com (robert bristow-johnson) Date: Mon, 18 Oct 2010 19:06:32 -0400 Subject: [music-dsp] ring modulation In-Reply-To: <6CE33E35-145B-4A8E-AD43-3E5E210A378F@bellsouth.net> References: <80F2EF3F-59D5-401E-9796-4A71FC365224@audioimagination.com> <80D24495-73C8-46A2-B8D1-D19090801929@earlevel.com> <6CE33E35-145B-4A8E-AD43-3E5E210A378F@bellsouth.net> Message-ID: <51D9DA72-98E4-4709-8583-1D2A8D1802E9@audioimagination.com> On Oct 18, 2010, at 4:57 PM, James Chandler Jr wrote: > I was impressed back in the old days with the balanced multiplier > vca circuits which were smart enough to change from being a non- > inverting VCA with positive control input, into being an inverting > VCA with negative control input. It was a neat trick in analog. > > Though, from the perspective of front panel inputs/outputs, the > circuits worked like four-quadrant multiplication on ground- > referenced AC signals (+/- 1 or whatever)-- The actual internal > circuitry would often need offsets and biases and nulling trimmer > resistors to do the trick. Sometimes inside the circuit it needed to > play tricks to "fool" a two quadrant multiplier into behaving like a > four quadrant multiplier. Apologies for being pedantic. 0 dunno why, but i never considered that extension to be particularly tricky. it's just an issue of biasing. like how did we use them transistors to amplify a bipolar signal? suppose you have a 1-quadrant multiplier that works good and you want to make it into a 4-quadrant multiplier. (and let's say that your signals have magnitude less than 1.) x(t)*y(t) = (1 + x(t))*(1 + y(t)) - x(t) - y(t) - 1 given the 1-quadrant multiplier as a black box, it doesn't seem too hard to put together an op-amp circuit to do either of the above. -- r b-j rbj at audioimagination.com "Imagination is more important than knowledge." From jchandjr at bellsouth.net Mon Oct 18 21:38:26 2010 From: jchandjr at bellsouth.net (James Chandler Jr) Date: Mon, 18 Oct 2010 21:38:26 -0400 Subject: [music-dsp] ring modulation In-Reply-To: <51D9DA72-98E4-4709-8583-1D2A8D1802E9@audioimagination.com> References: <80F2EF3F-59D5-401E-9796-4A71FC365224@audioimagination.com> <80D24495-73C8-46A2-B8D1-D19090801929@earlevel.com> <6CE33E35-145B-4A8E-AD43-3E5E210A378F@bellsouth.net> <51D9DA72-98E4-4709-8583-1D2A8D1802E9@audioimagination.com> Message-ID: <5AAC2497-B5DF-44E7-8025-E158C0FBE1F0@bellsouth.net> Thanks Robert You are correct it isn't especially tricky. I'm easier impressed than you. ;) You are an excellent EE and I'm a hacker who studied a few appnotes and synthesizer circuits. Just wanted to caution young folks not to expect the typical old synthesizer VCA to be a four-quadrant multiplier. I recall simple low-parts-count four quadrant multipliers from CA3080 appnotes though it worked with many OTAs. It was 'good enough' for audio use, though maybe not good enough for analog computer circuits or communications. The simplest incarnation may be figure 23 here-- http://www.intersilsemi.com/data/an/an6668.pdf A slightly more practical variation top of page 75 here-- http://www.schematicsforfree.com/archive/file/Op-Amps%20&%20Comparitors/3080%20Circuits.pdf Analog synth circuits were fun. James Chandler Jr. On Oct 18, 2010, at 7:06 PM, robert bristow-johnson wrote: > > On Oct 18, 2010, at 4:57 PM, James Chandler Jr wrote: > >> I was impressed back in the old days with the balanced multiplier vca circuits which were smart enough to change from being a non-inverting VCA with positive control input, into being an inverting VCA with negative control input. It was a neat trick in analog. >> >> Though, from the perspective of front panel inputs/outputs, the circuits worked like four-quadrant multiplication on ground-referenced AC signals (+/- 1 or whatever)-- The actual internal circuitry would often need offsets and biases and nulling trimmer resistors to do the trick. Sometimes inside the circuit it needed to play tricks to "fool" a two quadrant multiplier into behaving like a four quadrant multiplier. Apologies for being pedantic. 0 > > dunno why, but i never considered that extension to be particularly tricky. it's just an issue of biasing. like how did we use them transistors to amplify a bipolar signal? > > suppose you have a 1-quadrant multiplier that works good and you want to make it into a 4-quadrant multiplier. (and let's say that your signals have magnitude less than 1.) > > > x(t)*y(t) = (1 + x(t))*(1 + y(t)) - x(t) - y(t) - 1 > > > given the 1-quadrant multiplier as a black box, it doesn't seem too hard to put together an op-amp circuit to do either of the above. > > -- > > r b-j rbj at 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 kevin.c.dixon at gmail.com Tue Oct 19 02:54:11 2010 From: kevin.c.dixon at gmail.com (Kevin Dixon) Date: Mon, 18 Oct 2010 23:54:11 -0700 Subject: [music-dsp] BiQuad Magnitude Frequency Response problem Message-ID: Hi all, I was following this thread to calculate the magnitude frequency response of a BiQuad filter (as discussed in RBJ's cookbook): http://groups.google.com/group/comp.dsp/browse_frm/thread/8c0fa8d396aeb444/a1bc5b63ac56b686 in message 9, RBJ shows his revised equation, which I've implemented as such, where "atFreq" is the input parameter of frequency to calculate for. Float64 w = 2.0 * pi * atFreq / lastSampleRate; Float64 phi = 4.0 * pow(sin(w / 2.0), 2.0); Float64 c1 = 10.0 * log10(pow(b0+b1+b2, 2.0) + ( b0*b2*phi - (b1*(b0+b2) + 4.0 * b0 * b2) )*phi) ; Float64 c2 = 10.0 * log10(pow(a0+a1+a2, 2.0) + ( a0*a2*phi - (a1*(a0+a2) + 4.0 * a0 * a2) )*phi); return fabs(c1 - c2); c1 is the first bit of the equation, and c2 is the second. I'm trying to write a GUI to display the curve, so the GUI calculates the frequencies it wants based on the real estate it has to render in... I must have a bug, because my curves are coming out looking backwards. When I calculate for a low-pass at 500Hz, 0.7Q, I wind up with data points that look like a high-pass at 500Hz, but with some sort of boost. I know that my filter is implemented correctly, because if I run fuzzmeasure through my filter, the frequency response is proper. Please see the following links for the problem http://yano.wasteonline.net/software/bass/lp_plot.png http://yano.wasteonline.net/software/bass/lp_data.txt Anyone see any glaring problems with my implementation? Or maybe I'm missing some point entirely.... Thank in advance -kevin From padawan12 at obiwannabe.co.uk Tue Oct 19 02:58:04 2010 From: padawan12 at obiwannabe.co.uk (Andy Farnell) Date: Tue, 19 Oct 2010 07:58:04 +0100 Subject: [music-dsp] ring modulation In-Reply-To: <5AAC2497-B5DF-44E7-8025-E158C0FBE1F0@bellsouth.net> References: <80F2EF3F-59D5-401E-9796-4A71FC365224@audioimagination.com> <80D24495-73C8-46A2-B8D1-D19090801929@earlevel.com> <6CE33E35-145B-4A8E-AD43-3E5E210A378F@bellsouth.net> <51D9DA72-98E4-4709-8583-1D2A8D1802E9@audioimagination.com> <5AAC2497-B5DF-44E7-8025-E158C0FBE1F0@bellsouth.net> Message-ID: <20101019075804.16f15c54.padawan12@obiwannabe.co.uk> On Mon, 18 Oct 2010 21:38:26 -0400 James Chandler Jr wrote: > Analog synth circuits were fun. Fond memories of the 3080. There was a Maplin (do they exist outside UK?) book I built a "robot voice" from. -- Andy Farnell From andrew.capon at zen.co.uk Tue Oct 19 03:09:20 2010 From: andrew.capon at zen.co.uk (Andrew Capon) Date: Tue, 19 Oct 2010 09:09:20 +0200 Subject: [music-dsp] ring modulation In-Reply-To: <20101019075804.16f15c54.padawan12@obiwannabe.co.uk> References: <80F2EF3F-59D5-401E-9796-4A71FC365224@audioimagination.com> <80D24495-73C8-46A2-B8D1-D19090801929@earlevel.com> <6CE33E35-145B-4A8E-AD43-3E5E210A378F@bellsouth.net> <51D9DA72-98E4-4709-8583-1D2A8D1802E9@audioimagination.com> <5AAC2497-B5DF-44E7-8025-E158C0FBE1F0@bellsouth.net> <20101019075804.16f15c54.padawan12@obiwannabe.co.uk> Message-ID: Analog synth circuits are still fun : http://www.musicfromouterspace.com/ Andy On 19 Oct 2010, at 08:58, Andy Farnell wrote: > On Mon, 18 Oct 2010 21:38:26 -0400 > James Chandler Jr wrote: > >> Analog synth circuits were fun. > > Fond memories of the 3080. There was a Maplin (do they exist > outside UK?) book I built a "robot voice" from. > > -- > Andy Farnell > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, 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 Tue Oct 19 07:13:51 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Tue, 19 Oct 2010 22:13:51 +1100 Subject: [music-dsp] BiQuad Magnitude Frequency Response problem References: Message-ID: <054a01cb6f82$1c26fd60$0242000a@rossmacbook> Hi Kevin You might want to double check that that the coefficients you are inputting into those formulas are correct and match the transfer function in that thread (some people use a for numerator and b for denominator and vis-versa, also b0 is sometimes factored out.. so take care). Ross. From risto.holopainen at imv.uio.no Tue Oct 19 08:07:10 2010 From: risto.holopainen at imv.uio.no (Risto Holopainen) Date: Tue, 19 Oct 2010 14:07:10 +0200 Subject: [music-dsp] ring modulation In-Reply-To: <5AAC2497-B5DF-44E7-8025-E158C0FBE1F0@bellsouth.net> References: <80F2EF3F-59D5-401E-9796-4A71FC365224@audioimagination.com> <80D24495-73C8-46A2-B8D1-D19090801929@earlevel.com> <6CE33E35-145B-4A8E-AD43-3E5E210A378F@bellsouth.net> <51D9DA72-98E4-4709-8583-1D2A8D1802E9@audioimagination.com> <5AAC2497-B5DF-44E7-8025-E158C0FBE1F0@bellsouth.net> Message-ID: <0867d9ed4eebdd0002d9c0a06d6f52e9.squirrel@webmail.uio.no> Analog ring modulators sound very different from the straightforward digital implementation with just a multiplication, there is a distinctive sound that can be heard on several Stockhausen pieces for instance. I don't know why, since analog electronics remains a mystery to me, but there is a paper in dafx 2009 by Hoffmann-Burchardi that gives a formula for digital simulation. It goes like this: z[n] = (ax[n] + y[n]) * tanh(x[n] + by[n]) + cx[n] + dy[n] where a,b,c,d are small positive constants. Perhaps this formula can be explained by some imperfections in the four quadrant multiplier? Obviously the point about watching out for aliasing is even more critical here. Risto > On Oct 18, 2010, at 7:06 PM, robert bristow-johnson wrote: > >> >> suppose you have a 1-quadrant multiplier that works good and you want to >> make it into a 4-quadrant multiplier. (and let's say that your signals >> have magnitude less than 1.) >> >> >> x(t)*y(t) = (1 + x(t))*(1 + y(t)) - x(t) - y(t) - 1 >> >> >> given the 1-quadrant multiplier as a black box, it doesn't seem too hard >> to put together an op-amp circuit to do either of the above. >> >> -- >> >> r b-j rbj at audioimagination.com >> >> "Imagination is more important than knowledge." >> >> From rbj at audioimagination.com Tue Oct 19 10:28:52 2010 From: rbj at audioimagination.com (robert bristow-johnson) Date: Tue, 19 Oct 2010 10:28:52 -0400 Subject: [music-dsp] BiQuad Magnitude Frequency Response problem In-Reply-To: References: Message-ID: On Oct 19, 2010, at 2:54 AM, Kevin Dixon wrote: > Hi all, > > I was following this thread to calculate the magnitude frequency > response of a BiQuad filter (as discussed in RBJ's cookbook): > http://groups.google.com/group/comp.dsp/browse_frm/thread/8c0fa8d396aeb444/a1bc5b63ac56b686 > in message 9, RBJ shows his revised equation, which I've implemented > as such, where "atFreq" is the input parameter of frequency to > calculate for. > > Float64 w = 2.0 * pi * atFreq / lastSampleRate; > Float64 phi = 4.0 * pow(sin(w / 2.0), 2.0); > > Float64 c1 = 10.0 * log10(pow(b0+b1+b2, 2.0) + ( b0*b2*phi - > (b1*(b0+b2) + 4.0 * b0 * b2) )*phi) ; > > Float64 c2 = 10.0 * log10(pow(a0+a1+a2, 2.0) + ( a0*a2*phi - > (a1*(a0+a2) + 4.0 * a0 * a2) )*phi); > > return fabs(c1 - c2); this looks okay to me except for the fabs(). that should neither be necessary nor desired. but the worst that it should do is flip part of your response upside down. > > c1 is the first bit of the equation, and c2 is the second. I'm trying > to write a GUI to display the curve, so the GUI calculates the > frequencies it wants based on the real estate it has to render in... I > must have a bug, because my curves are coming out looking backwards. > When I calculate for a low-pass at 500Hz, 0.7Q, I wind up with data > points that look like a high-pass at 500Hz, but with some sort of > boost. I know that my filter is implemented correctly, because if I > run fuzzmeasure through my filter, the frequency response is proper. you haven't told us what your coefficients are. now, if you define your LPF coefficients as so: w0 = 2*pi*f0/Fs alpha = sin(w0)/(2*Q) LPF: H(s) = 1 / (s^2 + s/Q + 1) b0 = (1 - cos(w0))/2 b1 = 1 - cos(w0) b2 = (1 - cos(w0))/2 a0 = 1 + alpha a1 = -2*cos(w0) a2 = 1 - alpha and then evaluate your dB gain as: 20*log10[ |H(e^jw)| ] = 10 * ( log10[(b0+b1+b2)^2 + ( b0*b2*phi - (b1*(b0+b2) + 4*b0*b2) )*phi] - log10[(a0+a1+a2)^2 + ( a0*a2*phi - (a1*(a0+a2) + 4*a0*a2) )*phi] ) where phi = 4*sin^2(w/2) w = 2*pi*f/Fs 0 < f < Fs then you still have problems? i guess i would like to see the coefs you have. -- r b-j rbj at audioimagination.com "Imagination is more important than knowledge." From earlevel at earlevel.com Tue Oct 19 16:28:55 2010 From: earlevel at earlevel.com (Nigel Redmon) Date: Tue, 19 Oct 2010 13:28:55 -0700 Subject: [music-dsp] ring modulation In-Reply-To: <0867d9ed4eebdd0002d9c0a06d6f52e9.squirrel@webmail.uio.no> References: <80F2EF3F-59D5-401E-9796-4A71FC365224@audioimagination.com> <80D24495-73C8-46A2-B8D1-D19090801929@earlevel.com> <6CE33E35-145B-4A8E-AD43-3E5E210A378F@bellsouth.net> <51D9DA72-98E4-4709-8583-1D2A8D1802E9@audioimagination.com> <5AAC2497-B5DF-44E7-8025-E158C0FBE1F0@bellsouth.net> <0867d9ed4eebdd0002d9c0a06d6f52e9.squirrel@webmail.uio.no> Message-ID: Are you sure Stockhausen wasn't using a frequency shifter, and not a ring modulator? Just wondering--I don't know. We had a 360 Systems Frequency Shifter (a green one) in the electronic music lab at USC back in the 70's. I had a ring modulator on my home-built modular (mostly based on Aries modules) back then (well, still have it, but long time since power-up). Quite a different sound. A frequency shifter suppresses one sideband, so that all harmonics are shifted one way by a fixed amount (hence the harmonics will diverge). I just did a search and found a a forum post at gearslutz discussing frequency shifters, and the poster said, "Small shifts gave deep phasing effects, larger shifts were -interesting, if not over musically useful (frequency differences which were related to a note gave strange harmonic structures, when the note changes, purest dissonance- very Stockhausen)". On Oct 19, 2010, at 5:07 AM, Risto Holopainen wrote: > > Analog ring modulators sound very different from the straightforward > digital implementation with just a multiplication, there is a distinctive > sound that can be heard on several Stockhausen pieces for instance. I > don't know why, since analog electronics remains a mystery to me, but > there is a paper in dafx 2009 by Hoffmann-Burchardi that gives a formula > for digital simulation. It goes like this: > > z[n] = (ax[n] + y[n]) * tanh(x[n] + by[n]) + cx[n] + dy[n] > > where a,b,c,d are small positive constants. Perhaps this formula can be > explained by some imperfections in the four quadrant multiplier? Obviously > the point about watching out for aliasing is even more critical here. > > Risto From ebrombaugh1 at cox.net Tue Oct 19 16:45:35 2010 From: ebrombaugh1 at cox.net (Eric Brombaugh) Date: Tue, 19 Oct 2010 13:45:35 -0700 Subject: [music-dsp] ring modulation In-Reply-To: References: <80F2EF3F-59D5-401E-9796-4A71FC365224@audioimagination.com> <80D24495-73C8-46A2-B8D1-D19090801929@earlevel.com> <6CE33E35-145B-4A8E-AD43-3E5E210A378F@bellsouth.net> <51D9DA72-98E4-4709-8583-1D2A8D1802E9@audioimagination.com> <5AAC2497-B5DF-44E7-8025-E158C0FBE1F0@bellsouth.net> <0867d9ed4eebdd0002d9c0a06d6f52e9.squirrel@webmail.uio.no> Message-ID: <4CBE036F.7040304@cox.net> On 10/19/2010 01:28 PM, Nigel Redmon wrote: > Are you sure Stockhausen wasn't using a frequency shifter, and not a ring modulator? Just wondering--I don't know. > > We had a 360 Systems Frequency Shifter (a green one) in the electronic music lab at USC back in the 70's. I had a ring modulator on my home-built modular (mostly based on Aries modules) back then (well, still have it, but long time since power-up). Quite a different sound. A frequency shifter suppresses one sideband, so that all harmonics are shifted one way by a fixed amount (hence the harmonics will diverge). > > I just did a search and found a a forum post at gearslutz discussing frequency shifters, and the poster said, "Small shifts gave deep phasing effects, larger shifts were -interesting, if not over musically useful (frequency differences which were related to a note gave strange harmonic structures, when the note changes, purest dissonance- very Stockhausen)". Frequency shifters are fun. I've done a couple different ones in DSP for various modular synth manufacturers and in the course of bringing them up become pretty familiar with the things you can get out of them 1) small (< 10Hz) shifts with full wet mix & no regeneration provide for subtle phasing effects that sound like motion in the soundscape. 2) small shifts with various degrees of wet/dry mixing cause a sweeping notch-filter effect due to selective phase cancellation. 3) regeneration (mixing some output back to the input) with a small shift results in a sweeping resonance peak. Depending on how much feedback is used this can break into self-oscillation. Using either positive or negative regen can make subtle changes in the sound. 4) As noted, large shifts are interesting in a 'f#$k s&*t up' kind of way, but may be difficult to use in a particularly musical way. Eric From np at planetarc.de Tue Oct 19 16:49:55 2010 From: np at planetarc.de (Nils Pipenbrinck) Date: Tue, 19 Oct 2010 22:49:55 +0200 Subject: [music-dsp] fx architecture: Interleaved or flat samples.. Message-ID: <4CBE0473.3070004@planetarc.de> Hi folks. I'm currently working on a simple toy multieffect. Since I've never written such a thing I wonder in which order you keep your sample buffers in memory? Do you usually work with a single buffer containing the samples of all channels interleaved (e.g. how the data usually gets delivered from the codec) or do you split the buffers and work on a 'per channel basis? Any pros/cons/ideas about that? Cheers, Nils From kevin.c.dixon at gmail.com Tue Oct 19 17:03:33 2010 From: kevin.c.dixon at gmail.com (Kevin Dixon) Date: Tue, 19 Oct 2010 14:03:33 -0700 Subject: [music-dsp] BiQuad Magnitude Frequency Response problem In-Reply-To: References: Message-ID: Chalk it up to late night confusion -- I was putting the fabs on the result because the data looked wrong, but compounding the problem, the GUI code was assuming magnitude for input, and transforming it to dB scale. So the data returned from my method was flipped, and then GUI transformed it again. I've change the interface specification to note the filter magnitude is output in dB :) Thanks all, it works now! -Kevin On Tue, Oct 19, 2010 at 7:28 AM, robert bristow-johnson wrote: > > On Oct 19, 2010, at 2:54 AM, Kevin Dixon wrote: > >> Hi all, >> >> I was following this thread to calculate the magnitude frequency >> response of a BiQuad filter (as discussed in RBJ's cookbook): >> >> http://groups.google.com/group/comp.dsp/browse_frm/thread/8c0fa8d396aeb444/a1bc5b63ac56b686 >> in message 9, RBJ shows his revised equation, which I've implemented >> as such, where "atFreq" is the input parameter of frequency to >> calculate for. >> >> ? ? ? ?Float64 w = 2.0 * pi * atFreq / lastSampleRate; >> ? ? ? ?Float64 phi = 4.0 * pow(sin(w / 2.0), 2.0); >> >> ? ? ? ?Float64 c1 = ?10.0 * log10(pow(b0+b1+b2, 2.0) + ( b0*b2*phi - >> (b1*(b0+b2) + 4.0 * b0 * b2) )*phi) ; >> >> ? ? ? ?Float64 c2 = ?10.0 * log10(pow(a0+a1+a2, 2.0) + ( a0*a2*phi - >> (a1*(a0+a2) + 4.0 * a0 * a2) )*phi); >> >> ? ? ? ?return ?fabs(c1 - c2); > > > this looks okay to me except for the fabs(). ?that should neither be > necessary nor desired. ?but the worst that it should do is flip part of your > response upside down. > > >> >> c1 is the first bit of the equation, and c2 is the second. I'm trying >> to write a GUI to display the curve, so the GUI calculates the >> frequencies it wants based on the real estate it has to render in... I >> must have a bug, because my curves are coming out looking backwards. >> When I calculate for a low-pass at 500Hz, 0.7Q, I wind up with data >> points that look like a high-pass at 500Hz, but with some sort of >> boost. I know that my filter is implemented correctly, because if I >> run fuzzmeasure through my filter, the frequency response is proper. > > > you haven't told us what your coefficients are. > > > now, if you define your LPF coefficients as so: > > ? ? ? ? w0 = 2*pi*f0/Fs > > ? ? ? ? alpha = sin(w0)/(2*Q) > > LPF: ? ? H(s) = 1 / (s^2 + s/Q + 1) > ? ? ? ? b0 = (1 - cos(w0))/2 > ? ? ? ? b1 = 1 - cos(w0) > ? ? ? ? b2 = (1 - cos(w0))/2 > ? ? ? ? a0 = 1 + alpha > ? ? ? ? a1 = -2*cos(w0) > ? ? ? ? a2 = 1 - alpha > > > and then evaluate your dB gain as: > > ? 20*log10[ |H(e^jw)| ] ?= ?10 * ( > > ? log10[(b0+b1+b2)^2 + ( b0*b2*phi - (b1*(b0+b2) + 4*b0*b2) )*phi] > > ?- log10[(a0+a1+a2)^2 + ( a0*a2*phi - (a1*(a0+a2) + 4*a0*a2) )*phi] ) > > > > ? ? ? ? ?where ? phi = 4*sin^2(w/2) > > ? ? ? ? ? ? ? ? ?w ?= ?2*pi*f/Fs ? ? ? ?0 < f < Fs > > > > then you still have problems? > > i guess i would like to see the coefs you have. > > -- > > r b-j ? ? ? ? ? ? ? ? ?rbj at 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 jchandjr at bellsouth.net Tue Oct 19 17:47:29 2010 From: jchandjr at bellsouth.net (James Chandler Jr) Date: Tue, 19 Oct 2010 17:47:29 -0400 Subject: [music-dsp] fx architecture: Interleaved or flat samples.. In-Reply-To: <4CBE0473.3070004@planetarc.de> References: <4CBE0473.3070004@planetarc.de> Message-ID: Hi Nils Some audio driver specs and audio plugin specs pass an array of mono buffers back and forth. And some driver specs or audio plugin specs typically pass interleaved data (left0, right0, left1, right1, etc). The common audio file formats I usually use, stereo or multi-channel usually uses interleaved data, but there are probably audio file formats that use what is sometimes called "split stereo". Long ago I think Sound Designer SD2 file format was split stereo, but dunno if it is always that way nowadays. Maybe I'm not even recalling SD2 correctly. So the audio might be split stereo at one part of a program and interleaved stereo at other parts of a program's signal flow. If you are writing a plugin, just use whatever sample in/out configuration is specified by the plugin api. If writing a standalone program, perhaps configure the signal processing innards the easiest way you would like to work, and use format converters on input and output. Convert input audio to the format your DSP innards wants to work with, and then convert your DSP output to whatever format the output wants to see. For instance, if your program input is a typical WAV file but your output goes to ASIO or Mac CoreAudio, then the input will be interleaved stereo and the output will be split stereo, so you would have to do some conversion somewhere along the line. When I write 'utility objects' like filters or other processors, I usually write methods ProcessMono(buffer, buffersize), ProcessSplitStereo(leftbuffer, rightbuffer, buffersize) and also ProcessInterleavedStereo(buffer, buffersize). I rarely use more than stereo, but for a lot of multi-channel work, it would need to be more elaborate than those three cases. With all three options available, I can call such a utility function at different places in a signal flow without having to worry about the channel layout. It is a labor-saver to write all your dsp against your standard favorite numeric format. 32 bit float seems very common, as it is easy to work with and has good enough resolution for many tasks. Then if your program input happens to be 16 bit signed integer or whatever, or your output happens to be 24 bit signed integer or whatever, you would format convert short to float on input, and format convert float to 24 bit on output, but you don't have to write any special numeric cases inside your DSP code. Your DSP code always expects 32 bit floats internally. Or whatever internal numeric format you would like to "always use". James Chandler Jr. On Oct 19, 2010, at 4:49 PM, Nils Pipenbrinck wrote: > Hi folks. > > I'm currently working on a simple toy multieffect. Since I've never > written such a thing I wonder in which order you keep your sample > buffers in memory? > > Do you usually work with a single buffer containing the samples of all > channels interleaved (e.g. how the data usually gets delivered from the > codec) or do you split the buffers and work on a 'per channel basis? > > Any pros/cons/ideas about that? > > > Cheers, > Nils > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, 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 risto.holopainen at imv.uio.no Tue Oct 19 18:09:29 2010 From: risto.holopainen at imv.uio.no (Risto Holopainen) Date: Wed, 20 Oct 2010 00:09:29 +0200 Subject: [music-dsp] ring modulation In-Reply-To: <4CBE036F.7040304@cox.net> References: <80F2EF3F-59D5-401E-9796-4A71FC365224@audioimagination.com> <80D24495-73C8-46A2-B8D1-D19090801929@earlevel.com> <6CE33E35-145B-4A8E-AD43-3E5E210A378F@bellsouth.net> <51D9DA72-98E4-4709-8583-1D2A8D1802E9@audioimagination.com> <5AAC2497-B5DF-44E7-8025-E158C0FBE1F0@bellsouth.net> <0867d9ed4eebdd0002d9c0a06d6f52e9.squirrel@webmail.uio.no> <4CBE036F.7040304@cox.net> Message-ID: <6205b7d9bd0305a4f87da6c583c46765.squirrel@webmail.uio.no> > On 10/19/2010 01:28 PM, Nigel Redmon wrote: >> Are you sure Stockhausen wasn't using a frequency shifter, and not a >> ring modulator? Just wondering--I don't know. He was using a ring modulator in pieces such as Mantra, and Mikrophonie II where a Hammond organ modulates a choir (it's quite extreme at times). Frequency shifters appears to have been less used and less well known in early electronic music. But yes, they are versatile, think of their use as acoustic feedback suppressors for instance. > 1) small (< 10Hz) shifts with full wet mix & no regeneration provide for > subtle phasing effects that sound like motion in the soundscape. Yes, especially for spatial effects when detuning channels. > 2) small shifts with various degrees of wet/dry mixing cause a sweeping > notch-filter effect due to selective phase cancellation. > > 3) regeneration (mixing some output back to the input) with a small > shift results in a sweeping resonance peak. Depending on how much > feedback is used this can break into self-oscillation. Using either > positive or negative regen can make subtle changes in the sound. > > 4) As noted, large shifts are interesting in a 'f#$k s&*t up' kind of > way, but may be difficult to use in a particularly musical way. Well, up to a few hundred Hz isn't too bad. Risto > > Eric > -- From rossb-lists at audiomulch.com Wed Oct 20 00:50:22 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Wed, 20 Oct 2010 15:50:22 +1100 Subject: [music-dsp] fx architecture: Interleaved or flat samples.. References: <4CBE0473.3070004@planetarc.de> Message-ID: <078b01cb7012$50afc590$0242000a@rossmacbook> Hi Nils > I'm currently working on a simple toy multieffect. Since I've never > written such a thing I wonder in which order you keep your sample > buffers in memory? I keep channels in separate buffers since this is how many low latency audio APIs and plugin formats do it, and it's easier to keep track of with a pointer/array/object for each signal and perhaps slightly more efficient to iterate in some cases. I agree with what James said. One thing to add is that if you do use stereo interleaved it may give you opportunities for SSE based processing optimisations that aren't so easy on split buffers (but I'm no expert on this so perhaps someone else can explain whether this is exactly true) You could also think about the cache effects of each approach but it will depend on your algorithms which will perform better: eg if you have an interleaved buffer but you only do processing one channel at a time you may need to pull the whole buffer through cache twice (although in reality, real-time audio buffers are small compared to some caches, so this may not matter so much). Ross. From rbj at audioimagination.com Wed Oct 20 01:13:50 2010 From: rbj at audioimagination.com (robert bristow-johnson) Date: Wed, 20 Oct 2010 01:13:50 -0400 Subject: [music-dsp] fx architecture: Interleaved or flat samples.. In-Reply-To: <4CBE0473.3070004@planetarc.de> References: <4CBE0473.3070004@planetarc.de> Message-ID: <57BE0C5A-5153-4336-8884-8E80405FD7BB@audioimagination.com> On Oct 19, 2010, at 4:49 PM, Nils Pipenbrinck wrote: > I wonder in which order you keep your sample buffers in memory? > > Do you usually work with a single buffer containing the samples of all > channels interleaved (e.g. how the data usually gets delivered from > the > codec) or do you split the buffers and work on a 'per channel basis? > > Any pros/cons/ideas about that? i can't think of any pros to leaving the samples interleaved for processing. i always try to write algorithms in a context where many samples (in a sample "block" or "chunk") is processed at a time for each component (delays, filters, non-linear, etc.). these blocks can be as small as 4 or 8 samples or as large as, i dunno, 1024 samples (or larger, but then delay becomes noticeable). this processing code is either interrupted by the codec interrupt request (that inputs and outputs a single sample to the codec or whatever) or there may be (like in the SHArC) a DMA of some kind. that interrupt routine is expecting the samples to be interleaved in the I/O buffer. but the task of de-interleaving the I/O buffer to the sample blocks (and re-interleaving back out) is not wasted code. it has to be swapped anyway (at the beginning and ending of a sample block period) so that the processing code inside can be completely unaware of and independent of where in the I/O buffer the codec interrupt I/O pointer is. as long as you're moving samples in and out of the buffer, you may as well de-interleave going in and re-interleave going out as well as scale the input and scale (and mix with the dry input) the output as the samples are being passed around. then the code for the processing components (you know, the little delays and filters and whatever else is in your "secret sauce") is always working on a single signal channel and need not worry about whether or not it's interleaved (because it never is) and what the interleaving "stride" is. -- r b-j rbj at audioimagination.com "Imagination is more important than knowledge." From didid at skynet.be Wed Oct 20 02:23:07 2010 From: didid at skynet.be (Didier Dambrin) Date: Wed, 20 Oct 2010 08:23:07 +0200 Subject: [music-dsp] fx architecture: Interleaved or flat samples.. In-Reply-To: <078b01cb7012$50afc590$0242000a@rossmacbook> References: <4CBE0473.3070004@planetarc.de> <078b01cb7012$50afc590$0242000a@rossmacbook> Message-ID: <6B45F77552674A5D856469AA06C77BF8@GOLAMD> I'd agree, I stopped thinking that having grown a DSP library working on interleaved data was a bad idea (having to code things twice, poor expandability) when SSE came in. Big benefits for filtering, resampling, etc. ----- Original Message ----- From: "Ross Bencina" To: "A discussion list for music-related DSP" Sent: Wednesday, October 20, 2010 6:50 AM Subject: Re: [music-dsp] fx architecture: Interleaved or flat samples.. > I agree with what James said. One thing to add is that if you do use > stereo > interleaved it may give you opportunities for SSE based processing > optimisations that aren't so easy on split buffers (but I'm no expert on > this so perhaps someone else can explain whether this is exactly true) > From meeloo at meeloo.net Wed Oct 20 04:17:12 2010 From: meeloo at meeloo.net (Sebastien Metrot) Date: Wed, 20 Oct 2010 10:17:12 +0200 Subject: [music-dsp] fx architecture: Interleaved or flat samples.. In-Reply-To: <6B45F77552674A5D856469AA06C77BF8@GOLAMD> References: <4CBE0473.3070004@planetarc.de> <078b01cb7012$50afc590$0242000a@rossmacbook> <6B45F77552674A5D856469AA06C77BF8@GOLAMD> Message-ID: <33FA5EF2-57AD-4942-A206-A84FC3D4A722@meeloo.net> Beware, this can be a lot of work as soon as you have to optimize for mono, stereo, quad, 5.1, 7.1, etc. S. On Oct 20, 2010, at 8:23 AM, Didier Dambrin wrote: > I'd agree, I stopped thinking that having grown a DSP library working on interleaved data was a bad idea (having to code things twice, poor expandability) when SSE came in. Big benefits for filtering, resampling, etc. > > > > ----- Original Message ----- From: "Ross Bencina" > To: "A discussion list for music-related DSP" > Sent: Wednesday, October 20, 2010 6:50 AM > Subject: Re: [music-dsp] fx architecture: Interleaved or flat samples.. > >> I agree with what James said. One thing to add is that if you do use stereo >> interleaved it may give you opportunities for SSE based processing >> optimisations that aren't so easy on split buffers (but I'm no expert on >> this so perhaps someone else can explain whether this is exactly true) >> > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, 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 o.tristan at ultimatesoundbank.com Wed Oct 20 04:29:17 2010 From: o.tristan at ultimatesoundbank.com (Olivier Tristan) Date: Wed, 20 Oct 2010 10:29:17 +0200 Subject: [music-dsp] fx architecture: Interleaved or flat samples.. In-Reply-To: <6B45F77552674A5D856469AA06C77BF8@GOLAMD> References: <4CBE0473.3070004@planetarc.de> <078b01cb7012$50afc590$0242000a@rossmacbook> <6B45F77552674A5D856469AA06C77BF8@GOLAMD> Message-ID: <4CBEA85D.4080303@ultimatesoundbank.com> On 10/20/2010 8:23 AM, Didier Dambrin wrote: > I'd agree, I stopped thinking that having grown a DSP library working > on interleaved data was a bad idea (having to code things twice, poor > expandability) when SSE came in. Big benefits for filtering, > resampling, etc. > That's true if you code SSE by hand. All stuff like IPP or vDSP works better on non interleaved data. Having tried both. interleaved data in older version of our audio engine and now non interleaved, I can tell you that it's way easier with non interleaved. Moreover it allow you to have different path for different channel easily. -- Olivier Tristan Ultimate Sound Bank From didid at skynet.be Wed Oct 20 05:23:00 2010 From: didid at skynet.be (Didier Dambrin) Date: Wed, 20 Oct 2010 11:23:00 +0200 Subject: [music-dsp] fx architecture: Interleaved or flat samples.. In-Reply-To: <4CBEA85D.4080303@ultimatesoundbank.com> References: <4CBE0473.3070004@planetarc.de> <078b01cb7012$50afc590$0242000a@rossmacbook><6B45F77552674A5D856469AA06C77BF8@GOLAMD> <4CBEA85D.4080303@ultimatesoundbank.com> Message-ID: <3EE2FEA9E4254D8D8FF0C8F72B24CBA0@GOLAMD> > On 10/20/2010 8:23 AM, Didier Dambrin wrote: >> I'd agree, I stopped thinking that having grown a DSP library working >> on interleaved data was a bad idea (having to code things twice, poor >> expandability) when SSE came in. Big benefits for filtering, >> resampling, etc. >> > That's true if you code SSE by hand. > All stuff like IPP or vDSP works better on non interleaved data. > A lot of the "complex" versions (but not all) in IPP work on interleaved data. But yes, sadly it wasn't designed for this. > Having tried both. interleaved data in older version of our audio engine > and now non interleaved, I can tell you that it's way easier with non > interleaved. > Moreover it allow you to have different path for different channel easily. > > > -- > Olivier Tristan > Ultimate Sound Bank > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From michael.gogins at gmail.com Wed Oct 20 08:17:55 2010 From: michael.gogins at gmail.com (Michael Gogins) Date: Wed, 20 Oct 2010 08:17:55 -0400 Subject: [music-dsp] fx architecture: Interleaved or flat samples.. In-Reply-To: <3EE2FEA9E4254D8D8FF0C8F72B24CBA0@GOLAMD> References: <4CBE0473.3070004@planetarc.de> <078b01cb7012$50afc590$0242000a@rossmacbook> <6B45F77552674A5D856469AA06C77BF8@GOLAMD> <4CBEA85D.4080303@ultimatesoundbank.com> <3EE2FEA9E4254D8D8FF0C8F72B24CBA0@GOLAMD> Message-ID: I think you should examine the generated assembler to find out if the SSE stuff is built for interleaved and for non-interleaved buffers. If it is built for both, then I suggest using the buffers as they come to you, whatever format that is. If not, then use the layout that gets built for SSE. Regards, Mike On Wed, Oct 20, 2010 at 5:23 AM, Didier Dambrin wrote: > > >> On 10/20/2010 8:23 AM, Didier Dambrin wrote: >>> >>> I'd agree, I stopped thinking that having grown a DSP library working >>> on interleaved data was a bad idea (having to code things twice, poor >>> expandability) when SSE came in. Big benefits for filtering, >>> resampling, etc. >>> >> That's true if you code SSE by hand. >> All stuff like IPP or vDSP works better on non interleaved data. >> > > A lot of the "complex" versions (but not all) in IPP work on interleaved > data. But yes, sadly it wasn't designed for this. > > >> Having tried both. interleaved data in older version of our audio engine >> and now non interleaved, I can tell you that it's way easier with non >> interleaved. >> Moreover it allow you to have different path for different channel easily. >> >> >> -- >> Olivier Tristan >> Ultimate Sound Bank >> >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, source code archive, list archive, book reviews, >> dsp links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp > links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com From decoy at iki.fi Wed Oct 20 09:46:32 2010 From: decoy at iki.fi (Sampo Syreeni) Date: Wed, 20 Oct 2010 16:46:32 +0300 (EEST) Subject: [music-dsp] fx architecture: Interleaved or flat samples.. In-Reply-To: <078b01cb7012$50afc590$0242000a@rossmacbook> References: <4CBE0473.3070004@planetarc.de> <078b01cb7012$50afc590$0242000a@rossmacbook> Message-ID: On 2010-10-20, Ross Bencina wrote: > One thing to add is that if you do use stereo interleaved it may give > you opportunities for SSE based processing optimisations that aren't > so easy on split buffers (but I'm no expert on this so perhaps someone > else can explain whether this is exactly true) One extra benefit is cache locality and ordering. Granted, it's not a huge deal at audio rates, but still a minor factor, especially in heavily loaded multitasking environments where cache lines are easier to saturate and memory pipeline latencies can vary. One place where I've bumped into this is recirculating delay buffers. Their read and write points already create two separate memory hotspots, so if you build them in split stereo, happen to align the buffers badly and the user moreover happens to set the delay just right, suddenly that single process will saturate a 4-way set associative cache. And since caches tend to use simplistic LRU, they're not scan resistant, so that your simple loop can end up crowding out everything else in a substantial portion of the L1 cache. Interleaving cuts the risk proportional to the number of channels. But yeah, this example is a little bit far fetched in most cases. In general HPC, database and other large data folks tend to a) store data accessed together in the same place (locality) b) order the data by the most probable order of access, and segregate stuff by frequency of use (temperature). That's what I do on the rare occasion that I actually pull out an actual compiler, at least. But as I said, I suspect the benefits in audio rate stereo are rather minuscule. Really the Right Way here would be to use some numerically savvy language and compiler with high level DSP-friendly primitives, like APL or some functional derivative of it, and then let the compiler figure out the storage details, loop stacking, vectorization and all that. But unfortunately the best numerical compilers still seem to be for the worst languages, like Fortran, which would then force one to build a rather intricate framework on top of say the C environment to do that sort of thing for you. There are some successful examples of this being done, like FFTW, but they tend to be complicated, fragile and thus few and far between. > You could also think about the cache effects of each approach but it > will depend on your algorithms which will perform better: eg if you > have an interleaved buffer but you only do processing one channel at a > time you may need to pull the whole buffer through cache twice > (although in reality, real-time audio buffers are small compared to > some caches, so this may not matter so much). Once again I should have read the entire post before answering... -- Sampo Syreeni, aka decoy - decoy at iki.fi, http://decoy.iki.fi/front +358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 From michael.gogins at gmail.com Wed Oct 20 10:02:35 2010 From: michael.gogins at gmail.com (Michael Gogins) Date: Wed, 20 Oct 2010 10:02:35 -0400 Subject: [music-dsp] fx architecture: Interleaved or flat samples.. In-Reply-To: References: <4CBE0473.3070004@planetarc.de> <078b01cb7012$50afc590$0242000a@rossmacbook> Message-ID: And it goes without saying but I will say it anyway, you have measure what you do (time your code) and keep records so you don't repeat things that aren't optimal. Regards, Mike On Wed, Oct 20, 2010 at 9:46 AM, Sampo Syreeni wrote: > On 2010-10-20, Ross Bencina wrote: > >> One thing to add is that if you do use stereo interleaved it may give you >> opportunities for SSE based processing optimisations that aren't so easy on >> split buffers (but I'm no expert on this so perhaps someone else can explain >> whether this is exactly true) > > One extra benefit is cache locality and ordering. Granted, it's not a huge > deal at audio rates, but still a minor factor, especially in heavily loaded > multitasking environments where cache lines are easier to saturate and > memory pipeline latencies can vary. One place where I've bumped into this is > recirculating delay buffers. Their read and write points already create two > separate memory hotspots, so if you build them in split stereo, happen to > align the buffers badly and the user moreover happens to set the delay just > right, suddenly that single process will saturate a 4-way set associative > cache. And since caches tend to use simplistic LRU, they're not scan > resistant, so that your simple loop can end up crowding out everything else > in a substantial portion of the L1 cache. Interleaving cuts the risk > proportional to the number of channels. But yeah, this example is a little > bit far fetched in most cases. > > In general HPC, database and other large data folks tend to a) store data > accessed together in the same place (locality) b) order the data by the most > probable order of access, and segregate stuff by frequency of use > (temperature). That's what I do on the rare occasion that I actually pull > out an actual compiler, at least. But as I said, I suspect the benefits in > audio rate stereo are rather minuscule. > > Really the Right Way here would be to use some numerically savvy language > and compiler with high level DSP-friendly primitives, like APL or some > functional derivative of it, and then let the compiler figure out the > storage details, loop stacking, vectorization and all that. But > unfortunately the best numerical compilers still seem to be for the worst > languages, like Fortran, which would then force one to build a rather > intricate framework on top of say the C environment to do that sort of thing > for you. There are some successful examples of this being done, like FFTW, > but they tend to be complicated, fragile and thus few and far between. > >> You could also think about the cache effects of each approach but it will >> depend on your algorithms which will perform better: eg if you have an >> interleaved buffer but you only do processing one channel at a time you may >> need to pull the whole buffer through cache twice (although in reality, >> real-time audio buffers are small compared to some caches, so this may not >> matter so much). > > Once again I should have read the entire post before answering... > -- > Sampo Syreeni, aka decoy - decoy at iki.fi, http://decoy.iki.fi/front > +358-50-5756111, 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 > -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com From jchandjr at bellsouth.net Wed Oct 20 14:40:46 2010 From: jchandjr at bellsouth.net (James Chandler Jr) Date: Wed, 20 Oct 2010 14:40:46 -0400 Subject: [music-dsp] ring modulation In-Reply-To: References: <80F2EF3F-59D5-401E-9796-4A71FC365224@audioimagination.com> <80D24495-73C8-46A2-B8D1-D19090801929@earlevel.com> <6CE33E35-145B-4A8E-AD43-3E5E210A378F@bellsouth.net> <51D9DA72-98E4-4709-8583-1D2A8D1802E9@audioimagination.com> <5AAC2497-B5DF-44E7-8025-E158C0FBE1F0@bellsouth.net> <0867d9ed4eebdd0002d9c0a06d6f52e9.squirrel@webmail.uio.no> Message-ID: <7DDAA772-6F32-4579-9A63-EAAAE4FAD99C@bellsouth.net> On Oct 19, 2010, at 3:09 AM, Andrew Capon wrote: > Analog synth circuits are still fun : http://www.musicfromouterspace.com/ > > Andy Thanks for the link, Andy. That is a neat site! Lots of great info. On Oct 19, 2010, at 4:28 PM, Nigel Redmon wrote: > Are you sure Stockhausen wasn't using a frequency shifter, and not a ring modulator? Just wondering--I don't know. > > We had a 360 Systems Frequency Shifter (a green one) in the electronic music lab at USC back in the 70's. I had a ring modulator on my home-built modular (mostly based on Aries modules) back then (well, still have it, but long time since power-up). Quite a different sound. A frequency shifter suppresses one sideband, so that all harmonics are shifted one way by a fixed amount (hence the harmonics will diverge). > > I just did a search and found a a forum post at gearslutz discussing frequency shifters, and the poster said, "Small shifts gave deep phasing effects, larger shifts were -interesting, if not over musically useful (frequency differences which were related to a note gave strange harmonic structures, when the note changes, purest dissonance- very Stockhausen)". I found a fellow's home-made frequency shifter schematics. http://homepage.ntlworld.com/henry01/frequency_shifter/frequency_shifter.htm His analog quadrature phase shifter circuit is interesting-- http://homepage.ntlworld.com/henry01/frequency_shifter/freq_shifter03-01.pdf His filter network reminds me of this cartoon-- http://imgs.xkcd.com/comics/nerd_sniping.png From kelvin.bitnick at gmail.com Wed Oct 20 20:11:08 2010 From: kelvin.bitnick at gmail.com (philippe) Date: Thu, 21 Oct 2010 02:11:08 +0200 Subject: [music-dsp] ring modulation In-Reply-To: <7DDAA772-6F32-4579-9A63-EAAAE4FAD99C@bellsouth.net> References: <80F2EF3F-59D5-401E-9796-4A71FC365224@audioimagination.com> <80D24495-73C8-46A2-B8D1-D19090801929@earlevel.com> <6CE33E35-145B-4A8E-AD43-3E5E210A378F@bellsouth.net> <51D9DA72-98E4-4709-8583-1D2A8D1802E9@audioimagination.com> <5AAC2497-B5DF-44E7-8025-E158C0FBE1F0@bellsouth.net> <0867d9ed4eebdd0002d9c0a06d6f52e9.squirrel@webmail.uio.no> <7DDAA772-6F32-4579-9A63-EAAAE4FAD99C@bellsouth.net> Message-ID: the elektor electronic magazine (here in europe) published two such circuits in the last 10 or 15 years. the strange network is an all-pass 90? shifter, an analogue hilbert transformer. handy for PA usage to circumvent larsen. On Wed, Oct 20, 2010 at 8:40 PM, James Chandler Jr wrote: > On Oct 19, 2010, at 3:09 AM, Andrew Capon wrote: > >> Analog synth circuits are still fun : http://www.musicfromouterspace.com/ >> >> Andy > > Thanks for the link, Andy. That is a neat site! Lots of great info. > > On Oct 19, 2010, at 4:28 PM, Nigel Redmon wrote: > >> Are you sure Stockhausen wasn't using a frequency shifter, and not a ring modulator? Just wondering--I don't know. >> >> We had a 360 Systems Frequency Shifter (a green one) in the electronic music lab at USC back in the 70's. I had a ring modulator on my home-built modular (mostly based on Aries modules) back then (well, still have it, but long time since power-up). Quite a different sound. A frequency shifter suppresses one sideband, so that all harmonics are shifted one way by a fixed amount (hence the harmonics will diverge). >> >> I just did a search and found a a forum post at gearslutz discussing frequency shifters, and the poster said, "Small shifts gave deep phasing effects, larger shifts were -interesting, if not over musically useful (frequency differences which were related to a note gave strange harmonic structures, when the note changes, purest dissonance- very Stockhausen)". > > I found a fellow's home-made frequency shifter schematics. > > http://homepage.ntlworld.com/henry01/frequency_shifter/frequency_shifter.htm > > His analog quadrature phase shifter circuit is interesting-- > > http://homepage.ntlworld.com/henry01/frequency_shifter/freq_shifter03-01.pdf > > His filter network reminds me of this cartoon-- > > http://imgs.xkcd.com/comics/nerd_sniping.png > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, 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 np at planetarc.de Thu Oct 21 14:50:01 2010 From: np at planetarc.de (Nils Pipenbrinck) Date: Thu, 21 Oct 2010 20:50:01 +0200 Subject: [music-dsp] fx architecture: Interleaved or flat samples.. In-Reply-To: <4CBE0473.3070004@planetarc.de> References: <4CBE0473.3070004@planetarc.de> Message-ID: <4CC08B59.3090504@planetarc.de> Hi. Thank you all for your answers.. After reading all your posts and thinking about the problem I decided that I'll do most of the processing in stereo with interleaved data and split the data into independent streams when necessary. Since the thread drifted a bit into architecture specific things and optimization opportunities I rant a bit about the project I'm working on: I'm writing myself a multi-effect based on the OMAP3530 CPU from TI. All low latency audio processing happens on the C64x+ DSP that's part of the chip. The chip also has an ARM core, but I use it only for user-interface, network, file IO and so on. The DSP does not offer much SIMD functionality. You can do a bit of SIMD with 32 bit registers, but that's it. On the other hand the DSP can issue up to eight instructions per cycle. Multi-cycle instructions don't exist in the usual sense. If you issue a instruction that takes for example 4 cycles to execute The DSP will not halt the execution. It's the programmers (or compilers) business to make sure that you don't access the target register before the result is available. This has a interesting consequence: A multiplication with a 64 bit result for example takes 5 cycles to execute, and the DSP can issue 8 instructions per cycle, so you have 40 instructions to fill with useful calculations before you can access the result. The only way to fill the instruction slots is to run multiple independent things at the same time. So processing two channels (left & right) at the same time works well from a performance point of view. Loops where the calculation depends on the result of a previous loop-iterations on the other hand will kill performance (IIRs anyone?) Cache issues aren't my problem. I stream in all big data-chunks into internal (single cycle access) memory via DMA and let the cache handle the rest. Cheers, Nils Btw - I have my first effect working: A simplistic stereo delay. *jumps up and down in joy* Latency is at 2ms (excluding the latency of the converters itself). Next on my list: Fun with biquads. From spambait1000006 at cox.net Sat Oct 23 02:05:19 2010 From: spambait1000006 at cox.net (spambait1000006 at cox.net) Date: Fri, 22 Oct 2010 23:05:19 -0700 (MST) Subject: [music-dsp] ring modulation In-Reply-To: References: <80F2EF3F-59D5-401E-9796-4A71FC365224@audioimagination.com> <80D24495-73C8-46A2-B8D1-D19090801929@earlevel.com> <6CE33E35-145B-4A8E-AD43-3E5E210A378F@bellsouth.net> <51D9DA72-98E4-4709-8583-1D2A8D1802E9@audioimagination.com> <5AAC2497-B5DF-44E7-8025-E158C0FBE1F0@bellsouth.net> <0867d9ed4eebdd0002d9c0a06d6f52e9.squirrel@webmail.uio.no> <7DDAA772-6F32-4579-9A63-EAAAE4FAD99C@bellsouth.net> Message-ID: <20101022220430.E66360@bunrab.ronnet.moc> The 'classic' 4 diode ring modulator does not just multipy the two signals. The diodes are used to switch the polarity of the connection of the input signal to the output based on the polarity of the carrier, so when the carrier is positive the input is sent to the output unchanged, but when the carrier is negative the input is sent to the output inverted. i.e. when the carrier is positive it's like the input is multipied by 1 and when the carrier is negative it is mutlipied by -1 so for a sine wave carrier you have the equivalent of the input multiplied by a /square/ of the same frequncy as the carrier sine wave. So the output contains f_c+/-f_i, 3f_c+/-f_i, 5f_c+/-f_i etc. (where f_c = carrier freq and f_i the input freq) and for this type of ring modulator there is a difference between the 'input' and the 'carrier' signals. As a radio modulator (an early use of ring modulators) the 'input' freqeuncy would be small compared to the carrier frequency, so the output would be at fequencies near the frequncies of a square wave at the carrier frequency, f_c, 3f_c, 5f_c etc. and the unwanted signals could be easily filtered out. Many other ciruits have been called 'ring modulators' in addition to 4-quadrant multipliers. At least one synth used an xor gate (with signal offsets) as a 'ring mudulator' (so basically you get the product of square waves at both the input and carrier frequncies --though I think maybe the synths used square wave oscilator and inputs, so it was basically the same as simple multiplication anyway), And I've not figured out what Craig Anderton's LM565 based 'ring modulator' really does... CR From alan.wolfe at gmail.com Sat Oct 23 01:51:09 2010 From: alan.wolfe at gmail.com (Alan Wolfe) Date: Fri, 22 Oct 2010 22:51:09 -0700 Subject: [music-dsp] ring modulation In-Reply-To: <20101022220430.E66360@bunrab.ronnet.moc> References: <80F2EF3F-59D5-401E-9796-4A71FC365224@audioimagination.com> <80D24495-73C8-46A2-B8D1-D19090801929@earlevel.com> <6CE33E35-145B-4A8E-AD43-3E5E210A378F@bellsouth.net> <51D9DA72-98E4-4709-8583-1D2A8D1802E9@audioimagination.com> <5AAC2497-B5DF-44E7-8025-E158C0FBE1F0@bellsouth.net> <0867d9ed4eebdd0002d9c0a06d6f52e9.squirrel@webmail.uio.no> <7DDAA772-6F32-4579-9A63-EAAAE4FAD99C@bellsouth.net> <20101022220430.E66360@bunrab.ronnet.moc> Message-ID: That is so bizarre, how is it that so many different devices all came to have the same name? On Fri, Oct 22, 2010 at 11:05 PM, wrote: > ?The 'classic' 4 diode ring modulator does not just multipy the > two signals. The diodes are used to switch the polarity of the > connection of the input signal to the output based on the > polarity of the carrier, so when the carrier is positive the > input is sent to the output unchanged, but when the carrier is > negative the input is sent to the output inverted. i.e. when the > carrier is positive it's like the input is multipied by 1 and > when the carrier is negative it is mutlipied by -1 so for a sine > wave carrier you have the equivalent of the input multiplied by a > /square/ of the same frequncy as the carrier sine wave. > ?So the output contains f_c+/-f_i, 3f_c+/-f_i, 5f_c+/-f_i etc. > (where f_c = carrier freq and f_i the input freq) and for this type > of ring modulator there is a difference between the 'input' and the > 'carrier' signals. > > ?As a radio modulator (an early use of ring modulators) the 'input' > freqeuncy would be small compared to the carrier frequency, so the > output would be at fequencies near the frequncies of a square wave at the > carrier frequency, f_c, 3f_c, 5f_c etc. and the unwanted signals > could be easily filtered out. > > ?Many other ciruits have been called 'ring modulators' in addition to > 4-quadrant multipliers. At least one synth used an xor gate (with signal > offsets) as a 'ring mudulator' (so basically you get the product of square > waves at both the input and carrier frequncies --though I think maybe the > synths used square wave oscilator and inputs, so it was basically the same > as simple multiplication anyway), And I've not figured out what Craig > Anderton's LM565 based 'ring modulator' really does... > > ? CR > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, 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 alan.wolfe at gmail.com Sun Oct 24 17:23:13 2010 From: alan.wolfe at gmail.com (Alan Wolfe) Date: Sun, 24 Oct 2010 14:23:13 -0700 Subject: [music-dsp] Polyphony - how do you mix N number of signals and keep a consistent volume? Message-ID: Hey Guys, How I understand mixing is that if you have N signals, all in the range of -1,1 that you want to add all the signals together then divide by N to get an output signal still in the range of -1,1. What do you do then if you are making a live playing synthesizer and want to play 1 to N notes at the same time? If i cap the max number of notes to 8, add all the channels together (some of which may be silent) and then divide by 8, single notes played alone are very quiet. If i only divide by the number of non silent channels, there is an audible pop when a new note is added or removed and the rest of the audible channels suddenly increase or decrease in volume. How is this normally handled? Would it be a good idea to use an envelope to ramp in the volume of a new note when it starts playing and ramp out the volume of a note when it stops playing instead of a sudden volume change? Thanks! Alan From didid at skynet.be Sun Oct 24 17:38:07 2010 From: didid at skynet.be (Didier Dambrin) Date: Sun, 24 Oct 2010 23:38:07 +0200 Subject: [music-dsp] Polyphony - how do you mix N number of signals and keepa consistent volume? In-Reply-To: References: Message-ID: <185209A8D8474D84B73CE6BCF9524E8F@GOLAMD> You always need a ramp (a few ms), whatever the polyphony, if you start adding any random value to your output you're creating a discontinuity > Hey Guys, > > How I understand mixing is that if you have N signals, all in the > range of -1,1 that you want to add all the signals together then > divide by N to get an output signal still in the range of -1,1. > > What do you do then if you are making a live playing synthesizer and > want to play 1 to N notes at the same time? > > If i cap the max number of notes to 8, add all the channels together > (some of which may be silent) and then divide by 8, single notes > played alone are very quiet. > > If i only divide by the number of non silent channels, there is an > audible pop when a new note is added or removed and the rest of the > audible channels suddenly increase or decrease in volume. > > How is this normally handled? > > Would it be a good idea to use an envelope to ramp in the volume of a > new note when it starts playing and ramp out the volume of a note when > it stops playing instead of a sudden volume change? > > Thanks! > Alan > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.862 / Virus Database: 271.1.1/3216 - Release Date: 10/24/10 08:34:00 From rbj at audioimagination.com Sun Oct 24 20:26:25 2010 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sun, 24 Oct 2010 20:26:25 -0400 Subject: [music-dsp] Polyphony - how do you mix N number of signals and keep a consistent volume? In-Reply-To: References: Message-ID: <804006A8-2C73-4041-AD18-6978AA99E4E6@audioimagination.com> On Oct 24, 2010, at 5:23 PM, Alan Wolfe wrote: > How I understand mixing is that if you have N signals, all in the > range of -1,1 that you want to add all the signals together then > divide by N to get an output signal still in the range of -1,1. > > What do you do then if you are making a live playing synthesizer and > want to play 1 to N notes at the same time? > > If i cap the max number of notes to 8, add all the channels together > (some of which may be silent) and then divide by 8, single notes > played alone are very quiet. > > If i only divide by the number of non silent channels, there is an > audible pop when a new note is added or removed and the rest of the > audible channels suddenly increase or decrease in volume. would you expect something different? > How is this normally handled? i dunno what this is, a synthesized organ or similar? normally, whether you have 0 or 1 or 2 or N notes that may or may not have simultaneous onset or release, you do *no* scaling per se regarding the number of notes. just add 'em together. we assume that the note onset and release is click free by virtue of the synthesis or sample playback alg. now, to keep a consistent volume, that is level compression or AGC. you apply that to the summed channel or channels (in case of stereo). the gain change applied by the compressor or AGC better be designed to be reasonably smooth, by use of some ramping or LPF on the gain control signal. sometimes you cannot avoid some artifact of the gain change (usually called "pumping") but you should always be able to avoid clicking or popping. clicks or pops are an indication that some mistake has happened. that's my spin on it. -- r b-j rbj at audioimagination.com "Imagination is more important than knowledge." From alan.wolfe at gmail.com Sun Oct 24 20:33:00 2010 From: alan.wolfe at gmail.com (Alan Wolfe) Date: Sun, 24 Oct 2010 17:33:00 -0700 Subject: [music-dsp] Polyphony - how do you mix N number of signals and keep a consistent volume? In-Reply-To: <804006A8-2C73-4041-AD18-6978AA99E4E6@audioimagination.com> References: <804006A8-2C73-4041-AD18-6978AA99E4E6@audioimagination.com> Message-ID: Interesting! I'll do some research on compressors then. As always, thanks for the in depth info Robert, and thank you too Didier On Sun, Oct 24, 2010 at 5:26 PM, robert bristow-johnson wrote: > > On Oct 24, 2010, at 5:23 PM, Alan Wolfe wrote: > >> How I understand mixing is that if you have N signals, all in the >> range of -1,1 that you want to add all the signals together then >> divide by N to get an output signal still in the range of -1,1. >> >> What do you do then if you are making a live playing synthesizer and >> want to play 1 to N notes at the same time? >> >> If i cap the max number of notes to 8, add all the channels together >> (some of which may be silent) and then divide by 8, single notes >> played alone are very quiet. >> >> If i only divide by the number of non silent channels, there is an >> audible pop when a new note is added or removed and the rest of the >> audible channels suddenly increase or decrease in volume. > > would you expect something different? > >> How is this normally handled? > > > i dunno what this is, a synthesized organ or similar? > > normally, whether you have 0 or 1 or 2 or N notes that may or may not have > simultaneous onset or release, you do *no* scaling per se regarding the > number of notes. ?just add 'em together. ?we assume that the note onset and > release is click free by virtue of the synthesis or sample playback alg. > > now, to keep a consistent volume, that is level compression or AGC. ?you > apply that to the summed channel or channels (in case of stereo). ?the gain > change applied by the compressor or AGC better be designed to be reasonably > smooth, by use of some ramping or LPF on the gain control signal. ?sometimes > you cannot avoid some artifact of the gain change (usually called "pumping") > but you should always be able to avoid clicking or popping. ?clicks or pops > are an indication that some mistake has happened. > > that's my spin on it. > > -- > > r b-j ? ? ? ? ? ? ? ? ?rbj at 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 Mon Oct 25 02:51:14 2010 From: didid at skynet.be (Didier Dambrin) Date: Mon, 25 Oct 2010 08:51:14 +0200 Subject: [music-dsp] Polyphony - how do you mix N number of signals and keep a consistent volume? In-Reply-To: References: <804006A8-2C73-4041-AD18-6978AA99E4E6@audioimagination.com> Message-ID: <9ED48F4CA1A94895A83062F756FB9075@GOLAMD> I thought you were talking about audible pops because you weren't ramping/enveloping your voice in/out btw. Indeed you shouldn't adapt the level according to the # of voices, that's a job for a limiter (which may not be a synthesizer's job, although it's nice to have one built-in for ease of use/previewing). Subject: Re: [music-dsp] Polyphony - how do you mix N number of signals and keep a consistent volume? Interesting! I'll do some research on compressors then. As always, thanks for the in depth info Robert, and thank you too Didier On Sun, Oct 24, 2010 at 5:26 PM, robert bristow-johnson wrote: > > On Oct 24, 2010, at 5:23 PM, Alan Wolfe wrote: > >> How I understand mixing is that if you have N signals, all in the >> range of -1,1 that you want to add all the signals together then >> divide by N to get an output signal still in the range of -1,1. >> >> What do you do then if you are making a live playing synthesizer and >> want to play 1 to N notes at the same time? >> >> If i cap the max number of notes to 8, add all the channels together >> (some of which may be silent) and then divide by 8, single notes >> played alone are very quiet. >> >> If i only divide by the number of non silent channels, there is an >> audible pop when a new note is added or removed and the rest of the >> audible channels suddenly increase or decrease in volume. > > would you expect something different? > >> How is this normally handled? > > > i dunno what this is, a synthesized organ or similar? > > normally, whether you have 0 or 1 or 2 or N notes that may or may not have > simultaneous onset or release, you do *no* scaling per se regarding the > number of notes. just add 'em together. we assume that the note onset and > release is click free by virtue of the synthesis or sample playback alg. > > now, to keep a consistent volume, that is level compression or AGC. you > apply that to the summed channel or channels (in case of stereo). the gain > change applied by the compressor or AGC better be designed to be > reasonably > smooth, by use of some ramping or LPF on the gain control signal. > sometimes > you cannot avoid some artifact of the gain change (usually called > "pumping") > but you should always be able to avoid clicking or popping. clicks or pops > are an indication that some mistake has happened. > > that's my spin on it. > > -- > From rrsounds at aol.com Mon Oct 25 05:44:51 2010 From: rrsounds at aol.com (David Reaves) Date: Mon, 25 Oct 2010 11:44:51 +0200 Subject: [music-dsp] Polyphony - how do you mix N number of signals and keep a consistent volume? In-Reply-To: References: Message-ID: As someone who designs AGCs for a living, I think using an AGC or limiter is just wrong for something like this, especially since it is very possible that it really isn't needed. By definition, AGC, even when artfully accomplished, is a modification to the signal(s)'s original dynamics. For some reason, the ongoing mindset seems to be that all note values have to be produced at the highest level possible, and therefore when you add several together they clip. But why do they have to be at highest level in the first place? To enjoy the best signal-to-noise? To provide the purest waveform? The fact is, if you must eventually reduce their levels anyway to avoid clipping under summation, then perhaps they shouldn't (and needn't) be so loud in the first place. What we should be thinking is backwards from "all notes produced should be as close to clipping as possible." We should be thinking worst-case all inputs full level and summed, and simply scale our inputs accordingly (see below) from the beginning. Yes, the individual signals will be quieter. But this is the reason we have lots of bits. 24 bits of resolution allows for 144dB of dynamic range, WELL beyond the limits of human perception, never mind comfort. [Even 16 bits with its 96 dB clipping-to-noise range (perceived to be much greater with dither) has proven in practice to allow for 20 dB of headroom with a generally acceptable signal-to-noise, even for full orchestral recordings with quiet interludes and solos.] Also, keep in mind that unless all the signals are (1) identical, (2) at full value AND (3) in perfect phase coherence with each other (a very unusual circumstance), they will never sum at the peak theoretical value anyway, but tend to add up to a level of, for "N" summed channels, (N-1) * 3dB. So for eight inputs at full volume, each input could be scaled: ((8-1) *3) db, or -21 dB. So, no: ACG is a band-aid. The real world has pretty much shown that if you just mix at a reasonably lower level, the problem is greatly minimized if not eliminated, with little audible penalty, and does not require the complexity of creating an AGC and artfully implementing it. Kind Regards, David Reaves On Sun, 24 Oct 2010 20:26:25 -0400, robert bristow-johnson wrote: > > > On Oct 24, 2010, at 5:23 PM, Alan Wolfe wrote: > >> How I understand mixing is that if you have N signals, all in the >> range of -1,1 that you want to add all the signals together then >> divide by N to get an output signal still in the range of -1,1. >> >> What do you do then if you are making a live playing synthesizer and >> want to play 1 to N notes at the same time? >> >> If i cap the max number of notes to 8, add all the channels together >> (some of which may be silent) and then divide by 8, single notes >> played alone are very quiet. >> >> If i only divide by the number of non silent channels, there is an >> audible pop when a new note is added or removed and the rest of the >> audible channels suddenly increase or decrease in volume. > > would you expect something different? > >> How is this normally handled? > > > i dunno what this is, a synthesized organ or similar? > > normally, whether you have 0 or 1 or 2 or N notes that may or may not > have simultaneous onset or release, you do *no* scaling per se > regarding the number of notes. just add 'em together. we assume that > the note onset and release is click free by virtue of the synthesis or > sample playback alg. > > now, to keep a consistent volume, that is level compression or AGC. > you apply that to the summed channel or channels (in case of stereo). > the gain change applied by the compressor or AGC better be designed to > be reasonably smooth, by use of some ramping or LPF on the gain > control signal. sometimes you cannot avoid some artifact of the gain > change (usually called "pumping") but you should always be able to > avoid clicking or popping. clicks or pops are an indication that some > mistake has happened. > > that's my spin on it. From didid at skynet.be Mon Oct 25 05:54:44 2010 From: didid at skynet.be (Didier Dambrin) Date: Mon, 25 Oct 2010 11:54:44 +0200 Subject: [music-dsp] Polyphony - how do you mix N number of signals andkeep a consistent volume? In-Reply-To: References: Message-ID: > As someone who designs AGCs for a living, I think using an AGC or limiter > is just wrong for something like this, especially since it is very > possible that it really isn't needed. By definition, AGC, even when > artfully accomplished, is a modification to the signal(s)'s original > dynamics. > > For some reason, the ongoing mindset seems to be that all note values have > to be produced at the highest level possible, and therefore when you add > several together they clip. But why do they have to be at highest level in > the first place? To enjoy the best signal-to-noise? To provide the purest > waveform? > Marketing.. You'd be surprised how musicians are too fooled by loudness=quality. So it doesn't hurt for a synth to have its own limiter (especially for filter resonance), as long as pros can disable it. Besides, if it really has a big resonance, it will have to be limited in some way on its own, whether it's in the plugin or outside (or even in the filter itself. On top of this, AGC is often kinda built-in filters, it's common to lower the level along with resonance). > The fact is, if you must eventually reduce their levels anyway to avoid > clipping under summation, then perhaps they shouldn't (and needn't) be so > loud in the first place. > > What we should be thinking is backwards from "all notes produced should be > as close to clipping as possible." We should be thinking worst-case all > inputs full level and summed, and simply scale our inputs accordingly (see > below) from the beginning. > > Yes, the individual signals will be quieter. But this is the reason we > have lots of bits. 24 bits of resolution allows for 144dB of dynamic > range, WELL beyond the limits of human perception, never mind comfort. > [Even 16 bits with its 96 dB clipping-to-noise range (perceived to be much > greater with dither) has proven in practice to allow for 20 dB of headroom > with a generally acceptable signal-to-noise, even for full orchestral > recordings with quiet interludes and solos.] > > Also, keep in mind that unless all the signals are (1) identical, (2) at > full value AND (3) in perfect phase coherence with each other (a very > unusual circumstance), they will never sum at the peak theoretical value > anyway, but tend to add up to a level of, for "N" summed channels, (N-1) * > 3dB. So for eight inputs at full volume, each input could be scaled: > ((8-1) *3) db, or -21 dB. > > So, no: ACG is a band-aid. The real world has pretty much shown that if > you just mix at a reasonably lower level, the problem is greatly minimized > if not eliminated, with little audible penalty, and does not require the > complexity of creating an AGC and artfully implementing it. > > > Kind Regards, > David Reaves > > > On Sun, 24 Oct 2010 20:26:25 -0400, robert bristow-johnson > wrote: >> >> >> On Oct 24, 2010, at 5:23 PM, Alan Wolfe wrote: >> >>> How I understand mixing is that if you have N signals, all in the >>> range of -1,1 that you want to add all the signals together then >>> divide by N to get an output signal still in the range of -1,1. >>> >>> What do you do then if you are making a live playing synthesizer and >>> want to play 1 to N notes at the same time? >>> >>> If i cap the max number of notes to 8, add all the channels together >>> (some of which may be silent) and then divide by 8, single notes >>> played alone are very quiet. >>> >>> If i only divide by the number of non silent channels, there is an >>> audible pop when a new note is added or removed and the rest of the >>> audible channels suddenly increase or decrease in volume. >> >> would you expect something different? >> >>> How is this normally handled? >> >> >> i dunno what this is, a synthesized organ or similar? >> >> normally, whether you have 0 or 1 or 2 or N notes that may or may not >> have simultaneous onset or release, you do *no* scaling per se >> regarding the number of notes. just add 'em together. we assume that >> the note onset and release is click free by virtue of the synthesis or >> sample playback alg. >> >> now, to keep a consistent volume, that is level compression or AGC. >> you apply that to the summed channel or channels (in case of stereo). >> the gain change applied by the compressor or AGC better be designed to >> be reasonably smooth, by use of some ramping or LPF on the gain >> control signal. sometimes you cannot avoid some artifact of the gain >> change (usually called "pumping") but you should always be able to >> avoid clicking or popping. clicks or pops are an indication that some >> mistake has happened. >> >> that's my spin on 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 - www.avg.com Version: 9.0.862 / Virus Database: 271.1.1/3217 - Release Date: 10/24/10 20:34:00 From richarddobson at blueyonder.co.uk Mon Oct 25 06:41:53 2010 From: richarddobson at blueyonder.co.uk (Richard Dobson) Date: Mon, 25 Oct 2010 11:41:53 +0100 Subject: [music-dsp] Polyphony - how do you mix N number of signals andkeep a consistent volume? In-Reply-To: References: Message-ID: <4CC55EF1.20203@blueyonder.co.uk> On 25/10/2010 10:54, Didier Dambrin wrote: .. > > >> The fact is, if you must eventually reduce their levels anyway to >> avoid clipping under summation, then perhaps they shouldn't (and >> needn't) be so loud in the first place. >> > It's a fairly basic test - play one note (a "pedal tone") and then a large chord or cluster over it - there should be ~absolutely no perceptible change~ in the pedal tone when the chord is played. We have a volume control if we need it. If I find a synth that does impose such a change, that will the the last time I use it. I have yet to try a soft-synth that could not be pushed into clipping with extreme changes of polyphony - it goes with the territory. Therefore, the requirement is plain vanilla mixing. As noted elsewhere, unless voices are peak-aligned (which even with a chord is far from inevitable unless the sound really does have has a massive attack transient), division by N is usually excessive. A standard rule of thumb appears to be to scale by the square root of the number of voices. If any limiter is employed, it really has to be very smooth indeed, or that pedal tone will change in a very obvious way. I would have thought it not worth the trouble. If someone does want to play a 63-note cluster at 100% level, I think some clipping is an entirely appropriate consequence! Richard Dobson From rossb-lists at audiomulch.com Mon Oct 25 07:11:57 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Mon, 25 Oct 2010 22:11:57 +1100 Subject: [music-dsp] Polyphony - how do you mix N number of signals andkeep a consistent volume? References: Message-ID: <055f01cb7437$13afc220$0242000a@rossmacbook> David Reaves wrote: > Also, keep in mind that unless all the signals are (1) identical, (2) at > full value AND (3) in perfect phase coherence with each other (a very > unusual circumstance), they will never sum at the peak theoretical value > anyway, but tend to add up to a level of, for "N" summed channels, (N-1) * > 3dB. So for eight inputs at full volume, each input could be scaled: > ((8-1) *3) db, or -21 dB. I've always wondered about that. Do you know where this (N-1) * 3dB metric comes from or how it is derived David? Thanks Ross. From didid at skynet.be Mon Oct 25 08:03:55 2010 From: didid at skynet.be (Didier Dambrin) Date: Mon, 25 Oct 2010 14:03:55 +0200 Subject: [music-dsp] Polyphony - how do you mix N number of signalsandkeep a consistent volume? In-Reply-To: <055f01cb7437$13afc220$0242000a@rossmacbook> References: <055f01cb7437$13afc220$0242000a@rossmacbook> Message-ID: <371BB45E283A4BEEA80CB413E2B4410B@GOLAMD> I think a better estimation/average would be /Sqrt(NumVoices), no? > David Reaves wrote: >> Also, keep in mind that unless all the signals are (1) identical, (2) at >> full value AND (3) in perfect phase coherence with each other (a very >> unusual circumstance), they will never sum at the peak theoretical value >> anyway, but tend to add up to a level of, for "N" summed channels, (N-1) >> * >> 3dB. So for eight inputs at full volume, each input could be scaled: >> ((8-1) *3) db, or -21 dB. > > > I've always wondered about that. Do you know where this (N-1) * 3dB metric > comes from or how it is derived David? > > Thanks > > 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 -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.862 / Virus Database: 271.1.1/3217 - Release Date: 10/24/10 20:34:00 From rrsounds at aol.com Mon Oct 25 08:59:50 2010 From: rrsounds at aol.com (David Reaves) Date: Mon, 25 Oct 2010 14:59:50 +0200 Subject: [music-dsp] Polyphony - how do you mix N number of signals and keep a consistent volume? In-Reply-To: References: Message-ID: Two identical (correlated), but non-synchronized (non-coherent) sources "x" can either add (+-0 degrees phase relationship, 2x, or +6dB), subtract (180-degree relationship, 0x, or -inf. dB), or, depending upon phase, sum to some unknown figure somewhere in between. Statistically, the average summed amplitude relationship over time will tend to be the same as that of roughly 90 degrees; with random phase, a 90-degree relationship is likely to happen twice as often as either full summation or full cancellation. Two otherwise identical sources with a 90-degree phase relationship will sum at an amplitude of the square root of two or 1.414x, which is +3dB higher in amplitude than either one of the individual sources. This figure also happens to be the average *power* (RMS), non phase-dependent relationship between two identical sources and their summation (+6 dB is the voltage relationship), and the rule turns out to work with any two sources of the same power level, whether identical (correlated) program material or not. The two-channel-summation power rule formula can then be extended to additional source channels to be summed, to yield a safe attenuation figure to then be applied to each. While theoretical, the formula has proven to work out in practice over the decades, in untold numbers of mixing consoles, both analog and digital. If nothing else, it is certainly a well-worn starting place. Please note that this is all coming from my imperfect 55-year-old head, so... ;-) Kind Regards, David Reaves On Mon, 25 Oct 2010 22:11:57 +1100, "Ross Bencina" wrote: > > > David Reaves wrote: >> Also, keep in mind that unless all the signals are (1) identical, (2) at >> full value AND (3) in perfect phase coherence with each other (a very >> unusual circumstance), they will never sum at the peak theoretical value >> anyway, but tend to add up to a level of, for "N" summed channels, (N-1) * >> 3dB. So for eight inputs at full volume, each input could be scaled: >> ((8-1) *3) db, or -21 dB. > > > I've always wondered about that. Do you know where this (N-1) * 3dB metric > comes from or how it is derived David? > > Thanks > > Ross. From jkroll at lavabit.com Mon Oct 25 09:18:47 2010 From: jkroll at lavabit.com (Johannes Kroll) Date: Mon, 25 Oct 2010 15:18:47 +0200 Subject: [music-dsp] Polyphony - how do you mix N number of signals and keep a consistent volume? In-Reply-To: References: Message-ID: <20101025151847.015f45b1@arcadia> On Sun, 24 Oct 2010 14:23:13 -0700 Alan Wolfe wrote: > Hey Guys, > > How I understand mixing is that if you have N signals, all in the > range of -1,1 that you want to add all the signals together then > divide by N to get an output signal still in the range of -1,1. > > What do you do then if you are making a live playing synthesizer and > want to play 1 to N notes at the same time? You add them together using addition. Seriously, mixing doesn't involve any division by the number of channels used or anything like that. Mixing simply means addition and nothing more. From contact at quikquak.com Mon Oct 25 09:31:09 2010 From: contact at quikquak.com (Dave Hoskins) Date: Mon, 25 Oct 2010 14:31:09 +0100 Subject: [music-dsp] Polyphony - how do you mix N number of signals and keep a consistent volume? References: <20101025151847.015f45b1@arcadia> Message-ID: <4509772D5E0D437CBF54181CE3474D9D@DaveUpstairs> > On Sun, 24 Oct 2010 14:23:13 -0700 > Alan Wolfe wrote: > >> Hey Guys, >> >> How I understand mixing is that if you have N signals, all in the >> range of -1,1 that you want to add all the signals together then >> divide by N to get an output signal still in the range of -1,1. >> >> What do you do then if you are making a live playing synthesizer and >> want to play 1 to N notes at the same time? > > You add them together using addition. > > Seriously, mixing doesn't involve any division by the number of channels > used or anything like that. Mixing simply means addition and nothing > more. Yes, give the user an output volume control! BUT.. looking at some old code where I add together many tracks, I divide the overall sum by square root (number_of_channels) Which is what David Reaves was saying I guess. I found it to be the best fit model for constant volume when mixing more layers seemlessly. Dave From rrsounds at aol.com Mon Oct 25 09:51:47 2010 From: rrsounds at aol.com (David Reaves) Date: Mon, 25 Oct 2010 15:51:47 +0200 Subject: [music-dsp] Polyphony - how do you mix N number of signals and keep a consistent volume? In-Reply-To: References: Message-ID: <8D7EBECC-DE5E-4CD3-BF96-D3078B473E61@aol.com> Since obviously, you don't need to reduce the level for one channel alone (there's no summation involved), I think you can see why the rule is not -3dB **per channel**, but rather -3dB per every **ADDITIONAL** channel more than one. Hence, ((N-1) * -3dB), rather than simply (N * -3dB) David Reaves On Mon, 25 Oct 2010 14:31:09 +0100, "Dave Hoskins" wrote: > >> On Sun, 24 Oct 2010 14:23:13 -0700 >> Alan Wolfe wrote: >> >>> Hey Guys, >>> >>> How I understand mixing is that if you have N signals, all in the >>> range of -1,1 that you want to add all the signals together then >>> divide by N to get an output signal still in the range of -1,1. >>> >>> What do you do then if you are making a live playing synthesizer and >>> want to play 1 to N notes at the same time? >> >> You add them together using addition. >> >> Seriously, mixing doesn't involve any division by the number of channels >> used or anything like that. Mixing simply means addition and nothing >> more. > > Yes, give the user an output volume control! > > BUT.. looking at some old code where I add together many tracks, I divide > the overall sum by > square root (number_of_channels) > Which is what David Reaves was saying I guess. I found it to be the best fit > model for constant volume when mixing more layers seemlessly. > > Dave From jkroll at lavabit.com Mon Oct 25 09:54:31 2010 From: jkroll at lavabit.com (Johannes Kroll) Date: Mon, 25 Oct 2010 15:54:31 +0200 Subject: [music-dsp] Polyphony - how do you mix N number of signals and keep a consistent volume? In-Reply-To: <4509772D5E0D437CBF54181CE3474D9D@DaveUpstairs> References: <20101025151847.015f45b1@arcadia> <4509772D5E0D437CBF54181CE3474D9D@DaveUpstairs> Message-ID: <20101025155431.36a7117d@arcadia> On Mon, 25 Oct 2010 14:31:09 +0100 "Dave Hoskins" wrote: > > > > On Sun, 24 Oct 2010 14:23:13 -0700 > > Alan Wolfe wrote: > > > >> Hey Guys, > >> > >> How I understand mixing is that if you have N signals, all in the > >> range of -1,1 that you want to add all the signals together then > >> divide by N to get an output signal still in the range of -1,1. > >> > >> What do you do then if you are making a live playing synthesizer and > >> want to play 1 to N notes at the same time? > > > > You add them together using addition. > > > > Seriously, mixing doesn't involve any division by the number of channels > > used or anything like that. Mixing simply means addition and nothing > > more. > > Yes, give the user an output volume control! > > BUT.. looking at some old code where I add together many tracks, I divide > the overall sum by > square root (number_of_channels) > Which is what David Reaves was saying I guess. I found it to be the best fit > model for constant volume when mixing more layers seemlessly. In the case of a synthesizer, I would expect the volume to raise with the polyphony. If I don't want that, I add something like a compressor to the effect chain. I think doing some kind of automatic compression inside a synthesizer is counter-intuitive, very unusual and in most cases unwanted. From tom_info at ticino.com Mon Oct 25 11:03:52 2010 From: tom_info at ticino.com (Tom O'Hara) Date: Mon, 25 Oct 2010 17:03:52 +0200 Subject: [music-dsp] Polyphony - how do you mix N number of signals and keep a consistent volume? In-Reply-To: <8D7EBECC-DE5E-4CD3-BF96-D3078B473E61@aol.com> References: <8D7EBECC-DE5E-4CD3-BF96-D3078B473E61@aol.com> Message-ID: <4CC59C58.1060005@ticino.com> Actually, it's Log2(n) * -3dB, which is the same as dividing by sqrt(n). Tom On 25-Oct-10 15:51, David Reaves wrote: > Since obviously, you don't need to reduce the level for one channel alone (there's no summation involved), I think you can see why the rule is not -3dB **per channel**, but rather -3dB per every **ADDITIONAL** channel more than one. > > Hence, ((N-1) * -3dB), rather than simply (N * -3dB) > > David Reaves > > > On Mon, 25 Oct 2010 14:31:09 +0100, "Dave Hoskins" wrote: >>> On Sun, 24 Oct 2010 14:23:13 -0700 >>> Alan Wolfe wrote: >>> >>>> Hey Guys, >>>> >>>> How I understand mixing is that if you have N signals, all in the >>>> range of -1,1 that you want to add all the signals together then >>>> divide by N to get an output signal still in the range of -1,1. >>>> >>>> What do you do then if you are making a live playing synthesizer and >>>> want to play 1 to N notes at the same time? >>> You add them together using addition. >>> >>> Seriously, mixing doesn't involve any division by the number of channels >>> used or anything like that. Mixing simply means addition and nothing >>> more. >> Yes, give the user an output volume control! >> >> BUT.. looking at some old code where I add together many tracks, I divide >> the overall sum by >> square root (number_of_channels) >> Which is what David Reaves was saying I guess. I found it to be the best fit >> model for constant volume when mixing more layers seemlessly. >> >> Dave > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From jchandjr at bellsouth.net Mon Oct 25 14:04:51 2010 From: jchandjr at bellsouth.net (James Chandler Jr) Date: Mon, 25 Oct 2010 14:04:51 -0400 Subject: [music-dsp] ring modulation In-Reply-To: References: <80F2EF3F-59D5-401E-9796-4A71FC365224@audioimagination.com> <80D24495-73C8-46A2-B8D1-D19090801929@earlevel.com> <6CE33E35-145B-4A8E-AD43-3E5E210A378F@bellsouth.net> <51D9DA72-98E4-4709-8583-1D2A8D1802E9@audioimagination.com> <5AAC2497-B5DF-44E7-8025-E158C0FBE1F0@bellsouth.net> <0867d9ed4eebdd0002d9c0a06d6f52e9.squirrel@webmail.uio.no> <7DDAA772-6F32-4579-9A63-EAAAE4FAD99C@bellsouth.net> <20101022220430.E66360@bunrab.ronnet.moc> Message-ID: <1D9914D6-5C5A-4B8C-9F71-AE7E0DE8199D@bellsouth.net> Hi Alan I think they are different circuit methods to skin the same cat. An XOR ring modulator is a true ring modulation, though it is digitized and only works on pulse-wave digital logic signals. A simple XOR ring modulator would not work with input signals which have any values other than zero or one, AFAIK. I may be remembering wrong, but think that some of the Arp analog synths had an XOR ring modulator. An interesting sounding cymbal/hihat analog generator based on XOR was in the venerable Korg KR-55 drum machine. Took awhile to find a schematic online, but here it is-- http://www.fichier-pdf.fr/2010/05/18/3ql09wz/korg-kr-55-schematics.pdf The XOR generators are on the fifth page labeled KLM-199. To the right of the page are eight fixed frequency square wave oscillators (with circuit board trimmer resistors to tweak frequency). Pairs of these oscillators are routed to four XOR gates on the top-left of the page. Three of the XOR outputs are summed for "Ring1" output, and one XOR feeds the "Ring2" output. These constant-level signals were routed thru simple Attack-Release amplitude envelopes to emulate cymbals and hats and cowbell. Ring1 was variously processed for the cymbal/hat, and Ring2 was processed for the cowbell. The cymbal/hat processing/gating is on the ninth page, and the cowbell processing/gating is on the seventh page. James Chandler Jr. On Oct 23, 2010, at 1:51 AM, Alan Wolfe wrote: > That is so bizarre, how is it that so many different devices all came > to have the same name? > > On Fri, Oct 22, 2010 at 11:05 PM, wrote: >> The 'classic' 4 diode ring modulator does not just multipy the >> two signals. The diodes are used to switch the polarity of the >> connection of the input signal to the output based on the >> polarity of the carrier, so when the carrier is positive the >> input is sent to the output unchanged, but when the carrier is >> negative the input is sent to the output inverted. i.e. when the >> carrier is positive it's like the input is multipied by 1 and >> when the carrier is negative it is mutlipied by -1 so for a sine >> wave carrier you have the equivalent of the input multiplied by a >> /square/ of the same frequncy as the carrier sine wave. >> So the output contains f_c+/-f_i, 3f_c+/-f_i, 5f_c+/-f_i etc. >> (where f_c = carrier freq and f_i the input freq) and for this type >> of ring modulator there is a difference between the 'input' and the >> 'carrier' signals. >> >> As a radio modulator (an early use of ring modulators) the 'input' >> freqeuncy would be small compared to the carrier frequency, so the >> output would be at fequencies near the frequncies of a square wave at the >> carrier frequency, f_c, 3f_c, 5f_c etc. and the unwanted signals >> could be easily filtered out. >> >> Many other ciruits have been called 'ring modulators' in addition to >> 4-quadrant multipliers. At least one synth used an xor gate (with signal >> offsets) as a 'ring mudulator' (so basically you get the product of square >> waves at both the input and carrier frequncies --though I think maybe the >> synths used square wave oscilator and inputs, so it was basically the same >> as simple multiplication anyway), And I've not figured out what Craig >> Anderton's LM565 based 'ring modulator' really does... >> >> CR >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, 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 alan.wolfe at gmail.com Mon Oct 25 14:15:28 2010 From: alan.wolfe at gmail.com (Alan Wolfe) Date: Mon, 25 Oct 2010 11:15:28 -0700 Subject: [music-dsp] ring modulation In-Reply-To: <1D9914D6-5C5A-4B8C-9F71-AE7E0DE8199D@bellsouth.net> References: <80F2EF3F-59D5-401E-9796-4A71FC365224@audioimagination.com> <80D24495-73C8-46A2-B8D1-D19090801929@earlevel.com> <6CE33E35-145B-4A8E-AD43-3E5E210A378F@bellsouth.net> <51D9DA72-98E4-4709-8583-1D2A8D1802E9@audioimagination.com> <5AAC2497-B5DF-44E7-8025-E158C0FBE1F0@bellsouth.net> <0867d9ed4eebdd0002d9c0a06d6f52e9.squirrel@webmail.uio.no> <7DDAA772-6F32-4579-9A63-EAAAE4FAD99C@bellsouth.net> <20101022220430.E66360@bunrab.ronnet.moc> <1D9914D6-5C5A-4B8C-9F71-AE7E0DE8199D@bellsouth.net> Message-ID: Interesting stuff, thanks James! (: On Mon, Oct 25, 2010 at 11:04 AM, James Chandler Jr wrote: > Hi Alan > > I think they are different circuit methods to skin the same cat. An XOR ring modulator is a true ring modulation, though it is digitized and only works on pulse-wave digital logic signals. A simple XOR ring modulator would not work with input signals which have any values other than zero or one, AFAIK. > > I may be remembering wrong, but think that some of the Arp analog synths had an XOR ring modulator. > > An interesting sounding cymbal/hihat analog generator based on XOR was in the venerable Korg KR-55 drum machine. Took awhile to find a schematic online, but here it is-- > > http://www.fichier-pdf.fr/2010/05/18/3ql09wz/korg-kr-55-schematics.pdf > > The XOR generators are on the fifth page labeled KLM-199. > > To the right of the page are eight fixed frequency square wave oscillators (with circuit board trimmer resistors to tweak frequency). Pairs of these oscillators are routed to four XOR gates on the top-left of the page. Three of the XOR outputs are summed for "Ring1" output, and one XOR feeds the "Ring2" output. These constant-level signals were routed thru simple Attack-Release amplitude envelopes to emulate cymbals and hats and cowbell. > > Ring1 was variously processed for the cymbal/hat, and Ring2 was processed for the cowbell. > > The cymbal/hat processing/gating is on the ninth page, and the cowbell processing/gating is on the seventh page. > > James Chandler Jr. > > On Oct 23, 2010, at 1:51 AM, Alan Wolfe wrote: > >> That is so bizarre, how is it that so many different devices all came >> to have the same name? >> >> On Fri, Oct 22, 2010 at 11:05 PM, ? wrote: >>> ?The 'classic' 4 diode ring modulator does not just multipy the >>> two signals. The diodes are used to switch the polarity of the >>> connection of the input signal to the output based on the >>> polarity of the carrier, so when the carrier is positive the >>> input is sent to the output unchanged, but when the carrier is >>> negative the input is sent to the output inverted. i.e. when the >>> carrier is positive it's like the input is multipied by 1 and >>> when the carrier is negative it is mutlipied by -1 so for a sine >>> wave carrier you have the equivalent of the input multiplied by a >>> /square/ of the same frequncy as the carrier sine wave. >>> ?So the output contains f_c+/-f_i, 3f_c+/-f_i, 5f_c+/-f_i etc. >>> (where f_c = carrier freq and f_i the input freq) and for this type >>> of ring modulator there is a difference between the 'input' and the >>> 'carrier' signals. >>> >>> ?As a radio modulator (an early use of ring modulators) the 'input' >>> freqeuncy would be small compared to the carrier frequency, so the >>> output would be at fequencies near the frequncies of a square wave at the >>> carrier frequency, f_c, 3f_c, 5f_c etc. and the unwanted signals >>> could be easily filtered out. >>> >>> ?Many other ciruits have been called 'ring modulators' in addition to >>> 4-quadrant multipliers. At least one synth used an xor gate (with signal >>> offsets) as a 'ring mudulator' (so basically you get the product of square >>> waves at both the input and carrier frequncies --though I think maybe the >>> synths used square wave oscilator and inputs, so it was basically the same >>> as simple multiplication anyway), And I've not figured out what Craig >>> Anderton's LM565 based 'ring modulator' really does... >>> >>> ? CR >>> -- >>> dupswapdrop -- the music-dsp mailing list and website: >>> subscription info, FAQ, 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 rbj at audioimagination.com Mon Oct 25 14:32:30 2010 From: rbj at audioimagination.com (robert bristow-johnson) Date: Mon, 25 Oct 2010 14:32:30 -0400 Subject: [music-dsp] Polyphony - how do you mix N number of signals and keep a consistent volume? In-Reply-To: <4CC59C58.1060005@ticino.com> References: <8D7EBECC-DE5E-4CD3-BF96-D3078B473E61@aol.com> <4CC59C58.1060005@ticino.com> Message-ID: On Oct 25, 2010, at 11:03 AM, Tom O'Hara wrote: > Actually, it's Log2(n) * -3dB, which is the same as dividing by > sqrt(n). Tom's right. David R is right (except for the (N-1)*(-3 dB)). Dave H is right. Didier is right. and, in my opinion, Johannes is also right. i would think that a useful *option* for an organ or sampler (not a B3 simulation, that's a different animal) with potentially 128 note polyphony, that if the musicians were to lay both his entire forearms down on the keyboard, that maybe there should be something other than the volume pedal to limit the volume. for an internal compressor/ limiter, perhaps level detection wouldn't be needed as it would be for an outboard unit because the compressor/limiter would know the number of keys pressed. if the number of keys pressed is N, i might suggest a linear scaling factor of 1 when N < M, where M is some preset number where this scaling would begin to kick in. for N > M, perhaps it the linear scaling factor should be sqrt(M/N), but perhaps some other heuristic should be considered. this gain signal should always have some kinda LPF applied to it so that it slews or ramps from one value to the other reasonably slowly. but there should always be the volume pedal, in case the scaling applied by the compressor is not what the musician wants. i am not sure, but i think a B3 simulation would be applying some kinda overall scaling based on the number of keys pressed, but i don't know what it is. -- r b-j rbj at audioimagination.com "Imagination is more important than knowledge." From rossb-lists at audiomulch.com Tue Oct 26 00:39:14 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Tue, 26 Oct 2010 15:39:14 +1100 Subject: [music-dsp] Polyphony - how do you mix N number of signals andkeep a consistent volume? References: Message-ID: <00f601cb7516$b5d497d0$0201a8c0@rossmacbook> David Reaves: > Two identical (correlated), but non-synchronized (non-coherent) sources > "x"... [snip] Thanks for the explanation David Now I'm wondering about this: > While theoretical, the formula has proven to work out in practice over the > decades, in untold numbers of mixing consoles, both analog and digital. If > nothing else, it is certainly a well-worn starting place. Do you mean it's used to determine the required linear headroom before distortion for different stages of the mix bus? Thanks Ross. From tom_info at ticino.com Tue Oct 26 10:36:12 2010 From: tom_info at ticino.com (Tom O'Hara) Date: Tue, 26 Oct 2010 16:36:12 +0200 Subject: [music-dsp] Polyphony - how do you mix N number of signals andkeep a consistent volume? In-Reply-To: <00f601cb7516$b5d497d0$0201a8c0@rossmacbook> References: <00f601cb7516$b5d497d0$0201a8c0@rossmacbook> Message-ID: <4CC6E75C.7040807@ticino.com> On 26-Oct-10 06:39, Ross Bencina wrote: > Now I'm wondering about this: > >> While theoretical, the formula has proven to work out in practice >> over the decades, in untold numbers of mixing consoles, both analog >> and digital. If nothing else, it is certainly a well-worn starting >> place. > > > Do you mean it's used to determine the required linear headroom before > distortion for different stages of the mix bus? Yes. Tom From jchandjr at bellsouth.net Tue Oct 26 10:44:05 2010 From: jchandjr at bellsouth.net (James Chandler Jr) Date: Tue, 26 Oct 2010 10:44:05 -0400 Subject: [music-dsp] Polyphony - how do you mix N number of signals and keep a consistent volume? In-Reply-To: References: <8D7EBECC-DE5E-4CD3-BF96-D3078B473E61@aol.com> <4CC59C58.1060005@ticino.com> Message-ID: On Oct 25, 2010, at 2:32 PM, robert bristow-johnson wrote: > > i am not sure, but i think a B3 simulation would be applying some kinda overall scaling based on the number of keys pressed, but i don't know what it is. I don't know what it is either. Am guessing that the scaling would need to account for the "dilution" of each tonewheel according to the number of keys pressed. In the case of a big chord + pedal bass-- The bass pedal lowest drawbar probably will not get "diluted" by any higher keys (unless the organist is also playing low tones on the keyboard). So the pedal bass is likely to stay about the same amplitude in the mix. Some tonewheel generators will be loaded into several keyboard busses from several different held keys. Other tonewheel generators active in the chord will be loaded by fewer keyboard busses, and will not suffer as much attenuation. It is one of the things that makes old tonewheel organs so interesting in sound and playability. With some playing styles, if one is accustomed to piano, synth, or transistor organ, one can get a feeling that the dynamic range is limited. But the instruments effectively compress the volume without overtly sounding compressed. Hmm, wonder if the same thing can happen in pipe organs and accordions? If multiple keys are held, would a lot of pipes/reeds load down the wind chest and reduce the amplitude of each active pipe or reed? James Chandler Jr. From pjgee at emptysquare.com Tue Oct 26 13:34:03 2010 From: pjgee at emptysquare.com (pjgee at emptysquare.com) Date: Tue, 26 Oct 2010 10:34:03 -0700 Subject: [music-dsp] Polyphony - how do you mix N number of signals and keep a consistent volume? In-Reply-To: References: <8D7EBECC-DE5E-4CD3-BF96-D3078B473E61@aol.com> <4CC59C58.1060005@ticino.com> Message-ID: <3434feaa0fe8783c5366c7f86d953287.squirrel@email.powweb.com> A classic tonewheel organ has some natural tube compression going on and the player uses the expression pedal quite a bit for added control of dynamics. > > On Oct 25, 2010, at 2:32 PM, robert bristow-johnson wrote: > >> >> i am not sure, but i think a B3 simulation would be applying some kinda >> overall scaling based on the number of keys pressed, but i don't know >> what it is. > > I don't know what it is either. > > Am guessing that the scaling would need to account for the "dilution" of > each tonewheel according to the number of keys pressed. In the case of a > big chord + pedal bass-- The bass pedal lowest drawbar probably will not > get "diluted" by any higher keys (unless the organist is also playing low > tones on the keyboard). So the pedal bass is likely to stay about the same > amplitude in the mix. Some tonewheel generators will be loaded into > several keyboard busses from several different held keys. Other tonewheel > generators active in the chord will be loaded by fewer keyboard busses, > and will not suffer as much attenuation. > > It is one of the things that makes old tonewheel organs so interesting in > sound and playability. With some playing styles, if one is accustomed to > piano, synth, or transistor organ, one can get a feeling that the dynamic > range is limited. But the instruments effectively compress the volume > without overtly sounding compressed. > > Hmm, wonder if the same thing can happen in pipe organs and accordions? If > multiple keys are held, would a lot of pipes/reeds load down the wind > chest and reduce the amplitude of each active pipe or reed? > > James Chandler Jr. > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From padawan12 at obiwannabe.co.uk Tue Oct 26 16:40:04 2010 From: padawan12 at obiwannabe.co.uk (Andy Farnell) Date: Tue, 26 Oct 2010 21:40:04 +0100 Subject: [music-dsp] Polyphony - how do you mix N number of signals and keep a consistent volume? In-Reply-To: References: <8D7EBECC-DE5E-4CD3-BF96-D3078B473E61@aol.com> <4CC59C58.1060005@ticino.com> Message-ID: <20101026214004.04cbefe9.padawan12@obiwannabe.co.uk> Good point. This kind of energy sag seems likely in anything with voices sharing a common reservoir, bagpipes, accordian... Another thought: many distributed, uncorrelated sources have an apparent acoustic loudness as the root of the sum of their squares. Could it be that for certain situations (sample based sources maybe) a simple summation sounds wrong as more voices are added? Andy On Tue, 26 Oct 2010 10:44:05 -0400 James Chandler Jr wrote: > Hmm, wonder if the same thing can happen in pipe organs and accordions? If multiple keys are held, would a lot of pipes/reeds load down the wind chest and reduce the amplitude of each active pipe or reed? -- Andy Farnell From risto.holopainen at imv.uio.no Tue Oct 26 16:40:22 2010 From: risto.holopainen at imv.uio.no (Risto Holopainen) Date: Tue, 26 Oct 2010 22:40:22 +0200 Subject: [music-dsp] Polyphony - how do you mix N number of signals and keep a consistent volume? In-Reply-To: References: <8D7EBECC-DE5E-4CD3-BF96-D3078B473E61@aol.com> <4CC59C58.1060005@ticino.com> Message-ID: <9dc541d54249ac092e0c91afacb6fb7a.squirrel@webmail.uio.no> > Hmm, wonder if the same thing can happen in pipe organs and accordions? If > multiple keys are held, would a lot of pipes/reeds load down the wind > chest and reduce the amplitude of each active pipe or reed? > > James Chandler Jr. > -- Yes, as I recall from playing pipe organ long ago, if you attack a cluster of notes at once, there will be a sforzando kind of attack followed by a sound with lower loudness than expected. The timbre may be softer too. Now that would be an interesting thing to model. Risto From rbj at audioimagination.com Tue Oct 26 16:50:33 2010 From: rbj at audioimagination.com (robert bristow-johnson) Date: Tue, 26 Oct 2010 16:50:33 -0400 Subject: [music-dsp] Polyphony - how do you mix N number of signals and keep a consistent volume? In-Reply-To: <3434feaa0fe8783c5366c7f86d953287.squirrel@email.powweb.com> References: <8D7EBECC-DE5E-4CD3-BF96-D3078B473E61@aol.com> <4CC59C58.1060005@ticino.com> <3434feaa0fe8783c5366c7f86d953287.squirrel@email.powweb.com> Message-ID: <0382CF95-BB2A-453A-BA44-3BB69B2EDD63@audioimagination.com> On Oct 26, 2010, at 1:34 PM, pjgee at emptysquare.com wrote: > A classic tonewheel organ has some natural tube compression going on sure, but is there additional attenuation per note when notes are added and the B+ power supply is getting a little bit loaded? sorta like the pipe organs, but electrically, not pnuematically. the tube distortion (and whatever compression comes with it) and the leslie, them's more effects to worry about. L8r, -- r b-j rbj at audioimagination.com "Imagination is more important than knowledge." From richarddobson at blueyonder.co.uk Tue Oct 26 17:10:26 2010 From: richarddobson at blueyonder.co.uk (Richard Dobson) Date: Tue, 26 Oct 2010 22:10:26 +0100 Subject: [music-dsp] Polyphony - how do you mix N number of signals and keep a consistent volume? In-Reply-To: <9dc541d54249ac092e0c91afacb6fb7a.squirrel@webmail.uio.no> References: <8D7EBECC-DE5E-4CD3-BF96-D3078B473E61@aol.com> <4CC59C58.1060005@ticino.com> <9dc541d54249ac092e0c91afacb6fb7a.squirrel@webmail.uio.no> Message-ID: <4CC743C2.6080203@blueyonder.co.uk> On 26/10/2010 21:40, Risto Holopainen wrote: > >> Hmm, wonder if the same thing can happen in pipe organs and accordions? If >> multiple keys are held, would a lot of pipes/reeds load down the wind >> chest and reduce the amplitude of each active pipe or reed? >> >> James Chandler Jr. >> -- > > Yes, as I recall from playing pipe organ long ago, if you attack a cluster > of notes at once, there will be a sforzando kind of attack followed by a > sound with lower loudness than expected. The timbre may be softer too. Now > that would be an interesting thing to model. > The story goes that a performance some years ago of a Ligeti organ work full of clusters in (IIRC) the RFH in London, had the unfortunate consequence of actually blowing a fuse, as it demanded more current than was available. This seems like an excellent physical model to adopt for people inclined to overdo things. Richard Dobson From ebrombaugh1 at cox.net Tue Oct 26 23:55:56 2010 From: ebrombaugh1 at cox.net (Eric Brombaugh) Date: Tue, 26 Oct 2010 20:55:56 -0700 Subject: [music-dsp] Polyphony - how do you mix N number of signals and keep a consistent volume? In-Reply-To: <4CC743C2.6080203@blueyonder.co.uk> References: <8D7EBECC-DE5E-4CD3-BF96-D3078B473E61@aol.com> <4CC59C58.1060005@ticino.com> <9dc541d54249ac092e0c91afacb6fb7a.squirrel@webmail.uio.no> <4CC743C2.6080203@blueyonder.co.uk> Message-ID: <4CC7A2CC.7030202@cox.net> On 10/26/2010 02:10 PM, Richard Dobson wrote: > On 26/10/2010 21:40, Risto Holopainen wrote: >> >>> Hmm, wonder if the same thing can happen in pipe organs and >>> accordions? If >>> multiple keys are held, would a lot of pipes/reeds load down the wind >>> chest and reduce the amplitude of each active pipe or reed? Yes, but it depends on how the wind system was designed. Some organs are built with local bellows attached directly to the windchest - so called 'schwimmers' which act in a way very much like decoupling capacitors in electric power supplies and prevent or damp out transients in the windpressure. Some purists prefer these windpressure transients, hence the spate of T-shirts found on some organ enthusiasts which bore the text "Give wiggly wind a fair shake". >> Yes, as I recall from playing pipe organ long ago, if you attack a >> cluster >> of notes at once, there will be a sforzando kind of attack followed by a >> sound with lower loudness than expected. The timbre may be softer too. >> Now >> that would be an interesting thing to model. As noted earlier, the wind supply system of a pipe organ can be modeled as a passive LRC network - narrow wind conductors offer resistance, long straight wind conductors build up inertia in the air mass and act somewhat inductively, and bellows behave like capacitors. Similarly, keys are switches, blowers are supplies and pipes are loads. Fire up your spice simulator and see what falls out... > The story goes that a performance some years ago of a Ligeti organ work > full of clusters in (IIRC) the RFH in London, had the unfortunate > consequence of actually blowing a fuse, as it demanded more current than > was available. This seems like an excellent physical model to adopt for > people inclined to overdo things. Electric action. Meh. Go with tracker action - green power derived entirely from the organist and not subject to blown fuses... Eric (grew up in a tracker-action pipe-organ shop) From am at andre-michelle.com Wed Oct 27 05:45:15 2010 From: am at andre-michelle.com (Andre Michelle) Date: Wed, 27 Oct 2010 11:45:15 +0200 Subject: [music-dsp] C++ performance Message-ID: Hi all, I am currently developing a simple music toy for IOS in C++. To make this fast enough, I am in need for some tips. I am quite new to C++ so I don't have enough experience to google it by myself. #1 Is there a bit operation to clamp a float between zero and one in order to advance the phase through a wave-shaping algorithm? xIncr = frequency / samplingRate; loop: amp = wave(x); x += xIncr; if( x > 1.0 ) x -= 1.0; // can this be done faster by bit masking? #2 I am using a Signal class which holds 2 floats (left and right) and uses operation overloading to write much nicer code in implementations. This is pretty straight forward and I think the compiler inlines that automatically: Signal& operator += ( Signal rhs ) { l += rhs.l; r += rhs.r; return *this; } However this returns a new Signal: const Signal operator + ( const Signal& rhs ) const { return Signal( l + rhs.l, r + rhs.r ); } Is every compiler capable to see that the new Signal can be in most cases ignored and the values (left, right) be remained on stack? #3 Is it possible to inline an entirely class object? For instance I have a standard delay module with its own buffer and current write position. All functions (like put, get(offset) ) are set to 'inline', but there is still the drawback by accessing the objects members. I could unroll (or better move) all the code into all implementations I have so far, but this would completely destroy the readability of my sources. Is there a specific thing in C++ you can point me too? Thats it for now. Thanks for any help! -- aM http://www.andre-michelle.com From rainwarrior at gmail.com Wed Oct 27 06:42:14 2010 From: rainwarrior at gmail.com (Brad Smith) Date: Wed, 27 Oct 2010 06:42:14 -0400 Subject: [music-dsp] C++ performance In-Reply-To: References: Message-ID: 1. Offhand I would probably write it like this: #include x = x - floorf(x); There should be a bitwise way to do it (you can look up the IEEE 754 standard to see how bits are packed in a floating point), but it might not be the fastest way to do things. If you do try it, make sure to test and time it yourself to be sure that you've actually made it faster. I've also seen: #define FAST_FLOOR(x) ((float)(long)(x)) Again, I'm not sure if that would be faster on your architecture. For some compilers "floor" is an intrinsic. Again, test it yourself. Take a look at the output assembly code. Alternatively, if xlncr is constant while you are looping, you could calculate how many loops you can do before x >= 1 and just run that many loops without the check. 2. Declare your operators as inline and make sure they're in the header for that class, otherwise it will be a function in an object file somewhere and can't be optimized that way. Most compilers should be smart enough to do the optimization you want, but when in doubt check the assembly output. 3. Not sure exactly what you're asking. Simple inlined classes can get pretty lightweight, but it really depends what you do inside them. Again, if you can read assembly code, this can be output and it will tell you what you want to know about what is happening with your code. -- Brad Smith On Wed, Oct 27, 2010 at 5:45 AM, Andre Michelle wrote: > Hi all, > > > I am currently developing a simple music toy for IOS in C++. > > To make this fast enough, I am in need for some tips. I am quite new to C++ so I don't have enough experience to google it by myself. > > #1 > Is there a bit operation to clamp a float between zero and one in order to advance the phase through a wave-shaping algorithm? > > xIncr = frequency / samplingRate; > > loop: > amp = wave(x); > x += xIncr; > if( x > 1.0 ) x -= 1.0; // can this be done faster by bit masking? > > #2 > I am using a Signal class which holds 2 floats (left and right) and uses operation overloading to write much nicer code in implementations. > > This is pretty straight forward and I think the compiler inlines that automatically: > Signal& operator += ( Signal rhs ) { l += rhs.l; r += rhs.r; return *this; } > > However this returns a new Signal: > const Signal operator + ( const Signal& rhs ) const { return Signal( l + rhs.l, r + rhs.r ); } > > Is every compiler capable to see that the new Signal can be in most cases ignored and the values (left, right) be remained on stack? > > #3 > Is it possible to inline an entirely class object? For instance I have a standard delay module with its own buffer and current write position. All functions (like put, get(offset) ) are set to 'inline', but there is still the drawback by accessing the objects members. I could unroll (or better move) all the code into all implementations I have so far, but this would completely destroy the readability of my sources. Is there a specific thing in C++ you can point me too? > > Thats it for now. Thanks for any help! > > -- > aM > http://www.andre-michelle.com > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From am at andre-michelle.com Wed Oct 27 07:16:26 2010 From: am at andre-michelle.com (Andre Michelle) Date: Wed, 27 Oct 2010 13:16:26 +0200 Subject: [music-dsp] C++ performance In-Reply-To: References: Message-ID: Hi Brad, > 1. Offhand I would probably write it like this: > > #include > x = x - floorf(x); This is probably a much better way for the compiler to optimize it for the target platform. > 2. > > Declare your operators as inline and make sure they're in the header > for that class, otherwise it will be a function in an object file > somewhere and can't be optimized that way. Most compilers should be > smart enough to do the optimization you want, but when in doubt check > the assembly output. I checked memory leaks, which I didn't find. This may be a clue, that the compiler did a good job for the return expression: return Signal( l + rhs.l, r + rhs.r ); Since no 'new' is involved, the compiler has more options I suppose. > 3. > > Not sure exactly what you're asking. Simple inlined classes can get > pretty lightweight, but it really depends what you do inside them. > Again, if you can read assembly code, this can be output and it will > tell you what you want to know about what is happening with your code. The idea is to tell the compiler, that he should embed everything from the class for every instance I create in my implementation. This way I get rid of scope changes. Maybe this is not a good idea at all. Obviously I cannot read assembly nor do I have the tools to output them. Anything you can recommend (best case for xCode) is much appreciated. Thanks -- aM http://www.andre-michelle.com From thomas at pdp7.org Wed Oct 27 07:59:45 2010 From: thomas at pdp7.org (Thomas Strathmann) Date: Wed, 27 Oct 2010 13:59:45 +0200 Subject: [music-dsp] C++ performance In-Reply-To: References: Message-ID: <4CC81431.404@pdp7.org> On 10/27/10 13:16 , Andre Michelle wrote: >> Not sure exactly what you're asking. Simple inlined classes can get >> pretty lightweight, but it really depends what you do inside them. >> Again, if you can read assembly code, this can be output and it will >> tell you what you want to know about what is happening with your code. > > The idea is to tell the compiler, that he should embed everything from the class for every instance I create in my implementation. This way I get rid of scope changes. Maybe this is not a good idea at all. Obviously I cannot read assembly nor do I have the tools to output them. Anything you can recommend (best case for xCode) is much appreciated. Some generic advice first: 1. Get to know your compiler and library and write "common sense" code that the compiler knows how to deal with in an (near to) optimal way. 2. Use a profiler (gprof, Instruments.app, etc.) to identify those parts of the code that are performance critical and could be improved. 3. Don't optimize until you have concrete evidence that something should be optimized (i.e. don't play the "let's see what compiler switch I do not use already" game). 4. To reiterate: Don't think your cleverer than the people who wrote the compiler and the runtime and don't try to port idioms from other languages in the hope of making your code run faster. As for assembler: If you really care about performance there's no way around learning to read the compiler's output. This is the only valid way of removing doubt about whether the compiler actually does the optimization you had in mind. To look at assembler code (assuming you use gcc) use "gcc -S foo.c". It takes some getting used to, but it's well worth it. Sometimes you'll be able to just get the info you want by doing A-B comparisons of the generated assembler code. Thomas From michael.gogins at gmail.com Wed Oct 27 10:03:11 2010 From: michael.gogins at gmail.com (Michael Gogins) Date: Wed, 27 Oct 2010 10:03:11 -0400 Subject: [music-dsp] C++ performance In-Reply-To: <4CC81431.404@pdp7.org> References: <4CC81431.404@pdp7.org> Message-ID: You may be interested in my advice on programming, most of which is based on experience with music programming: http://michael-gogins.com/?p=299 Regards, Mike Gogins On Wed, Oct 27, 2010 at 7:59 AM, Thomas Strathmann wrote: > On 10/27/10 13:16 , Andre Michelle wrote: >>> >>> Not sure exactly what you're asking. Simple inlined classes can get >>> pretty lightweight, but it really depends what you do inside them. >>> Again, if you can read assembly code, this can be output and it will >>> tell you what you want to know about what is happening with your code. >> >> The idea is to tell the compiler, that he should embed everything from the >> class for every instance I create in my implementation. This way I get rid >> of scope changes. Maybe this is not a good idea at all. Obviously I cannot >> read assembly nor do I have the tools to output them. Anything you can >> recommend (best case for xCode) is much appreciated. > > Some generic advice first: > > 1. Get to know your compiler and library and write "common sense" code > ? that the compiler knows how to deal with in an (near to) optimal way. > 2. Use a profiler (gprof, Instruments.app, etc.) to identify those > ? parts of the code that are performance critical and could be > ? improved. > 3. Don't optimize until you have concrete evidence that something > ? should be optimized (i.e. don't play the "let's see what compiler > ? switch I do not use already" game). > 4. To reiterate: Don't think your cleverer than the people who wrote > ? the compiler and the runtime and don't try to port idioms from > ? other languages in the hope of making your code run faster. > > As for assembler: If you really care about performance there's no way around > learning to read the compiler's output. This is the only valid way of > removing doubt about whether the compiler actually does the optimization you > had in mind. To look at assembler code (assuming you use gcc) use "gcc -S > foo.c". It takes some getting used to, but it's well worth it. Sometimes > you'll be able to just get the info you want by doing A-B comparisons of the > generated assembler code. > > ? ? ? ?Thomas > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp > links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com From rossb-lists at audiomulch.com Wed Oct 27 11:14:44 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Thu, 28 Oct 2010 02:14:44 +1100 Subject: [music-dsp] C++ performance References: Message-ID: <052e01cb75e9$b05807a0$0201a8c0@rossmacbook> Andre wrote: > To make this fast enough, I am in need for some tips. I am quite new to > C++ so I don't have enough experience to google it by myself. If you are new to C++ my #1 suggestion would be: don't try to be too cute with the compiler. write straightforwad C code. There are few C++ language features that are guaranteed to make your code faster, most only risk it going slower (although compilers are pretty good these days I think). Making inlining possible is always a good idea though -- definitely do that. > #1 > Is there a bit operation to clamp a float between zero and one in order to > advance the phase through a wave-shaping algorithm? > > xIncr = frequency / samplingRate; > > loop: > amp = wave(x); > x += xIncr; > if( x > 1.0 ) x -= 1.0; // can this be done faster by bit masking? That's the way I'd usually write it. or even while( x > 1.0 ) x -= 1.0; The only way to be sure is to benchmark different options. As others have said, different architectures and compilers will behave differently. > #2 > I am using a Signal class which holds 2 floats (left and right) and uses > operation overloading to write much nicer code in implementations. > > This is pretty straight forward and I think the compiler inlines that > automatically: > Signal& operator += ( Signal rhs ) { l += rhs.l; r += rhs.r; return > *this; } > > However this returns a new Signal: > const Signal operator + ( const Signal& rhs ) const { return Signal( l + > rhs.l, r + rhs.r ); } That's pretty unorthodox. Are you sure you don't just want to keep 2 floats around: float left, float right; left += a; right+= b; It's a bit more code but it will be fast and other people will be able to read it. You can use typdef if you're not sure if you want signal to be a float or a double: typedef float signal_t; or typedef double signal_t; > Is every compiler capable to see that the new Signal can be in most cases > ignored and the values (left, right) be remained on stack? I would say no. You can't depend on every compiler to do that, but some will, especially in such a simple example where the type is just two scalar values. for more complex cases the whole world of template metaprogramming (google "template metaprogramming") was invented. > #3 > Is it possible to inline an entirely class object? For instance I have a > standard delay module with its own buffer and current write position. All > functions (like put, get(offset) ) are set to 'inline', but there is still > the drawback by accessing the objects members. Inlined functions will be inlined when the compiler thinks it's appropriate (often it will for simple functions). You could try googling for "when are inline C++ functions inlined". To me what you are proposing sounds fine. There will always be a drawback to accessing the object members whether you dereference them via a this ptr or some other ptr. If you want to avoid function-call overhead you should consider block processing -- every function processes an array of samples for each call rather than a single sample -- this gives the compiler opportunities to unroll loops and optimise things into registers (depending on your processor), for example, instead of: // sample-by-sample myBigEffect( float *output, const float *input, int count ) { for( int =0; i < count;++i ){ float a = filter.process( input[i] ); float b = a * someFactor; float c = oscillator1.generate(); float d = oscillator2.generate(); output[i] = b * c * d; } } // block processing myBigEffect( float *output, const float *input, int count ) { float temp1[COUNT]; // perhaps you allocate this before hand filter.process( temp1, input, count ); // a = filter.process( input[i] ); multiply( output, temp1, someFactor, count ); // b = a * someFactor; oscillator1.generate( temp1, count ); // c = oscillator1.generate(); multiply( output, temp1, count ); // output = b * c; oscillator2.generate( temp1, count ); // oscillator2.generate(); multiply( output, temp1, count ); // output = b * c * d } Whether this is possible, and to what degree depends mainly on the structure of feedback loops in your signal path. Each unit generator only has to implement a simple procesing loop which is easy for you to optimise by hand, unroll, recode in asm etc. Many CPUs have vector processing capabilities that can may processing simple loops easy and fast. The more complex your loops the harder the compiler will have to work.. but it could still be fast. Whether block processing is faster than sample-by-sample depends on many factors. You may end up with a combination of both. >I could unroll (or better move) all the code into all implementations I >have so far, but this would completely destroy the readability of my >sources. Is there a specific thing in C++ you can point me too? Another option for your inlining question is to use preprocessor macros. You should experiement to see which approach is fastest and best for you. But really I think you should just write clear clean code and profile it to work out where the bottle necks are. there will probably be a few places where most of the time is spent and you should spend your time optimising those bits. There are almost certainly platformance tweaks that are ARM specific. There may be a preferred general approach for coding dsp on ARM/iPhone for maximum performance.. perhaps someone else can suggest it. After a bit of googling found this: http://www.cs.virginia.edu/~jg9h/photos/tms320c54x_docs/downloaded/dsp-progrtechniques.pdf Good luck Ross. From alan.wolfe at gmail.com Wed Oct 27 11:14:42 2010 From: alan.wolfe at gmail.com (Alan Wolfe) Date: Wed, 27 Oct 2010 08:14:42 -0700 Subject: [music-dsp] C++ performance In-Reply-To: References: <4CC81431.404@pdp7.org> Message-ID: you may already know this, and this may be in MG's programming tips but one of the most common mistakes less experienced programmers make is premature optimization. That is, optimizing before there is a problem, or without understanding what exactly the problem is. Another mistake that less experienced programmers make is too much focus on micro optimizations such as changing multiplies to bit shifts and things like that, without first trying macro optimizations such as changes in the algorithms. Macro optimizations often win you far more than micro optimizations. Basically, write your program as best you can, then profile it to see where the slowdown happens. Address the slowdown and then run the program again. If it's still too slow, go back to the profiling step and repeat until your program is fast enough. On Wed, Oct 27, 2010 at 7:03 AM, Michael Gogins wrote: > You may be interested in my advice on programming, most of which is > based on experience with music programming: > > http://michael-gogins.com/?p=299 > > Regards, > Mike Gogins > > On Wed, Oct 27, 2010 at 7:59 AM, Thomas Strathmann wrote: >> On 10/27/10 13:16 , Andre Michelle wrote: >>>> >>>> Not sure exactly what you're asking. Simple inlined classes can get >>>> pretty lightweight, but it really depends what you do inside them. >>>> Again, if you can read assembly code, this can be output and it will >>>> tell you what you want to know about what is happening with your code. >>> >>> The idea is to tell the compiler, that he should embed everything from the >>> class for every instance I create in my implementation. This way I get rid >>> of scope changes. Maybe this is not a good idea at all. Obviously I cannot >>> read assembly nor do I have the tools to output them. Anything you can >>> recommend (best case for xCode) is much appreciated. >> >> Some generic advice first: >> >> 1. Get to know your compiler and library and write "common sense" code >> ? that the compiler knows how to deal with in an (near to) optimal way. >> 2. Use a profiler (gprof, Instruments.app, etc.) to identify those >> ? parts of the code that are performance critical and could be >> ? improved. >> 3. Don't optimize until you have concrete evidence that something >> ? should be optimized (i.e. don't play the "let's see what compiler >> ? switch I do not use already" game). >> 4. To reiterate: Don't think your cleverer than the people who wrote >> ? the compiler and the runtime and don't try to port idioms from >> ? other languages in the hope of making your code run faster. >> >> As for assembler: If you really care about performance there's no way around >> learning to read the compiler's output. This is the only valid way of >> removing doubt about whether the compiler actually does the optimization you >> had in mind. To look at assembler code (assuming you use gcc) use "gcc -S >> foo.c". It takes some getting used to, but it's well worth it. Sometimes >> you'll be able to just get the info you want by doing A-B comparisons of the >> generated assembler code. >> >> ? ? ? ?Thomas >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, source code archive, list archive, book reviews, dsp >> links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp >> > > > > -- > Michael Gogins > Irreducible Productions > http://www.michael-gogins.com > Michael dot Gogins at gmail dot com > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From rbj at audioimagination.com Wed Oct 27 11:34:06 2010 From: rbj at audioimagination.com (robert bristow-johnson) Date: Wed, 27 Oct 2010 11:34:06 -0400 Subject: [music-dsp] C++ performance In-Reply-To: <4CC81431.404@pdp7.org> References: <4CC81431.404@pdp7.org> Message-ID: On Oct 27, 2010, at 7:59 AM, Thomas Strathmann wrote: > Some generic advice first: > > 1. Get to know your compiler and library and write "common sense" code > that the compiler knows how to deal with in an (near to) optimal > way. this i agree with. > 4. To reiterate: Don't think your cleverer than the people who wrote > the compiler and the runtime and don't try to port idioms from > other languages in the hope of making your code run faster. i don't think i agree with this. here is an example (a simple one-pole LPF with noise shaping): // // transfer function: H(z) = b0/(1 - (a1+1)*z^(-1)) // // void myProject::LPF(LPFBlock* this_filter, long* input) { register long* output_ptr = &(this_filter->output[0]); register long b0 = this_filter->b0; // feedforward coefficient Q8.24 register long a1 = this_filter->a1; // feedback coefficient Q8.24 register long long y1 = this_filter->y1; // previous output Q16.48, roundoff noise state in lower 24 bits register long output_sample = (long)(y1>>24); // now is previous output sample, y[n-1] for (register int i=CHUNK_SIZE; i>0; i--) { y1 += (long long)b0 * (long long)(*input++); // (y[n-1] + b0*x[n]) * 2^24 y1 += (long long)a1 * (long long)output_sample; // (y[n-1] + b0*x[n] + a1*y[n-1]) * 2^24 output_sample = (long)(y1>>24); // this truncation has simple roundoff noise shaping *output_ptr++ = output_sample; } this_filter->y1 = y1; // save state, including roundoff error state } the use of register variables, the use of simple arithmetic lines with "+=" in the loop is there to make sure the compiler has no doubt what i want it to do. the fact that i have "i" count down to zero rather than up to CHUNK_SIZE is to prevent the compiler from loading CHUNK_SIZE and subtracting, it only needs to compare to zero. sometimes you *should* spell it out for the compiler. i only wish the promotion to (long long) was unnecessary. i wish that in C and C++, it was automatically understood that the type of the result of multiplying two N-bit numbers was a type with a 2N-bit number if a 2N- bit type is available. that is one flaw of C or C++. -- r b-j rbj at audioimagination.com "Imagination is more important than knowledge." From thomas at pdp7.org Wed Oct 27 13:52:14 2010 From: thomas at pdp7.org (Thomas Strathmann) Date: Wed, 27 Oct 2010 19:52:14 +0200 Subject: [music-dsp] C++ performance In-Reply-To: References: <4CC81431.404@pdp7.org> Message-ID: <4CC866CE.6020602@pdp7.org> On 10/27/10 17:34 , robert bristow-johnson wrote: >> 1. Get to know your compiler and library and write "common sense" code >> that the compiler knows how to deal with in an (near to) optimal way. > > this i agree with. > >> 4. To reiterate: Don't think your cleverer than the people who wrote >> the compiler and the runtime and don't try to port idioms from >> other languages in the hope of making your code run faster. > > i don't think i agree with this. > > here is an example (a simple one-pole LPF with noise shaping): > > // > // transfer function: H(z) = b0/(1 - (a1+1)*z^(-1)) > // > // > void myProject::LPF(LPFBlock* this_filter, long* input) > { > register long* output_ptr = &(this_filter->output[0]); > > register long b0 = this_filter->b0; // feedforward coefficient Q8.24 > register long a1 = this_filter->a1; // feedback coefficient Q8.24 > > register long long y1 = this_filter->y1; // previous output Q16.48, > roundoff noise state in lower 24 bits > > register long output_sample = (long)(y1>>24); // now is previous output > sample, y[n-1] > > for (register int i=CHUNK_SIZE; i>0; i--) > { > y1 += (long long)b0 * (long long)(*input++); // (y[n-1] + b0*x[n]) * 2^24 > y1 += (long long)a1 * (long long)output_sample; // (y[n-1] + b0*x[n] + > a1*y[n-1]) * 2^24 > output_sample = (long)(y1>>24); // this truncation has simple roundoff > noise shaping > *output_ptr++ = output_sample; > } > > this_filter->y1 = y1; // save state, including roundoff error state > } > > the use of register variables, the use of simple arithmetic lines with > "+=" in the loop is there to make sure the compiler has no doubt what i > want it to do. the fact that i have "i" count down to zero rather than > up to CHUNK_SIZE is to prevent the compiler from loading CHUNK_SIZE and > subtracting, it only needs to compare to zero. The register qualifier is just a hint. The compiler does not necessarily hold the variable in a CPU register. Likewise, the comparison need not be implemented using subtraction if your processor has more comparison instructions than just a test for zero. gcc 4.2.1 for Intel 32 bit loads either 0 (in your case) or CHUNK_SIZE-1 (in the other case) and does the appropriate comparison. So i both cases you get a load. Bottom line is: You will still have to look at the generated code and/or do profiling. No amount of trickery with qualifiers and restructuring your code will automatically change anything. But it does not hurt to give the compiler some advice. It's always free to ignore it and will often enough do so. > sometimes you *should* spell it out for the compiler. i only wish the > promotion to (long long) was unnecessary. i wish that in C and C++, it > was automatically understood that the type of the result of multiplying > two N-bit numbers was a type with a 2N-bit number if a 2N-bit type is > available. that is one flaw of C or C++. Spelling it out for the compiler is using idioms appropriate for your language, compiler, and runtime (point 1). But you can easily overdo it, especially if you just think that you know better than the compiler. Point 4 does not apply if you actually know how the compiler translates certain code sequences. It's dangerous to think that if compiler X for language Y in version Z and options O for target T produces such and such code then in another setting it must certainly also emit the same code. Thomas From rossb-lists at audiomulch.com Wed Oct 27 14:08:11 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Thu, 28 Oct 2010 05:08:11 +1100 Subject: [music-dsp] C++ performance References: <4CC81431.404@pdp7.org> Message-ID: <05f601cb7601$ec11de70$0201a8c0@rossmacbook> robert bristow-johnson wrote: > for (register int i=CHUNK_SIZE; i>0; i--) > { [snip] > *output_ptr++ = output_sample; > } When I looked at this I thought "that isn't spelling out anything" -- but really, it depends on how advanced your compiler is. For a simple compiler that trusts you, I agree. But I imagine for most modern mainstream compilers this isn't spelling out anything. If it thought it appropriate the compiler could easily rewrite your example as: long *end = output_ptr + CHUNK_SIZE; while( output_ptr != end ){ ... *output_ptr++ = output_sample; } or rewrite the latter as the former, or whatever other implementation is known to be fastest on the target, given available registers etc etc Ross. From jkroll at lavabit.com Wed Oct 27 14:14:34 2010 From: jkroll at lavabit.com (Johannes Kroll) Date: Wed, 27 Oct 2010 20:14:34 +0200 Subject: [music-dsp] C++ performance In-Reply-To: <4CC866CE.6020602@pdp7.org> References: <4CC81431.404@pdp7.org> <4CC866CE.6020602@pdp7.org> Message-ID: <20101027201434.16602118@arcadia> On Wed, 27 Oct 2010 19:52:14 +0200 Thomas Strathmann wrote: > The register qualifier is just a hint. The compiler does not necessarily > hold the variable in a CPU register. Likewise, the comparison need not > be implemented using subtraction if your processor has more comparison > instructions than just a test for zero. gcc 4.2.1 for Intel 32 bit loads > either 0 (in your case) or CHUNK_SIZE-1 (in the other case) and does the > appropriate comparison. So i both cases you get a load. Bottom line is: The point is, of course, that you have to load the top value for the comparison when counting up, but when counting down, you compare to zero, which the CPU can do with a dedicated instruction. So when you count down, you free up a register inside the loop, or you get one less memory access if the compiler stores the top value in memory. You don't have to do any profiling to know that. From rbj at audioimagination.com Wed Oct 27 14:21:39 2010 From: rbj at audioimagination.com (robert bristow-johnson) Date: Wed, 27 Oct 2010 14:21:39 -0400 Subject: [music-dsp] C++ performance In-Reply-To: <4CC866CE.6020602@pdp7.org> References: <4CC81431.404@pdp7.org> <4CC866CE.6020602@pdp7.org> Message-ID: <5762A8CE-AF7F-4027-84ED-5D64D4108459@audioimagination.com> On Oct 27, 2010, at 1:52 PM, Thomas Strathmann wrote: > > The register qualifier is just a hint. The compiler does not > necessarily hold the variable in a CPU register. Likewise, the > comparison need not be implemented using subtraction if your > processor has more comparison instructions than just a test for > zero. gcc 4.2.1 for Intel 32 bit loads either 0 (in your case) or > CHUNK_SIZE-1 (in the other case) and does the appropriate > comparison. So i both cases you get a load. Bottom line is: You will > still have to look at the generated code and/or do profiling. No > amount of trickery with qualifiers and restructuring your code will > automatically change anything. But it does not hurt to give the > compiler some advice. It's always free to ignore it and will often > enough do so. > >> sometimes you *should* spell it out for the compiler. i only wish the >> promotion to (long long) was unnecessary. i wish that in C and C++, >> it >> was automatically understood that the type of the result of >> multiplying >> two N-bit numbers was a type with a 2N-bit number if a 2N-bit type is >> available. that is one flaw of C or C++. > > Spelling it out for the compiler is using idioms appropriate for > your language, compiler, and runtime (point 1). But you can easily > overdo it, especially if you just think that you know better than > the compiler. Point 4 does not apply if you actually know how the > compiler translates certain code sequences. It's dangerous to think > that if compiler X for language Y in version Z and options O for > target T produces such and such code then in another setting it must > certainly also emit the same code. i still think that this code: y1 += (long long)b0 * (long long)(*input++); y1 += (long long)a1 * (long long)output_sample; output_sample = (long)(y1>>24); *output_ptr++ = output_sample; has a better chance of being compiled into the simplest machine code than *output_ptr++ = (long)( (y1 + (long long)a1*(y1>>24) + (long long)b0*(long long)(*input++) )>>24 ); On Oct 27, 2010, at 2:08 PM, Ross Bencina wrote: > robert bristow-johnson wrote: >> for (register int i=CHUNK_SIZE; i>0; i--) >> { > [snip] >> *output_ptr++ = output_sample; >> } > > When I looked at this I thought "that isn't spelling out anything" > -- but really, it depends on how advanced your compiler is. For a > simple compiler that trusts you, I agree. But I imagine for most > modern mainstream compilers this isn't spelling out anything. > > If it thought it appropriate the compiler could easily rewrite your > example as: > > long *end = output_ptr + CHUNK_SIZE; > while( output_ptr != end ){ > ... > *output_ptr++ = output_sample; > } > > or rewrite the latter as the former, or whatever other > implementation is known to be fastest on the target, given available > registers etc etc using output_ptr instead of "i" is fine, but it might not save a register (if "end" must be saved). and since end is compared or subtracted from a copy of output_ptr, i do not believe it saves an addition (compared to decrementing i). -- r b-j rbj at audioimagination.com "Imagination is more important than knowledge." -- r b-j rbj at audioimagination.com "Imagination is more important than knowledge." From michael.gogins at gmail.com Wed Oct 27 20:44:11 2010 From: michael.gogins at gmail.com (Michael Gogins) Date: Wed, 27 Oct 2010 20:44:11 -0400 Subject: [music-dsp] C++ performance In-Reply-To: <5762A8CE-AF7F-4027-84ED-5D64D4108459@audioimagination.com> References: <4CC81431.404@pdp7.org> <4CC866CE.6020602@pdp7.org> <5762A8CE-AF7F-4027-84ED-5D64D4108459@audioimagination.com> Message-ID: I did the experiment comparing std::vector::iterator versus double buffer [mysize] access versus pointer arithmetic access using both Microsoft VC++ 2005 and MingW 3.4.5 (I think those were the versions). There was no signficant difference at all in speed, and none that I could see (though I'm not an expert) in the generated assembler. Regards, Mike On Wed, Oct 27, 2010 at 2:21 PM, robert bristow-johnson wrote: > > On Oct 27, 2010, at 1:52 PM, Thomas Strathmann wrote: > >> >> The register qualifier is just a hint. The compiler does not necessarily >> hold the variable in a CPU register. Likewise, the comparison need not be >> implemented using subtraction if your processor has more comparison >> instructions than just a test for zero. gcc 4.2.1 for Intel 32 bit loads >> either 0 (in your case) or CHUNK_SIZE-1 (in the other case) and does the >> appropriate comparison. So i both cases you get a load. Bottom line is: You >> will still have to look at the generated code and/or do profiling. No amount >> of trickery with qualifiers and restructuring your code will automatically >> change anything. But it does not hurt to give the compiler some advice. It's >> always free to ignore it and will often enough do so. >> >>> sometimes you *should* spell it out for the compiler. i only wish the >>> promotion to (long long) was unnecessary. i wish that in C and C++, it >>> was automatically understood that the type of the result of multiplying >>> two N-bit numbers was a type with a 2N-bit number if a 2N-bit type is >>> available. that is one flaw of C or C++. >> >> Spelling it out for the compiler is using idioms appropriate for your >> language, compiler, and runtime (point 1). But you can easily overdo it, >> especially if you just think that you know better than the compiler. Point 4 >> does not apply if you actually know how the compiler translates certain code >> sequences. It's dangerous to think that if compiler X for language Y in >> version Z and options O for target T produces such and such code then in >> another setting it must certainly also emit the same code. > > > i still think that this code: > > ? ? ? y1 += (long long)b0 * (long long)(*input++); > ? ? ? y1 += (long long)a1 * (long long)output_sample; > ? ? ? output_sample = (long)(y1>>24); > ? ? ? *output_ptr++ = output_sample; > > has a better chance of being compiled into the simplest machine code than > > ? ? ?*output_ptr++ = (long)( (y1 + (long long)a1*(y1>>24) + (long > long)b0*(long long)(*input++) ?)>>24 ); > > > > On Oct 27, 2010, at 2:08 PM, Ross Bencina wrote: > >> robert bristow-johnson wrote: >>> >>> ? for (register int i=CHUNK_SIZE; i>0; i--) >>> ? ? ? { >> >> [snip] >>> >>> ? ? ? *output_ptr++ = output_sample; >>> ? ? ? } >> >> When I looked at this I thought "that isn't spelling out anything" -- but >> really, it depends on how advanced your compiler is. For a simple compiler >> that trusts you, I agree. But I imagine for most modern mainstream compilers >> this isn't spelling out anything. >> >> If it thought it appropriate the compiler could easily rewrite your >> example as: >> >> long *end = output_ptr + CHUNK_SIZE; >> while( output_ptr != end ){ >> ... >> *output_ptr++ = output_sample; >> } >> >> or rewrite the latter as the former, or whatever other implementation is >> known to be fastest on the target, given available registers etc etc > > using output_ptr instead of "i" is fine, but it might not save a register > (if "end" must be saved). ?and since end is compared or subtracted from a > copy of output_ptr, i do not believe it saves an addition (compared to > decrementing i). > > > -- > > r b-j ? ? ? ? ? ? ? ? ?rbj at audioimagination.com > > "Imagination is more important than knowledge." > > > > > > > -- > > r b-j ? ? ? ? ? ? ? ? ?rbj at 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 > -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com From alan.wolfe at gmail.com Wed Oct 27 21:03:32 2010 From: alan.wolfe at gmail.com (Alan Wolfe) Date: Wed, 27 Oct 2010 18:03:32 -0700 Subject: [music-dsp] C++ performance In-Reply-To: References: <4CC81431.404@pdp7.org> <4CC866CE.6020602@pdp7.org> <5762A8CE-AF7F-4027-84ED-5D64D4108459@audioimagination.com> Message-ID: Feel free to ignore this message but most benchmarks only benchmark how something preforms in benchmarks (not realistic scenarios) I'm not saying that vector and direct array access may necessarily have very different performance, but if you are going to benchmark you should make sure and benchmark an actual realistic situation instead of a tight loop. If you already know this, or disagree, feel free to ignore :P On Wed, Oct 27, 2010 at 5:44 PM, Michael Gogins wrote: > I did the experiment comparing std::vector::iterator versus > double buffer [mysize] access versus pointer arithmetic access using > both Microsoft VC++ 2005 and MingW 3.4.5 (I think those were the > versions). There was no signficant difference at all in speed, and > none that I could see (though I'm not an expert) in the generated > assembler. > > Regards, > Mike > On Wed, Oct 27, 2010 at 2:21 PM, robert bristow-johnson > wrote: >> >> On Oct 27, 2010, at 1:52 PM, Thomas Strathmann wrote: >> >>> >>> The register qualifier is just a hint. The compiler does not necessarily >>> hold the variable in a CPU register. Likewise, the comparison need not be >>> implemented using subtraction if your processor has more comparison >>> instructions than just a test for zero. gcc 4.2.1 for Intel 32 bit loads >>> either 0 (in your case) or CHUNK_SIZE-1 (in the other case) and does the >>> appropriate comparison. So i both cases you get a load. Bottom line is: You >>> will still have to look at the generated code and/or do profiling. No amount >>> of trickery with qualifiers and restructuring your code will automatically >>> change anything. But it does not hurt to give the compiler some advice. It's >>> always free to ignore it and will often enough do so. >>> >>>> sometimes you *should* spell it out for the compiler. i only wish the >>>> promotion to (long long) was unnecessary. i wish that in C and C++, it >>>> was automatically understood that the type of the result of multiplying >>>> two N-bit numbers was a type with a 2N-bit number if a 2N-bit type is >>>> available. that is one flaw of C or C++. >>> >>> Spelling it out for the compiler is using idioms appropriate for your >>> language, compiler, and runtime (point 1). But you can easily overdo it, >>> especially if you just think that you know better than the compiler. Point 4 >>> does not apply if you actually know how the compiler translates certain code >>> sequences. It's dangerous to think that if compiler X for language Y in >>> version Z and options O for target T produces such and such code then in >>> another setting it must certainly also emit the same code. >> >> >> i still think that this code: >> >> ? ? ? y1 += (long long)b0 * (long long)(*input++); >> ? ? ? y1 += (long long)a1 * (long long)output_sample; >> ? ? ? output_sample = (long)(y1>>24); >> ? ? ? *output_ptr++ = output_sample; >> >> has a better chance of being compiled into the simplest machine code than >> >> ? ? ?*output_ptr++ = (long)( (y1 + (long long)a1*(y1>>24) + (long >> long)b0*(long long)(*input++) ?)>>24 ); >> >> >> >> On Oct 27, 2010, at 2:08 PM, Ross Bencina wrote: >> >>> robert bristow-johnson wrote: >>>> >>>> ? for (register int i=CHUNK_SIZE; i>0; i--) >>>> ? ? ? { >>> >>> [snip] >>>> >>>> ? ? ? *output_ptr++ = output_sample; >>>> ? ? ? } >>> >>> When I looked at this I thought "that isn't spelling out anything" -- but >>> really, it depends on how advanced your compiler is. For a simple compiler >>> that trusts you, I agree. But I imagine for most modern mainstream compilers >>> this isn't spelling out anything. >>> >>> If it thought it appropriate the compiler could easily rewrite your >>> example as: >>> >>> long *end = output_ptr + CHUNK_SIZE; >>> while( output_ptr != end ){ >>> ... >>> *output_ptr++ = output_sample; >>> } >>> >>> or rewrite the latter as the former, or whatever other implementation is >>> known to be fastest on the target, given available registers etc etc >> >> using output_ptr instead of "i" is fine, but it might not save a register >> (if "end" must be saved). ?and since end is compared or subtracted from a >> copy of output_ptr, i do not believe it saves an addition (compared to >> decrementing i). >> >> >> -- >> >> r b-j ? ? ? ? ? ? ? ? ?rbj at audioimagination.com >> >> "Imagination is more important than knowledge." >> >> >> >> >> >> >> -- >> >> r b-j ? ? ? ? ? ? ? ? ?rbj at 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 >> > > > > -- > Michael Gogins > Irreducible Productions > http://www.michael-gogins.com > Michael dot Gogins at gmail dot com > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From kevin.c.dixon at gmail.com Wed Oct 27 22:00:44 2010 From: kevin.c.dixon at gmail.com (Kevin Dixon) Date: Wed, 27 Oct 2010 19:00:44 -0700 Subject: [music-dsp] C++ performance In-Reply-To: References: <4CC81431.404@pdp7.org> <4CC866CE.6020602@pdp7.org> <5762A8CE-AF7F-4027-84ED-5D64D4108459@audioimagination.com> Message-ID: On Wed, Oct 27, 2010 at 5:44 PM, Michael Gogins wrote: > I did the experiment comparing std::vector::iterator versus > double buffer [mysize] access versus pointer arithmetic access using > both Microsoft VC++ 2005 and MingW 3.4.5 (I think those were the > versions). There was no signficant difference at all in speed, and > none that I could see (though I'm not an expert) in the generated > assembler. > > Regards, > Mike For the record, this discussion started relating to iOS, implying that the target architecture is ARM. How do you guys think that a compiler for ARM might behave differently than our run of the mill x86 familiars? I think discussing that aspect might give more value to the OP -Kevin From rossb-lists at audiomulch.com Thu Oct 28 01:38:58 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Thu, 28 Oct 2010 16:38:58 +1100 Subject: [music-dsp] C++ performance References: <4CC81431.404@pdp7.org><4CC866CE.6020602@pdp7.org><5762A8CE-AF7F-4027-84ED-5D64D4108459@audioimagination.com> Message-ID: <088401cb7662$6bc5aa60$0201a8c0@rossmacbook> Kevin wrote: > For the record, this discussion started relating to iOS, implying that > the target architecture is ARM. How do you guys think that a compiler > for ARM might behave differently than our run of the mill x86 > familiars? I think discussing that aspect might give more value to the > OP As far as I know, the iOS dev kit/XCode uses a recent version of gcc, according to this http://en.wikipedia.org/wiki/Xcode you have the option of gcc 4.0.1, 4.2.1 and gcc LLVM 4.2.1. I have been hearing good things about gcc LLVM C++ code generation lately (although I havn't had time to test it myself). The benchmarks I've seen suggest that gcc C++ code generation is within 10% of the performance of the best compilers available on IA32 (havn't seen any recent ones, but google "C++ compiler performance benchmarks"). Although I can't say for certain, I expect the same to be true on gcc/ARM. So, for iOS development with gcc I think there is likely to be strong similarities with the desktop. If you were doing embedded ARM development with a different compiler (not sure why you wouln't use gcc unless you had a better one) it might be a different story. One thing that no one seems to have mentioned is performance of floating point arithmetic on iOS devices. I don't think they have a dedicated FPU (please correct me if I'm wrong) -- certainly I've got better performance out of the integer version of the CELT audio codec library than the floating point version. I think they have the NEON floating point SIMD core though, see for example: http://blogs.arm.com/software-enablement/coding-for-neon-part-1-load-and-stores/ http://blogs.arm.com/software-enablement/coding-for-neon-part-2-dealing-with-leftovers/ http://blogs.arm.com/software-enablement/coding-for-neon-part-3-matrix-multiplication/ I'm not sure how gcc generates code for scalar floating point operations for iOS devices, but I'd be interested to know... Either enabling auto-vectorisation or hand coding routines in NEON assembler might be a big win. Ross. From michael.gogins at gmail.com Thu Oct 28 08:26:46 2010 From: michael.gogins at gmail.com (Michael Gogins) Date: Thu, 28 Oct 2010 08:26:46 -0400 Subject: [music-dsp] C++ performance In-Reply-To: References: <4CC81431.404@pdp7.org> <4CC866CE.6020602@pdp7.org> <5762A8CE-AF7F-4027-84ED-5D64D4108459@audioimagination.com> Message-ID: I tried to make my tests reasonably realistic, as I am aware of the issues you raise. My loops performed arithmetic on randomly generated numbers in the arrays. I also did examine the generated assembler. The designers and implementers of the Standard C++ Library state that a primary design objective for containers and algorithms is to equal, for all practical purposes, the performance of hand-coded assembler. My experience and indeed my tests lead me to conclude that in at least some cases, this objective has indeed been met. That reinforces the advice, "write clear code, then profile, then analyze hot spots for re-design and/or optimization." I cannot over-emphasize the importance of clarity and simplicity in programming. Clever tricks will obscure the clarity of the algorithms, if not always for the author of the code, then certainly for its maintainers. Regards, Mike On Wed, Oct 27, 2010 at 9:03 PM, Alan Wolfe wrote: > Feel free to ignore this message but most benchmarks only benchmark > how something preforms in benchmarks (not realistic scenarios) > > I'm not saying that vector and direct array access may necessarily > have very different performance, but if you are going to benchmark you > should make sure and benchmark an actual realistic situation instead > of a tight loop. > > If you already know this, or disagree, feel free to ignore :P > > On Wed, Oct 27, 2010 at 5:44 PM, Michael Gogins > wrote: >> I did the experiment comparing std::vector::iterator versus >> double buffer [mysize] access versus pointer arithmetic access using >> both Microsoft VC++ 2005 and MingW 3.4.5 (I think those were the >> versions). There was no signficant difference at all in speed, and >> none that I could see (though I'm not an expert) in the generated >> assembler. >> >> Regards, >> Mike >> On Wed, Oct 27, 2010 at 2:21 PM, robert bristow-johnson >> wrote: >>> >>> On Oct 27, 2010, at 1:52 PM, Thomas Strathmann wrote: >>> >>>> >>>> The register qualifier is just a hint. The compiler does not necessarily >>>> hold the variable in a CPU register. Likewise, the comparison need not be >>>> implemented using subtraction if your processor has more comparison >>>> instructions than just a test for zero. gcc 4.2.1 for Intel 32 bit loads >>>> either 0 (in your case) or CHUNK_SIZE-1 (in the other case) and does the >>>> appropriate comparison. So i both cases you get a load. Bottom line is: You >>>> will still have to look at the generated code and/or do profiling. No amount >>>> of trickery with qualifiers and restructuring your code will automatically >>>> change anything. But it does not hurt to give the compiler some advice. It's >>>> always free to ignore it and will often enough do so. >>>> >>>>> sometimes you *should* spell it out for the compiler. i only wish the >>>>> promotion to (long long) was unnecessary. i wish that in C and C++, it >>>>> was automatically understood that the type of the result of multiplying >>>>> two N-bit numbers was a type with a 2N-bit number if a 2N-bit type is >>>>> available. that is one flaw of C or C++. >>>> >>>> Spelling it out for the compiler is using idioms appropriate for your >>>> language, compiler, and runtime (point 1). But you can easily overdo it, >>>> especially if you just think that you know better than the compiler. Point 4 >>>> does not apply if you actually know how the compiler translates certain code >>>> sequences. It's dangerous to think that if compiler X for language Y in >>>> version Z and options O for target T produces such and such code then in >>>> another setting it must certainly also emit the same code. >>> >>> >>> i still think that this code: >>> >>> ? ? ? y1 += (long long)b0 * (long long)(*input++); >>> ? ? ? y1 += (long long)a1 * (long long)output_sample; >>> ? ? ? output_sample = (long)(y1>>24); >>> ? ? ? *output_ptr++ = output_sample; >>> >>> has a better chance of being compiled into the simplest machine code than >>> >>> ? ? ?*output_ptr++ = (long)( (y1 + (long long)a1*(y1>>24) + (long >>> long)b0*(long long)(*input++) ?)>>24 ); >>> >>> >>> >>> On Oct 27, 2010, at 2:08 PM, Ross Bencina wrote: >>> >>>> robert bristow-johnson wrote: >>>>> >>>>> ? for (register int i=CHUNK_SIZE; i>0; i--) >>>>> ? ? ? { >>>> >>>> [snip] >>>>> >>>>> ? ? ? *output_ptr++ = output_sample; >>>>> ? ? ? } >>>> >>>> When I looked at this I thought "that isn't spelling out anything" -- but >>>> really, it depends on how advanced your compiler is. For a simple compiler >>>> that trusts you, I agree. But I imagine for most modern mainstream compilers >>>> this isn't spelling out anything. >>>> >>>> If it thought it appropriate the compiler could easily rewrite your >>>> example as: >>>> >>>> long *end = output_ptr + CHUNK_SIZE; >>>> while( output_ptr != end ){ >>>> ... >>>> *output_ptr++ = output_sample; >>>> } >>>> >>>> or rewrite the latter as the former, or whatever other implementation is >>>> known to be fastest on the target, given available registers etc etc >>> >>> using output_ptr instead of "i" is fine, but it might not save a register >>> (if "end" must be saved). ?and since end is compared or subtracted from a >>> copy of output_ptr, i do not believe it saves an addition (compared to >>> decrementing i). >>> >>> >>> -- >>> >>> r b-j ? ? ? ? ? ? ? ? ?rbj at audioimagination.com >>> >>> "Imagination is more important than knowledge." >>> >>> >>> >>> >>> >>> >>> -- >>> >>> r b-j ? ? ? ? ? ? ? ? ?rbj at 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 >>> >> >> >> >> -- >> Michael Gogins >> Irreducible Productions >> http://www.michael-gogins.com >> Michael dot Gogins at gmail dot com >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, source code archive, list archive, book reviews, dsp links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp >> > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com From didid at skynet.be Thu Oct 28 08:36:19 2010 From: didid at skynet.be (Didier Dambrin) Date: Thu, 28 Oct 2010 14:36:19 +0200 Subject: [music-dsp] C++ performance In-Reply-To: References: <4CC81431.404@pdp7.org><4CC866CE.6020602@pdp7.org><5762A8CE-AF7F-4027-84ED-5D64D4108459@audioimagination.com> Message-ID: While I don't know C++ and I have to write asm all the time (because Delphi's compiler hasn't evolved since the 386 came out), I think that what helps the most is to process in layers. That is, don't write big complex loops processing 1 sample at a time, but process a good amount of samples in layers. That way the plain code will have more chances to be well optimized, and you will be able to use block-processing libraries. Besides, coding in layer is also clearer. (this of course doesn't always work, not suitable for processing in which feedback occurs) But I'm not a fan of "optimize later", you could end up with something that can't be made fast enough & it won't be any usable. To know where you can go, you need to know the speed of your building blocks. ----- Original Message ----- From: "Michael Gogins" To: "A discussion list for music-related DSP" Sent: Thursday, October 28, 2010 2:26 PM Subject: Re: [music-dsp] C++ performance I tried to make my tests reasonably realistic, as I am aware of the issues you raise. My loops performed arithmetic on randomly generated numbers in the arrays. I also did examine the generated assembler. The designers and implementers of the Standard C++ Library state that a primary design objective for containers and algorithms is to equal, for all practical purposes, the performance of hand-coded assembler. My experience and indeed my tests lead me to conclude that in at least some cases, this objective has indeed been met. That reinforces the advice, "write clear code, then profile, then analyze hot spots for re-design and/or optimization." I cannot over-emphasize the importance of clarity and simplicity in programming. Clever tricks will obscure the clarity of the algorithms, if not always for the author of the code, then certainly for its maintainers. Regards, Mike On Wed, Oct 27, 2010 at 9:03 PM, Alan Wolfe wrote: > Feel free to ignore this message but most benchmarks only benchmark > how something preforms in benchmarks (not realistic scenarios) > > I'm not saying that vector and direct array access may necessarily > have very different performance, but if you are going to benchmark you > should make sure and benchmark an actual realistic situation instead > of a tight loop. > > If you already know this, or disagree, feel free to ignore :P > > On Wed, Oct 27, 2010 at 5:44 PM, Michael Gogins > wrote: >> I did the experiment comparing std::vector::iterator versus >> double buffer [mysize] access versus pointer arithmetic access using >> both Microsoft VC++ 2005 and MingW 3.4.5 (I think those were the >> versions). There was no signficant difference at all in speed, and >> none that I could see (though I'm not an expert) in the generated >> assembler. >> >> Regards, >> Mike >> On Wed, Oct 27, 2010 at 2:21 PM, robert bristow-johnson >> wrote: >>> >>> On Oct 27, 2010, at 1:52 PM, Thomas Strathmann wrote: >>> >>>> >>>> The register qualifier is just a hint. The compiler does not >>>> necessarily >>>> hold the variable in a CPU register. Likewise, the comparison need not >>>> be >>>> implemented using subtraction if your processor has more comparison >>>> instructions than just a test for zero. gcc 4.2.1 for Intel 32 bit >>>> loads >>>> either 0 (in your case) or CHUNK_SIZE-1 (in the other case) and does >>>> the >>>> appropriate comparison. So i both cases you get a load. Bottom line is: >>>> You >>>> will still have to look at the generated code and/or do profiling. No >>>> amount >>>> of trickery with qualifiers and restructuring your code will >>>> automatically >>>> change anything. But it does not hurt to give the compiler some advice. >>>> It's >>>> always free to ignore it and will often enough do so. >>>> >>>>> sometimes you *should* spell it out for the compiler. i only wish the >>>>> promotion to (long long) was unnecessary. i wish that in C and C++, it >>>>> was automatically understood that the type of the result of >>>>> multiplying >>>>> two N-bit numbers was a type with a 2N-bit number if a 2N-bit type is >>>>> available. that is one flaw of C or C++. >>>> >>>> Spelling it out for the compiler is using idioms appropriate for your >>>> language, compiler, and runtime (point 1). But you can easily overdo >>>> it, >>>> especially if you just think that you know better than the compiler. >>>> Point 4 >>>> does not apply if you actually know how the compiler translates certain >>>> code >>>> sequences. It's dangerous to think that if compiler X for language Y in >>>> version Z and options O for target T produces such and such code then >>>> in >>>> another setting it must certainly also emit the same code. >>> >>> >>> i still think that this code: >>> >>> y1 += (long long)b0 * (long long)(*input++); >>> y1 += (long long)a1 * (long long)output_sample; >>> output_sample = (long)(y1>>24); >>> *output_ptr++ = output_sample; >>> >>> has a better chance of being compiled into the simplest machine code >>> than >>> >>> *output_ptr++ = (long)( (y1 + (long long)a1*(y1>>24) + (long >>> long)b0*(long long)(*input++) )>>24 ); >>> >>> >>> >>> On Oct 27, 2010, at 2:08 PM, Ross Bencina wrote: >>> >>>> robert bristow-johnson wrote: >>>>> >>>>> for (register int i=CHUNK_SIZE; i>0; i--) >>>>> { >>>> >>>> [snip] >>>>> >>>>> *output_ptr++ = output_sample; >>>>> } >>>> >>>> When I looked at this I thought "that isn't spelling out anything" -- >>>> but >>>> really, it depends on how advanced your compiler is. For a simple >>>> compiler >>>> that trusts you, I agree. But I imagine for most modern mainstream >>>> compilers >>>> this isn't spelling out anything. >>>> >>>> If it thought it appropriate the compiler could easily rewrite your >>>> example as: >>>> >>>> long *end = output_ptr + CHUNK_SIZE; >>>> while( output_ptr != end ){ >>>> ... >>>> *output_ptr++ = output_sample; >>>> } >>>> >>>> or rewrite the latter as the former, or whatever other implementation >>>> is >>>> known to be fastest on the target, given available registers etc etc >>> >>> using output_ptr instead of "i" is fine, but it might not save a >>> register >>> (if "end" must be saved). and since end is compared or subtracted from a >>> copy of output_ptr, i do not believe it saves an addition (compared to >>> decrementing i). >>> >>> >>> -- >>> >>> r b-j rbj at audioimagination.com >>> >>> "Imagination is more important than knowledge." >>> >>> >>> >>> >>> >>> >>> -- >>> >>> r b-j rbj at 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 >>> >> >> >> >> -- >> Michael Gogins >> Irreducible Productions >> http://www.michael-gogins.com >> Michael dot Gogins at gmail dot com >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, source code archive, list archive, book reviews, >> dsp links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp >> > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.864 / Virus Database: 271.1.1/3223 - Release Date: 10/27/10 21:12:00 From jkroll at lavabit.com Thu Oct 28 09:21:52 2010 From: jkroll at lavabit.com (Johannes Kroll) Date: Thu, 28 Oct 2010 15:21:52 +0200 Subject: [music-dsp] C++ performance In-Reply-To: References: <4CC81431.404@pdp7.org> <4CC866CE.6020602@pdp7.org> <5762A8CE-AF7F-4027-84ED-5D64D4108459@audioimagination.com> Message-ID: <20101028152152.20ccbe45@arcadia> On Thu, 28 Oct 2010 08:26:46 -0400 Michael Gogins wrote: > I tried to make my tests reasonably realistic, as I am aware of the > issues you raise. My loops performed arithmetic on randomly generated > numbers in the arrays. > > I also did examine the generated assembler. > > The designers and implementers of the Standard C++ Library state that > a primary design objective for containers and algorithms is to equal, > for all practical purposes, the performance of hand-coded assembler. > My experience and indeed my tests lead me to conclude that in at least > some cases, this objective has indeed been met. I came to the same conclusion when comparing vector to a C array with GCC -O2. The assembly code is roughly the same, which is not surprising because vector essentially is an array. The STL vector is implemented and inlined in such a way that iterator access essentially boils down to a simple array access. > That reinforces the advice, "write clear code, then profile, then > analyze hot spots for re-design and/or optimization." > > I cannot over-emphasize the importance of clarity and simplicity in > programming. Clever tricks will obscure the clarity of the algorithms, > if not always for the author of the code, then certainly for its > maintainers. It does not follow from a simple access speed comparison that one should not try to optimize code. From mcbinc at panix.com Thu Oct 28 09:44:16 2010 From: mcbinc at panix.com (m brandenberg) Date: Thu, 28 Oct 2010 09:44:16 -0400 (EDT) Subject: [music-dsp] C++ performance In-Reply-To: References: <4CC81431.404@pdp7.org> <4CC866CE.6020602@pdp7.org> <5762A8CE-AF7F-4027-84ED-5D64D4108459@audioimagination.com> Message-ID: On Thu, 28 Oct 2010, Michael Gogins wrote: > The designers and implementers of the Standard C++ Library state that > a primary design objective for containers and algorithms is to equal, > for all practical purposes, the performance of hand-coded assembler. > My experience and indeed my tests lead me to conclude that in at least > some cases, this objective has indeed been met. Well, it's best to keep statements of intent separate from marks of achievement. The problem with that C vs C++ test is that it actually hits a special case in the STL: std::vector<>. The requirements on this template effectively dictate that its iterators will be implemented as C-style pointers wrapped up with type information and inlined code. The resulting usage becomes equivalent to pointer-based, C-style array loops. Start using an STL container whose values are stored in an aggregating node and you will see performance differences. -- Monty Brandenberg From rossb-lists at audiomulch.com Thu Oct 28 10:00:02 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Fri, 29 Oct 2010 01:00:02 +1100 Subject: [music-dsp] C++ performance References: <4CC81431.404@pdp7.org><4CC866CE.6020602@pdp7.org><5762A8CE-AF7F-4027-84ED-5D64D4108459@audioimagination.com> <20101028152152.20ccbe45@arcadia> Message-ID: <0a6401cb76a8$6bed7ae0$0201a8c0@rossmacbook> I happened to come accross this the other day: http://www.bluebytesoftware.com/blog/2010/09/06/ThePrematureOptimizationIsEvilMyth.aspx I think how you write your dsp code depends on a whole bunch of stuff... sometimes it's more important to be maintainable than fast, sometimes the other way. But there are plenty of ways to write slow maintainable code that should be avoided (using division vs. multiplying by cached reciprocals comes to mind as one example). R. From contact at quikquak.com Thu Oct 28 10:36:02 2010 From: contact at quikquak.com (Dave Hoskins) Date: Thu, 28 Oct 2010 15:36:02 +0100 Subject: [music-dsp] C++ performance References: <4CC81431.404@pdp7.org><4CC866CE.6020602@pdp7.org><5762A8CE-AF7F-4027-84ED-5D64D4108459@audioimagination.com><20101028152152.20ccbe45@arcadia> <0a6401cb76a8$6bed7ae0$0201a8c0@rossmacbook> Message-ID: <29DF8C4C791F4EE98ABDA1011F7BDCA3@DaveUpstairs> ----- Original Message ----- From: "Ross Bencina" To: "A discussion list for music-related DSP" Sent: Thursday, October 28, 2010 3:00 PM Subject: Re: [music-dsp] C++ performance >I happened to come accross this the other day: > http://www.bluebytesoftware.com/blog/2010/09/06/ThePrematureOptimizationIsEvilMyth.aspx > > I think how you write your dsp code depends on a whole bunch of stuff... > sometimes it's more important to be maintainable than fast, sometimes the > other way. > > But there are plenty of ways to write slow maintainable code that should > be avoided (using division vs. multiplying by cached reciprocals comes to > mind as one example). > > R. Yep. Although I'd like to think that coding efficiently is a cyclic thing - you create it, then you re-write it with the knowledge of the thing you've created. I wouldn't go as far as say it's an 'organic' process, but it often boils down to the phrase "Use less code" as the winning optimisation. Unfortunately programmers don't like going over old code, and besides there's those dead-lines to consider... I've found memory access in delay loops (for a reverb) works far quicker if I looped on an 'if' statement, rather than do a binary wrap like ' n &= 8191' Even for quite small delays, where I didn't expect memory to be a issue. But that's not specically for C++ of course. From earlevel at earlevel.com Thu Oct 28 15:42:54 2010 From: earlevel at earlevel.com (Nigel Redmon) Date: Thu, 28 Oct 2010 12:42:54 -0700 Subject: [music-dsp] C++ performance In-Reply-To: References: <4CC81431.404@pdp7.org> <4CC866CE.6020602@pdp7.org> <5762A8CE-AF7F-4027-84ED-5D64D4108459@audioimagination.com> Message-ID: <6AB82B91-D92C-4612-8BF2-52197A031762@earlevel.com> In general, the language is fairly well suited to conversion to machine code, but there are some limitations to the language that make things awkward. Plenty has been said here, but I see people saying they aren't that familiar with assembly and machine level, so I'll comment specifically (and briefly) on that--maybe it will be helpful to give an idea of the challenges in compiling a high-level language to me the equivalent of a routine written in assembly language: Most CPUs set flag, automatically, when loading an accumulator or testing memory--flag if zero, and flag the sign. You can, for instance, load a value, then branch to one place if it's negative, another if it's zero, and fall thru if positive, without retest. In C/C++, you'd grab the value, test for negative, handle it if so, test for zero, handle it if so, then fall through to handle the positive case: if (val < 0) { // process negative val } else if (val == 0) { // process zero val } else { // process positive val } I know many people look at this type of construct, then look at the generated code, and say--"the compiler did a perfect optimization". But that's usually only true in that it translated the C code perfectly. Someone writing in assembly language would have done it a different way--getting the two comparison with zero for free. But in general it's not worth worrying about things like this. Optimize your code where it does the most good--you can usually do it in the high-level language (except where you need to code around crazy legacy stuff like float-to-int assignment vs Microsoft/Intel/8087-sim, where you pay an insane price for rounding). On Oct 28, 2010, at 5:26 AM, Michael Gogins wrote: > The designers and implementers of the Standard C++ Library state that > a primary design objective for containers and algorithms is to equal, > for all practical purposes, the performance of hand-coded assembler. > My experience and indeed my tests lead me to conclude that in at least > some cases, this objective has indeed been met. From theover at tiscali.nl Thu Oct 28 19:51:01 2010 From: theover at tiscali.nl (Theo Verelst) Date: Fri, 29 Oct 2010 01:51:01 +0200 Subject: [music-dsp] C++ performance Message-ID: <1288309861.23134.15.camel@localhost.localdomain> I can't help thinking that it might be more advantageous to organize C code properly, possibly even using case tools, and to use good ol' Unix programming to get out of the not-so-terribly-powerful additions which C ++ gives, with no good basis for parallel programming. Luckily C++ can be mixed with C usually easily (I think the famous enough Gnu compiler chain can link the both together, too), I'd think the old rule of the thumb was that C gets about 70% of the speed of assembly, and I see no reason to believe that's better for C++ or the (older) Objective C, maybe there are object hierarchies "libraries"/"classes" which instantiate handily into single-processor SSE2 optimized code fragments, which is fine, but less insightful. I'm glad C is still a major language and that for instance Risc 1000 and (Nvidia) Cuda processors and of course most big DSPs can be programmed in it. I don't think I really miss an OO language much for that (Which I professionally used at university for hierarchical graphics, which was handy). I've found myself searching for cheap Fermi cards to do some heavy sound processing in double precision, anyone working on that ? Theo Verelst http://www.theover.org/Cuda From michael.gogins at gmail.com Thu Oct 28 20:21:09 2010 From: michael.gogins at gmail.com (Michael Gogins) Date: Thu, 28 Oct 2010 20:21:09 -0400 Subject: [music-dsp] C++ performance In-Reply-To: <1288309861.23134.15.camel@localhost.localdomain> References: <1288309861.23134.15.camel@localhost.localdomain> Message-ID: I think your take on C++ is rather skewed, First, consider what languages actually are used to write critical software. Avionics, scientific data processing, performance-critical consumer software, are mostly (and increasingly) written in C++ not C. C++ and C both have, in all current main implementations, OpenMP for parallel processing. In addition, C++ now has futures, a built-in facility for parallel processing. That puts C++ ahead of C. The additions C++ gives are much more powerful than you seem to think. It is the template system that gives the real power, not classes. One can write sophisticated algorithms such as graph traversal, multimaps, and so on in a type-safe manner, easy to write and read, that will perform, if one is careful, as fast as C or hand-coded assembler. This is hardly minor. It cuts down drastically on bugs, too. Though not so powerful as templates, classes afford a vital means of organizing large-scale software systems that is possible to emulate in C, but this always seems clumsy in comparison. Then of course functional programming features are finding their way into C++, including lambas and closures. Regards, Mike On Thu, Oct 28, 2010 at 7:51 PM, Theo Verelst wrote: > I can't help thinking that it might be more advantageous to organize C > code properly, possibly even using case tools, and to use good ol' Unix > programming to get out of the not-so-terribly-powerful additions which C > ++ gives, with no good basis for parallel programming. Luckily C++ can > be mixed with C usually easily (I think the famous enough Gnu compiler > chain can link the both together, too), I'd think the old rule of the > thumb was that C gets about 70% of the speed of assembly, and I see no > reason to believe that's better for C++ or the (older) Objective C, > maybe there are object hierarchies "libraries"/"classes" which > instantiate handily into single-processor SSE2 optimized code fragments, > which is fine, but less insightful. > > I'm glad C is still a major language and that for instance Risc 1000 and > (Nvidia) Cuda processors and of course most big DSPs can be programmed > in it. I don't think I really miss an OO language much for that (Which I > professionally used at university for hierarchical graphics, which was > handy). > > I've found myself searching for cheap Fermi cards to do some heavy sound > processing in double precision, anyone working on that ? > > ?Theo Verelst > ?http://www.theover.org/Cuda > > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com From contact at quikquak.com Thu Oct 28 22:37:33 2010 From: contact at quikquak.com (Dave Hoskins) Date: Fri, 29 Oct 2010 03:37:33 +0100 Subject: [music-dsp] C++ performance References: <1288309861.23134.15.camel@localhost.localdomain> Message-ID: <396D6D9246714DA3BF06365C022FF574@DaveUpstairs> But this stuff just makes programmers lazy!: http://www.google.co.uk/search?sourceid=navclient&hl=en-GB&ie=UTF-8&rlz=1T4GGLL_enGB338GB338&q=arm+new+procesor+2.5 ----- Original Message ----- From: "Theo Verelst" To: Sent: Friday, October 29, 2010 12:51 AM Subject: Re: [music-dsp] C++ performance >I can't help thinking that it might be more advantageous to organize C > code properly, possibly even using case tools, and to use good ol' Unix > programming to get out of the not-so-terribly-powerful additions which C > ++ gives, with no good basis for parallel programming. Luckily C++ can > be mixed with C usually easily (I think the famous enough Gnu compiler > chain can link the both together, too), I'd think the old rule of the > thumb was that C gets about 70% of the speed of assembly, and I see no > reason to believe that's better for C++ or the (older) Objective C, > maybe there are object hierarchies "libraries"/"classes" which > instantiate handily into single-processor SSE2 optimized code fragments, > which is fine, but less insightful. > > I'm glad C is still a major language and that for instance Risc 1000 and > (Nvidia) Cuda processors and of course most big DSPs can be programmed > in it. I don't think I really miss an OO language much for that (Which I > professionally used at university for hierarchical graphics, which was > handy). > > I've found myself searching for cheap Fermi cards to do some heavy sound > processing in double precision, anyone working on that ? > > Theo Verelst > http://www.theover.org/Cuda > > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From theover at tiscali.nl Fri Oct 29 05:54:33 2010 From: theover at tiscali.nl (Theo Verelst) Date: Fri, 29 Oct 2010 11:54:33 +0200 Subject: [music-dsp] C++ performance Message-ID: <4CCA99D9.8080808@tiscali.nl> I?d rather have some good manuals from a non-programmer point of view with libraries of pro standing than the so many-th C++ coding scheme.. I mean I compiled and used a quite accelerated fft-based mastering effect called Jamin based on a fast fft library, which I think is cool in Open Source, and gives a nice tool to play with, just like a lot of the ladspa plugins, which at least don?t come accross very artificial. I?m a proponent of openness in programming like I promoted graphs (with bwise), without the use of some secret code to unlock understanding a bunch of C++ classes, though I agree they can have some use. I mean, unless the source is open, most vacuum cleaners come with more relevant technical data in their manual than a lot of software! Theo Verelst http://wiki.tcl.tk/bwise From thomas at pdp7.org Fri Oct 29 06:12:16 2010 From: thomas at pdp7.org (Thomas Strathmann) Date: Fri, 29 Oct 2010 12:12:16 +0200 Subject: [music-dsp] C++ performance In-Reply-To: <4CCA99D9.8080808@tiscali.nl> References: <4CCA99D9.8080808@tiscali.nl> Message-ID: <4CCA9E00.6000608@pdp7.org> On 10/29/10 11:54 , Theo Verelst wrote: > I?d rather have some good manuals from a non-programmer point of view > with libraries of pro standing than the so many-th C++ coding scheme.. What's your problem with Scheme? Many people use ECMAscript which at heart is a bastardized version of Scheme. Besides it's a good, relatively clean impure functional language. It's strict by default, it can be lazy, what's not to like? > I?m a proponent of openness in programming like I promoted graphs (with > bwise), without the use of some secret code to unlock understanding a > bunch of C++ classes, though I agree they can have some use. I mean, > unless the source is open, most vacuum cleaners come with more relevant > technical data in their manual than a lot of software! I don't understand this paragraph. Where is the secret code to unlock the understanding of C++ classes? The compiler's implementation? The runtime? The operating system? The firmware of the chips on your computer's motherboard? Why exactly is your tool more open or has less hidden secrets than any given (FLOSS) software? Does the user (in the good old-fashioned sense, someone who "only" uses software, does not read it's source code, does not hack around if something does not seem to work like he imagined, etc.) care about this level of technical information? I mean: I'm all for a return to architectures like the Lisp machine where you can inspect and modify everything at runtime (including "kernel" drivers) and it's all written in basically the same language. What proponents of the open source movement call open is not really a step forward when you think of what has been achieved in the past, but I guess we're already way off-topic on this list. I always thought the discussion whether C++ could be used for serious programming (i.e. including low-level performance critical stuff) was over for at least 10 years now. Thomas From richarddobson at blueyonder.co.uk Fri Oct 29 05:31:55 2010 From: richarddobson at blueyonder.co.uk (Richard Dobson) Date: Fri, 29 Oct 2010 10:31:55 +0100 Subject: [music-dsp] C++ performance In-Reply-To: References: <1288309861.23134.15.camel@localhost.localdomain> Message-ID: <4CCA948B.6080308@blueyonder.co.uk> But the discussion is on processing speed = power, not on semantic/structural expressivity = power. It is always tempting to equate the two, but I do not think that is safe. Given the same template code in C++, we would still be interested in which ~compiler~ translates it into the fastest machine code, where both cpu speed and ram are somewhat constrained (ARM on iPhone) compared to the luxury of 3GHZ multi-core cpus with 8GB of fast RAM to play in. And then, in whether it is faster than what hand-rolled C can produce. FFTW remains written in C - I am sure that if it led to a significant speed increase, given their interest in benchmarks, they would have moved it all to C++ by now. Many large systems clearly benefit from the language facilities of C++, to the extent that they might not be able to be written in C in a reasonable timescale, but this does not mean a priori that ~all~ possible algorithms (especially thosw with loads as extremely variable as must msuic apps) on all possible platforms will benefit similarly. For a lot of heavy HPC computation, Fortran is still in very widespread use, as it is still regarded as achieving the fastest raw performance. And I doubt if even the new parallel stuff in the planned new C++ can really address the massively-parallel processing tasks that need the power of Cuda/OpenCL etc. I get the impression that while the architectural level of an app may be written in C++, the critical dsp code may even today be implemented in assembler (or hand-optimised C). No need for templates if you know everything is always going to be in doubles! Richard Dobson On 29/10/2010 01:21, Michael Gogins wrote: > I think your take on C++ is rather skewed, First, consider what > languages actually are used to write critical software. Avionics, > scientific data processing, performance-critical consumer software, > are mostly (and increasingly) written in C++ not C. > ... From michael.gogins at gmail.com Fri Oct 29 09:56:05 2010 From: michael.gogins at gmail.com (Michael Gogins) Date: Fri, 29 Oct 2010 09:56:05 -0400 Subject: [music-dsp] C++ performance In-Reply-To: <4CCA948B.6080308@blueyonder.co.uk> References: <1288309861.23134.15.camel@localhost.localdomain> <4CCA948B.6080308@blueyonder.co.uk> Message-ID: I make no such assumption regarding FFTW. As in all complex software systems, there must be considerable inertia in the code base and in the skills of the programmers. Besides, why fix what is not broken? I think it is more relevant to look at libraries for matrix arithmetic. This technology is constantly evolving under heavy demand for scientific programming. The current leading Fortran libraries contain code that is extensively tweaked for specific architectures. I would not be surprised to learn that military versions of these libraries use GPU cores. Yet, for dense matrices, the churning evolution of various C and C++ libraries has produced a situation where the leading C++ library. Eigen, performs in the upper range of the vendor-tuned Fortran libraries (http://eigen.tuxfamily.org/index.php?title=Benchmark). Of course, Eigen itself contains tweaks and specializations for specific processors and vectorizations. Still, not only is the code much easier to USE than the plain BLAS/LAPACK, but the implementation code also is easier to read than, say, ATLAS or GOTO. Of course, I use Eigen myself for new numerical projects. Note: Eigen 3 beta supports ARM NEON. It also supports parallel evaluations in some cases (e.g. large matrix dot products) using OpenMP. I did address expressivity. But I also directly addressed speed. My claim is simply that using clear, standard C++ including the Standard C++ Library, code can be written that is as fast as C or as most hand-written assembler. My evidence is irrefutable: personal experience, some personal tests, Eigen (of course), and the increasing practice of those who MUST write the fastest code (e.g. military avionics, commercial signal processing applications). The question here is what to use when beginning a project where speed is a high priority. If you have three tools that will produce FAPP equal speed, why use the clunky, complex tool when you can use the clear, expressive one? Regards, Mike On Fri, Oct 29, 2010 at 5:31 AM, Richard Dobson wrote: > But the discussion is on processing speed = power, not on > semantic/structural expressivity = power. It is always tempting to equate > the two, but I do not think that is safe. ?Given the same template code in > C++, we would still be interested in which ~compiler~ translates it into the > fastest machine code, where both cpu speed and ram are somewhat constrained > (ARM on iPhone) compared to the luxury of 3GHZ multi-core cpus with 8GB of > fast RAM to play in. ?And then, in whether it is faster than what > hand-rolled C can produce. ?FFTW remains written in C - I am sure that if it > led to a significant speed increase, given their interest in ?benchmarks, > they would have moved it all to C++ by now. Many large systems clearly > benefit from the language facilities of C++, to the extent that they might > not be able to be written in C in a reasonable timescale, but this does not > mean a priori that ~all~ possible algorithms (especially thosw with loads as > extremely variable as must msuic apps) on all possible platforms will > benefit similarly. For a lot of heavy HPC computation, Fortran is still in > very widespread use, as it is still regarded as achieving the fastest raw > performance. And I doubt if even the new parallel stuff in the planned new > C++ can really address the massively-parallel processing tasks that need the > power of Cuda/OpenCL etc. I get the impression that while the architectural > level of an app may be written in C++, the critical dsp code may even today > be implemented in assembler (or hand-optimised C). No need for templates if > you know everything is always going to be in doubles! > > > Richard Dobson > > > On 29/10/2010 01:21, Michael Gogins wrote: >> >> I think your take on C++ is rather skewed, First, consider what >> languages actually are used to write critical software. Avionics, >> scientific data processing, performance-critical consumer software, >> are mostly (and increasingly) written in C++ not C. >> > ... > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp > links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com From richarddobson at blueyonder.co.uk Fri Oct 29 14:26:28 2010 From: richarddobson at blueyonder.co.uk (Richard Dobson) Date: Fri, 29 Oct 2010 19:26:28 +0100 Subject: [music-dsp] C++ performance In-Reply-To: References: <1288309861.23134.15.camel@localhost.localdomain> <4CCA948B.6080308@blueyonder.co.uk> Message-ID: <4CCB11D4.2050503@blueyonder.co.uk> On 29/10/2010 14:56, Michael Gogins wrote: .. > > The question here is what to use when beginning a project where speed > is a high priority. If you have three tools that will produce FAPP > equal speed, why use the clunky, complex tool when you can use the > clear, expressive one? > So that's a vote for C then :-). And whether any of this debate is actually answering the OPs question is a bit moot... Richard Dobson From michael.gogins at gmail.com Fri Oct 29 15:30:16 2010 From: michael.gogins at gmail.com (Michael Gogins) Date: Fri, 29 Oct 2010 15:30:16 -0400 Subject: [music-dsp] C++ performance In-Reply-To: <4CCB11D4.2050503@blueyonder.co.uk> References: <1288309861.23134.15.camel@localhost.localdomain> <4CCA948B.6080308@blueyonder.co.uk> <4CCB11D4.2050503@blueyonder.co.uk> Message-ID: It is definitely not a vote for C if you are doing any kind of linear algebra or using any data structures more complex than arrays. Of course my posts fail to answer the original poster's original question, but I do feel they probably are relevant to his project... Regards, Mike On Fri, Oct 29, 2010 at 2:26 PM, Richard Dobson wrote: > On 29/10/2010 14:56, Michael Gogins wrote: > .. >> >> The question here is what to use when beginning a project where speed >> is a high priority. If you have three tools that will produce FAPP >> equal speed, why use the clunky, complex tool when you can use the >> clear, expressive one? >> > > So that's a vote for C then :-). > > And whether any of this debate is actually answering the OPs question is a > bit moot... > > 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 > -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com From rbj at audioimagination.com Fri Oct 29 20:37:35 2010 From: rbj at audioimagination.com (robert bristow-johnson) Date: Fri, 29 Oct 2010 20:37:35 -0400 Subject: [music-dsp] C++ performance In-Reply-To: References: <1288309861.23134.15.camel@localhost.localdomain> <4CCA948B.6080308@blueyonder.co.uk> <4CCB11D4.2050503@blueyonder.co.uk> Message-ID: <7EB3B559-44F3-4BEC-9F3B-FB8568ADA2B3@audioimagination.com> On Oct 29, 2010, at 3:30 PM, Michael Gogins wrote: > It is definitely not a vote for C if you are doing any kind of linear > algebra or using any data structures more complex than arrays. unless you need to redfine operators (i think it's called "operator overloading"), why can't you use C for linear algebra (i presume you mean matrix arithmetic) or more complex data structs. it means the manipulation would have to be with function calls, might be less pretty than with a decent OO language, but i see no reason it can't be done in C. -- r b-j rbj at audioimagination.com "Imagination is more important than knowledge." From michael.gogins at gmail.com Fri Oct 29 21:21:28 2010 From: michael.gogins at gmail.com (Michael Gogins) Date: Fri, 29 Oct 2010 21:21:28 -0400 Subject: [music-dsp] C++ performance In-Reply-To: <7EB3B559-44F3-4BEC-9F3B-FB8568ADA2B3@audioimagination.com> References: <1288309861.23134.15.camel@localhost.localdomain> <4CCA948B.6080308@blueyonder.co.uk> <4CCB11D4.2050503@blueyonder.co.uk> <7EB3B559-44F3-4BEC-9F3B-FB8568ADA2B3@audioimagination.com> Message-ID: You guys are making things up I did not say. Of course could it be done in C. I said (and I can prove it) that it can be done more clearly and simply in C++, yet still run just as fast. Is that a vote for C++? It is if you value clarity and readability in your code. Regards, Mike On Fri, Oct 29, 2010 at 8:37 PM, robert bristow-johnson wrote: > > On Oct 29, 2010, at 3:30 PM, Michael Gogins wrote: > >> It is definitely not a vote for C if you are doing any kind of linear >> algebra or using any data structures more complex than arrays. > > > unless you need to redfine operators (i think it's called "operator > overloading"), why can't you use C for linear algebra (i presume you mean > matrix arithmetic) or more complex data structs. ?it means the manipulation > would have to be with function calls, might be less pretty than with a > decent OO language, but i see no reason it can't be done in C. > > -- > > r b-j ? ? ? ? ? ? ? ? ?rbj at 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 > -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com From gwenhwyfaer at gmail.com Sat Oct 30 01:33:24 2010 From: gwenhwyfaer at gmail.com (Gwenhwyfaer) Date: Sat, 30 Oct 2010 06:33:24 +0100 Subject: [music-dsp] C++ performance In-Reply-To: References: <1288309861.23134.15.camel@localhost.localdomain> <4CCA948B.6080308@blueyonder.co.uk> <4CCB11D4.2050503@blueyonder.co.uk> <7EB3B559-44F3-4BEC-9F3B-FB8568ADA2B3@audioimagination.com> Message-ID: On 30/10/2010, Michael Gogins wrote: > You guys are making things up I did not say. Of course could it be > done in C. I said (and I can prove it) that it can be done more > clearly and simply in C++, yet still run just as fast. Is that a vote > for C++? It is if you value clarity and readability in your code. There's clarity, and there's transparency. In C++ I can easily read a piece of code and *think* I know what it does and how long it'll take to do it - but *only* if I trust the guy who wrote all those operator overloads not to have (a) dropped the ball in efficiency terms, (b) not to have redefined those operators in an interesting way. In C, reading a bunch of function calls might challenge my patience, but (a) that's what comments are for, isn't it? and (b) I know *exactly* how much each of those native constructs is going to cost me; I'm not going to be taken by surprise. From rossb-lists at audiomulch.com Sat Oct 30 02:25:24 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Sat, 30 Oct 2010 17:25:24 +1100 Subject: [music-dsp] C++ performance References: <1288309861.23134.15.camel@localhost.localdomain><4CCA948B.6080308@blueyonder.co.uk><4CCB11D4.2050503@blueyonder.co.uk><7EB3B559-44F3-4BEC-9F3B-FB8568ADA2B3@audioimagination.com> Message-ID: <10af01cb77fb$3da65a40$0201a8c0@rossmacbook> Gwenhwyfaer wrote: > There's clarity, and there's transparency. Expressing a quicksort algorithm clearly and transparently in C++ or C is not so hard -- it's a sequential algorithm -- these programming languages are intended to express sequential algorithms. Expressing a signal processing structure (some kind of signal flow model for example) in C++ or C is not There is always going to be a tradeoff between clarity and transparency. Sometimes clarity is more important than transparency, sometimes transparency is more important than clarity. It is difficult to achieve both at the same time in any language given that the domain one is trying to be clear in isn't necessarily about software at all. > In C++ I can easily read a > piece of code and *think* I know what it does and how long it'll take > to do it - but *only* if I trust the guy who wrote all those operator > overloads not to have (a) dropped the ball in efficiency terms, (b) > not to have redefined those operators in an interesting way. In C, > reading a bunch of function calls might challenge my patience, but (a) > that's what comments are for, isn't it? and (b) I know *exactly* how > much each of those native constructs is going to cost me; I'm not > going to be taken by surprise. You seem to be saying "I don't like C++ because if I encounter code by someone I don't trust that's poorly written or has efficiency problems it's harder for me to locate the errors". Alternatively you could be comfortable with the issues you outline and (a) avoid code by people who don't know how to write efficient code and (b) avoid code by people who do stupid things with operator overloading. And if you're writing the code yourself, well I don't think these issues apply.. you've made your own problem by doing these things. There will always be cases where C is better than C++ or vis-versa. But just because C++ might make it easier for inexperienced programmers to write opaque code than C doesn't mean you should avoid it and always use C. If you know C++ well, and the code has been written by yourself, or a developer you trust, it probably won't have either of the problems you describe. And it's not like C++ is some arcane language with lots of barely competent software engineers using it (like eg Perl) -- there is really no excuse for people not learning C++ properly if they want to use it -- there are plenty of resources to learn C++ best practices (Herb Sutter's excellent GoTW posts and books come to mind: http://www.gotw.ca/gotw/). From rbj at audioimagination.com Sat Oct 30 02:52:44 2010 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sat, 30 Oct 2010 02:52:44 -0400 Subject: [music-dsp] C++ performance In-Reply-To: References: <1288309861.23134.15.camel@localhost.localdomain> <4CCA948B.6080308@blueyonder.co.uk> <4CCB11D4.2050503@blueyonder.co.uk> <7EB3B559-44F3-4BEC-9F3B-FB8568ADA2B3@audioimagination.com> Message-ID: <2A78895A-C5A0-422F-8332-C294CE140CF1@audioimagination.com> i'm not trying to make anything up about what anyone else says. certainly in C++, the core methods that are wrapped up in a class can be as efficient as C because, eventually, the lowest-level code (where no other functions/methods are called) *is* C. i really don't know how to program C++ to the point where i can build a project from scratch. i know how to add methods and data to a class. sorta. for audio processing usually there are three main methods that i need to define: the initialization code when an object is created (and i s'pose the cleaning up when the object is destructed). the sample processing code (usually in "chunks" of samples). and the coefficient cooking code (whatever goes in between the knob the user twists and the coefficients and parameters the sample processing code needs). that's nicely done in C++ and nicely allows for these things to be inherited when the class is used to build another class upon. but if i do it in C using structs, i feel like i understand what i am doing and what the computer is doing better. the clarity and readability is very important to me. OOP offers something valuable for that. i have heard there are better/cleaner OOP languages than C++ (someone told me that "SmallTalk" or something similarly named was a nice OOP language). my problem with C++ is some syntax issues that are ugly and unnecessarily so (like "<<" for I/O when fread() or fwrite() would do just fine and not get confused with the shift operator). and C++ is big, not really concise. an OOP language should accomplish the encapsulation & modularity, polymorphism & inheritance (admittedly, i have trouble telling the difference between the first and second of each pair, for me modularity *is* encapsulation and inheritance *is* polymorphism, but then again, i'm not much of a C++ coder) that makes it an OOP. but i wish the languages would not try to be all things to all men (sorta like Ada is) because it's just too much to learn for an old and atrophied brain like mine. so i might try to accomplish the same kinda goals with a simpler and smaller language like C or even in assembler, as long as there is a functioning macro facility in it. if you're careful, you can make clear and readable code (that can be expanded on) with a decent macro assembler or in C. and if you're sloppy, you can make horrible horrible unreadable horrible code in C++. i have seen it done, both long ago and recently. i can never understand why people do that. why bother with C++ if you're not going to make readable, modular, and concise code with it? that's my $0.02, anyway. r b-j On Oct 30, 2010, at 1:33 AM, Gwenhwyfaer wrote: > On 30/10/2010, Michael Gogins wrote: >> You guys are making things up I did not say. Of course could it be >> done in C. I said (and I can prove it) that it can be done more >> clearly and simply in C++, yet still run just as fast. Is that a vote >> for C++? It is if you value clarity and readability in your code. > > There's clarity, and there's transparency. In C++ I can easily read a > piece of code and *think* I know what it does and how long it'll take > to do it - but *only* if I trust the guy who wrote all those operator > overloads not to have (a) dropped the ball in efficiency terms, (b) > not to have redefined those operators in an interesting way. In C, > reading a bunch of function calls might challenge my patience, but (a) > that's what comments are for, isn't it? and (b) I know *exactly* how > much each of those native constructs is going to cost me; I'm not > going to be taken by surprise. > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book > reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > -- r b-j rbj at audioimagination.com "Imagination is more important than knowledge." From rossb-lists at audiomulch.com Sat Oct 30 02:56:08 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Sat, 30 Oct 2010 17:56:08 +1100 Subject: [music-dsp] C++ performance References: <1288309861.23134.15.camel@localhost.localdomain><4CCA948B.6080308@blueyonder.co.uk><4CCB11D4.2050503@blueyonder.co.uk><7EB3B559-44F3-4BEC-9F3B-FB8568ADA2B3@audioimagination.com> Message-ID: <10b801cb77ff$8867c920$0201a8c0@rossmacbook> [oops hit send too soon, please ignore previous garbled reply] Gwenhwyfaer wrote: > There's clarity, and there's transparency. Agreed.. both are important: (1) clarity for understanding what the code expresses in the problem domain (signal processing) -- since you need to be able to look at the code and understand what kind of processing it's doing, and (2) transparency for understanding what the CPU is doing so you can optimise (whether by micro-optimising or going with a completely different implementation). (2) is not so important if you are using someone elses library and it is known to be well written and reliable (Michael's example is Eigen but you could pick any other library). But I think there is going to be a trade off when dealing with any application domain/implementation domain translation: Expressing a quicksort algorithm clearly and transparently in C++ or C is not so hard -- quicksort is a sequential algorithm -- programming languages are intended to express sequential algorithms. The application and implementation domains are closely aligned. Expressing a signal processing structure (some kind of signal flow model for example) or perhaps some matrix algebra in C++ or C is not really likely to be all that clear if you also want to be transparent. The more you try to be clear, the more you will move towards a domain specific langauge/representation, and the less transparent things will be. The more transparent you try to be, the more your code will look like loops and function calls and the less like something that reads as a signal processing structure (or algebraic expression). This trade off exists in any language. It's just that C++ gives you more tools than C to move towards the clarity end of the scale for some domains. I think matrix algebra is a good example: using Eigen (or Blitz or whatever) lets you write matrix algebra in C++ using algebraic expressions rather than matrix operation function calls as you would need to do in C. But in the case of a lot of audio DSP.. it's less clear that there's so much benefit to trying to construct a domain specific language in C++ -- DSP algorithms are not always expressed using algebraic expressions: they're often expressed using data flow structures - and translating these structures into text is rarely particularly clear and usually involves some kind of restriction on the domain of expressible things (think about what is hard to express in CSound for example). Based on this, I have concluded, after thinking and experimenting with this for a long time, that it's better to err on the side of transparency when it comes to writing DSP code in C++> But that's not to say you can't get some clarity benefits from using C++ over C. One of the questions the OP asked was about efficiency of inlining when creating abstractions with classes -- they are trying to create clearer code by using C++'s abstraction mechanisms. They were comfortable trading off a bit of transparency for clarity. I think most people using C++ will do this to some degree. The further you go, the more risky it becomes -- things can get so opaque that you have little hope of understanding the library you're using without a lot of study (template metaprogramming systems like blitz come to mind). But if you know they are fast, and you trust them, they can help you write clearer code that is also efficient. (see also below). My advice to a beginner would be to not get too carried away with over-abstracting things for the sake of clarity. Sooner or later you will become interested in the instructions the CPU is executing as much as the DSP structure the code is expressing. > In C++ I can easily read a > piece of code and *think* I know what it does and how long it'll take > to do it - but *only* if I trust the guy who wrote all those operator > overloads not to have (a) dropped the ball in efficiency terms, (b) > not to have redefined those operators in an interesting way. In C, > reading a bunch of function calls might challenge my patience, but (a) > that's what comments are for, isn't it? and (b) I know *exactly* how > much each of those native constructs is going to cost me; I'm not > going to be taken by surprise. If you know C++ well, and the code has been written by yourself, or a developer you trust, it probably won't have either of the problems you describe. And it's not like C++ is some arcane language with lots of barely competent software engineers using it (like eg Perl) -- there is really no excuse for people not learning C++ properly if they want to use it -- there are plenty of resources to learn C++ best practices (Herb Sutter's excellent GoTW posts and books come to mind: http://www.gotw.ca/gotw/). On the other hand, the learning curve to mastery is indeed long. Ross. From thomas at pdp7.org Sat Oct 30 10:09:54 2010 From: thomas at pdp7.org (Thomas Strathmann) Date: Sat, 30 Oct 2010 16:09:54 +0200 Subject: [music-dsp] C++ performance In-Reply-To: <2A78895A-C5A0-422F-8332-C294CE140CF1@audioimagination.com> References: <1288309861.23134.15.camel@localhost.localdomain> <4CCA948B.6080308@blueyonder.co.uk> <4CCB11D4.2050503@blueyonder.co.uk> <7EB3B559-44F3-4BEC-9F3B-FB8568ADA2B3@audioimagination.com> <2A78895A-C5A0-422F-8332-C294CE140CF1@audioimagination.com> Message-ID: <4CCC2732.1040000@pdp7.org> On 10/30/10 08:52 , robert bristow-johnson wrote: > but if i do it in C using structs, i feel like i understand what i am > doing and what the computer is doing better. Then just write struct instead of class and everything is fine if that's the problem. ;-) > the clarity and readability is very important to me. OOP offers > something valuable for that. i have heard there are better/cleaner OOP > languages than C++ (someone told me that "SmallTalk" or something > similarly named was a nice OOP language). my problem with C++ is some > syntax issues that are ugly and unnecessarily so (like "<<" for I/O when > fread() or fwrite() would do just fine and not get confused with the > shift operator). and C++ is big, not really concise. an OOP language > should accomplish the encapsulation & modularity, polymorphism & > inheritance (admittedly, i have trouble telling the difference between > the first and second of each pair, for me modularity *is* encapsulation > and inheritance *is* polymorphism, but then again, i'm not much of a C++ > coder) that makes it an OOP. but i wish the languages would not try to > be all things to all men (sorta like Ada is) because it's just too much > to learn for an old and atrophied brain like mine. Well, the syntax of C++ leaves a lot to be desired, but the stream operator part is certainly not one of it. This is where the power of polymorphism comes in. It avoids using something like format strings in printf type functions or do manual conversion from the data structure you want to print (or output to any old file, character device, etc.) inline with the code you use to express what you really had in mind. I've yet to see an example of sensibly written C++ code where one who knows the language would mistake "<<" or ">>" for the shift operator when it's meant to be a stream operation. The syntax for pure virtual methods is far uglier for example, Stroustrup himself admits that but states he caved into pressure from others not to add new keywords to C++. As for Smalltalk: It's a different kind of deal. It's a prototype based OOP language, whereas C++ is class-based. You don't define classes in Smalltalk, instead you clone an object and modify its internals until you're satisfied that it's the object you wanted to construct in the first place. Alan Kay was a big fan of Lisp whereas Stroustrup was a big fan of Simula. Inheritance is not polymorphism, polymorphism is a very broad concept that applies to a lot of different concepts. Inheritance is closely related to subtype polymorphism, but you've also go parametric polymorphism where you parametrise a function with a type you can instantiate later (template in C++ comes to mind although the template facility can do much more being a Turing complete language in itself), and the list goes on. Likewise modularity and encapsulation are seen be many people as two sides of the same medal, but then others argue that encapsulation is actually a bad thing or at best unnecessary so you should not implement it in an object or module system. Although I would not go as far as saying that modularity and encapsulation are orthogonal concepts, I can safely say that it's not always a package deal with those two. > so i might try to accomplish the same kinda goals with a simpler and > smaller language like C or even in assembler, as long as there is a > functioning macro facility in it. if you're careful, you can make clear > and readable code (that can be expanded on) with a decent macro > assembler or in C. and if you're sloppy, you can make horrible horrible > unreadable horrible code in C++. i have seen it done, both long ago and > recently. i can never understand why people do that. why bother with C++ > if you're not going to make readable, modular, and concise code with it? I believe others have beaten this horse to death already: A language cannot solely judged by its programmers especially if you admittedly don't know the language in question that well. It's like spreading rumours about the young couple that just moved in next to your flat without bothering to get to know them on a personal basis. Thomas From gwenhwyfaer at gmail.com Sat Oct 30 10:35:56 2010 From: gwenhwyfaer at gmail.com (Gwenhwyfaer) Date: Sat, 30 Oct 2010 15:35:56 +0100 Subject: [music-dsp] C++ performance In-Reply-To: <10af01cb77fb$3da65a40$0201a8c0@rossmacbook> References: <1288309861.23134.15.camel@localhost.localdomain> <4CCA948B.6080308@blueyonder.co.uk> <4CCB11D4.2050503@blueyonder.co.uk> <7EB3B559-44F3-4BEC-9F3B-FB8568ADA2B3@audioimagination.com> <10af01cb77fb$3da65a40$0201a8c0@rossmacbook> Message-ID: On 30/10/2010, Ross Bencina wrote: > Gwenhwyfaer wrote: >> In C++ I can easily read a >> piece of code and *think* I know what it does and how long it'll take >> to do it... > You seem to be saying "I don't like C++... ...Whoa there. Lisp and Forth both suffer from the same problem to an even greater degree - you can redefine *everything* arbitrarily - and I like both of those languages. A *lot*. I was simply pointing out that there's a difference between clarity of intent and, for want of better terminology, transparency of implementation cost. ...It's unfortunate that this conversation appears to have devolved to the level of a religious war, but since it has, I'll be bowing out now. From gwenhwyfaer at gmail.com Sat Oct 30 10:39:12 2010 From: gwenhwyfaer at gmail.com (Gwenhwyfaer) Date: Sat, 30 Oct 2010 15:39:12 +0100 Subject: [music-dsp] C++ performance In-Reply-To: <10b801cb77ff$8867c920$0201a8c0@rossmacbook> References: <1288309861.23134.15.camel@localhost.localdomain> <4CCA948B.6080308@blueyonder.co.uk> <4CCB11D4.2050503@blueyonder.co.uk> <7EB3B559-44F3-4BEC-9F3B-FB8568ADA2B3@audioimagination.com> <10b801cb77ff$8867c920$0201a8c0@rossmacbook> Message-ID: On 30/10/2010, Ross Bencina wrote: > [oops hit send too soon, please ignore previous garbled reply] ...Heh. It looks like I hit reply too soon. I will if you will. :) Anyway, reading your revised reply, it looks as though we're on much the same page anyway. From andrew.capon at zen.co.uk Sat Oct 30 11:55:28 2010 From: andrew.capon at zen.co.uk (Andrew Capon) Date: Sat, 30 Oct 2010 16:55:28 +0100 Subject: [music-dsp] C++ performance In-Reply-To: <4CCC2732.1040000@pdp7.org> References: <1288309861.23134.15.camel@localhost.localdomain> <4CCA948B.6080308@blueyonder.co.uk> <4CCB11D4.2050503@blueyonder.co.uk> <7EB3B559-44F3-4BEC-9F3B-FB8568ADA2B3@audioimagination.com> <2A78895A-C5A0-422F-8332-C294CE140CF1@audioimagination.com> <4CCC2732.1040000@pdp7.org> Message-ID: Smalltalk is class based not prototype based! On 30 Oct 2010, at 15:09, Thomas Strathmann wrote: > On 10/30/10 08:52 , robert bristow-johnson wrote: >> but if i do it in C using structs, i feel like i understand what i am >> doing and what the computer is doing better. > > Then just write struct instead of class and everything is fine if that's the problem. ;-) > >> the clarity and readability is very important to me. OOP offers >> something valuable for that. i have heard there are better/cleaner OOP >> languages than C++ (someone told me that "SmallTalk" or something >> similarly named was a nice OOP language). my problem with C++ is some >> syntax issues that are ugly and unnecessarily so (like "<<" for I/O when >> fread() or fwrite() would do just fine and not get confused with the >> shift operator). and C++ is big, not really concise. an OOP language >> should accomplish the encapsulation & modularity, polymorphism & >> inheritance (admittedly, i have trouble telling the difference between >> the first and second of each pair, for me modularity *is* encapsulation >> and inheritance *is* polymorphism, but then again, i'm not much of a C++ >> coder) that makes it an OOP. but i wish the languages would not try to >> be all things to all men (sorta like Ada is) because it's just too much >> to learn for an old and atrophied brain like mine. > > Well, the syntax of C++ leaves a lot to be desired, but the stream operator part is certainly not one of it. This is where the power of polymorphism comes in. It avoids using something like format strings in printf type functions or do manual conversion from the data structure you want to print (or output to any old file, character device, etc.) inline with the code you use to express what you really had in mind. > I've yet to see an example of sensibly written C++ code where one who knows the language would mistake "<<" or ">>" for the shift operator when it's meant to be a stream operation. The syntax for pure virtual methods is far uglier for example, Stroustrup himself admits that but states he caved into pressure from others not to add new keywords to C++. > > As for Smalltalk: It's a different kind of deal. It's a prototype based OOP language, whereas C++ is class-based. You don't define classes in Smalltalk, instead you clone an object and modify its internals until you're satisfied that it's the object you wanted to construct in the first place. Alan Kay was a big fan of Lisp whereas Stroustrup was a big fan of Simula. > > Inheritance is not polymorphism, polymorphism is a very broad concept that applies to a lot of different concepts. Inheritance is closely related to subtype polymorphism, but you've also go parametric polymorphism where you parametrise a function with a type you can instantiate later (template in C++ comes to mind although the template facility can do much more being a Turing complete language in itself), and the list goes on. Likewise modularity and encapsulation are seen be many people as two sides of the same medal, but then others argue that encapsulation is actually a bad thing or at best unnecessary so you should not implement it in an object or module system. Although I would not go as far as saying that modularity and encapsulation are orthogonal concepts, I can safely say that it's not always a package deal with those two. > >> so i might try to accomplish the same kinda goals with a simpler and >> smaller language like C or even in assembler, as long as there is a >> functioning macro facility in it. if you're careful, you can make clear >> and readable code (that can be expanded on) with a decent macro >> assembler or in C. and if you're sloppy, you can make horrible horrible >> unreadable horrible code in C++. i have seen it done, both long ago and >> recently. i can never understand why people do that. why bother with C++ >> if you're not going to make readable, modular, and concise code with it? > > I believe others have beaten this horse to death already: A language cannot solely judged by its programmers especially if you admittedly don't know the language in question that well. It's like spreading rumours about the young couple that just moved in next to your flat without bothering to get to know them on a personal basis. > > Thomas > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From gwenhwyfaer at gmail.com Sat Oct 30 12:06:24 2010 From: gwenhwyfaer at gmail.com (Gwenhwyfaer) Date: Sat, 30 Oct 2010 17:06:24 +0100 Subject: [music-dsp] C++ performance In-Reply-To: References: <1288309861.23134.15.camel@localhost.localdomain> <4CCA948B.6080308@blueyonder.co.uk> <4CCB11D4.2050503@blueyonder.co.uk> <7EB3B559-44F3-4BEC-9F3B-FB8568ADA2B3@audioimagination.com> <2A78895A-C5A0-422F-8332-C294CE140CF1@audioimagination.com> <4CCC2732.1040000@pdp7.org> Message-ID: On 30/10/2010, Andrew Capon wrote: > Smalltalk is class based not prototype based! The author might be thinking of SELF, which grew out of the work on Smalltalk. On the other hand, Smalltalk is a completely reflective environment, and can do pretty much any trick with classes that prototype-based languages can do with objects; and as Lynn Stein concluded, "Delegation IS inheritance". ;) From thomas at pdp7.org Sat Oct 30 12:18:04 2010 From: thomas at pdp7.org (Thomas Strathmann) Date: Sat, 30 Oct 2010 18:18:04 +0200 Subject: [music-dsp] C++ performance In-Reply-To: References: <1288309861.23134.15.camel@localhost.localdomain> <4CCA948B.6080308@blueyonder.co.uk> <4CCB11D4.2050503@blueyonder.co.uk> <7EB3B559-44F3-4BEC-9F3B-FB8568ADA2B3@audioimagination.com> <2A78895A-C5A0-422F-8332-C294CE140CF1@audioimagination.com> <4CCC2732.1040000@pdp7.org> Message-ID: <4CCC453C.9090609@pdp7.org> On 10/30/10 18:06 , Gwenhwyfaer wrote: > On 30/10/2010, Andrew Capon wrote: >> Smalltalk is class based not prototype based! > > The author might be thinking of SELF, which grew out of the work on > Smalltalk. On the other hand, Smalltalk is a completely reflective > environment, and can do pretty much any trick with classes that > prototype-based languages can do with objects; and as Lynn Stein > concluded, "Delegation IS inheritance". ;) Exactly, I was thinking of Self. I should abstain from writing about programming languages when not sufficiently caffeinated. ;-) Thoams From theover at tiscali.nl Sat Oct 30 17:28:31 2010 From: theover at tiscali.nl (Theo Verelst) Date: Sat, 30 Oct 2010 23:28:31 +0200 Subject: [music-dsp] Some production path Ladspa DSP tryout Message-ID: <1288474112.1434.17.camel@localhost.localdomain> Hi all, Just to give an idea of my current activities in audio production DSP, I've tried out a Linux Ladspa based multiband compression/gating construction, where I use 15 jack-rack programs each using one band of a 15 band equalizer to feed a stereo compressor and noise-gate unit. Using two AT2020 mics, Lexicon preamp and AD converters, and some compression and slight reverb, the 15 parallel compressor frequencies are fed. On my big monitoring system (no bass reflex, 15 inch sub, 3 channel multi amped, 5 way), an AKG K271 mk2 headphone set, and a computer monitor speaker the following example sounds good: http://www.theover.org/Prod/micmulti2.mp3 The gate-ing hides a pretty noise computer pair nearby, so that's audible when putting the example loud, I didn't try deep or hard to get setting or other processing to make that nicer.. The give an idea of the parameters of the compressors I've used (some other time, I don't know if the settings I used today are the exact same), here's a screendump: http://www.theover.org/Diary/Ldi99/calforg139.png The computer running the 15 eq/compression effects is a at the time (years ago) fairly fast bus, 3 GHz Pentium D system with Fedora 12/64 Linux. Greetings, Theo Verelst http://www.theover.org