[LAD] Something like Processing for audio

Darren Landrum darren.landrum at sbcglobal.net
Sun Sep 28 18:11:37 UTC 2008


Frank Barknecht wrote:
> Faust can, but: Is it really important? And why would it be important
> (taking aside speed issues)? 

Speed is a large part of it, yes.

Another reason to stick to C++ is for things that need the speed and 
low-level abilities, like on-demand sample streaming from disk for 
making a sampler.

> You're probably thinking of Max/MSP, but Pd cannot export binary
> executables. It's not a feature that I consider important anyway.
> Interpreted languages rule a big part of the FLOSS world. Exporting
> binaries is important for some Max-users because a) they can give their
> Max patches to people without Max and b) they can obfuscate their
> patches so that other users don't see their patchings tricks. Both a)
> and b) are not of much relevance in an open source world.

I'm pretty darn sure I read that Pd can export patches to some sort of 
standalone state on OSX, but I could have misunderstood.

> Yes: Every Pd patch can be reused in other patches as a so called
> abstraction, which is a bit like a module or funciton in a normal
> programming language. I have literally thousands of abstractions on my
> disk.

Okay, one point to Pd. So far, so good.

> The latest versions of Pd now work on 64-bit systems as well.

Pd-vanilla can (and I do have it working), but Pd-extended still cannot. 
I've been on their mailing list about this issue, and they insist that 
the version being worked on will work 64-bit, but I don't know when that 
will happen.

Nevertheless, there are lots of other programs, some not music-related, 
that cannot work (or have issues working) in 64-bit, necessitating a 
switch. That has little to do with Pd, really.

> If you skip the compilation part, Pd (or the other environments I
> mentioned, Pd is just one example) can do all that. Just bundle the
> Pd binary and a sh-script with your Pd application to distribute it, if
> you want. (I would prefer an unbundled download as I already have Pd.)

Does Pd do oversampling? I seem to recall it can. I keep bringing this 
up because several of the things I want to work on, namely lumped 
modeling/wave digital filters and non-linear processing, both require 
oversampling to work right, largely to avoid frequency warping and 
aliasing issues.

> If you dislike graphical coding then I guess Faust is a good option. I
> think, having a kind of IDE for Faust similar to the one of Processing
> might be useful.

On the contrary, I might even prefer graphical programming if I could 
finally get everything working right. Right now, I'm also dealing with 
hardware issues (my soundcard went bad), which is one other reason I can 
only read about this stuff and ask questions rather than trying it out.

And again, that ignores the fact that Faust does not currently support 
oversampling, and neither does Supercollider. I think CLM does, though. 
I realize that I seem to be the only one with that itch, but isn't that 
the point of open source? I want to make what I want because I have my 
own itch to scratch.

A Processing-alike for audio can also integrate and abstract away things 
like LASH support, MIDI, and OSC. Something like LASH (session state 
saving, see the other current thread) is an important capability in my 
world.

Really, the Synthesis Toolkit (STK) is already quite close to the mark, 
if it could be made to be easily extensible (it probably already is) and 
that whole "integrated editor/compilation control" paradigm could be 
brought to it, along with some extra abstractions for LASH, FFTW, and 
some other common libraries. We'd also need to add DSP graph 
construction, along with that variable frame size thing I mentioned 
before (I refuse to say the o***s******* word again in this email). :-)

Okay, that's a big enough email for now. Thanks for letting me rant.

-- Darren Landrum




More information about the Linux-audio-dev mailing list