Faust: Functional programming language for real-time DSP and synthesis(faust.grame.fr)
faust.grame.fr
Faust: Functional programming language for real-time DSP and synthesis
http://faust.grame.fr/about/
10 comments
I missed the previous HN discussion of FAUST, but your comment led me to dig it up; it's good: https://news.ycombinator.com/item?id=13012880
Has some good links to relevant textbooks and MOOCs on the topic.
Has some good links to relevant textbooks and MOOCs on the topic.
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.
> 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".
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".
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.
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.
Much of Julius O. Smith III's work is done in Faust, if you're interested in seeing how Faust is used in research: https://scholar.google.com/citations?hl=en&user=Dx1EblMAAAAJ
I've been using csound as the audio engine for my Android apps but I'm looking at Faust for my new one because csound has a fairly limiting library in terms of where and how events need to be attached. With Faust I can place it in my own jni library and import and call the dsp method even if it's from deep within a nested custom view.
Have you considered libpd, the embeddable version of Puredata?
I've used Faust for a few months two years ago and I plan to use it again to write audio DSP apps. It's very powerful and expressive, and targeting many different systems/platforms is no problem. I have used generated C code on bare-metal ARM Cortex M4F platform, which is some distance away of original scope of Faust project. It was fairly easy to do. The documentation is also well written and comprehensive, it gives you very nice introduction into functional languages, time-domain DSP, as well as explanation of some common applications (pitch detector, panner...).
Two downsides I noticed (maybe they are fixed in the mean time?) are error messages and block composition. Because of the way Faust compiler works, error messages are long and not very meaningful. Some expressions are merged and simplified before error is triggered, so it's difficult correlate the expression in error output with your source code.
The other problem is that once you have the basic blocks and want to merge them into complex system, the syntax suddenly gets in your way. You have to introduce dummy wires in some blocks just to pass-through signal to its destination. The compiler can output graphical representation of code, but it would sometimes be much easier to use visual tool like the Simulink or LabView. Perhaps this is just tooling issue, but I found language syntax to be confusing and not scaling up properly.