From douglas at music.columbia.edu Sun Nov 1 07:00:00 2009 From: douglas at music.columbia.edu (douglas repetto) Date: Sun, 1 Nov 2009 07:00:00 -0500 (EST) Subject: [music-dsp] [admin] music-dsp FAQ Message-ID: <20091101120000.CDFA690E717@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 contact at quikquak.com Sun Nov 1 10:21:09 2009 From: contact at quikquak.com (contact) Date: Sun, 1 Nov 2009 15:21:09 -0000 Subject: [music-dsp] platform choice References: <01db01ca59d4$2804c320$0773a8c0@rossmacbook><4AEC0C0A.7040008@blueyonder.co.uk><5B2EBE2A-C010-4D11-94BD-51338850FE98@nuim.ie><99B2E82E95AE42F79EF287843BF18A7C@DaveUpstairs><2385BDC6-B628-47DC-80C7-01236EDE1635@audioimagination.com><948B7ACA-0446-4E45-923D-E2A928C37A7E@silberstein.de> Message-ID: <9AB6AEE459474308925B1A369CC037C3@DaveUpstairs> > On Oct 31, 2009, at 1:02 PM, bastian.schnuerle wrote: > >> but cool about matlab is, if you use such a function cheby2(..) .. >> you can just dig into the .m file and learn a lot on how this >> function works .. > > yeah, but you gotta turn their stupid indexing convention around > sometimes. not only the stupid "all arrays have origin 1" thing, but > their polyfit and polyval functions have the high order coefficient > first. untangling that in anything non-trivial is, well, non-trivial. > > reverse-engineering MATLAB spaghetti code is about as bad as reverse- > engineering decade old uncommented spaghetti code at Kurzweil. You won't find me digging around in some creeky old obfuscated Matlab code like that, and trying to reverse engineer stuff. I wouldn't learn anything doing that sort of thing! LOL. Joking. Everybody tries it. From rbj at audioimagination.com Sun Nov 1 10:41:26 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sun, 1 Nov 2009 10:41:26 -0500 Subject: [music-dsp] platform choice In-Reply-To: <4AEC930C.3050002@pdp7.org> References: <01db01ca59d4$2804c320$0773a8c0@rossmacbook> <4AEC0C0A.7040008@blueyonder.co.uk> <5B2EBE2A-C010-4D11-94BD-51338850FE98@nuim.ie> <99B2E82E95AE42F79EF287843BF18A7C@DaveUpstairs> <2385BDC6-B628-47DC-80C7-01236EDE1635@audioimagination.com> <948B7ACA-0446-4E45-923D-E2A928C37A7E@silberstein.de> <907277ED-F2A7-4AD6-8DEB-07B1EB45B12E@nuim.ie> <4AEC7791.6000600@pdp7.org> <463E662C-B3B2-47E4-9E83-6D41B22BEBCE@audioimagination.com> <4AEC930C.3050002@pdp7.org> Message-ID: <34DAFEAC-B5BD-4EF2-932B-934809EE888D@audioimagination.com> On Oct 31, 2009, at 3:42 PM, Thomas Strathmann wrote: > Array indexing is a problem, of course. But this problem is not > limited > to a discussion about Matlab or specific functions implemented in > Matlab. A mathematician would probably say, 1 is the first index. A > programmer and many computer scientists will probably disagree and > declare 0 as the only sensible start index of an array or virtually > anything (that has semanttics close to arrays). If one were to allow > both conventions to coexist in a language or even move to a notion of > encoding the first index of an array and its length in the type, what > would happen? Total anarchy? Horribly unreadable programs? no, the precise opposite. there is no reason that you cannot make the origin of each dimension of an array a property, just like the length of rows and columns of an array in MATLAB is a property you can change with reshape(). so, similarly to size() and reshape() which inform us and allow us to change the length of rows and columns, there could be two utilities called origin() and reorigin() (or base() and rebase()) that would allow us to know what the value of the lowest index is for each dimension and to change it. each new array would have 1 as the origin for every dimension. this would be perfectly backward compatible. only those who use the functions origin() and reorigin() would be able to screw this up and break their code. not only is there a need for us to concisely define arrays with 0 as the origin, but sometimes we need negative indices (like to describe a non-causal impulse response). it is not just a 0-based vs. 1-based issue. it's whether or not you have the freedom to set the base or origin of the array to what is natural for the problem that you're modeling in MATLAB. that's what the language is for. > Seems like the Matlab user base is pretty much divided in different > camps according to their particular usage of the program. That > would be > part of an explanation why Matlab seems to make little progress > besides > tweaking the "user experience" and adding new functionality/toolboxes. the very very first toolbox for MATLAB was the Signal Processing toolbox. it's the most well established camp. one of the original authors of that toolbox, Thomas Krause i think his name was, told me that he told them back then (around 1990) that they needed to fix this thing and they rejected him. it would be interesting to see how things would have been different had they heeded him instead. -- r b-j rbj at audioimagination.com "Imagination is more important than knowledge." From thomas at pdp7.org Sun Nov 1 13:54:37 2009 From: thomas at pdp7.org (Thomas Strathmann) Date: Sun, 01 Nov 2009 19:54:37 +0100 Subject: [music-dsp] platform choice In-Reply-To: <34DAFEAC-B5BD-4EF2-932B-934809EE888D@audioimagination.com> References: <01db01ca59d4$2804c320$0773a8c0@rossmacbook> <4AEC0C0A.7040008@blueyonder.co.uk> <5B2EBE2A-C010-4D11-94BD-51338850FE98@nuim.ie> <99B2E82E95AE42F79EF287843BF18A7C@DaveUpstairs> <2385BDC6-B628-47DC-80C7-01236EDE1635@audioimagination.com> <948B7ACA-0446-4E45-923D-E2A928C37A7E@silberstein.de> <907277ED-F2A7-4AD6-8DEB-07B1EB45B12E@nuim.ie> <4AEC7791.6000600@pdp7.org> <463E662C-B3B2-47E4-9E83-6D41B22BEBCE@audioimagination.com> <4AEC930C.3050002@pdp7.org> <34DAFEAC-B5BD-4EF2-932B-934809EE888D@audioimagination.com> Message-ID: <4AEDD96D.6010601@pdp7.org> robert bristow-johnson wrote: > On Oct 31, 2009, at 3:42 PM, Thomas Strathmann wrote: > >> Array indexing is a problem, of course. But this problem is not >> limited >> to a discussion about Matlab or specific functions implemented in >> Matlab. A mathematician would probably say, 1 is the first index. A >> programmer and many computer scientists will probably disagree and >> declare 0 as the only sensible start index of an array or virtually >> anything (that has semanttics close to arrays). If one were to allow >> both conventions to coexist in a language or even move to a notion of >> encoding the first index of an array and its length in the type, what >> would happen? Total anarchy? Horribly unreadable programs? > > no, the precise opposite. > > there is no reason that you cannot make the origin of each dimension > of an array a property, just like the length of rows and columns of > an array in MATLAB is a property you can change with reshape(). so, > similarly to size() and reshape() which inform us and allow us to > change the length of rows and columns, there could be two utilities > called origin() and reorigin() (or base() and rebase()) that would > allow us to know what the value of the lowest index is for each > dimension and to change it. each new array would have 1 as the > origin for every dimension. > > this would be perfectly backward compatible. only those who use the > functions origin() and reorigin() would be able to screw this up and > break their code. Exactly the answer I was hoping for. Although, I would not want a language where the array starting index etc. is just a property of a datatype in a record-like fashion. This would indeed give rise to the problem you describe with origin() and reorigin() in the context of legacy code. Instead, I propose to define a language in which such properties are part of the type itself such that function signatures which only take 4x4 matrices or vectors starting at -2 for instance can be written and the corresponding properties be enforced at compile time. > not only is there a need for us to concisely define arrays with 0 as > the origin, but sometimes we need negative indices (like to describe > a non-causal impulse response). it is not just a 0-based vs. 1-based > issue. it's whether or not you have the freedom to set the base or > origin of the array to what is natural for the problem that you're > modeling in MATLAB. that's what the language is for. Yes, I also think that it's rather unintuitive that you cannot express such properties directly in a language that is intended for expressing numerical algorithms. > the very very first toolbox for MATLAB was the Signal Processing > toolbox. it's the most well established camp. one of the original > authors of that toolbox, Thomas Krause i think his name was, told me > that he told them back then (around 1990) that they needed to fix > this thing and they rejected him. it would be interesting to see how > things would have been different had they heeded him instead. Interesting. I must ask the psycho-accoustic guys here at the university if they would consider buying a Matlab upgrade, if this feature was added. ;-) Thomas From andrew.capon at zen.co.uk Sun Nov 1 14:00:19 2009 From: andrew.capon at zen.co.uk (Andrew Capon) Date: Sun, 1 Nov 2009 19:00:19 +0000 Subject: [music-dsp] platform choice In-Reply-To: <4AEDD96D.6010601@pdp7.org> References: <01db01ca59d4$2804c320$0773a8c0@rossmacbook> <4AEC0C0A.7040008@blueyonder.co.uk> <5B2EBE2A-C010-4D11-94BD-51338850FE98@nuim.ie> <99B2E82E95AE42F79EF287843BF18A7C@DaveUpstairs> <2385BDC6-B628-47DC-80C7-01236EDE1635@audioimagination.com> <948B7ACA-0446-4E45-923D-E2A928C37A7E@silberstein.de> <907277ED-F2A7-4AD6-8DEB-07B1EB45B12E@nuim.ie> <4AEC7791.6000600@pdp7.org> <463E662C-B3B2-47E4-9E83-6D41B22BEBCE@audioimagination.com> <4AEC930C.3050002@pdp7.org> <34DAFEAC-B5BD-4EF2-932B-934809EE888D@audioimagination.com> <4AEDD96D.6010601@pdp7.org> Message-ID: <3BC34908-4323-48E5-8B1F-8E228D6CBD1B@zen.co.uk> Does all this lead to the question whether arrays are a good thing at all? Maybe containers and decent itterators should be the way to go? I know the basic argument against this will be around performance but a decent itterator implementation with offset support should be up to the job I would have thought. On 1 Nov 2009, at 18:54, Thomas Strathmann wrote: > robert bristow-johnson wrote: >> On Oct 31, 2009, at 3:42 PM, Thomas Strathmann wrote: >> >>> Array indexing is a problem, of course. But this problem is not >>> limited >>> to a discussion about Matlab or specific functions implemented in >>> Matlab. A mathematician would probably say, 1 is the first index. A >>> programmer and many computer scientists will probably disagree and >>> declare 0 as the only sensible start index of an array or virtually >>> anything (that has semanttics close to arrays). If one were to allow >>> both conventions to coexist in a language or even move to a notion >>> of >>> encoding the first index of an array and its length in the type, >>> what >>> would happen? Total anarchy? Horribly unreadable programs? >> >> no, the precise opposite. >> >> there is no reason that you cannot make the origin of each dimension >> of an array a property, just like the length of rows and columns of >> an array in MATLAB is a property you can change with reshape(). so, >> similarly to size() and reshape() which inform us and allow us to >> change the length of rows and columns, there could be two utilities >> called origin() and reorigin() (or base() and rebase()) that would >> allow us to know what the value of the lowest index is for each >> dimension and to change it. each new array would have 1 as the >> origin for every dimension. >> >> this would be perfectly backward compatible. only those who use the >> functions origin() and reorigin() would be able to screw this up and >> break their code. > > Exactly the answer I was hoping for. Although, I would not want a > language where the array starting index etc. is just a property of a > datatype in a record-like fashion. This would indeed give rise to the > problem you describe with origin() and reorigin() in the context of > legacy code. Instead, I propose to define a language in which such > properties are part of the type itself such that function signatures > which only take 4x4 matrices or vectors starting at -2 for instance > can be written and the corresponding properties be enforced at > compile time. > >> not only is there a need for us to concisely define arrays with 0 as >> the origin, but sometimes we need negative indices (like to describe >> a non-causal impulse response). it is not just a 0-based vs. 1-based >> issue. it's whether or not you have the freedom to set the base or >> origin of the array to what is natural for the problem that you're >> modeling in MATLAB. that's what the language is for. > > Yes, I also think that it's rather unintuitive that you cannot express > such properties directly in a language that is intended for expressing > numerical algorithms. > >> the very very first toolbox for MATLAB was the Signal Processing >> toolbox. it's the most well established camp. one of the original >> authors of that toolbox, Thomas Krause i think his name was, told me >> that he told them back then (around 1990) that they needed to fix >> this thing and they rejected him. it would be interesting to see how >> things would have been different had they heeded him instead. > > Interesting. I must ask the psycho-accoustic guys here at the > university > if they would consider buying a Matlab upgrade, if this feature was > added. ;-) > > 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 michael.gogins at gmail.com Sun Nov 1 14:38:16 2009 From: michael.gogins at gmail.com (michael.gogins at gmail.com) Date: Sun, 1 Nov 2009 14:38:16 -0500 Subject: [music-dsp] platform choice References: <01db01ca59d4$2804c320$0773a8c0@rossmacbook> <4AEC0C0A.7040008@blueyonder.co.uk> <5B2EBE2A-C010-4D11-94BD-51338850FE98@nuim.ie> <99B2E82E95AE42F79EF287843BF18A7C@DaveUpstairs> <2385BDC6-B628-47DC-80C7-01236EDE1635@audioimagination.com> <948B7ACA-0446-4E45-923D-E2A928C37A7E@silberstein.de> <907277ED-F2A7-4AD6-8DEB-07B1EB45B12E@nuim.ie> <4AEC7791.6000600@pdp7.org> <463E662C-B3B2-47E4-9E83-6D41B22BEBCE@audioimagination.com> <4AEC930C.3050002@pdp7.org><34DAFEAC-B5BD-4EF2-932B-934809EE888D@audioimagination.com><4AEDD96D.6010601@pdp7.org> <3BC34908-4323-48E5-8B1F-8E228D6CBD1B@zen.co.uk> Message-ID: <45CCCC7CB1C5434BAA77829196B8EE5F@toshibauser> If you examine assembler for std::vector iterators, poiner arithmetic, and array index iteration you will find them very similar, almost identical. Compilers do this. The designers of the std library undertsood what that would be. Regards, Mike ----- Original Message ----- From: "Andrew Capon" To: "A discussion list for music-related DSP" Sent: Sunday, November 01, 2009 2:00 PM Subject: Re: [music-dsp] platform choice > Does all this lead to the question whether arrays are a good thing at > all? > > Maybe containers and decent itterators should be the way to go? > > I know the basic argument against this will be around performance but > a decent itterator implementation with offset support should be up to > the job I would have thought. > > > > On 1 Nov 2009, at 18:54, Thomas Strathmann wrote: > >> robert bristow-johnson wrote: >>> On Oct 31, 2009, at 3:42 PM, Thomas Strathmann wrote: >>> >>>> Array indexing is a problem, of course. But this problem is not >>>> limited >>>> to a discussion about Matlab or specific functions implemented in >>>> Matlab. A mathematician would probably say, 1 is the first index. A >>>> programmer and many computer scientists will probably disagree and >>>> declare 0 as the only sensible start index of an array or virtually >>>> anything (that has semanttics close to arrays). If one were to allow >>>> both conventions to coexist in a language or even move to a notion >>>> of >>>> encoding the first index of an array and its length in the type, >>>> what >>>> would happen? Total anarchy? Horribly unreadable programs? >>> >>> no, the precise opposite. >>> >>> there is no reason that you cannot make the origin of each dimension >>> of an array a property, just like the length of rows and columns of >>> an array in MATLAB is a property you can change with reshape(). so, >>> similarly to size() and reshape() which inform us and allow us to >>> change the length of rows and columns, there could be two utilities >>> called origin() and reorigin() (or base() and rebase()) that would >>> allow us to know what the value of the lowest index is for each >>> dimension and to change it. each new array would have 1 as the >>> origin for every dimension. >>> >>> this would be perfectly backward compatible. only those who use the >>> functions origin() and reorigin() would be able to screw this up and >>> break their code. >> >> Exactly the answer I was hoping for. Although, I would not want a >> language where the array starting index etc. is just a property of a >> datatype in a record-like fashion. This would indeed give rise to the >> problem you describe with origin() and reorigin() in the context of >> legacy code. Instead, I propose to define a language in which such >> properties are part of the type itself such that function signatures >> which only take 4x4 matrices or vectors starting at -2 for instance >> can be written and the corresponding properties be enforced at >> compile time. >> >>> not only is there a need for us to concisely define arrays with 0 as >>> the origin, but sometimes we need negative indices (like to describe >>> a non-causal impulse response). it is not just a 0-based vs. 1-based >>> issue. it's whether or not you have the freedom to set the base or >>> origin of the array to what is natural for the problem that you're >>> modeling in MATLAB. that's what the language is for. >> >> Yes, I also think that it's rather unintuitive that you cannot express >> such properties directly in a language that is intended for expressing >> numerical algorithms. >> >>> the very very first toolbox for MATLAB was the Signal Processing >>> toolbox. it's the most well established camp. one of the original >>> authors of that toolbox, Thomas Krause i think his name was, told me >>> that he told them back then (around 1990) that they needed to fix >>> this thing and they rejected him. it would be interesting to see how >>> things would have been different had they heeded him instead. >> >> Interesting. I must ask the psycho-accoustic guys here at the >> university >> if they would consider buying a Matlab upgrade, if this feature was >> added. ;-) >> >> 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 > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From andrew.capon at zen.co.uk Sun Nov 1 14:40:37 2009 From: andrew.capon at zen.co.uk (Andrew Capon) Date: Sun, 1 Nov 2009 19:40:37 +0000 Subject: [music-dsp] platform choice In-Reply-To: <45CCCC7CB1C5434BAA77829196B8EE5F@toshibauser> References: <01db01ca59d4$2804c320$0773a8c0@rossmacbook> <4AEC0C0A.7040008@blueyonder.co.uk> <5B2EBE2A-C010-4D11-94BD-51338850FE98@nuim.ie> <99B2E82E95AE42F79EF287843BF18A7C@DaveUpstairs> <2385BDC6-B628-47DC-80C7-01236EDE1635@audioimagination.com> <948B7ACA-0446-4E45-923D-E2A928C37A7E@silberstein.de> <907277ED-F2A7-4AD6-8DEB-07B1EB45B12E@nuim.ie> <4AEC7791.6000600@pdp7.org> <463E662C-B3B2-47E4-9E83-6D41B22BEBCE@audioimagination.com> <4AEC930C.3050002@pdp7.org><34DAFEAC-B5BD-4EF2-932B-934809EE888D@audioimagination.com><4AEDD96D.6010601@pdp7.org> <3BC34908-4323-48E5-8B1F-8E228D6CBD1B@zen.co.uk> <45CCCC7CB1C5434BA! A77829196B8EE5F@toshibauser> Message-ID: So why do people use arrays? On 1 Nov 2009, at 19:38, michael.gogins at gmail.com wrote: > If you examine assembler for std::vector iterators, poiner > arithmetic, and > array index iteration you will find them very similar, almost > identical. > > Compilers do this. The designers of the std library undertsood what > that > would be. > > Regards, > Mike > > ----- Original Message ----- > From: "Andrew Capon" > To: "A discussion list for music-related DSP" > > Sent: Sunday, November 01, 2009 2:00 PM > Subject: Re: [music-dsp] platform choice > > >> Does all this lead to the question whether arrays are a good thing at >> all? >> >> Maybe containers and decent itterators should be the way to go? >> >> I know the basic argument against this will be around performance but >> a decent itterator implementation with offset support should be up to >> the job I would have thought. >> >> >> >> On 1 Nov 2009, at 18:54, Thomas Strathmann wrote: >> >>> robert bristow-johnson wrote: >>>> On Oct 31, 2009, at 3:42 PM, Thomas Strathmann wrote: >>>> >>>>> Array indexing is a problem, of course. But this problem is not >>>>> limited >>>>> to a discussion about Matlab or specific functions implemented in >>>>> Matlab. A mathematician would probably say, 1 is the first >>>>> index. A >>>>> programmer and many computer scientists will probably disagree and >>>>> declare 0 as the only sensible start index of an array or >>>>> virtually >>>>> anything (that has semanttics close to arrays). If one were to >>>>> allow >>>>> both conventions to coexist in a language or even move to a notion >>>>> of >>>>> encoding the first index of an array and its length in the type, >>>>> what >>>>> would happen? Total anarchy? Horribly unreadable programs? >>>> >>>> no, the precise opposite. >>>> >>>> there is no reason that you cannot make the origin of each >>>> dimension >>>> of an array a property, just like the length of rows and columns of >>>> an array in MATLAB is a property you can change with reshape(). >>>> so, >>>> similarly to size() and reshape() which inform us and allow us to >>>> change the length of rows and columns, there could be two utilities >>>> called origin() and reorigin() (or base() and rebase()) that would >>>> allow us to know what the value of the lowest index is for each >>>> dimension and to change it. each new array would have 1 as the >>>> origin for every dimension. >>>> >>>> this would be perfectly backward compatible. only those who use >>>> the >>>> functions origin() and reorigin() would be able to screw this up >>>> and >>>> break their code. >>> >>> Exactly the answer I was hoping for. Although, I would not want a >>> language where the array starting index etc. is just a property of a >>> datatype in a record-like fashion. This would indeed give rise to >>> the >>> problem you describe with origin() and reorigin() in the context of >>> legacy code. Instead, I propose to define a language in which such >>> properties are part of the type itself such that function signatures >>> which only take 4x4 matrices or vectors starting at -2 for instance >>> can be written and the corresponding properties be enforced at >>> compile time. >>> >>>> not only is there a need for us to concisely define arrays with 0 >>>> as >>>> the origin, but sometimes we need negative indices (like to >>>> describe >>>> a non-causal impulse response). it is not just a 0-based vs. 1- >>>> based >>>> issue. it's whether or not you have the freedom to set the base or >>>> origin of the array to what is natural for the problem that you're >>>> modeling in MATLAB. that's what the language is for. >>> >>> Yes, I also think that it's rather unintuitive that you cannot >>> express >>> such properties directly in a language that is intended for >>> expressing >>> numerical algorithms. >>> >>>> the very very first toolbox for MATLAB was the Signal Processing >>>> toolbox. it's the most well established camp. one of the original >>>> authors of that toolbox, Thomas Krause i think his name was, told >>>> me >>>> that he told them back then (around 1990) that they needed to fix >>>> this thing and they rejected him. it would be interesting to see >>>> how >>>> things would have been different had they heeded him instead. >>> >>> Interesting. I must ask the psycho-accoustic guys here at the >>> university >>> if they would consider buying a Matlab upgrade, if this feature was >>> added. ;-) >>> >>> 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 >> >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, 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 michael.gogins at gmail.com Sun Nov 1 15:09:10 2009 From: michael.gogins at gmail.com (michael.gogins at gmail.com) Date: Sun, 1 Nov 2009 15:09:10 -0500 Subject: [music-dsp] platform choice References: A77829196B8EE5F@toshibauser> Message-ID: <44C3A2C79CEE4253A4E22E25B1AFC277@toshibauser> Arrays are easier to read. This is important. Regards, Mike ----- Original Message ----- From: "Andrew Capon" To: "A discussion list for music-related DSP" Sent: Sunday, November 01, 2009 2:40 PM Subject: Re: [music-dsp] platform choice > So why do people use arrays? > > On 1 Nov 2009, at 19:38, michael.gogins at gmail.com wrote: > >> If you examine assembler for std::vector iterators, poiner >> arithmetic, and >> array index iteration you will find them very similar, almost >> identical. >> >> Compilers do this. The designers of the std library undertsood what >> that >> would be. >> >> Regards, >> Mike >> >> ----- Original Message ----- >> From: "Andrew Capon" >> To: "A discussion list for music-related DSP" >> > > >> Sent: Sunday, November 01, 2009 2:00 PM >> Subject: Re: [music-dsp] platform choice >> >> >>> Does all this lead to the question whether arrays are a good thing at >>> all? >>> >>> Maybe containers and decent itterators should be the way to go? >>> >>> I know the basic argument against this will be around performance but >>> a decent itterator implementation with offset support should be up to >>> the job I would have thought. >>> >>> >>> >>> On 1 Nov 2009, at 18:54, Thomas Strathmann wrote: >>> >>>> robert bristow-johnson wrote: >>>>> On Oct 31, 2009, at 3:42 PM, Thomas Strathmann wrote: >>>>> >>>>>> Array indexing is a problem, of course. But this problem is not >>>>>> limited >>>>>> to a discussion about Matlab or specific functions implemented in >>>>>> Matlab. A mathematician would probably say, 1 is the first >>>>>> index. A >>>>>> programmer and many computer scientists will probably disagree and >>>>>> declare 0 as the only sensible start index of an array or >>>>>> virtually >>>>>> anything (that has semanttics close to arrays). If one were to >>>>>> allow >>>>>> both conventions to coexist in a language or even move to a notion >>>>>> of >>>>>> encoding the first index of an array and its length in the type, >>>>>> what >>>>>> would happen? Total anarchy? Horribly unreadable programs? >>>>> >>>>> no, the precise opposite. >>>>> >>>>> there is no reason that you cannot make the origin of each >>>>> dimension >>>>> of an array a property, just like the length of rows and columns of >>>>> an array in MATLAB is a property you can change with reshape(). >>>>> so, >>>>> similarly to size() and reshape() which inform us and allow us to >>>>> change the length of rows and columns, there could be two utilities >>>>> called origin() and reorigin() (or base() and rebase()) that would >>>>> allow us to know what the value of the lowest index is for each >>>>> dimension and to change it. each new array would have 1 as the >>>>> origin for every dimension. >>>>> >>>>> this would be perfectly backward compatible. only those who use >>>>> the >>>>> functions origin() and reorigin() would be able to screw this up >>>>> and >>>>> break their code. >>>> >>>> Exactly the answer I was hoping for. Although, I would not want a >>>> language where the array starting index etc. is just a property of a >>>> datatype in a record-like fashion. This would indeed give rise to >>>> the >>>> problem you describe with origin() and reorigin() in the context of >>>> legacy code. Instead, I propose to define a language in which such >>>> properties are part of the type itself such that function signatures >>>> which only take 4x4 matrices or vectors starting at -2 for instance >>>> can be written and the corresponding properties be enforced at >>>> compile time. >>>> >>>>> not only is there a need for us to concisely define arrays with 0 >>>>> as >>>>> the origin, but sometimes we need negative indices (like to >>>>> describe >>>>> a non-causal impulse response). it is not just a 0-based vs. 1- >>>>> based >>>>> issue. it's whether or not you have the freedom to set the base or >>>>> origin of the array to what is natural for the problem that you're >>>>> modeling in MATLAB. that's what the language is for. >>>> >>>> Yes, I also think that it's rather unintuitive that you cannot >>>> express >>>> such properties directly in a language that is intended for >>>> expressing >>>> numerical algorithms. >>>> >>>>> the very very first toolbox for MATLAB was the Signal Processing >>>>> toolbox. it's the most well established camp. one of the original >>>>> authors of that toolbox, Thomas Krause i think his name was, told >>>>> me >>>>> that he told them back then (around 1990) that they needed to fix >>>>> this thing and they rejected him. it would be interesting to see >>>>> how >>>>> things would have been different had they heeded him instead. >>>> >>>> Interesting. I must ask the psycho-accoustic guys here at the >>>> university >>>> if they would consider buying a Matlab upgrade, if this feature was >>>> added. ;-) >>>> >>>> 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 >>> >>> -- >>> dupswapdrop -- the music-dsp mailing list and website: >>> subscription info, FAQ, 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 andrew.capon at zen.co.uk Sun Nov 1 15:59:32 2009 From: andrew.capon at zen.co.uk (Andrew Capon) Date: Sun, 1 Nov 2009 20:59:32 +0000 Subject: [music-dsp] platform choice In-Reply-To: <44C3A2C79CEE4253A4E22E25B1AFC277@toshibauser> References: A77829196B8EE5F@toshibauser> <44C3A2C79CEE4253A4E22E25B1AFC277@toshibauser> Message-ID: I must admit I don't see this being true for the majority of cases. Maybe DSP guys/girls just like arrays. Cheers Andy On 1 Nov 2009, at 20:09, michael.gogins at gmail.com wrote: > Arrays are easier to read. This is important. > > Regards, > Mike > > ----- Original Message ----- > From: "Andrew Capon" > To: "A discussion list for music-related DSP" > > Sent: Sunday, November 01, 2009 2:40 PM > Subject: Re: [music-dsp] platform choice > > >> So why do people use arrays? >> >> On 1 Nov 2009, at 19:38, michael.gogins at gmail.com wrote: >> >>> If you examine assembler for std::vector iterators, poiner >>> arithmetic, and >>> array index iteration you will find them very similar, almost >>> identical. >>> >>> Compilers do this. The designers of the std library undertsood what >>> that >>> would be. >>> >>> Regards, >>> Mike >>> >>> ----- Original Message ----- >>> From: "Andrew Capon" >>> To: "A discussion list for music-related DSP" >>> >>> >>> Sent: Sunday, November 01, 2009 2:00 PM >>> Subject: Re: [music-dsp] platform choice >>> >>> >>>> Does all this lead to the question whether arrays are a good >>>> thing at >>>> all? >>>> >>>> Maybe containers and decent itterators should be the way to go? >>>> >>>> I know the basic argument against this will be around performance >>>> but >>>> a decent itterator implementation with offset support should be >>>> up to >>>> the job I would have thought. >>>> >>>> >>>> >>>> On 1 Nov 2009, at 18:54, Thomas Strathmann wrote: >>>> >>>>> robert bristow-johnson wrote: >>>>>> On Oct 31, 2009, at 3:42 PM, Thomas Strathmann wrote: >>>>>> >>>>>>> Array indexing is a problem, of course. But this problem is not >>>>>>> limited >>>>>>> to a discussion about Matlab or specific functions implemented >>>>>>> in >>>>>>> Matlab. A mathematician would probably say, 1 is the first >>>>>>> index. A >>>>>>> programmer and many computer scientists will probably disagree >>>>>>> and >>>>>>> declare 0 as the only sensible start index of an array or >>>>>>> virtually >>>>>>> anything (that has semanttics close to arrays). If one were to >>>>>>> allow >>>>>>> both conventions to coexist in a language or even move to a >>>>>>> notion >>>>>>> of >>>>>>> encoding the first index of an array and its length in the type, >>>>>>> what >>>>>>> would happen? Total anarchy? Horribly unreadable programs? >>>>>> >>>>>> no, the precise opposite. >>>>>> >>>>>> there is no reason that you cannot make the origin of each >>>>>> dimension >>>>>> of an array a property, just like the length of rows and >>>>>> columns of >>>>>> an array in MATLAB is a property you can change with reshape(). >>>>>> so, >>>>>> similarly to size() and reshape() which inform us and allow us to >>>>>> change the length of rows and columns, there could be two >>>>>> utilities >>>>>> called origin() and reorigin() (or base() and rebase()) that >>>>>> would >>>>>> allow us to know what the value of the lowest index is for each >>>>>> dimension and to change it. each new array would have 1 as the >>>>>> origin for every dimension. >>>>>> >>>>>> this would be perfectly backward compatible. only those who use >>>>>> the >>>>>> functions origin() and reorigin() would be able to screw this up >>>>>> and >>>>>> break their code. >>>>> >>>>> Exactly the answer I was hoping for. Although, I would not want a >>>>> language where the array starting index etc. is just a property >>>>> of a >>>>> datatype in a record-like fashion. This would indeed give rise to >>>>> the >>>>> problem you describe with origin() and reorigin() in the context >>>>> of >>>>> legacy code. Instead, I propose to define a language in which such >>>>> properties are part of the type itself such that function >>>>> signatures >>>>> which only take 4x4 matrices or vectors starting at -2 for >>>>> instance >>>>> can be written and the corresponding properties be enforced at >>>>> compile time. >>>>> >>>>>> not only is there a need for us to concisely define arrays with 0 >>>>>> as >>>>>> the origin, but sometimes we need negative indices (like to >>>>>> describe >>>>>> a non-causal impulse response). it is not just a 0-based vs. 1- >>>>>> based >>>>>> issue. it's whether or not you have the freedom to set the >>>>>> base or >>>>>> origin of the array to what is natural for the problem that >>>>>> you're >>>>>> modeling in MATLAB. that's what the language is for. >>>>> >>>>> Yes, I also think that it's rather unintuitive that you cannot >>>>> express >>>>> such properties directly in a language that is intended for >>>>> expressing >>>>> numerical algorithms. >>>>> >>>>>> the very very first toolbox for MATLAB was the Signal Processing >>>>>> toolbox. it's the most well established camp. one of the >>>>>> original >>>>>> authors of that toolbox, Thomas Krause i think his name was, told >>>>>> me >>>>>> that he told them back then (around 1990) that they needed to fix >>>>>> this thing and they rejected him. it would be interesting to see >>>>>> how >>>>>> things would have been different had they heeded him instead. >>>>> >>>>> Interesting. I must ask the psycho-accoustic guys here at the >>>>> university >>>>> if they would consider buying a Matlab upgrade, if this feature >>>>> was >>>>> added. ;-) >>>>> >>>>> 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 >>>> >>>> -- >>>> dupswapdrop -- the music-dsp mailing list and website: >>>> subscription info, FAQ, 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 >> > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, 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 Nov 1 16:05:32 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sun, 1 Nov 2009 16:05:32 -0500 Subject: [music-dsp] platform choice In-Reply-To: References: A77829196B8EE5F@toshibauser> <44C3A2C79CEE4253A4E22E25B1AFC277@toshibauser> Message-ID: oh, c'mon. a matrix equation like A = B*C or C = B\A is harder to read in the majority of cases than the code necessary to compute every element of these arrays? r b-j On Nov 1, 2009, at 3:59 PM, Andrew Capon wrote: > I must admit I don't see this being true for the majority of cases. > > Maybe DSP guys/girls just like arrays. > > Cheers > > Andy > > On 1 Nov 2009, at 20:09, michael.gogins at gmail.com wrote: > >> Arrays are easier to read. This is important. >> >> Regards, >> Mike >> >> ----- Original Message ----- >> From: "Andrew Capon" >> To: "A discussion list for music-related DSP" > dsp at music.columbia.edu >>> >> Sent: Sunday, November 01, 2009 2:40 PM >> Subject: Re: [music-dsp] platform choice >> >> >>> So why do people use arrays? >>> From music.maker at gte.net Sun Nov 1 15:11:28 2009 From: music.maker at gte.net (Scott Gravenhorst) Date: Sun, 01 Nov 2009 13:11:28 -0700 Subject: [music-dsp] platform choice Message-ID: <200911012111.nA1LBSSY000346@linux7.lan> A discussion list for music-related DSP wrote: >I must admit I don't see this being true for the majority of cases. > >Maybe DSP guys/girls just like arrays. > >Cheers > >Andy IMO, because it's a simple, predictable, useful basic data organization structure. Also IMO, it can model many things as it is. >On 1 Nov 2009, at 20:09, michael.gogins at gmail.com wrote: > >> Arrays are easier to read. This is important. >> >> Regards, >> Mike >> >> ----- Original Message ----- >> From: "Andrew Capon" >> To: "A discussion list for music-related DSP" > > >> Sent: Sunday, November 01, 2009 2:40 PM >> Subject: Re: [music-dsp] platform choice >> >> >>> So why do people use arrays? >>> >>> On 1 Nov 2009, at 19:38, michael.gogins at gmail.com wrote: >>> >>>> If you examine assembler for std::vector iterators, poiner >>>> arithmetic, and >>>> array index iteration you will find them very similar, almost >>>> identical. >>>> >>>> Compilers do this. The designers of the std library undertsood what >>>> that >>>> would be. >>>> >>>> Regards, >>>> Mike >>>> >>>> ----- Original Message ----- >>>> From: "Andrew Capon" >>>> To: "A discussion list for music-related DSP" >>>> >>>> >>>> Sent: Sunday, November 01, 2009 2:00 PM >>>> Subject: Re: [music-dsp] platform choice >>>> >>>> >>>>> Does all this lead to the question whether arrays are a good >>>>> thing at >>>>> all? >>>>> >>>>> Maybe containers and decent itterators should be the way to go? >>>>> >>>>> I know the basic argument against this will be around performance >>>>> but >>>>> a decent itterator implementation with offset support should be >>>>> up to >>>>> the job I would have thought. >>>>> >>>>> >>>>> >>>>> On 1 Nov 2009, at 18:54, Thomas Strathmann wrote: >>>>> >>>>>> robert bristow-johnson wrote: >>>>>>> On Oct 31, 2009, at 3:42 PM, Thomas Strathmann wrote: >>>>>>> >>>>>>>> Array indexing is a problem, of course. But this problem is not >>>>>>>> limited >>>>>>>> to a discussion about Matlab or specific functions implemented >>>>>>>> in >>>>>>>> Matlab. A mathematician would probably say, 1 is the first >>>>>>>> index. A >>>>>>>> programmer and many computer scientists will probably disagree >>>>>>>> and >>>>>>>> declare 0 as the only sensible start index of an array or >>>>>>>> virtually >>>>>>>> anything (that has semanttics close to arrays). If one were to >>>>>>>> allow >>>>>>>> both conventions to coexist in a language or even move to a >>>>>>>> notion >>>>>>>> of >>>>>>>> encoding the first index of an array and its length in the type, >>>>>>>> what >>>>>>>> would happen? Total anarchy? Horribly unreadable programs? >>>>>>> >>>>>>> no, the precise opposite. >>>>>>> >>>>>>> there is no reason that you cannot make the origin of each >>>>>>> dimension >>>>>>> of an array a property, just like the length of rows and >>>>>>> columns of >>>>>>> an array in MATLAB is a property you can change with reshape(). >>>>>>> so, >>>>>>> similarly to size() and reshape() which inform us and allow us to >>>>>>> change the length of rows and columns, there could be two >>>>>>> utilities >>>>>>> called origin() and reorigin() (or base() and rebase()) that >>>>>>> would >>>>>>> allow us to know what the value of the lowest index is for each >>>>>>> dimension and to change it. each new array would have 1 as the >>>>>>> origin for every dimension. >>>>>>> >>>>>>> this would be perfectly backward compatible. only those who use >>>>>>> the >>>>>>> functions origin() and reorigin() would be able to screw this up >>>>>>> and >>>>>>> break their code. >>>>>> >>>>>> Exactly the answer I was hoping for. Although, I would not want a >>>>>> language where the array starting index etc. is just a property >>>>>> of a >>>>>> datatype in a record-like fashion. This would indeed give rise to >>>>>> the >>>>>> problem you describe with origin() and reorigin() in the context >>>>>> of >>>>>> legacy code. Instead, I propose to define a language in which such >>>>>> properties are part of the type itself such that function >>>>>> signatures >>>>>> which only take 4x4 matrices or vectors starting at -2 for >>>>>> instance >>>>>> can be written and the corresponding properties be enforced at >>>>>> compile time. >>>>>> >>>>>>> not only is there a need for us to concisely define arrays with 0 >>>>>>> as >>>>>>> the origin, but sometimes we need negative indices (like to >>>>>>> describe >>>>>>> a non-causal impulse response). it is not just a 0-based vs. 1- >>>>>>> based >>>>>>> issue. it's whether or not you have the freedom to set the >>>>>>> base or >>>>>>> origin of the array to what is natural for the problem that >>>>>>> you're >>>>>>> modeling in MATLAB. that's what the language is for. >>>>>> >>>>>> Yes, I also think that it's rather unintuitive that you cannot >>>>>> express >>>>>> such properties directly in a language that is intended for >>>>>> expressing >>>>>> numerical algorithms. >>>>>> >>>>>>> the very very first toolbox for MATLAB was the Signal Processing >>>>>>> toolbox. it's the most well established camp. one of the >>>>>>> original >>>>>>> authors of that toolbox, Thomas Krause i think his name was, told >>>>>>> me >>>>>>> that he told them back then (around 1990) that they needed to fix >>>>>>> this thing and they rejected him. it would be interesting to see >>>>>>> how >>>>>>> things would have been different had they heeded him instead. >>>>>> >>>>>> Interesting. I must ask the psycho-accoustic guys here at the >>>>>> university >>>>>> if they would consider buying a Matlab upgrade, if this feature >>>>>> was >>>>>> added. ;-) >>>>>> >>>>>> 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 >>>>> >>>>> -- >>>>> dupswapdrop -- the music-dsp mailing list and website: >>>>> subscription info, FAQ, 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 >>> >> >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, source code archive, list archive, book >> reviews, dsp links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp > >-- >dupswapdrop -- the music-dsp mailing list and website: >subscription info, FAQ, source code archive, list archive, book reviews, dsp links >http://music.columbia.edu/cmc/music-dsp >http://music.columbia.edu/mailman/listinfo/music-dsp > -- ScottG ________________________________________________________________________ -- Scott Gravenhorst -- FPGA MIDI Synthesizer Information: home1.gte.net/res0658s/FPGA_synth/ -- FatMan: home1.gte.net/res0658s/fatman/ -- NonFatMan: home1.gte.net/res0658s/electronics/ -- When the going gets tough, the tough use the command line. From michael.gogins at gmail.com Sun Nov 1 16:18:38 2009 From: michael.gogins at gmail.com (michael.gogins at gmail.com) Date: Sun, 1 Nov 2009 16:18:38 -0500 Subject: [music-dsp] platform choice References: A77829196B8EE5F@toshibauser><44C3A2C79CEE4253A4E22E25B1AFC277@toshibauser> Message-ID: <6949D7F279B7421398B24777A004D901@toshibauser> You a right. I meant: c[i] = a[i] + b[i]; is easier to read than: *c++ = *a++ + *b++; I don't see any iterators in A = B*C, though. Regards, Mike ----- Original Message ----- From: "robert bristow-johnson" To: "A discussion list for music-related DSP" Sent: Sunday, November 01, 2009 4:05 PM Subject: Re: [music-dsp] platform choice > > oh, c'mon. a matrix equation like A = B*C or C = B\A is harder to > read in the majority of cases than the code necessary to compute > every element of these arrays? > > r b-j > > On Nov 1, 2009, at 3:59 PM, Andrew Capon wrote: > >> I must admit I don't see this being true for the majority of cases. >> >> Maybe DSP guys/girls just like arrays. >> >> Cheers >> >> Andy >> >> On 1 Nov 2009, at 20:09, michael.gogins at gmail.com wrote: >> >>> Arrays are easier to read. This is important. >>> >>> Regards, >>> Mike >>> >>> ----- Original Message ----- >>> From: "Andrew Capon" >>> To: "A discussion list for music-related DSP" >> dsp at music.columbia.edu >>>> >>> Sent: Sunday, November 01, 2009 2:40 PM >>> Subject: Re: [music-dsp] platform choice >>> >>> >>>> So why do people use arrays? >>>> > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, 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 cournape at gmail.com Sun Nov 1 22:05:14 2009 From: cournape at gmail.com (David Cournapeau) Date: Mon, 2 Nov 2009 12:05:14 +0900 Subject: [music-dsp] platform choice In-Reply-To: References: <948B7ACA-0446-4E45-923D-E2A928C37A7E@silberstein.de> <907277ED-F2A7-4AD6-8DEB-07B1EB45B12E@nuim.ie> <4AEC7791.6000600@pdp7.org> <463E662C-B3B2-47E4-9E83-6D41B22BEBCE@audioimagination.com> <4AEC930C.3050002@pdp7.org> <5EB704BFD6B940A188918AE971EA1974@GOLAMD> Message-ID: <5b8d13220911011905p11a3787dsf29b1bae6d9ea96c@mail.gmail.com> On Sun, Nov 1, 2009 at 6:06 AM, Victor Lazzarini wrote: > Of course, you can create a C++ template to do this > (I am not sure there is one in STL, but there might be). > > The question is why, since 0-indexing makes much more > sense. It is really nothing more than a convention. In matlab's case, it is almost certainly a historical consequence of the fortran heritage (matlab was born 30 years ago as a 'shell' around the LINPACK/EIPACK libraries - now LAPACK). Fortran indexing starts at 1, and Fortran is arguably a better language for serious scientific work compared to C or C++, as none of those have decent linear algebra support. It is interesting to note that R is somewhat worse than matlab, as indexing starts at 1, but getting 0 index does not fail (http://radfordneal.wordpress.com/2008/09/21/design-flaws-in-r-3-%E2%80%94-zero-subscripts/). I don't think 1 vs 0 for indexing matters much while you stay in one convention - converting between both can be a pain. What matters is the indexing capabilities: negative indexing, strides, etc... This is much harder to get right than most people thiny, though. In numpy (a core array package for python), we have quite a few goodies compared to matlab (in particular w.r.t. to automatic broadcasting for linear algebra), but still no feature such as index starting at a negative index, although you could fake it through a wrapper (but it would be slower I think). I guess a signal class with signal-oriented features would make sense (the advantage of python over matlab is that the array object is an instance of a real class, and can be subclassed). LastWave has a nice feature for fractional indexing (interpreted as interpolation): http://www.cmap.polytechnique.fr/~bacry/LastWave/packages/signal/signal.html Speaking of stupid conventions, I am much more bothered by the normalized frequency being 2 and Nyquist frequency being 1 in matlab :) David From rbj at audioimagination.com Sun Nov 1 22:36:12 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sun, 1 Nov 2009 22:36:12 -0500 Subject: [music-dsp] platform choice In-Reply-To: <5b8d13220911011905p11a3787dsf29b1bae6d9ea96c@mail.gmail.com> References: <948B7ACA-0446-4E45-923D-E2A928C37A7E@silberstein.de> <907277ED-F2A7-4AD6-8DEB-07B1EB45B12E@nuim.ie> <4AEC7791.6000600@pdp7.org> <463E662C-B3B2-47E4-9E83-6D41B22BEBCE@audioimagination.com> <4AEC930C.3050002@pdp7.org> <5EB704BFD6B940A188918AE971EA1974@GOLAMD> <5b8d13220911011905p11a3787dsf29b1bae6d9ea96c@mail.gmail.com> Message-ID: <84C39CF7-2220-4636-9CB7-FCBD9AD5407D@audioimagination.com> On Nov 1, 2009, at 10:05 PM, David Cournapeau wrote: > On Sun, Nov 1, 2009 at 6:06 AM, Victor Lazzarini > wrote: >> Of course, you can create a C++ template to do this >> (I am not sure there is one in STL, but there might be). >> >> The question is why, since 0-indexing makes much more >> sense. > > It is really nothing more than a convention. i disagree with the premise. conventions matter. and not all conventions are of equal value. why don't we just define a convention that offsets every index by 9? it's really nothing more than a convention. (sorry, not trying to pick a fight. that's what comp.dsp is for. :-) > In matlab's case, it is > almost certainly a historical consequence of the fortran heritage and also the common convention of matrices you'll see in nearly any linear algebra or matrix theory text. but that's probably where Fortran got it. > (matlab was born 30 years ago as a 'shell' around the LINPACK/EIPACK > libraries - now LAPACK). Fortran indexing starts at 1, and Fortran is > arguably a better language for serious scientific work compared to > C or > C++, as none of those have decent linear algebra support. no. only because of some old libraries that might still not be ported over. well, C does not have a native "complex" type and has no operator overloading. i've never been real good at C++ and a long time ago i wrote my own complex lib in C so i could combine and manipulate frequency response expressions in C. it looked more like lisp than C. with the complex class in C++, i don't know any other reason than existing libraries why Fortran would be better than C++ (except to those engineers who grew up with Fortran). but there could be something i am missing. BTW, Fortran 4 was the very first programming language i learned (back in the punch-card daze of the early/mid 70s). > It is interesting to note that R is somewhat worse than matlab, as > indexing starts at 1, but getting 0 index does not fail > (http://radfordneal.wordpress.com/2008/09/21/design-flaws-in-r-3-% > E2%80%94-zero-subscripts/). someone (i can't remember who) who knew of my indexing diatribe against MATLAB, suggested that i propose to the R folks to fix R while it was still early in its development. i think this person made such a proposal and caught no supporters in the R group. i'm glad i didn't get involved. > I don't think 1 vs 0 for indexing matters much while you stay in one > convention it is clearly inferior to define the Discrete Fourier Transform as: N X[k] = SUM{ x[n] exp(i*2*pi*(n-1)*(k-1)/N) } n=1 that *can't* be as good as the definition common in the lit. > - converting between both can be a pain. who is converting. they're making us convert equations that are well established in the literature to fit their sorry-assed convention. they're making us *remember* to always subtract 1 from the index when using max() or some other search (like find()) that returns an index. this is common in a phase vocoder or most any frequency- domain manipulation. when you do it in MATLAB or Octave and you forget to subtract the 1, you get errors. but the step of subtracting 1 is not in the algorithm description in the lit. i am still astonished that, especially in these circles (people that might very likely be doing vocoding or some other frequency-domain processing) that the two "mere" conventions would be seen as equally useful or elegant. > What matters is the indexing capabilities: > negative indexing, MATLAB doesn't do that. i wish it could and then 0 would just be one of the commonly used special cases. > strides, etc... there's a notation i think you can use in MATLAB to do a dot=product with a stride in one of the vectors. > This is much harder to get right > than most people thiny, though. In numpy (a core array package for > python), we have quite a few goodies compared to matlab (in particular > w.r.t. to automatic broadcasting for linear algebra), but still no > feature such as index starting at a negative index, although you could > fake it through a wrapper (but it would be slower I think). I guess a > signal class with signal-oriented features would make sense (the > advantage of python over matlab is that the array object is an > instance of a real class, and can be subclassed). i met a couple of python proponents. i just don't want to have to learn another language unless i become convinced that it is necessary and the new language has lasting promise. > LastWave has a nice feature for fractional indexing (interpreted as > interpolation): > http://www.cmap.polytechnique.fr/~bacry/LastWave/packages/signal/ > signal.html that's kinda cool, but we *know* that there is much additional processing to do the interpoation. and there are parameters: how is the interpolation being done? Lagrange? Hermite? some windowed sinc () function? how far out does the interpolation kernel reach? you would need meaningful and good enough initial settings for that and maybe allow the user to adjust it. > Speaking of stupid conventions, I am much more bothered by the > normalized frequency being 2 and Nyquist frequency being 1 in > matlab :) yup. that sucks too. another is their polyfit() and polyval() run the indices of the polynomial coefs backwards, in my opinion. but it's an issue with their functions and you can redefine functions. this "all indices are positive integers" thing is worse, because you *can't* fix it. they have to fix it and they do not recognize that it *is* anything that needs fixing. L8r, -- r b-j rbj at audioimagination.com "Imagination is more important than knowledge." From contact at quikquak.com Sun Nov 1 23:07:30 2009 From: contact at quikquak.com (contact) Date: Mon, 2 Nov 2009 04:07:30 -0000 Subject: [music-dsp] platform choice References: <948B7ACA-0446-4E45-923D-E2A928C37A7E@silberstein.de><907277ED-F2A7-4AD6-8DEB-07B1EB45B12E@nuim.ie><4AEC7791.6000600@pdp7.org><463E662C-B3B2-47E4-9E83-6D41B22BEBCE@audioimagination.com><4AEC930C.3050002@pdp7.org><5EB704BFD6B940A188918AE971EA1974@GOLAMD><5b8d13220911011905p11a3787dsf29b1bae6d9ea96c@mail.gmail.com> <84C39CF7-2220-4636-9CB7-FCBD9AD5407D@audioimagination.com> Message-ID: Discussions like this are really interesting in revealing commercial package's faults; software's inherent in-breeding and bloat through sales incentives and years of building, coupled with the frustrations of people that use them. But I like side swipes (and Fourier's ideals), so in a not too serious a manner, and as you would expect from me: Computers go: 0001111110001010101101010101010011011111010101110000001 (yes, random typing) Which 'high level' language do you want to use for DSP? None. BTW, will someone tell that DNA crowd of scientists that reducing life to four symbols is not quite there yet? Try two. ; ) Yeah I know, I'll get my jacket. Dave H. ----- Original Message ----- From: "robert bristow-johnson" To: "A discussion list for music-related DSP" Sent: Monday, November 02, 2009 3:36 AM Subject: Re: [music-dsp] platform choice > > On Nov 1, 2009, at 10:05 PM, David Cournapeau wrote: > >> On Sun, Nov 1, 2009 at 6:06 AM, Victor Lazzarini >> wrote: >>> Of course, you can create a C++ template to do this >>> (I am not sure there is one in STL, but there might be). >>> >>> The question is why, since 0-indexing makes much more >>> sense. >> >> It is really nothing more than a convention. > > i disagree with the premise. conventions matter. and not all > conventions are of equal value. why don't we just define a > convention that offsets every index by 9? it's really nothing more > than a convention. > > (sorry, not trying to pick a fight. that's what comp.dsp is for. :-) > > >> In matlab's case, it is >> almost certainly a historical consequence of the fortran heritage > > and also the common convention of matrices you'll see in nearly any > linear algebra or matrix theory text. but that's probably where > Fortran got it. > >> (matlab was born 30 years ago as a 'shell' around the LINPACK/EIPACK >> libraries - now LAPACK). Fortran indexing starts at 1, and Fortran is >> arguably a better language for serious scientific work compared to >> C or >> C++, as none of those have decent linear algebra support. > > no. only because of some old libraries that might still not be > ported over. well, C does not have a native "complex" type and has > no operator overloading. i've never been real good at C++ and a long > time ago i wrote my own complex lib in C so i could combine and > manipulate frequency response expressions in C. it looked more like > lisp than C. > > with the complex class in C++, i don't know any other reason than > existing libraries why Fortran would be better than C++ (except to > those engineers who grew up with Fortran). but there could be > something i am missing. BTW, Fortran 4 was the very first > programming language i learned (back in the punch-card daze of the > early/mid 70s). > >> It is interesting to note that R is somewhat worse than matlab, as >> indexing starts at 1, but getting 0 index does not fail >> (http://radfordneal.wordpress.com/2008/09/21/design-flaws-in-r-3-% >> E2%80%94-zero-subscripts/). > > someone (i can't remember who) who knew of my indexing diatribe > against MATLAB, suggested that i propose to the R folks to fix R > while it was still early in its development. i think this person > made such a proposal and caught no supporters in the R group. i'm > glad i didn't get involved. > >> I don't think 1 vs 0 for indexing matters much while you stay in one >> convention > > it is clearly inferior to define the Discrete Fourier Transform as: > > N > X[k] = SUM{ x[n] exp(i*2*pi*(n-1)*(k-1)/N) } > n=1 > > that *can't* be as good as the definition common in the lit. > >> - converting between both can be a pain. > > who is converting. they're making us convert equations that are well > established in the literature to fit their sorry-assed convention. > they're making us *remember* to always subtract 1 from the index when > using max() or some other search (like find()) that returns an > index. this is common in a phase vocoder or most any frequency- > domain manipulation. when you do it in MATLAB or Octave and you > forget to subtract the 1, you get errors. but the step of > subtracting 1 is not in the algorithm description in the lit. > > i am still astonished that, especially in these circles (people that > might very likely be doing vocoding or some other frequency-domain > processing) that the two "mere" conventions would be seen as equally > useful or elegant. > >> What matters is the indexing capabilities: >> negative indexing, > > MATLAB doesn't do that. i wish it could and then 0 would just be one > of the commonly used special cases. > >> strides, etc... > > there's a notation i think you can use in MATLAB to do a dot=product > with a stride in one of the vectors. > >> This is much harder to get right >> than most people thiny, though. In numpy (a core array package for >> python), we have quite a few goodies compared to matlab (in particular >> w.r.t. to automatic broadcasting for linear algebra), but still no >> feature such as index starting at a negative index, although you could >> fake it through a wrapper (but it would be slower I think). I guess a >> signal class with signal-oriented features would make sense (the >> advantage of python over matlab is that the array object is an >> instance of a real class, and can be subclassed). > > i met a couple of python proponents. i just don't want to have to > learn another language unless i become convinced that it is necessary > and the new language has lasting promise. > >> LastWave has a nice feature for fractional indexing (interpreted as >> interpolation): >> http://www.cmap.polytechnique.fr/~bacry/LastWave/packages/signal/ >> signal.html > > that's kinda cool, but we *know* that there is much additional > processing to do the interpoation. and there are parameters: how is > the interpolation being done? Lagrange? Hermite? some windowed sinc > () function? how far out does the interpolation kernel reach? you > would need meaningful and good enough initial settings for that and > maybe allow the user to adjust it. > >> Speaking of stupid conventions, I am much more bothered by the >> normalized frequency being 2 and Nyquist frequency being 1 in >> matlab :) > > yup. that sucks too. another is their polyfit() and polyval() run > the indices of the polynomial coefs backwards, in my opinion. but > it's an issue with their functions and you can redefine functions. > this "all indices are positive integers" thing is worse, because you > *can't* fix it. they have to fix it and they do not recognize that > it *is* anything that needs fixing. > > L8r, > > -- > > 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 cournape at gmail.com Sun Nov 1 23:19:29 2009 From: cournape at gmail.com (David Cournapeau) Date: Mon, 2 Nov 2009 13:19:29 +0900 Subject: [music-dsp] platform choice In-Reply-To: <84C39CF7-2220-4636-9CB7-FCBD9AD5407D@audioimagination.com> References: <907277ED-F2A7-4AD6-8DEB-07B1EB45B12E@nuim.ie> <4AEC7791.6000600@pdp7.org> <463E662C-B3B2-47E4-9E83-6D41B22BEBCE@audioimagination.com> <4AEC930C.3050002@pdp7.org> <5EB704BFD6B940A188918AE971EA1974@GOLAMD> <5b8d13220911011905p11a3787dsf29b1bae6d9ea96c@mail.gmail.com> <84C39CF7-2220-4636-9CB7-FCBD9AD5407D@audioimagination.com> Message-ID: <5b8d13220911012019t7447564te1291776eecc0d74@mail.gmail.com> On Mon, Nov 2, 2009 at 12:36 PM, robert bristow-johnson wrote: > > On Nov 1, 2009, at 10:05 PM, David Cournapeau wrote: > >> On Sun, Nov 1, 2009 at 6:06 AM, Victor Lazzarini >> wrote: >>> Of course, you can create a C++ template to do this >>> (I am not sure there is one in STL, but there might be). >>> >>> The question is why, since 0-indexing makes much more >>> sense. >> >> It is really nothing more than a convention. > > i disagree with the premise. ?conventions matter. ?and not all > conventions are of equal value. ?why don't we just define a > convention that offsets every index by 9? ?it's really nothing more > than a convention. I agree that convention matter - I don't see why 1 would be better than 0, though > and also the common convention of matrices you'll see in nearly any > linear algebra or matrix theory text. ?but that's probably where > Fortran got it. Maybe - would be nice to know where the 1 indexing is coming from in Fortran. >> (matlab was born 30 years ago as a 'shell' around the LINPACK/EIPACK >> libraries - now LAPACK). Fortran indexing starts at 1, and Fortran is >> arguably a better language for serious scientific work compared to >> C or >> C++, as none of those have decent linear algebra support. > > no. ?only because of some old libraries that might still not be > ported over. ?well, C does not have a native "complex" type and has > no operator overloading. ?i've never been real good at C++ and a long > time ago i wrote my own complex lib in C so i could combine and > manipulate frequency response expressions in C. ?it looked more like > lisp than C. It depends on what you do. I agree for 'basic' signal processing, Fortran has no advantage over C. Also, in signal processing, because of embedded software, low level and efficiency strongly overlap, and you can rarely hope for anything else than C compiler anyway (and C++ if your lucky). But for scientific computing, C and C++ are inferior to (modern) Fortran in most cases. Portable C does indeed lack complex type (MS compilers, for example, do not handle C99 complex type), and C++ does not have a native type for matrix/vector, so you end up with 10 incompatible libraries (blitz, boost.ublas, etc...). So the lack of libraries is inherent to the language IMHO. If you write a numerical library with linear algebra in C/C++, you have to choose a library, and you end up with home-grown solution, Boost or other non portable dependencies. There is a lot of NIH and lack of reusability in C++ for scientific programming (and C). > > with the complex class in C++, i don't know any other reason than > existing libraries why Fortran would be better than C++ (except to > those engineers who grew up with Fortran). ?but there could be > something i am missing. ?BTW, Fortran 4 was the very first > programming language i learned (back in the punch-card daze of the > early/mid 70s). I was born after F77 :) Modern fortran dialects (the ones which support IEEE754, F95 and F2003) are much nicer than old fortran, though. There is support for openmp, objects, etc... > > it is clearly inferior to define the Discrete Fourier Transform as: > > ? ? ? ? ? ?N > ? ?X[k] = SUM{ x[n] exp(i*2*pi*(n-1)*(k-1)/N) } > ? ? ? ? ? n=1 > > that *can't* be as good as the definition common in the lit. I agree it is better in this case. But you can find cases where it is inferior as well. Matlab is not only used for signal processing. > who is converting. Well, me for example ! I am quite involved in numpy, and core parts of numpy are in C (because python was explicitly designed to be easily extended in C). Because so many core numerical libraries are available in Fortran only, I often have to think about 1 vs 0 when I work on numpy. Sometimes, when I give tutorial or help people coming from matlab, I often have to convert some matlab code as well. > there's a notation i think you can use in MATLAB to do a dot=product > with a stride in one of the vectors. In numpy, we have a few things which are better than matlab IMO (but I am obviously biased): - broadcasting: in matlab, if you have a 4x3 matrix, and you want to add i to each row i, you need to create a matrix [0, 0, 0; 1, 1, 1; ...] to add it. In numpy, we have broadcasting: http://www.scipy.org/EricsBroadcastingDoc - the data model for arrays allows for nice tricks. For example, if you have an array [1, 2, 3, 4.....], and you want to do a window per window processing, you want to "split" the array into overlapping arrays for each windows. In numpy, you can 'abuse' the internal strides so that you can create this representation from the original array without copying anything (compared to the buffer function in matlab). We also inherit a couple of useful conventions from python: negative index to read from the end (a[-1] is the last item), a[:3] contains 3 items (from item 0 to item 3, 3 excluded). > i met a couple of python proponents. ?i just don't want to have to > learn another language unless i become convinced that it is necessary > and the new language has lasting promise. Sure, I understand. I am younger and more easily excited by new technologies :) There are quite a few interesting languages nowadays to experiment for things which are awkward in C and C++: python, ocaml, F#, scala, etc... When I started my PhD a few years ago, I wanted to get away from matlab for various reasons, and I ended up choosing python (the other strong contender was OCAML but I thought the python community was more friendly and more practical). I also like that python looks like pseudo-code, and is readable by many people - as a scientist, I consider that source code is as much a communication as an implementation issue. And numpy arrays start at 0 :) If you are willing to spend one hour on the topic, this year's keynote by P. Norvig was pretty good: http://www.archive.org/details/scipy09_day1_03-Peter_Norvig David From andrew.capon at zen.co.uk Mon Nov 2 02:26:29 2009 From: andrew.capon at zen.co.uk (Andrew Capon) Date: Mon, 2 Nov 2009 07:26:29 +0000 Subject: [music-dsp] platform choice In-Reply-To: <6949D7F279B7421398B24777A004D901@toshibauser> References: A77829196B8EE5F@toshibauser><44C3A2C79CEE4253A4E22E25B1AFC277@toshibauser> <6949D7F279B7421398B24777A004D901@toshibauser> Message-ID: HI Guys, I did say majority, all I meant was that DSP guys/girls do more of this sort of thing: > c[i] = a[i] + b[i]; Than other programmers working in different fields. Cheers Andy On 1 Nov 2009, at 21:18, michael.gogins at gmail.com wrote: > You a right. I meant: > > c[i] = a[i] + b[i]; > > is easier to read than: > > *c++ = *a++ + *b++; > > I don't see any iterators in A = B*C, though. > > Regards, > Mike > > ----- Original Message ----- > From: "robert bristow-johnson" > To: "A discussion list for music-related DSP" > > Sent: Sunday, November 01, 2009 4:05 PM > Subject: Re: [music-dsp] platform choice > > >> >> oh, c'mon. a matrix equation like A = B*C or C = B\A is harder to >> read in the majority of cases than the code necessary to compute >> every element of these arrays? >> >> r b-j >> >> On Nov 1, 2009, at 3:59 PM, Andrew Capon wrote: >> >>> I must admit I don't see this being true for the majority of cases. >>> >>> Maybe DSP guys/girls just like arrays. >>> >>> Cheers >>> >>> Andy >>> >>> On 1 Nov 2009, at 20:09, michael.gogins at gmail.com wrote: >>> >>>> Arrays are easier to read. This is important. >>>> >>>> Regards, >>>> Mike >>>> >>>> ----- Original Message ----- >>>> From: "Andrew Capon" >>>> To: "A discussion list for music-related DSP" >>> dsp at music.columbia.edu >>>>> >>>> Sent: Sunday, November 01, 2009 2:40 PM >>>> Subject: Re: [music-dsp] platform choice >>>> >>>> >>>>> So why do people use arrays? >>>>> >> >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, 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 richarddobson at blueyonder.co.uk Mon Nov 2 04:18:47 2009 From: richarddobson at blueyonder.co.uk (Richard Dobson) Date: Mon, 02 Nov 2009 09:18:47 +0000 Subject: [music-dsp] platform choice In-Reply-To: <5b8d13220911011905p11a3787dsf29b1bae6d9ea96c@mail.gmail.com> References: <948B7ACA-0446-4E45-923D-E2A928C37A7E@silberstein.de> <907277ED-F2A7-4AD6-8DEB-07B1EB45B12E@nuim.ie> <4AEC7791.6000600@pdp7.org> <463E662C-B3B2-47E4-9E83-6D41B22BEBCE@audioimagination.com> <4AEC930C.3050002@pdp7.org> <5EB704BFD6B940A188918AE971EA1974@GOLAMD> <5b8d13220911011905p11a3787dsf29b1bae6d9ea96c@mail.gmail.com> Message-ID: <4AEEA3F7.5090603@blueyonder.co.uk> David Cournapeau wrote: > On Sun, Nov 1, 2009 at 6:06 AM, Victor Lazzarini > wrote: >> Of course, you can create a C++ template to do this >> (I am not sure there is one in STL, but there might be). >> >> The question is why, since 0-indexing makes much more >> sense. > > It is really nothing more than a convention. Hmm, not really. In real life, computers depend on integer types. We all know that an 8bit number can represent up to 256 distinct values; that would be 0-255, not 1-256. If we want to count to ten using one digit, it has to be 0-9, not 1-10. Why waste a number? It all comes down to the perennial mixup between formal (cardinal, ordinal) number theory and "natural language" - there is zero, but we don't normally speak of "a zeroth item" when counting: humans who insist on thinking like a human, v the computer that thinks like a computer (at least, like one with fixed-size integer types). ~Computers~ naturally count from zero - perhaps all we need is to add one to each value when printing to the screen. Happens all the time. Richard Dobson From bruno.ronzani at utbm.fr Mon Nov 2 05:09:26 2009 From: bruno.ronzani at utbm.fr (Ronzani Bruno) Date: Mon, 2 Nov 2009 11:09:26 +0100 Subject: [music-dsp] Equalizer Coefficients Message-ID: Hi ! I am trying to make an Equalizer in C++ using RBJ Filters. I want it to be very generic, thus you can add as much points as you want. Each point is specified by its frequency and of course its gain. For example it could be : 200Hz : +0.3 500Hz : +0.7 5000Hz : -0.1 5100Hz : +0.2 (so you see that you don't have the same range between each point) My main idea is to make the sum of all the filters to the current audio, ie, in pseudo code : double output = 0 for each point P of the equalizer do: output += applyFilter(intput, P.frequency ) * P.Volume done return output; is this the correct way to do it ?! Of course, my main problem is how to calculate the Q coefficient ? For now, what I do is : if it's the first point of my Equalizer, I use a LOWSHELF filter if it's the last point, I use a HISHELF filter else I use a BANDPASS filter then, for each filter, I set the Q value -- here Q is a bandwidth -- to : nextPoint.Frequency - currentPoint.Frequency I guess it's not correct... how should I do this in a better way ? Thank a lot, I hope I am clear enough... Bruno Ronzani From cournape at gmail.com Mon Nov 2 05:22:57 2009 From: cournape at gmail.com (David Cournapeau) Date: Mon, 2 Nov 2009 19:22:57 +0900 Subject: [music-dsp] platform choice In-Reply-To: <4AEEA3F7.5090603@blueyonder.co.uk> References: <907277ED-F2A7-4AD6-8DEB-07B1EB45B12E@nuim.ie> <4AEC7791.6000600@pdp7.org> <463E662C-B3B2-47E4-9E83-6D41B22BEBCE@audioimagination.com> <4AEC930C.3050002@pdp7.org> <5EB704BFD6B940A188918AE971EA1974@GOLAMD> <5b8d13220911011905p11a3787dsf29b1bae6d9ea96c@mail.gmail.com> <4AEEA3F7.5090603@blueyonder.co.uk> Message-ID: <5b8d13220911020222o53ddfb95v72bce0a1427bdd5d@mail.gmail.com> On Mon, Nov 2, 2009 at 6:18 PM, Richard Dobson wrote: > Why waste a number? > > It all comes down to the perennial mixup between formal (cardinal, > ordinal) number theory and "natural language" - there is zero, but we > don't normally speak of "a zeroth item" when counting: humans who insist > on thinking like a human, v the computer that thinks like a computer (at > least, like one with fixed-size integer types). > > ~Computers~ naturally count from zero - perhaps all we need is to add > one to each value when printing to the screen. Happens all the time. The disagreement may come from our different way of looking at a computer and programming language. Most of the time, I could not care less about how a computer may 'think': the programming language is here to express my 'idea' of a certain algorithm, using the conventions from the concerned fields. I thought this was the convention we were talking about (i.e. in formula). Now, for C, you *have* to start at 0, otherwise a[i] could not be the same as a + i. In that sense, I guess it is not a convention for the C programming language family. Most other programming languages, which are not as low level as C, do not have this restriction, since pointer and arrays are totally distinct. For those languages, it is a convention - and curiously, a lot of math-oriented 'languages' starts at one (matlab, R, Fortran, maybe Mathematica as well ?). There are many engineering fields where the convention is to start at one: I have yet encountered a linear algebra book which count item starting at 0, and in statistics, you often represent N samples as (x_1, ...., x_N), not (x_0, ..., X_{N-1}. Things get messy in statistical signal processing :) David From didid at skynet.be Mon Nov 2 07:39:16 2009 From: didid at skynet.be (Didier Dambrin) Date: Mon, 2 Nov 2009 13:39:16 +0100 Subject: [music-dsp] platform choice In-Reply-To: <4AEEA3F7.5090603@blueyonder.co.uk> References: <948B7ACA-0446-4E45-923D-E2A928C37A7E@silberstein.de> <907277ED-F2A7-4AD6-8DEB-07B1EB45B12E@nuim.ie> <4AEC7791.6000600@pdp7.org> <463E662C-B3B2-47E4-9E83-6D41B22BEBCE@audioimagination.com> <4AEC930C.3050002@pdp7.org><5EB704BFD6B940A188918AE971EA1974@GOLAMD> <5b8d13220911011905p11a3787dsf29b1bae6d9ea96c@mail.gmail.com> <4AEEA3F7.5090603@blueyonder.co.uk> Message-ID: Really, it's not just about arrays starting at 0 vs 1. In pascal I sometimes have arrays that are states of existing indexes, thus they're defined in the same range, so that I just need to read "StateOf[ThisIndex]" and not "StateOf[ThisIndex-FirstPossibleIndex]" (and yes that's what the compiler does, which is the point of a compiler). Another use are negative indexes - you defined an array of constants, then you want to add special values, you can append them to the left, it's not uncommon to have arrays starting at -1 or other kind of bipolar arrays. Third use is when it's something you give directly to the user and don't really work with in depth. Since you're gonna display its first item as "1" to the user, sometimes it's just easier to define the first index as 1. And since the language (pascal) allows to access the boundaries of the defined type, it can be written safely. Like "for n:=Low(Array) to High(Array)" instead of "for n:=0 to x". > David Cournapeau wrote: >> On Sun, Nov 1, 2009 at 6:06 AM, Victor Lazzarini >> wrote: >>> Of course, you can create a C++ template to do this >>> (I am not sure there is one in STL, but there might be). >>> >>> The question is why, since 0-indexing makes much more >>> sense. >> >> It is really nothing more than a convention. > > Hmm, not really. In real life, computers depend on integer types. We all > know that an 8bit number can represent up to 256 distinct values; that > would be 0-255, not 1-256. If we want to count to ten using one digit, > it has to be 0-9, not 1-10. > > Why waste a number? > > It all comes down to the perennial mixup between formal (cardinal, > ordinal) number theory and "natural language" - there is zero, but we > don't normally speak of "a zeroth item" when counting: humans who insist > on thinking like a human, v the computer that thinks like a computer (at > least, like one with fixed-size integer types). > > ~Computers~ naturally count from zero - perhaps all we need is to add > one to each value when printing to the screen. Happens all the time. > > > > Richard Dobson > > > > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.423 / Virus Database: 270.14.45/2476 - Release Date: 11/02/09 07:51:00 From michael.gogins at gmail.com Mon Nov 2 08:41:35 2009 From: michael.gogins at gmail.com (Michael Gogins) Date: Mon, 2 Nov 2009 08:41:35 -0500 Subject: [music-dsp] platform choice In-Reply-To: <5b8d13220911011905p11a3787dsf29b1bae6d9ea96c@mail.gmail.com> References: <948B7ACA-0446-4E45-923D-E2A928C37A7E@silberstein.de> <907277ED-F2A7-4AD6-8DEB-07B1EB45B12E@nuim.ie> <4AEC7791.6000600@pdp7.org> <463E662C-B3B2-47E4-9E83-6D41B22BEBCE@audioimagination.com> <4AEC930C.3050002@pdp7.org> <5EB704BFD6B940A188918AE971EA1974@GOLAMD> <5b8d13220911011905p11a3787dsf29b1bae6d9ea96c@mail.gmail.com> Message-ID: <898dd7270911020541m400ae9bcj476009dec36a6116@mail.gmail.com> C++ does not have the degree of linear algebra support as Fortran, but it does now have what could be called _decent_ support in the form of libraries, foremost Eigen and Gmm++. These go up at least to eigenvalue decompositions, which is where I guess "decent" begins. Regards, Mike On 11/1/09, David Cournapeau wrote: > On Sun, Nov 1, 2009 at 6:06 AM, Victor Lazzarini > wrote: >> Of course, you can create a C++ template to do this >> (I am not sure there is one in STL, but there might be). >> >> The question is why, since 0-indexing makes much more >> sense. > > It is really nothing more than a convention. In matlab's case, it is > almost certainly a historical consequence of the fortran heritage > (matlab was born 30 years ago as a 'shell' around the LINPACK/EIPACK > libraries - now LAPACK). Fortran indexing starts at 1, and Fortran is > arguably a better language for serious scientific work compared to C or > C++, as none of those have decent linear algebra support. > > It is interesting to note that R is somewhat worse than matlab, as > indexing starts at 1, but getting 0 index does not fail > (http://radfordneal.wordpress.com/2008/09/21/design-flaws-in-r-3-%E2%80%94-zero-subscripts/). > > I don't think 1 vs 0 for indexing matters much while you stay in one > convention - converting > between both can be a pain. What matters is the indexing capabilities: > negative indexing, strides, etc... This is much harder to get right > than most people thiny, though. In numpy (a core array package for > python), we have quite a few goodies compared to matlab (in particular > w.r.t. to automatic broadcasting for linear algebra), but still no > feature such as index starting at a negative index, although you could > fake it through a wrapper (but it would be slower I think). I guess a > signal class with signal-oriented features would make sense (the > advantage of python over matlab is that the array object is an > instance of a real class, and can be subclassed). > > LastWave has a nice feature for fractional indexing (interpreted as > interpolation): > http://www.cmap.polytechnique.fr/~bacry/LastWave/packages/signal/signal.html > > Speaking of stupid conventions, I am much more bothered by the > normalized frequency being 2 and Nyquist frequency being 1 in matlab :) > > David > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, 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 Mon Nov 2 12:15:55 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Mon, 2 Nov 2009 12:15:55 -0500 Subject: [music-dsp] platform choice In-Reply-To: <5b8d13220911020222o53ddfb95v72bce0a1427bdd5d@mail.gmail.com> References: <907277ED-F2A7-4AD6-8DEB-07B1EB45B12E@nuim.ie> <4AEC7791.6000600@pdp7.org> <463E662C-B3B2-47E4-9E83-6D41B22BEBCE@audioimagination.com> <4AEC930C.3050002@pdp7.org> <5EB704BFD6B940A188918AE971EA1974@GOLAMD> <5b8d13220911011905p11a3787dsf29b1bae6d9ea96c@mail.gmail.com> <4AEEA3F7.5090603@blueyonder.co.uk> <5b8d13220911020222o53ddfb95v72bce0a1427bdd5d@mail.gmail.com> Message-ID: <9915D986-131A-447C-8D98-C47768FD3A6D@audioimagination.com> On Nov 2, 2009, at 5:22 AM, David Cournapeau wrote: > > The disagreement may come from our different way of looking at a > computer and programming language. Most of the time, I could not care > less about how a computer may 'think': the programming language is > here to express my 'idea' of a certain algorithm, using the > conventions from the concerned fields. I thought this was the > convention we were talking about (i.e. in formula). the issue is what MATLAB long ago used to put in their > Now, for C, you *have* to start at 0, no you don't. > otherwise a[i] could not be the same as a + i. double _a[2N+1], *a; a = &(_a[N]); for (n=-N; n<=N; n++) { do_something(a[n]); } > In that sense, I guess it is not a convention for the C > programming language family. Most other programming languages, which > are not as low level as C, do not have this restriction, since pointer > and arrays are totally distinct. the reason that zero-based arrays are more natural than 1-based arrays is not so much that 0-based translates more directly to machine language. see the Dijkstra missive: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/ EWD831.html > For those languages, it is a > convention - and curiously, a lot of math-oriented 'languages' starts > at one (matlab, R, Fortran, maybe Mathematica as well ?). it's because, when we were kids, we first learned the term "natural numbers" or "counting numbers" which were positive integers only. then we learned the term "whole numbers" which were the non-negative integers. then we learned about negative integers and the term "integer". > There are > many engineering fields where the convention is to start at one: I > have yet encountered a linear algebra book which count item starting > at 0, and in statistics, you often represent N samples as (x_1, ...., > x_N), agreed. the 1-based convention seems natural and doesn't break anything. try it with notation for convolution or the DFT. or for polynomial coefficients. -- r b-j rbj at audioimagination.com "Imagination is more important than knowledge." From bruno.ronzani at utbm.fr Mon Nov 2 12:31:14 2009 From: bruno.ronzani at utbm.fr (Ronzani Bruno) Date: Mon, 2 Nov 2009 18:31:14 +0100 Subject: [music-dsp] Equalizer Coefficients In-Reply-To: References: Message-ID: Hello again... I still didn't manage to do it. Is this a good idea to use RBJ Filters to make an equalizer ? Thanks, Bruno 2009/11/2 Ronzani Bruno : > Hi ! > > I am trying to make an Equalizer in C++ using RBJ Filters. > > I want it to be very generic, thus you can add as much points as you want. > > Each point is specified by its frequency and of course its gain. > > For example it could be : > > 200Hz : +0.3 > 500Hz : +0.7 > 5000Hz : -0.1 > 5100Hz : +0.2 > > (so you see that you don't have the same range between each point) > > My main idea is to make the sum of all the filters to the current > audio, ie, in pseudo code : > > double output = 0 > for each point P of the equalizer do: > ? output += applyFilter(intput, P.frequency ) * P.Volume > done > return output; > > > is this the correct way to do it ?! > > Of course, my main problem is how to calculate the Q coefficient ?? > > For now, what I do is : > > if it's the first point of my Equalizer, I use a LOWSHELF filter > if it's the last point, I use a HISHELF filter > else I use a BANDPASS filter > > then, for each filter, I set the Q value -- here Q is a bandwidth -- to : > > nextPoint.Frequency - currentPoint.Frequency > > I guess it's not correct... how should I do this in a better way ? > > Thank a lot, I hope I am clear enough... > > Bruno Ronzani > From richarddobson at blueyonder.co.uk Mon Nov 2 12:35:57 2009 From: richarddobson at blueyonder.co.uk (Richard Dobson) Date: Mon, 02 Nov 2009 17:35:57 +0000 Subject: [music-dsp] ANN: update to CDP Multi-Channel Toolkit Message-ID: <4AEF187D.3040109@blueyonder.co.uk> (Sorry for any cross-posting; there will not be very much anyway) Tools for managing multi-channel files, and to explore basic Ambisonic B-Format encoding and decoding. New decode options (compatible with Csound) cover a standard set of regular speaker layouts, and 5.0/1. No shelf filters or nearfield compensation (yet). Several new programs are introduced with this release. Find it here: http://people.bath.ac.uk/masrwd/mctools.html As usual there are separate archives for Windows and OS X (Universal Binaries, should be OK for 10.4 and 10.5). The 5.0/1 decodes may be of interest here: the coefficients have been kindly supplied by David Moore (http://compeng.hud.ac.uk/sengdjm, but very recently moved to Glasgow Cal) as a result of his research into exhaustive search techniques using Clearspeed massively-parallel accelerator cards installed at Bath Uni. He will hopefully have a web page about it soon; there is a little information on my new pages to be getting on with. I would ask anyone linking the toolkit from their pages to link to the ~page~ as above, not directly to the archive files themselves. Apart from the fact that those I have seen link only to the Windows version, I reserve the right to change file names, as on this occasion. The programs are free to download, as usual; but I would modestly draw the attention of anyone using thems on an "industrial scale" to the new Paypal donation opportunity! Bug reports will be gratefully received, and acted on at the earliest opportunity... Richard Dobson From developer at netcologne.de Mon Nov 2 13:08:32 2009 From: developer at netcologne.de (Thomas Rehaag) Date: Mon, 02 Nov 2009 19:08:32 +0100 Subject: [music-dsp] Equalizer Coefficients References: Message-ID: <4AEF2020.BC5A9277@netcologne.de> Hi Bruno, for your code: > double output = 0 > for each point P of the equalizer do: > output += applyFilter(intput, P.frequency ) * P.Volume > done > return output; you need normal low/hi/band pass filters, but you'll not be satisfied with the resulting curves, especially not if attenuate a band's volume. Better use the peak and shelf filters and do something like: double output = input; input = LowShelfe(input); input = HighShelfe(input); for(all bands) input = Peak(input); You should find examples on musicdsp.org > Of course, my main problem is how to calculate the Q coefficient ? The question is what you want to create. (1) an EQ with adjacent bands or (2) a conventional parametric EQ with random f0 and Q for N bands. If you want to set random mid frequencies, the cutoff frequencies won't match so that fcUpper[n] == fcLower[n+1]. If you'd like to have an EQ with adjacent bands, you'll have to set 'split points' to insert a new band and the mid frequencies will follow. Best Regards, Thomas From rbj at audioimagination.com Mon Nov 2 12:41:42 2009 From: rbj at audioimagination.com (robert bristow-johnson) Date: Mon, 2 Nov 2009 12:41:42 -0500 Subject: [music-dsp] Equalizer Coefficients In-Reply-To: References: Message-ID: <124D6325-72FE-4D32-AD75-F4EFBFA5C006@audioimagination.com> it appears that you're stringing these together in cascade, with the shelving filters as "bookends". if you're trying to use these as a means of doing a sorta generalized graphic eq (with fixed frequencies and Qs), then you should try to space these peaking EQs equally in log frequency. then their bandwidth (in octaves) should be *something* like the spacing (in octaves). in the cookbook, there is a formula that relates the bandwidth (in octaves) to the Q. but maybe your app is a true parametric where you're moving f0 around, then you can have whatever you want. -- r b-j On Nov 2, 2009, at 12:31 PM, Ronzani Bruno wrote: > Hello again... I still didn't manage to do it. > > Is this a good idea to use RBJ Filters to make an equalizer ? > > Thanks, > > Bruno > > 2009/11/2 Ronzani Bruno : >> Hi ! >> >> I am trying to make an Equalizer in C++ using RBJ Filters. >> >> I want it to be very generic, thus you can add as much points as >> you want. >> >> Each point is specified by its frequency and of course its gain. >> >> For example it could be : >> >> 200Hz : +0.3 >> 500Hz : +0.7 >> 5000Hz : -0.1 >> 5100Hz : +0.2 >> >> (so you see that you don't have the same range between each point) >> >> My main idea is to make the sum of all the filters to the current >> audio, ie, in pseudo code : >> >> double output = 0 >> for each point P of the equalizer do: >> output += applyFilter(intput, P.frequency ) * P.Volume >> done >> return output; >> >> >> is this the correct way to do it ?! >> >> Of course, my main problem is how to calculate the Q coefficient ? >> >> For now, what I do is : >> >> if it's the first point of my Equalizer, I use a LOWSHELF filter >> if it's the last point, I use a HISHELF filter >> else I use a BANDPASS filter >> >> then, for each filter, I set the Q value -- here Q is a bandwidth >> -- to : >> >> nextPoint.Frequency - currentPoint.Frequency >> >> I guess it's not correct... how should I do this in a better way ? >> >> Thank a lot, I hope I am clear enough... >> -- r b-j rbj at audioimagination.com "Imagination is more important than knowledge." From earlevel at earlevel.com Mon Nov 2 21:13:34 2009 From: earlevel at earlevel.com (Nigel Redmon) Date: Mon, 2 Nov 2009 18:13:34 -0800 Subject: [music-dsp] platform choice In-Reply-To: <4AEEA3F7.5090603@blueyonder.co.uk> References: <948B7ACA-0446-4E45-923D-E2A928C37A7E@silberstein.de> <907277ED-F2A7-4AD6-8DEB-07B1EB45B12E@nuim.ie> <4AEC7791.6000600@pdp7.org> <463E662C-B3B2-47E4-9E83-6D41B22BEBCE@audioimagination.com> <4AEC930C.3050002@pdp7.org> <5EB704BFD6B940A188918AE971EA1974@GOLAMD> <5b8d13220911011905p11a3787dsf29b1bae6d9ea96c@mail.gmail.com> <4AEEA3F7.5090603@blueyonder.co.uk> Message-ID: On Nov 2, 2009, at 1:18 AM, Richard Dobson wrote: >> >> It is really nothing more than a convention. > > Hmm, not really. In real life, computers depend on integer types. We > all > know that an 8bit number can represent up to 256 distinct values; that > would be 0-255, not 1-256. If we want to count to ten using one digit, > it has to be 0-9, not 1-10. I believe it comes from traditional convention in mathematics (where the first position in a sequence would be referred to as the first/ 1st, not the zeroeth/0th, the last value of a sequence of length 10 would be the 10th, etc.). I suppose this carried over to early computer languages (I haven't done a survey on that), and I suppose the benefits of zero-based array become obvious as computing matured (Pascal was definable, right?). FORTRAN was my first high-level language in college, and in my youth I programmed automated-test systems in a FORTRAN-based language. And yes, it's really annoying to work in 1-based systems, especially when get accustomed to performance optimizations such as wrapping around arrays with modulo arithmetic (such as AND-masking the index in power-of-2 length array). From earlevel at earlevel.com Mon Nov 2 21:32:45 2009 From: earlevel at earlevel.com (Nigel Redmon) Date: Mon, 2 Nov 2009 18:32:45 -0800 Subject: [music-dsp] platform choice In-Reply-To: <898dd7270911020541m400ae9bcj476009dec36a6116@mail.gmail.com> References: <948B7ACA-0446-4E45-923D-E2A928C37A7E@silberstein.de> <907277ED-F2A7-4AD6-8DEB-07B1EB45B12E@nuim.ie> <4AEC7791.6000600@pdp7.org> <463E662C-B3B2-47E4-9E83-6D41B22BEBCE@audioimagination.com> <4AEC930C.3050002@pdp7.org> <5EB704BFD6B940A188918AE971EA1974@GOLAMD> <5b8d13220911011905p11a3787dsf29b1bae6d9ea96c@mail.gmail.com> <898dd7270911020541m400ae9bcj476009dec36a6116@mail.gmail.com> Message-ID: On Nov 2, 2009, at 5:41 AM, Michael Gogins wrote: > C++ does not have the degree of linear algebra support as Fortran, but > it does now have what could be called _decent_ support in the form of > libraries, foremost Eigen and Gmm++. (Mike, I'm not directing this at you--you probably know it already-- but just for the benefit of misc. lurkers...) Another issue for C++ vs FORTRAN for heavy number crunching is the way C++ deals with numbers (pairwise evaluation with operator overloading, resulting in intermediate storage in vector calculations, etc.). This can be addressed in C++ with template meta programming (Blitz, etc.). Anyway, just mentioning this for people who wonder why anyone in their right mind would still use FORTRAN (FORmula TRANslation--that's what it was made for ;-) From bastian.schnuerle at silberstein.de Tue Nov 3 15:35:32 2009 From: bastian.schnuerle at silberstein.de (bastian.schnuerle) Date: Tue, 3 Nov 2009 21:35:32 +0100 Subject: [music-dsp] intellectual properties in softwaredevelopment In-Reply-To: <90E23386-EF8A-4D9D-9158-4B01109A0BBA@audioimagination.com> References: <037A2915F3DB403B9A6B63C503F5F515@GOLAMD><56FB32C8-9BA2-4C93-816A-BE1623F34A93@audioimagination.com> <6D776234-1B7A-4DA8-AFEE-F17D94C7FC70@audioimagination.com> <18E97DEC-43B0-4FC3-AE03-5E529BFD94AC@audioimagination.com> <71762F20-BC2D-4420-AEF4-BC352AAFBD2D@silberstein.de> <014201ca45e7$59ab2230$0d016690$@co.uk> <3C33878C-53BA-43B5-94D1-D58FF99D0DF2@silberstein.de> <6D704F48-3C1A-46D0-B4D5-89539BD77F11@silberstein.de> <90E23386-EF8A-4D9D-9158-4B01109A0BBA@audioimagination.com> Message-ID: i lost, visit me in jail please ... for all the young developers out there, never bite the hand that feeds you ... ;) Am 08.10.2009 um 19:30 schrieb robert bristow-johnson: > > On Oct 8, 2009, at 12:36 PM, bastian.schnuerle wrote: > >> sorry guys, my last statement was also not a very professional. > > > this is a professional list? i'm just here to have fun. > > > onward to NYC and AES. see ya guys. > > -- > > 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 mista.tapas at gmx.net Tue Nov 10 14:58:50 2009 From: mista.tapas at gmx.net (Florian Schmidt) Date: Tue, 10 Nov 2009 20:58:50 +0100 Subject: [music-dsp] Fixed-point effects lib? Linux friendly floating-point DSP? In-Reply-To: References: Message-ID: <200911102058.50844.mista.tapas@gmx.net> On Thursday 08 October 2009, Amusing Muses wrote: > Hi I'm investigating the Blackfin as a platform for a music DSP > toolkit, unfortunately all the examples for simple effects like > choruses & flangers I can find utilize floating-point > arithmetic--which cripples their performance on the Blackfin because > it has no FPU. > > Does anyone know of any open source DSP effects packages that use > fixed-point arithmetic? Could save me a bunch of time rewriting these > effects myself... or should I just use a floating-point DSP? I'm > looking for something that is supported well by open source tools > (gcc, u-boot, Linux, etc) and that is low-cost enough for a high > volume consumer product... The Blackfin meets these requirements > except the lack of floating-point is turning out to be a hassle. Any > suggestions? > > Thanks. Hi, you might also take a look at Intel Atom boards.. They are rather cheap and can do some number crunching :) Flo -- Palimm Palimm! http://tapas.affenbande.org From douglas at music.columbia.edu Sun Nov 15 07:00:01 2009 From: douglas at music.columbia.edu (douglas repetto) Date: Sun, 15 Nov 2009 07:00:01 -0500 (EST) Subject: [music-dsp] [admin] music-dsp FAQ Message-ID: <20091115120001.17AD4B1FCA6@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 stevenpaulcook at tiscali.co.uk Tue Nov 17 15:41:06 2009 From: stevenpaulcook at tiscali.co.uk (Steven Cook) Date: Tue, 17 Nov 2009 20:41:06 -0000 Subject: [music-dsp] Polyphase Downsampling/Upsampling By 4, 8, 16... Message-ID: Hi, I'm experimenting with downsampling by a factor of 4 (8, 16...). I'd like to try polyphase downsampling but can't figure out how to 'wire together' 2 (or would it be 3?) polyphase filters between 4 (8. 16...) input samples and 1 output sample. Would someone give me a clue? While I'm here, does it matter in which order the 2 input samples are read into a polyphase filter? Regards, Steven Cook. http://www.spcplugins.com/ From earlevel at earlevel.com Wed Nov 18 14:58:53 2009 From: earlevel at earlevel.com (Nigel Redmon) Date: Wed, 18 Nov 2009 11:58:53 -0800 Subject: [music-dsp] Polyphase Downsampling/Upsampling By 4, 8, 16... In-Reply-To: References: Message-ID: Not quite sure of what you're asking--when you say "'wire together' 2 (or would it be 3?)", are you talking about multistage downsampling? It sort of seems like that's what you are saying. But then again, if you understand one stage, subsequent stages would be the same thing, so I'm not sure what you're asking. If you want to understand the nuts and bolts of why it works (I think such an understanding inherently answers a lot of the usual implementation questions), try this: http://www.earlevel.com/Digital%20Audio/RateConversion.html On Nov 17, 2009, at 12:41 PM, Steven Cook wrote: > Hi, > > I'm experimenting with downsampling by a factor of 4 (8, 16...). I'd like to > try polyphase downsampling but can't figure out how to 'wire together' 2 (or > would it be 3?) polyphase filters between 4 (8. 16...) input samples and 1 > output sample. Would someone give me a clue? While I'm here, does it matter > in which order the 2 input samples are read into a polyphase filter? > > Regards, > > Steven Cook. > http://www.spcplugins.com/ From earlevel at earlevel.com Wed Nov 18 15:04:48 2009 From: earlevel at earlevel.com (Nigel Redmon) Date: Wed, 18 Nov 2009 12:04:48 -0800 Subject: [music-dsp] Polyphase Downsampling/Upsampling By 4, 8, 16... In-Reply-To: References: Message-ID: Re-reading your question, Steven, I think the answer to your question is "use a circular output buffer between stages", so you'll have enough samples saved to run an iteration of the next stage. On Nov 17, 2009, at 12:41 PM, Steven Cook wrote: > Hi, > > I'm experimenting with downsampling by a factor of 4 (8, 16...). I'd like to > try polyphase downsampling but can't figure out how to 'wire together' 2 (or > would it be 3?) polyphase filters between 4 (8. 16...) input samples and 1 > output sample. Would someone give me a clue? While I'm here, does it matter > in which order the 2 input samples are read into a polyphase filter? > > Regards, > > Steven Cook. > http://www.spcplugins.com/ From stevenpaulcook at tiscali.co.uk Wed Nov 18 17:51:02 2009 From: stevenpaulcook at tiscali.co.uk (Steven Cook) Date: Wed, 18 Nov 2009 22:51:02 -0000 Subject: [music-dsp] Polyphase Downsampling/Upsampling By 4, 8, 16... References: Message-ID: Thanks Nigel. I've been thinking very hard about your answer but don't understand... I'm thinking of the type of polyphase filter (decimator?) which has two inputs and one output. I assume that to downsample by a factor of 2, it's simply a question of doing: out = filter(in1, in2). When downsampling by a factor of 4, do I process my 4 input samples (in1, in2, in3, in4) like: temp1 = filter(in1, in2); temp2 = filter(in3, in4); out = filter(temp1, temp2); Or some other way? Regards, Steven Cook. http://www.spcplugins.com/ ----- Original Message ----- From: "Nigel Redmon" To: "A discussion list for music-related DSP" Sent: Wednesday, November 18, 2009 8:04 PM Subject: Re: [music-dsp] Polyphase Downsampling/Upsampling By 4, 8, 16... > Re-reading your question, Steven, I think the answer to your question is > "use a circular output buffer between stages", so you'll have enough > samples saved to run an iteration of the next stage. > > > On Nov 17, 2009, at 12:41 PM, Steven Cook wrote: > >> Hi, >> >> I'm experimenting with downsampling by a factor of 4 (8, 16...). I'd like >> to >> try polyphase downsampling but can't figure out how to 'wire together' 2 >> (or >> would it be 3?) polyphase filters between 4 (8. 16...) input samples and >> 1 >> output sample. Would someone give me a clue? While I'm here, does it >> matter >> in which order the 2 input samples are read into a polyphase filter? >> >> Regards, >> >> Steven Cook. >> http://www.spcplugins.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 earlevel at earlevel.com Wed Nov 18 22:29:00 2009 From: earlevel at earlevel.com (Nigel Redmon) Date: Wed, 18 Nov 2009 19:29:00 -0800 Subject: [music-dsp] Polyphase Downsampling/Upsampling By 4, 8, 16... In-Reply-To: References: Message-ID: Hi Steven, Something's not right here... first, I encourage you to read my web article, but basically... For downsampling, you need to reduce the bandwidth of the signal, to avoid aliasing in the result. For instance, if you want to downsample by a factor of two, you need to apply a lowpass filter with a cutoff low enough to ensure no aliasing at the new rate. That means the lowpass filter corner frequency should be well less than one-fourth the sample rate to make sure the highs are rolled of sufficiently by half the new sample rate. At that point you have a lowpassed version of your signal, but still at the original sample rate. It's "oversampled" at this point--the sample rate is twice as high as needed to contain the reduced-bandwidth signal. So, you just throw away every-other sample. That's the gist of downsampling--filter it so that it will fit the new bandwidth, then throw away what you no longer need, to arrive at the new sample rate. So, the "filter()" function in your code, I presume, rolls the filter and the decimator into one--typical of a polyphase filter. But there are only two inputs for every output, meaning it's either a horrendously bad FIR filter, or it's an IIR (or FIR) with one more input than needed and keeps its own history (in which case you couldn't call it the way you are without some way to make separate instances of it--obviously not possible in your code example). Neither makes sense. (Maybe one input is a pointer to a buffer, and the other is length?) Could you elaborate more on "filter()"? Is that a library function for which you have no code, something you have code for, or a flow diagram you're trying to implement as code? Nigel On Nov 18, 2009, at 2:51 PM, Steven Cook wrote: > Thanks Nigel. > > I've been thinking very hard about your answer but don't understand... I'm > thinking of the type of polyphase filter (decimator?) which has two inputs > and one output. I assume that to downsample by a factor of 2, it's simply a > question of doing: out = filter(in1, in2). When downsampling by a factor of > 4, do I process my 4 input samples (in1, in2, in3, in4) like: > > temp1 = filter(in1, in2); > temp2 = filter(in3, in4); > out = filter(temp1, temp2); > > Or some other way? > > Regards, > > Steven Cook. > http://www.spcplugins.com/ > > ----- Original Message ----- > From: "Nigel Redmon" > To: "A discussion list for music-related DSP" > Sent: Wednesday, November 18, 2009 8:04 PM > Subject: Re: [music-dsp] Polyphase Downsampling/Upsampling By 4, 8, 16... > > >> Re-reading your question, Steven, I think the answer to your question is >> "use a circular output buffer between stages", so you'll have enough >> samples saved to run an iteration of the next stage. >> >> >> On Nov 17, 2009, at 12:41 PM, Steven Cook wrote: >> >>> Hi, >>> >>> I'm experimenting with downsampling by a factor of 4 (8, 16...). I'd like >>> to >>> try polyphase downsampling but can't figure out how to 'wire together' 2 >>> (or >>> would it be 3?) polyphase filters between 4 (8. 16...) input samples and >>> 1 >>> output sample. Would someone give me a clue? While I'm here, does it >>> matter >>> in which order the 2 input samples are read into a polyphase filter? >>> >>> Regards, >>> >>> Steven Cook. >>> http://www.spcplugins.com/ >> From stevenpaulcook at tiscali.co.uk Thu Nov 19 05:39:59 2009 From: stevenpaulcook at tiscali.co.uk (Steven Cook) Date: Thu, 19 Nov 2009 10:39:59 -0000 Subject: [music-dsp] Polyphase Downsampling/Upsampling By 4, 8, 16... References: Message-ID: <557839F1E0DF49C19E84BD17103BDD29@pc> Hi Nigel, Thanks for your continuing input. I have read your webpage and it is a very clear and well presented explanation of downsampling. I am fairly sure that I understand the basics of downsampling/upsampling, however, and my question is one of implementation. The filter design I am asking about is the IIR half-band filter from "The Quest for the Perfect Resampler" (Chapter 4) by Laurent De Soras. http://ldesoras.free.fr/doc/articles/resampler-en.pdf (Which is referenced [9] as originally coming from a now defunct web link) This combines the filtering and decimation into one operation (presumably to improve efficiency), so it has two inputs but only one output. I think filters of this type are also described in the Music DSP archives. My question is: I would like to try using filters like this to downsample by a factor of four (or more) but I'm unsure how to use two-input-one-output filters in this way. Can the filters be used like this? (in1, in2, in3, in4 are my 4 (oversampled) input samples) temp1 = filter(in1, in2) temp2 = filter(in3, in4) out = filter(temp1, temp2) Kind regards, Steven Cook. http://www.spcplugins.com/ ----- Original Message ----- From: "Nigel Redmon" To: "A discussion list for music-related DSP" Sent: Thursday, November 19, 2009 3:29 AM Subject: Re: [music-dsp] Polyphase Downsampling/Upsampling By 4, 8, 16... > Hi Steven, > > Something's not right here... first, I encourage you to read my web > article, but basically... > > For downsampling, you need to reduce the bandwidth of the signal, to avoid > aliasing in the result. For instance, if you want to downsample by a > factor of two, you need to apply a lowpass filter with a cutoff low enough > to ensure no aliasing at the new rate. That means the lowpass filter > corner frequency should be well less than one-fourth the sample rate to > make sure the highs are rolled of sufficiently by half the new sample > rate. At that point you have a lowpassed version of your signal, but still > at the original sample rate. It's "oversampled" at this point--the sample > rate is twice as high as needed to contain the reduced-bandwidth signal. > So, you just throw away every-other sample. > > That's the gist of downsampling--filter it so that it will fit the new > bandwidth, then throw away what you no longer need, to arrive at the new > sample rate. > > So, the "filter()" function in your code, I presume, rolls the filter and > the decimator into one--typical of a polyphase filter. But there are only > two inputs for every output, meaning it's either a horrendously bad FIR > filter, or it's an IIR (or FIR) with one more input than needed and keeps > its own history (in which case you couldn't call it the way you are > without some way to make separate instances of it--obviously not possible > in your code example). Neither makes sense. (Maybe one input is a pointer > to a buffer, and the other is length?) > > Could you elaborate more on "filter()"? Is that a library function for > which you have no code, something you have code for, or a flow diagram > you're trying to implement as code? > > Nigel > > > > On Nov 18, 2009, at 2:51 PM, Steven Cook wrote: > >> Thanks Nigel. >> >> I've been thinking very hard about your answer but don't understand... >> I'm >> thinking of the type of polyphase filter (decimator?) which has two >> inputs >> and one output. I assume that to downsample by a factor of 2, it's simply >> a >> question of doing: out = filter(in1, in2). When downsampling by a factor >> of >> 4, do I process my 4 input samples (in1, in2, in3, in4) like: >> >> temp1 = filter(in1, in2); >> temp2 = filter(in3, in4); >> out = filter(temp1, temp2); >> >> Or some other way? >> >> Regards, >> >> Steven Cook. >> http://www.spcplugins.com/ >> >> ----- Original Message ----- >> From: "Nigel Redmon" >> To: "A discussion list for music-related DSP" >> >> Sent: Wednesday, November 18, 2009 8:04 PM >> Subject: Re: [music-dsp] Polyphase Downsampling/Upsampling By 4, 8, 16... >> >> >>> Re-reading your question, Steven, I think the answer to your question is >>> "use a circular output buffer between stages", so you'll have enough >>> samples saved to run an iteration of the next stage. >>> >>> >>> On Nov 17, 2009, at 12:41 PM, Steven Cook wrote: >>> >>>> Hi, >>>> >>>> I'm experimenting with downsampling by a factor of 4 (8, 16...). I'd >>>> like >>>> to >>>> try polyphase downsampling but can't figure out how to 'wire together' >>>> 2 >>>> (or >>>> would it be 3?) polyphase filters between 4 (8. 16...) input samples >>>> and >>>> 1 >>>> output sample. Would someone give me a clue? While I'm here, does it >>>> matter >>>> in which order the 2 input samples are read into a polyphase filter? >>>> >>>> Regards, >>>> >>>> Steven Cook. >>>> http://www.spcplugins.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 laurent.de.soras at free.fr Thu Nov 19 06:36:57 2009 From: laurent.de.soras at free.fr (Laurent de Soras) Date: Thu, 19 Nov 2009 12:36:57 +0100 Subject: [music-dsp] Polyphase Downsampling/Upsampling By 4, 8, 16... In-Reply-To: <557839F1E0DF49C19E84BD17103BDD29@pc> References: <557839F1E0DF49C19E84BD17103BDD29@pc> Message-ID: <4B052DD9.8060908@free.fr> Steven Cook wrote: > > My question is: I would like to try using filters like this to downsample by > a factor of four (or more) but I'm unsure how to use two-input-one-output > filters in this way. Can the filters be used like this? (in1, in2, in3, in4 > are my 4 (oversampled) input samples) > > temp1 = filter(in1, in2) > temp2 = filter(in3, in4) > out = filter(temp1, temp2) You're right, but filters for both stages must be distinct ones : temp1 = filter1 (in1, in2) temp2 = filter1 (in3, in4) out = filter2 (temp1, temp2) You might be interested by the HIIR library - . The readme file explains how to design cascaded filters for upsampling or downsampling by a power-of-two ratio. -- Laurent de Soras | Ohm Force DSP developer & Software designer | Digital Audio Software http://ldesoras.free.fr | http://www.ohmforce.com From stevenpaulcook at tiscali.co.uk Thu Nov 19 16:35:39 2009 From: stevenpaulcook at tiscali.co.uk (Steven Cook) Date: Thu, 19 Nov 2009 21:35:39 -0000 Subject: [music-dsp] Polyphase Downsampling/Upsampling By 4, 8, 16... References: <557839F1E0DF49C19E84BD17103BDD29@pc> <4B052DD9.8060908@free.fr> Message-ID: <609DA3B6D24B4502A6F84F8951FBE7E0@pc> Hi Laurent, Many thanks for your answer. I was hoping that it might be possible to use just two polyphase filters for 4x downsampling but at least three filters is an improvement on my current arrangement. Thanks also for the link to your HIIR library, which I've downloaded and will study. Kind Regards, Steven Cook. http://www.spcplugins.com/ > You're right, but filters for both stages must be distinct > ones : > > temp1 = filter1 (in1, in2) > temp2 = filter1 (in3, in4) > out = filter2 (temp1, temp2) > > You might be interested by the HIIR library - > . The readme > file explains how to design cascaded filters for upsampling > or downsampling by a power-of-two ratio. > > > -- > Laurent de Soras | Ohm Force > DSP developer & Software designer | Digital Audio Software > http://ldesoras.free.fr | http://www.ohmforce.com From doug at musclefish.com Wed Nov 25 18:57:31 2009 From: doug at musclefish.com (Doug Keislar) Date: Wed, 25 Nov 2009 15:57:31 -0800 Subject: [music-dsp] Positions at Computer Music Journal Message-ID: <4B0DC46B.3010102@musclefish.com> [Apologies for cross-postings.] Positions at Computer Music Journal Computer Music Journal, MIT Press's definitive quarterly on computer music, invites applications for two positions: (1) an assistant editor for manuscript editing, and (2) an intern or editorial consultant for news and announcements. The positions have no geographical limitations, but native English fluency is required. Members of underrepresented groups are encouraged to apply, as are all other qualified applicants. For questions, please contact the Editor at cmj at mitpress.mit.edu. Applications and inquiries are accepted by email; send to cmj at mitpress.mit.edu with "[CMJ application]" in the subject line. Hard-copy applications are also accepted; send to Editor, Computer Music Journal, 2550 9th Street #207 B, Berkeley, CA 94710, USA. (Materials will not be returned.) Your application should include: 1. A brief letter explaining your interest and qualifications and specifying which of the two positions is of interest. 2. A curriculum vitae, including education, any publications, any editorial experience, a list of research areas of computer music in which you have competence or expertise, and a summary of mathematical and technical skills as well as musical training. 3. Names, phone numbers, addresses, and email addresses of references. 4. One or more samples of your writing (not necessarily published) on any topic related to computer music. 5. The date when you can start, preferably by January 2, 2010. We recommend that applications be submitted by December 4, 2009. Review of applications will continue until the position is filled. Detailed job descriptions follow. 1. Assistant Editor for Manuscript Editing Responsibilities focus on editing and preparing peer-reviewed manuscripts for submission to MIT Press for publication, including some communication with authors on technical topics regarding their articles. (This position does not include managing the peer-review process or seeking substantial revisions from authors.) The position entails approximately 60-120 hours per quarterly issue. Detailed requirements are listed below. Applicants should demonstrate both eagerness for success as an editor and a commitment to computer music. Because of the technical nature of many CMJ manuscripts, preference will be given to applicants who have a background in engineering, computer science, or related research areas. The ideal applicant will be able to comprehend and evaluate manuscripts on a wide variety of topics, so that he or she can edit each manuscript that has undergone the peer-review process to conform with the CMJ style and MIT Press publication standards. We are seeking a native speaker of English who has top-notch language skills and an eye for detail. The current editor for manuscript editing, Colby Leider, is stepping down for lack of time, owing to increased responsibilities in his academic department. We are sorry to see him leave after over a decade with the Journal. However, it is gratifying to witness his successful career development. He will be available to assist the new editor during the transition. Location: May live anywhere in the world Requirements: - Broad and deep knowledge of computer music - Master's degree or higher - At least a bachelor's degree or equivalent in a technical field (e.g., computer science, engineering, mathematics, sciences) - Musical training - Native English fluency and superb editing skills - Punctuality and attention to detail - Familiarity with Microsoft Word, LaTeX, and Adobe Photoshop Helpful: - Familiarity with foreign languages - Editing experience - Familiarity with the Chicago Manual of Style Responsibilities: - Communicate with CMJ Editor, authors, managing editor, and copyeditor - Assemble materials (documents, figures, captions, etc.) for each accepted manuscript, starting with the author?s final version. - Edit each manuscript for conformance to existing CMJ style - Email authors regarding editing questions and copyright matters - Collate multiple versions of manuscripts into a final document - Check bibliographic items for accuracy, completeness, and format; supply missing details - Deliver edited manuscripts on time for publication - Attend the annual CMJ editorial summit meeting (by phone, Skype, or in person) - Cultivate future manuscript submissions from potential authors Compensation: A small salary is available through a contract with MIT Press; contact the Editor. 2. Intern or Editorial Consultant for News and Announcements Responsibilities consist of gathering and carefully editing items for the Announcements and News sections near the beginning of the Journal. The position entails an average of approximately 20 hours per quarterly issue. Detailed requirements are listed below. The first year of the position will be treated as an internship, unless the appointee is exceptionally well qualified and has already achieved widespread recognition for his or her career in computer music. In that case, the appointee's title will be Editorial Consultant; otherwise, it will initially be Editorial Intern. This is a volunteer position: there is no financial compensation, but the appointee will gain experience in publishing, and will be able to participate in the "cutting edge" of the computer music field. The appointee will be listed by name on the inside front cover of each issue on which he or she works, and on the Journal's Web site. Applicants should demonstrate both eagerness for success as an editor and a commitment to computer music. Interests might include composition, performance, engineering, or research topics in the field. We are seeking a native speaker of English who has top-notch language skills and an eye for detail. A solid knowledge of the computer music field will be invaluable in ascertaining the priority of potential news items, as well as in editing the chosen items. The current editor of of news and announcements, Lonce Wyse, will be taking on other responsibilities with the Journal, and he will also be available to assist the appointee during the transition. Location: May live anywhere in the world Requirements: - Good knowledge of the computer music field - Bachelor's degree or higher - Native English fluency and excellent writing and editing skills - Punctuality and attention to detail - Familiarity with Microsoft Word Helpful: - Familiarity with other languages (German, French, Spanish, Italian, Japanese, etc.) - Editing experience - Familiarity with the Chicago Manual of Style - Familiarity with Adobe Photoshop Responsibilities: - Receive potential news items and announcements from Editor - Collect other items from Web, mailing lists, etc. - Send collected, unedited items to Editor for approval - Edit each item - Send edited items to Editor and Managing Editor as Microsoft Word files - Collect several pieces of artwork to accompany news items (such as photos, image files from the Web, or hard-copy illustrations in brochures) - Attend the annual CMJ editorial summit meeting (by phone, Skype, or in person)