What is your development setup?

[brownerthanu]

Hi all,

I'm getting started in DSP and I'm interested in what setup/workflow you use for dsp development. Do you start in an interpreted environment (e.g. Matlab) and then move to C or do you do everything in C? If you work in Matlab, is there an easy way to manipulate parameters in realtime? Any advice about good practices for DSP development?

[brownerthanu]

I've noticed that there are a lot of view of the topic but no responses. Is this 1) a silly question 2) not easily answerable 3) been answered many times before? I'm just curious about how people make the transition from prototyping to polished result. Do you do them in different environments? Are there environments that are better for prototyping that make the transition easier? I'd be grateful for any input.

[Mike Janney]

That's pretty much my workflow, prototype/analyze things in Matlab and then move over to C++. If it is a heavy scalar calculation for Matlab I invoke the C++ compiler, let Matlab call the resulting .exe and then read the output float buffers into Matlab for further processing. This also helps keep the code updated between Matlab/C++.

[DaveHoskins]

I'm primarily creating plug-ins, so for FX I have a plug-in test bench. Which is basically a large window with 30 dials underneath.
I built up a collection of filters and effects as C++ classes that can be instanced easily, as well as commented out. That way I know exactly how fast they'll be in the final plug-in as well as testing in a host's sample frame process.
The window can display anything I want of course and has FFT plots and various line drawing loops that display information and text.
The generic dials can be easily hooked into what ever I'm playing with at the time, by reading the VST parameters.
It wasn't long before I had collected a shedload of fx classes that can be plugged into other developments later, without having to change language.
But then again I don't know Matlab, many example Matlab scripts are obfuscated and difficult to follow, not to mention all the calls to it's black box library functions. It seemed like a waste of time for me personally, others will argue vehemently of course!

[davidguda]

For me it is c++ only. I don't have matlab, I don't know how to program it and it is going to be C++ in the end anyhow so I don't see the need for it.
As I develop on mac Xcode is where I do all my work.

[brownerthanu]

Thans so much for the information, guys. This is super helpful! It's great get an idea of what experienced folks are doing!

[mkdr]

Isn't Matlab super expensive too?

[brownerthanu]

Isn't Matlab super expensive too?

Yes, at full price. But if you can get it through an academic institution it can be relatively cheap or, sometimes, free.

[karrikuh]

Isn't Matlab super expensive too?

There are a number of free alternatives/clones, most prominently GNU Octave
http://www.octave.org
For most DSP stuff, it's just as good as MATLAB bar the IDE which IMHO is the only part of MATLAB that doesn't suck. The "programming" language is just a joke (like array indices starting at 1, to name only a small annoyance).

Personally I much prefer SciPy (aka "Scientific Python")
http://www.scipy.org
which is an open source library package for scientific computing (i.e. the stuff MATLAB does) on top of the very popular Python programming language. Learning Python is always worth it not only for DSP prototyping but everything else, because it's a very powerful general purpose language.

Really, no need to waste money on a MATLAB license!

[mystran]

I tend to use Maxima (and occasionally Wolfram Alpha) because I like to be different.

[Amusesmile]

Only c++. Agreeing with davidguda, I find prototyping it in Matlab/Octave and then translating it is much more complicated than just writing it in c++ from the beginning. If you get fast enough at creating classes and build up a library of fundamental tools (interpolator, oscillators, white noise, delay line, different types of filters, etc.) you can prototype and debug very quickly. Another thing that helps is the ability to set up a fast GUI to mess around with parameters in real-time (not going to happen in Matlab). It's kind of strange for audio, but a friend of mine wrote what I think is the easiest c++ GUI library available as an extension to Cinder, so I use it for everything. Honestly, I'm developing RE's as part of Unfiltered Audio and I send out little Cinder apps as prototypes so the other guys can see what I'm working on. It's unconventional, but here's a tutorial/justification if anyone is interested: http://www.amusesmile.com/?p=339

Also this page is disorganized and old but it taught me a hell of a lot: http://musicdsp.org/archive.php?classid=0

[ro.cking]

I recommend JesuSonic. It can be used either as standalone, VST, or as part of REAPER. It keeps you away from any technicalities and lets you dive right into the DSP part. It is very simple, however it is also somehow limited on what you can do (not object oriented, no functions, etc.) so once you have the basics of DSP developed in JesuSonic, say a simple EQ, compressor, or what-ya-want you can climb up the ladder to deal with the surrounding environment such as VST or standalone application.

[mahaya]

Another thing that helps is the ability to set up a fast GUI to mess around with parameters in real-time (not going to happen in Matlab).

I'm doing exactly that using guide in Matlab. I generally prefere the workflow in Matlab (except for easy stuff) but in the end this is a matter of personal taste and workflow.


Chris

[Amusesmile]

I stand corrected- completely forgot about Matlab's GUI capabilities when I wrote that. Many pardons. Thanks mahaya.

[Caco]

I generally start off in Csound and then move to C++ from there. I also use R if there is anything I want to analyse or graph in more detail.