Re: [LAD] Something like Processing for audio

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

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Mon Sep 29 00:15:03 2008