Re: [LAD] Something like Processing for audio

Hallo,
Darren Landrum hat gesagt: // Darren Landrum wrote:

> Part of why I don't like any of those is that they create whole new
> languages, or use languages I've never touched.

Some use multi-purpose languages: Lua and Lisp. IMO these languages are
much nicer to work with in this realm than C++ directly, especially for
live coding etc. The fact, that Processing is using a simplified general
purpose language that is stripped from things like memory management is
largely responsible for its success.
 
> Also, processing compiles everything down to a standalone executable
> that can be distributed. Can any of those audio options do that?

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

> Of all of those Lua-AV looks the closest to what I see in my head. I
> just wish I could understand why I can't seem to communicate that all of
> these options miss the mark, in my opinion. I just don't get them.
> There's still too large of a learning curve that has nothing to do with
> math or DSP. Maybe Pd would be an option if it were possible for Pd to
> compile its patches out as standalone programs, which I understand can
> be done on OSX, but not on any other platform.

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.

> But even then, is Pd atomic enough that I can graphically build
> something like a filter from the most basic of elements like adders,
> multipliers, and delays and have it savable as a new Ugen or whatever
> Pd calls them?

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.

Alternatively you can write extensions in various other languages.
C/C++ of course (has to be compiled), Python, Lua, Scheme, etc.

> Unfortunately, my 64-bit system keeps me from trying the vast majority
> of these options out (that's another complaint I have, but that's
> another thread, and one we've already done I might add). I'm going to be
> switching to 32-bit soon, but first, I need to get some other work done.
> It'll probably happen sometime this week.

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

> How about I pose it this way: what tool will allow me to code any JACK
> client I want, with a custom GUI, with complete abstraction, by way of
> built-in methods that allow me to set options and define certain
> functions (like in that Processing tutorial video), allow the creation
> of DSP graphs (which support variable numbers of frames per node from
> the get-go, for easy oversampling support) with pre-defined as well as
> custom nodes created right there in the same editor, and then allow
> one-touch compilation and running, and then make it easy to package up
> the code for distribution to anyone who wants it?

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

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.

Ciao

-- 
Frank
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev