platform choice

[Thomaz Oliveira-2]

Hi,
I´m going to start some dsp coding and I need some advice,
Platform choice is my issue.
basically I would like an environment so I can intercharge codes with
other people specially in this comunity...
I would like it to have some built in funtions and it to be popular
among developers..
so people could help me out...
is matlab popular here in musicdsp??

thanks

Thomaz
--
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

[Luis Gustavo Martins-2]

Hi Thomaz,

In case you are into C++, have a look at Marsyas:

http://marsyas.sf.net

It's a pretty active and fairly documented audio analysis and  
processing framework, quite well known in the Music Information  
Retrieval (MIR) community.

I  hope this helps,

Cheers,

Gustavo

Luis Gustavo Martins
lgustavomartins@...



On 29 Oct, 2009, at 21:55 , Thomaz Oliveira wrote:

> Hi,
> I´m going to start some dsp coding and I need some advice,
> Platform choice is my issue.
> basically I would like an environment so I can intercharge codes with
> other people specially in this comunity...
> I would like it to have some built in funtions and it to be popular
> among developers..
> so people could help me out...
> is matlab popular here in musicdsp??
>
> thanks
>
> Thomaz
> --
> 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

[Thomaz Oliveira-2]

thanks a lot,
what do folks in here use most??

C++  is pretty cool.  I´m used to C programming...

thanks a lot

Thomaz
--
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

[richarddobson]

Matlab is ~very~ expensive - targetted at professional (industrial, etc)
developers. Unless you are fortunate enough to have free academic
access. Octave is a widely uses alternative, high level of
compatibility, but not completely (especially with regard to DSP). I am
not aware of an especially active user community though.

The most widely used/shared environment by far (for classic text-based
audio programming) is Csound. You can design dsp processes directly in
it, and then implement them (in C) as opcodes for efficiency. The
builtin functions (i.e. opcodes) are second-to-none (IMO). The user and
development communities are much overlapped, and very active in the
mailing lists.

Richard Dobson

Thomaz Oliveira wrote:

> Hi,
> I´m going to start some dsp coding and I need some advice,
> Platform choice is my issue.
> basically I would like an environment so I can intercharge codes with
> other people specially in this comunity...
> I would like it to have some built in funtions and it to be popular
> among developers..
> so people could help me out...
> is matlab popular here in musicdsp??
>
> thanks
>
> Thomaz
> --
> 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

[Victor Lazzarini]

As an alternative to MatLab, I would recommend looking at
Python plus its scientific libraries. They're pretty good.

Victor

On 30 Oct 2009, at 22:55, Richard Dobson wrote:

> Matlab is ~very~ expensive - targetted at professional (industrial,  
> etc)
> developers. Unless you are fortunate enough to have free academic
> access. Octave is a widely uses alternative, high level of
> compatibility, but not completely (especially with regard to DSP). I  
> am
> not aware of an especially active user community though.
>
> The most widely used/shared environment by far (for classic text-based
> audio programming) is Csound. You can design dsp processes directly in
> it, and then implement them (in C) as opcodes for efficiency. The
> builtin functions (i.e. opcodes) are second-to-none (IMO). The user  
> and
> development communities are much overlapped, and very active in the
> mailing lists.
>
> Richard Dobson
>
> Thomaz Oliveira wrote:
>> Hi,
>> I´m going to start some dsp coding and I need some advice,
>> Platform choice is my issue.
>> basically I would like an environment so I can intercharge codes with
>> other people specially in this comunity...
>> I would like it to have some built in funtions and it to be popular
>> among developers..
>> so people could help me out...
>> is matlab popular here in musicdsp??
>>
>> thanks
>>
>> Thomaz
>> --
>> 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

[Thomaz Oliveira-2]

well
I'm studing at a university and we have a matlab license, Unicamp in Brazil
do you you think that it has enough functions for audio programming??

I´m basically implement tube Ordinary Differencial Equations to model them...

Cheers
--
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

[robert bristow-johnson]

On Oct 30, 2009, at 7:38 PM, Thomaz Oliveira wrote:

> well
> I'm studing at a university and we have a matlab license, Unicamp  
> in Brazil
> do you you think that it has enough functions for audio programming??

if you're not doing real-time processing, it's fine.  so would a C or  
C++ environment, using std I/O and some boilerplate software to read  
and write sound files of whatever format.  i'm not sure, but perhaps  
MATLAB is only smart enough to I/O .wav files, but i dunno.

> I´m basically implement tube Ordinary Differencial Equations to  
> model them...


so is your desired platform something you want to do to sound files  
or something that you want to do to an electric guitar?

if the latter, maybe getting some Line6 pod and their SDK and coding  
it in a 56K.  you would still model and research with MATLAB, but if  
you don't mind porting it from MATLAB to 56K assembly (piece of  
cake), you can test it out with your yer axe and Line6 pod.

--

r b-j                  rbj@...

"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

[Charles Henry]

On Fri, Oct 30, 2009 at 5:33 PM, Thomaz Oliveira <thomazchaves@...> wrote:
> thanks a lot,
> what do folks in here use most??
>
> C++  is pretty cool.  I´m used to C programming...

If you're good at C, use Pure Data.  You can get a rudimentary signal
processing external written with just a few lines of code and an
appropriate template to get started.

I have had lots of fun coding signal processing effects in Pure Data.
It works well on Linux platforms.

Chuck

>
> thanks a lot
>
> Thomaz
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book reviews, dsp links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp
>

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp 
http://music.columbia.edu/mailman/listinfo/music-dsp

[Michael Gogins-2]

There is an embarrassment of riches.

You need to know what you are trying to do, in the sense of your ULTIMATE
goal. If that is to understand DSP or to research new methods, matlab is
good, Octave works, Mathematica works, C++ works. Faust (see below) might
work for you.

If you want to develop software instruments or effects to sell, you will
need to use C or C++ because only they truly are fast enough. I recommend
gcc (MinGW on Windows) because it is free and the code it makes seems about
as good as Microsoft C++. In production, to make money, I would want to use
the Intel compiler (which is better) and the Intel performance libraries.

Ditto, if you want to develop synthesizers.

If you want to develop stuff because ULTIMATELY you want to make music, use
Csound, Pure Data, or something like that. You can write plugins for these
systems in C or C++. (This is what I do!)

In any event, one of these systems makes an excellent test-bed for your
ideas developed in other ways.

In addition to writing plugins in C or C++, you can use Faust
(http://faust.grame.fr) which has its own DSP language that it translates
into C++ for various synthesis systems.

A workable alternative to C/C++ is functional programming, see Nyquist,
sndlib, etc. But you will not have the vast resources of stuff developed by
other people that you can read and use in C/C++.

Note well: military signal processing software, which is the state of the
art, is now written almost exclusively in C++. Commercial signal processing
software, mostly ditto.

Hope this helps,
Mike Gogins

----- Original Message -----
From: "Charles Henry" <czhenry@...>
To: "A discussion list for music-related DSP" <music-dsp@...>
Sent: Friday, October 30, 2009 9:16 PM
Subject: Re: [music-dsp] platform choice


On Fri, Oct 30, 2009 at 5:33 PM, Thomaz Oliveira <thomazchaves@...>
wrote:
> thanks a lot,
> what do folks in here use most??
>
> C++ is pretty cool. I´m used to C programming...

If you're good at C, use Pure Data.  You can get a rudimentary signal
processing external written with just a few lines of code and an
appropriate template to get started.

I have had lots of fun coding signal processing effects in Pure Data.
It works well on Linux platforms.

Chuck

>
> thanks a lot
>
> Thomaz
> --
> 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

[Ross Bencina-3]

Hi Thomaz:
>what do folks in here use most??

I mainly use C/C++ and a little IA32ASM now and then.

My impression is that when code gets posted here its usually in C or C++.
Rarely in matlab.

I'm sure there are big communities around 56K and SHARC dsp code (on other
mailing lists, on comp.dsp)

My impression is that matlab is popular in university research contexts, but
I've never seen it used by independent developers. If you need to publish
research papers /thesis with source code it might be a good option. I always
found it awkward to use compared to C/C++... but perhaps there are
advantages over C/C++ if you want to leverage the built-in functions and
libraries for analysis, filter design, graphing etc. SciPy is often cited as
an alternative.

PureData is one option if you want to code real-time processing in C,
another is to develop VST plugins -- I think there's a much wider user
audience for VST plugins (see kvraudio.com for example) than PD externals --  
but it depend how much you want to buy into the whole FOSS thing.

You might want to check out the #musicdsp irc channel .. there are people
floating around doing tube sim stuff there (also check out musicdsp.org if
you havn't already)

Just my 2 .au cents

Ross.


----
AudioMulch 2, now for Mac and PC
http://www.audiomulch.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

[richarddobson]

Ross Bencina wrote:

> Hi Thomaz:
>> what do folks in here use most??
>
> I mainly use C/C++ and a little IA32ASM now and then.
>
> My impression is that when code gets posted here its usually in C or C++.
> Rarely in matlab.
>
> I'm sure there are big communities around 56K and SHARC dsp code (on other
> mailing lists, on comp.dsp)
>

Funnily enough, few comp.dsp regulars post code or even maths (rbj being
a notable exception for both); it is mainly a question/answer list
expert to expert, peppered with the occasional flame war and complaints
about students (or suspected students) wanting solutions to homework
problems. And the occasional maverick who insists "dsp theory is all
wrong", etc. And a number of entertaining excursions into OT territory.
It is not a comfortable place for anyone who is relatively a novice, or
who is seen as not knowing what they are talking about. I've lurked for
many years, but have not yet, IIRC, actually asked a question there (but
have answered a few on music/audio topics, as one does). I find it
useful and stimulating for reading about techniques I have never heard
of before, much less know anything about. But I would not call it a
generous source of code examples.


> My impression is that matlab is popular in university research contexts, but
> I've never seen it used by independent developers. If you need to publish
> research papers /thesis with source code it might be a good option. I always
> found it awkward to use compared to C/C++... but perhaps there are
> advantages over C/C++ if you want to leverage the built-in functions and
> libraries for analysis, filter design, graphing etc. SciPy is often cited as
> an alternative.


It probably crops up on comp.dsp more than any other language. Matlab
can also be made to output code for the leading dsp chips (I think the
Sharc is supported, and one or more TI chips, not so sure about 56x).
And Simulink is  a module wire-up system that I think is also mainly
used in industry. So I would guess it is maybe 50/50 academia and
industry, overall. Companies such as Nvidia and Clearspeed produce
massively-parallel accelerator hardware with support libraries that can
hook into both Matlab and Mathematica, to enable it to run much faster.
Matlab is far from being only a tool for dsp. Statistics, financial
modelling etc etc etc also figure largely.

But for the truly independent developer, matlab is simply too expensive
to consider (you would have to buy at least the DSP Toolkit on top), and
the other choices mentioned, particularly Octave and Scilab, are
correspondingly popular. A custom version of Scilab was supplied with
the SDK for the Chameleon 56K-based audio system.

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

[richarddobson]

I wrote:
..
> Funnily enough, few comp.dsp regulars post code or even maths (rbj being
> a notable exception for both);


...and he has just posted a terrific reply to a short comment of mine in
a thread on the subject of, in essence, are imaginary numbers "real"?
Nothing comes even close to comp.dsp in "mathological" debates of that kind.

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

[Didier Dambrin]

I think there are 2 kinds of people here, programmers (like me, except that
I picked the wrong language) who know how to program in general and came to
DSP afterwards, and had never heard of Matlab or anything like that, and
then people with a scientific background who first learnt about DSP & then
the practice.

There can only be some kind of miscommunication between both. When I read
papers I rarely find readable code, most often formulas in scientific
notation I can't read. 2 different worlds with different knowledge &
different approaches.


(I've also noticed that people with a scientific background sometimes like
to write about hot hair, especially in their school thesis (but that's
normal afterall) :)
So when you read some online paper that's someone's thesis, it's to be taken
lightly as what's described most likely doesn't work very well in practice)

> Ross Bencina wrote:
>> Hi Thomaz:
>>> what do folks in here use most??
>>
>> I mainly use C/C++ and a little IA32ASM now and then.
>>
>> My impression is that when code gets posted here its usually in C or C++.
>> Rarely in matlab.
>>
>> I'm sure there are big communities around 56K and SHARC dsp code (on
>> other
>> mailing lists, on comp.dsp)
>>
>
> Funnily enough, few comp.dsp regulars post code or even maths (rbj being
> a notable exception for both); it is mainly a question/answer list
> expert to expert, peppered with the occasional flame war and complaints
> about students (or suspected students) wanting solutions to homework
> problems. And the occasional maverick who insists "dsp theory is all
> wrong", etc. And a number of entertaining excursions into OT territory.
> It is not a comfortable place for anyone who is relatively a novice, or
> who is seen as not knowing what they are talking about. I've lurked for
> many years, but have not yet, IIRC, actually asked a question there (but
> have answered a few on music/audio topics, as one does). I find it
> useful and stimulating for reading about techniques I have never heard
> of before, much less know anything about. But I would not call it a
> generous source of code examples.
>
>
>> My impression is that matlab is popular in university research contexts,
>> but
>> I've never seen it used by independent developers. If you need to publish
>> research papers /thesis with source code it might be a good option. I
>> always
>> found it awkward to use compared to C/C++... but perhaps there are
>> advantages over C/C++ if you want to leverage the built-in functions and
>> libraries for analysis, filter design, graphing etc. SciPy is often cited
>> as
>> an alternative.
>
>
> It probably crops up on comp.dsp more than any other language. Matlab
> can also be made to output code for the leading dsp chips (I think the
> Sharc is supported, and one or more TI chips, not so sure about 56x).
> And Simulink is  a module wire-up system that I think is also mainly
> used in industry. So I would guess it is maybe 50/50 academia and
> industry, overall. Companies such as Nvidia and Clearspeed produce
> massively-parallel accelerator hardware with support libraries that can
> hook into both Matlab and Mathematica, to enable it to run much faster.
> Matlab is far from being only a tool for dsp. Statistics, financial
> modelling etc etc etc also figure largely.
>
> But for the truly independent developer, matlab is simply too expensive
> to consider (you would have to buy at least the DSP Toolkit on top), and
> the other choices mentioned, particularly Octave and Scilab, are
> correspondingly popular. A custom version of Scilab was supplied with
> the SDK for the Chameleon 56K-based audio system.
>
> 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.40/2471 - Release Date: 10/31/09
07:53:00

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp 
http://music.columbia.edu/mailman/listinfo/music-dsp

[Victor Lazzarini]

you're dead right: two worlds. A while ago when I used to only use C  
or C++ to prototype ideas, some engineer friends looked at me as if I  
was some kind of freak. Matlab is for prototyping, they'd say. But I  
could never get into it, never felt like a proper programming language.

When I discovered Python & its libraries, it was just right for me. A  
nice, readable language and good tools for graphics, etc.. So now for  
much of what I do I write Python scripts to go with it.

I am also considering extending my range and starting to use SAGE,  
which might just have the tools for some things I was contemplating  
doing in the past.

Interesting reading these posts, because I had the impression lots of  
folks here would favour Matlab, but it does not seem to be the case.

As an aside, for someone interested in a tutorial on using free tools by
Julius Smyth
http://lac.linuxaudio.org/2008/download/papers/22.pdf

Regards

Victor



On 31 Oct 2009, at 11:31, Didier Dambrin wrote:

> I think there are 2 kinds of people here, programmers (like me,  
> except that
> I picked the wrong language) who know how to program in general and  
> came to
> DSP afterwards, and had never heard of Matlab or anything like that,  
> and
> then people with a scientific background who first learnt about DSP  
> & then
> the practice.
>
> There can only be some kind of miscommunication between both. When I  
> read
> papers I rarely find readable code, most often formulas in scientific
> notation I can't read. 2 different worlds with different knowledge &
> different approaches.
>
>
> (I've also noticed that people with a scientific background  
> sometimes like
> to write about hot hair, especially in their school thesis (but that's
> normal afterall) :)
> So when you read some online paper that's someone's thesis, it's to  
> be taken
> lightly as what's described most likely doesn't work very well in  
> practice)
>
>
>
>
>
>
>> Ross Bencina wrote:
>>> Hi Thomaz:
>>>> what do folks in here use most??
>>>
>>> I mainly use C/C++ and a little IA32ASM now and then.
>>>
>>> My impression is that when code gets posted here its usually in C  
>>> or C++.
>>> Rarely in matlab.
>>>
>>> I'm sure there are big communities around 56K and SHARC dsp code (on
>>> other
>>> mailing lists, on comp.dsp)
>>>
>>
>> Funnily enough, few comp.dsp regulars post code or even maths (rbj  
>> being
>> a notable exception for both); it is mainly a question/answer list
>> expert to expert, peppered with the occasional flame war and  
>> complaints
>> about students (or suspected students) wanting solutions to homework
>> problems. And the occasional maverick who insists "dsp theory is all
>> wrong", etc. And a number of entertaining excursions into OT  
>> territory.
>> It is not a comfortable place for anyone who is relatively a  
>> novice, or
>> who is seen as not knowing what they are talking about. I've lurked  
>> for
>> many years, but have not yet, IIRC, actually asked a question there  
>> (but
>> have answered a few on music/audio topics, as one does). I find it
>> useful and stimulating for reading about techniques I have never  
>> heard
>> of before, much less know anything about. But I would not call it a
>> generous source of code examples.
>>
>>
>>> My impression is that matlab is popular in university research  
>>> contexts,
>>> but
>>> I've never seen it used by independent developers. If you need to  
>>> publish
>>> research papers /thesis with source code it might be a good  
>>> option. I
>>> always
>>> found it awkward to use compared to C/C++... but perhaps there are
>>> advantages over C/C++ if you want to leverage the built-in  
>>> functions and
>>> libraries for analysis, filter design, graphing etc. SciPy is  
>>> often cited
>>> as
>>> an alternative.
>>
>>
>> It probably crops up on comp.dsp more than any other language. Matlab
>> can also be made to output code for the leading dsp chips (I think  
>> the
>> Sharc is supported, and one or more TI chips, not so sure about 56x).
>> And Simulink is  a module wire-up system that I think is also mainly
>> used in industry. So I would guess it is maybe 50/50 academia and
>> industry, overall. Companies such as Nvidia and Clearspeed produce
>> massively-parallel accelerator hardware with support libraries that  
>> can
>> hook into both Matlab and Mathematica, to enable it to run much  
>> faster.
>> Matlab is far from being only a tool for dsp. Statistics, financial
>> modelling etc etc etc also figure largely.
>>
>> But for the truly independent developer, matlab is simply too  
>> expensive
>> to consider (you would have to buy at least the DSP Toolkit on  
>> top), and
>> the other choices mentioned, particularly Octave and Scilab, are
>> correspondingly popular. A custom version of Scilab was supplied with
>> the SDK for the Chameleon 56K-based audio system.
>>
>> 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.40/2471 - Release Date:  
> 10/31/09
> 07:53:00
>
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book  
> reviews, dsp links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp

--
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

[contact-68]

For me, code needs to be fast to be competitive. And that's about it - well
it also has to work. : )

So when I see math software like Matlab, it just appears to be the ultimate
procrastination!
Now that I've built up a bunch of C++ filter and effect classes, I can
prototype quickly and as closely to the finished product as possible.

But that's not helping Thomaz much.

Matlab's comunity forums and blogs are extensive, and there appears to be a
large file exchange system.
For example, here someone posted a real-time filter and designer with GUI:-
http://www.mathworks.com/matlabcentral/fileexchange/24654-real-time-filters-gui

Personally I can't read it, and its black-box approach to functions like
Chebyshev filters for example, means that I learn nothing about the
processes.
Matlab's a maths tool of course - why code a filter if you can just call a
function, so you'll find most examples don't give away much low level DSP
secrets.

This free book is a great introduction to what goes on under the hood:
http://www.dspguide.com/


Dave H.


----- Original Message -----
From: "Victor Lazzarini" <Victor.Lazzarini@...>
To: "A discussion list for music-related DSP" <music-dsp@...>
Sent: Saturday, October 31, 2009 1:14 PM
Subject: Re: [music-dsp] platform choice

> you're dead right: two worlds. A while ago when I used to only use C
> or C++ to prototype ideas, some engineer friends looked at me as if I
> was some kind of freak. Matlab is for prototyping, they'd say. But I
> could never get into it, never felt like a proper programming language.
>
> When I discovered Python & its libraries, it was just right for me. A
> nice, readable language and good tools for graphics, etc.. So now for
> much of what I do I write Python scripts to go with it.
>
> I am also considering extending my range and starting to use SAGE,
> which might just have the tools for some things I was contemplating
> doing in the past.
>
> Interesting reading these posts, because I had the impression lots of
> folks here would favour Matlab, but it does not seem to be the case.
>
> As an aside, for someone interested in a tutorial on using free tools by
> Julius Smyth
> http://lac.linuxaudio.org/2008/download/papers/22.pdf
>
> Regards
>
> Victor
>
>
>
> On 31 Oct 2009, at 11:31, Didier Dambrin wrote:
>
>> I think there are 2 kinds of people here, programmers (like me,
>> except that
>> I picked the wrong language) who know how to program in general and
>> came to
>> DSP afterwards, and had never heard of Matlab or anything like that,
>> and
>> then people with a scientific background who first learnt about DSP
>> & then
>> the practice.
>>
>> There can only be some kind of miscommunication between both. When I
>> read
>> papers I rarely find readable code, most often formulas in scientific
>> notation I can't read. 2 different worlds with different knowledge &
>> different approaches.
>>
>>
>> (I've also noticed that people with a scientific background
>> sometimes like
>> to write about hot hair, especially in their school thesis (but that's
>> normal afterall) :)
>> So when you read some online paper that's someone's thesis, it's to
>> be taken
>> lightly as what's described most likely doesn't work very well in
>> practice)

--
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

[Eric Brombaugh-2]

On Oct 31, 2009, at 3:06 AM, Richard Dobson wrote:

> Funnily enough, few comp.dsp regulars post code or even maths (rbj  
> being
> a notable exception for both); it is mainly a question/answer list
> expert to expert, peppered with the occasional flame war and  
> complaints
> about students (or suspected students) wanting solutions to homework
> problems. And the occasional maverick who insists "dsp theory is all
> wrong", etc. And a number of entertaining excursions into OT  
> territory.
> It is not a comfortable place for anyone who is relatively a novice,  
> or
> who is seen as not knowing what they are talking about. I've lurked  
> for
> many years, but have not yet, IIRC, actually asked a question there  
> (but
> have answered a few on music/audio topics, as one does). I find it
> useful and stimulating for reading about techniques I have never heard
> of before, much less know anything about. But I would not call it a
> generous source of code examples.

This is an excellent 'nutshell' description of comp.dsp. I've been  
lurking there for more than a decade and although I occasionally  
answer questions on topics I know about, I've never asked a question -  
seems like there are too many sharks in the waters. It's a great way  
to broaden one's view though.

>> My impression is that matlab is popular in university research  
>> contexts, but
>> I've never seen it used by independent developers.
>
> It probably crops up on comp.dsp more than any other language. Matlab
> can also be made to output code for the leading dsp chips (I think the
> Sharc is supported, and one or more TI chips, not so sure about 56x).
> And Simulink is  a module wire-up system that I think is also mainly
> used in industry.

I use Matlab & Simulink heavily in my day job to model wireless  
systems. Although I have done a little bit of off-line synthesis stuff  
with it, as well as filter design for some audio projects, I've never  
really thought of it as a particularly musical tool. Maybe it's just  
that it seems like work to me.

> But for the truly independent developer, matlab is simply too  
> expensive
> to consider (you would have to buy at least the DSP Toolkit on top),  
> and
> the other choices mentioned, particularly Octave and Scilab, are
> correspondingly popular. A custom version of Scilab was supplied with
> the SDK for the Chameleon 56K-based audio system.

Matlab is not cheap - I believe that the total cost of the my current  
license probably approaches $10k, and annual maintenance is on the  
order of $2k. Octave is an excellent FOSS alternative to Matlab though  
and is _almost_ code compatible - there are enough minor differences  
to be frustrating, so it's best to pick one or the other and not try  
to write code for both.

Eric

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp 
http://music.columbia.edu/mailman/listinfo/music-dsp

[contact-68]

> On Oct 31, 2009, at 3:06 AM, Richard Dobson wrote:
>
>> Funnily enough, few comp.dsp regulars post code or even maths (rbj  
>> being
>> a notable exception for both); it is mainly a question/answer list
>> expert to expert, peppered with the occasional flame war and  
>> complaints
>> about students (or suspected students) wanting solutions to homework
>> problems. And the occasional maverick who insists "dsp theory is all
>> wrong", etc. And a number of entertaining excursions into OT  
>> territory.
>> It is not a comfortable place for anyone who is relatively a novice,  
>> or
>> who is seen as not knowing what they are talking about. I've lurked  
>> for
>> many years, but have not yet, IIRC, actually asked a question there  
>> (but
>> have answered a few on music/audio topics, as one does). I find it
>> useful and stimulating for reading about techniques I have never heard
>> of before, much less know anything about. But I would not call it a
>> generous source of code examples.
>
> This is an excellent 'nutshell' description of comp.dsp. I've been  
> lurking there for more than a decade and although I occasionally  
> answer questions on topics I know about, I've never asked a question -  
> seems like there are too many sharks in the waters. It's a great way  
> to broaden one's view though.

But he forgot to mention Vlad the Impaler!
; )

And there's the odd spam tidal wave that hits it.

But, yeah, despite that, 'comp.dsp' is great.










--
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

[richarddobson]

contact wrote:
..

> Matlab's comunity forums and blogs are extensive, and there appears to be a
> large file exchange system.
> For example, here someone posted a real-time filter and designer with GUI:-
> http://www.mathworks.com/matlabcentral/fileexchange/24654-real-time-filters-gui
>
> Personally I can't read it, and its black-box approach to functions like
> Chebyshev filters for example, means that I learn nothing about the
> processes.
> Matlab's a maths tool of course - why code a filter if you can just call a
> function, so you'll find most examples don't give away much low level DSP
> secrets.

The only thing I would say about this is that you won't necessarily
learn much "about Chebyshev filters" by reading source code either
(whether in Matlab-ese or C, for that matter). You may see the code is
using cosh here, and tanh there; what the code won't tell you is ~why~.
  Tools like Matlab are very much aimed at R&D and rapid prototyping -
that is, to use it you already need to know about Chebyshev filters (and
  about the maths involved); and why you would choose them (or avoid
them) over elliptical or Butterworth. Hence, books and study! Still
working on it...

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

[robert bristow-johnson]

On Oct 31, 2009, at 10:34 AM, contact wrote:

> Personally I can't read it, and its black-box approach to functions  
> like
> Chebyshev filters for example, means that I learn nothing about the
> processes.

so what do you wanna learn about Tchebyshev filters?  if you said  
Elliptical filters, i would say "tough luck, get a damn textbook that  
tells you something about the Jacobi elliptical function and then get  
that book "Digital Filters" (can't remember the author) who has a big  
messy appendix doing the math details).

the first issue is to learn how Tchebyshev functions (which turn out  
to be polynomials) work.  then how to make them do something for you  
with a rational function of s (the Type 1 and Type 2 Tchebyshev  
filters).  then how to get the poles and zeros (from which analog  
coefficients are derived).  then convert to digital with bilinear  
transform.  like the Butterworth (which is really a special case of  
either the Type 1 or 2 Tchebyshev), the math is straightforward.

--

r b-j                  rbj@...

"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

[Andrew Capon]

Ah, is that what comp.dsp is like then!

On 31 Oct 2009, at 16:04, robert bristow-johnson wrote:

>
> On Oct 31, 2009, at 10:34 AM, contact wrote:
>
>> Personally I can't read it, and its black-box approach to functions
>> like
>> Chebyshev filters for example, means that I learn nothing about the
>> processes.
>
> so what do you wanna learn about Tchebyshev filters?  if you said
> Elliptical filters, i would say "tough luck, get a damn textbook that
> tells you something about the Jacobi elliptical function and then get
> that book "Digital Filters" (can't remember the author) who has a big
> messy appendix doing the math details).
>
> the first issue is to learn how Tchebyshev functions (which turn out
> to be polynomials) work.  then how to make them do something for you
> with a rational function of s (the Type 1 and Type 2 Tchebyshev
> filters).  then how to get the poles and zeros (from which analog
> coefficients are derived).  then convert to digital with bilinear
> transform.  like the Butterworth (which is really a special case of
> either the Type 1 or 2 Tchebyshev), the math is straightforward.
>
> --
>
> r b-j                  rbj@...
>
> "Imagination is more important than knowledge."
>
>
>
>
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book  
> reviews, dsp links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp 
http://music.columbia.edu/mailman/listinfo/music-dsp