[music-dsp] platform choice

contact contact at quikquak.com
Sun Nov 1 23:07:30 EST 2009

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?

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" <rbj at audioimagination.com>
To: "A discussion list for music-related DSP" <music-dsp at music.columbia.edu>
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
>> <Victor.Lazzarini at nuim.ie> 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 

More information about the music-dsp mailing list