4 ms·

I stumbled on FAUST while reading up on how to make VST plugins. It's incredibly concise for building signal processors and synths, as it removes nearly all of

I stumbled on FAUST while reading up on how to make VST plugins. It's incredibly concise for building signal processors and synths, as it removes nearly all of the tedious stuff; you just write functions to generate or act on a signal and plug them together in sequence or in parallel and it'll spit out a plugin to do the job. No boilerplate, no fiddling with the (very fiddly) VST SDK, etc. A C/C++ program is usually an order of magnitude longer than what a FAUST program would need to be.

eighthnate 9y ago
> A C/C++ program is usually an order of magnitude longer than what a FAUST program would need to be. That's true for all functional/scripting languages vs imperative languages. There is a study that was done years ago which came to the same conclusion as you did - "An Empirical Comparison of C, C++, Java, Perl, Python, Rexx, and Tcl".
- throwaway7645 9y ago
  http://page.mi.fu-berlin.de/prechelt/Biblio/jccpprtTR.pdf http://page.mi.fu-berlin.de/prechelt/Biblio/jccpprtTR.pdf
- SwellJoe 9y ago
  FAUST leads to shorter programs for a few reasons, one of them is certainly its pure functional nature. The other reasons I think FAUST programs are shockingly short: - It's a DSL for signal processing that overloads single character identifiers with commonly used signal processing functions (+ sums multiple signals, < splits into two signals, etc.). And, of course, it has a very powerful standard library of signal processing related functions. - The boilerplate for getting signals in and out are handled by the language/compiler, rather than the programmer. You don't need to setup a ring buffer to receive an input/output signal or whatever...FAUST does it automagically. Even with very helpful libraries, such as JUCE, you're still doing a lot of the same tasks for every new signal processing program. One could do these other two things in another language, even some imperative ones, I think. But, this is among the most concise tools for writing signal processing code I've seen. I only found it yesterday, so have only started reading the docs (and there's some math concepts I need to review before I can make sense out of some of the more advanced examples), but I was really struck by what a cool combination of pragmatism and purity FAUST is. It spits out the ugly stuff, so you can still readily use it in real world programs that are used by non-programmers. It's also got a real-time experimental environment, so you can tweak your program in semi-realtime and immediately hear and see results. And, by "see" results, I mean it has a diagramming tool that spits out a block diagram of your function(s). I'm amazed it took me this long to find FAUST, as I've been reading up on this kind of programming for a couple of weeks, and it seems pretty clear it's the best thing going.
frozenport 9y ago
Fuast gives you a C++ program.

eighthnate 9y ago

> A C/C++ program is usually an order of magnitude longer than what a FAUST program would need to be. That's true for all functional/scripting languages vs imperative languages. There is a study that was done years ago which came to the same conclusion as you did - "An Empirical Comparison of C, C++, Java, Perl, Python, Rexx, and Tcl".

throwaway7645 9y ago
http://page.mi.fu-berlin.de/prechelt/Biblio/jccpprtTR.pdf http://page.mi.fu-berlin.de/prechelt/Biblio/jccpprtTR.pdf
SwellJoe 9y ago
FAUST leads to shorter programs for a few reasons, one of them is certainly its pure functional nature. The other reasons I think FAUST programs are shockingly short: - It's a DSL for signal processing that overloads single character identifiers with commonly used signal processing functions (+ sums multiple signals, < splits into two signals, etc.). And, of course, it has a very powerful standard library of signal processing related functions. - The boilerplate for getting signals in and out are handled by the language/compiler, rather than the programmer. You don't need to setup a ring buffer to receive an input/output signal or whatever...FAUST does it automagically. Even with very helpful libraries, such as JUCE, you're still doing a lot of the same tasks for every new signal processing program. One could do these other two things in another language, even some imperative ones, I think. But, this is among the most concise tools for writing signal processing code I've seen. I only found it yesterday, so have only started reading the docs (and there's some math concepts I need to review before I can make sense out of some of the more advanced examples), but I was really struck by what a cool combination of pragmatism and purity FAUST is. It spits out the ugly stuff, so you can still readily use it in real world programs that are used by non-programmers. It's also got a real-time experimental environment, so you can tweak your program in semi-realtime and immediately hear and see results. And, by "see" results, I mean it has a diagramming tool that spits out a block diagram of your function(s). I'm amazed it took me this long to find FAUST, as I've been reading up on this kind of programming for a couple of weeks, and it seems pretty clear it's the best thing going.

frozenport 9y ago

Fuast gives you a C++ program.