Hi all, First off, sorry for the long email, especially considering it's my first to this ML. I hope its length and long-windedness doesn't deter anybody from reading it. My next project announcement will definitely be shorter ;) .
I've recently started using FAUST. I started off with a relatively trivial (and currently somewhat naively implemented) toy (https://github.com/marcecj/stream_looper), and would like to ask for feedback on my second public FAUST project. Anyway, get it here: https://github.com/marcecj/faust_mbstereophony This implements an N-band Regalia-Mitra filter bank using third order Cauer filters (identical to lowpass3e in filter.lib). Specifically, it implements the "collapsed" structure seen in figure 9 (and 10a) in [0]. The project consists of four filter bank programs and one demo effect. See the README for details. I'd also like to explicitly point out that I did this mostly out of interest and don't have a particular use in mind, but will explore it eventually. [ Background: the demo effect (down-mixing individual bands of a stereo signal) was an idea from the final project in a DAFx class during my Bachelor studies a couple of years ago. The idea of using Regalia-Mitra filters to do the band-splitting came from the professor who teaches the class. I got a MATLAB prototype working fairly quickly, once I knew what to do, but the C++ version just didn't want to work (strictly speaking parts of it do work, but not the whole). I worked on it occasionally since then, and eventually, out of frustration, I wrote a Python/NumPy version, which also "just worked". Now thanks to FAUST, I finally have a working C++ version :) . ] Some caveats with the current implementation: - Strictly speaking this doesn't _really_ implement a Regalia-Mitra filter bank, because the structure does not consist of the all-pass sections proposed in [0]. Instead, the equivalent structure using LP and HP filters is used (i.e., A0 = LP + HP and A1 = LP - HP). I already have a C++ function that calculates the all-pass coefficients (necessary because you need to calculate the roots of the numerator of LP+HP), I just haven't wrapped it with the FAUST FFI yet. - The above also means that the implementation is not as efficient as it could be, which you can infer by looking at the figures referenced above and replacing all the single all-pass filters with LPs and HPs, which together have twice as many coefficients as both APs. - The 3rd order Cauer filters are not ideal for this filter structure. The problem is mainly that the high pass-band ripple in the LP causes the corresponding doubly complementary HP filter to have low stop-band suppression. You would need something like 7th order filters with a much lower pass-band ripple in order for both the LP and the HP to have good stop-band suppression. (Although I think it still sounds OK, it's just not ideal). However, to be reasonably efficient, I would need to use the AP structure as outlined above. - Compilation time is atrocious (AFAIK a new record, too). More on this below. I also wrote some library functions that might be nice to have in general (but might need to be renamed more systematically): - polynomial multiplication (convolution) of two expression lists, - polynomial multiplication (convolution) of two sets of buses, - a "rest" function to complement take(1,expr), - a function to reverse the order of an N-bus, and - a function to reverse the order of an expression list. The reason there are versions for expression lists and buses was that I rewrote the project to use expression lists to improve readability of the source code. At the same time, I thought that the bus versions might be useful in their own right, so I kept them. I would also like to use the opportunity to mention what I like and dislike about FAUST so far (not that enough people haven't already written about that, but still). What I like: - Functional DSP programming; the hygienic macro system in particular stands out. I didn't really have experience with (pure) functional programming before I started using FAUST, but being able to define the filter bank structure recursively was quite incredible; I think I had a small "moment of zen" after writing that code :) . I also loved being able to type down a recursive equation almost literally from the paper [0]. - The BDA is inspired :) . Being able to type out filter structures "just like that" is pretty neat. - I kind of like the fact that FAUST is really just a specification language, and that I get to express things in a compact and high-level way, while knowing that it will be compiled to a pre-optimised C++ program. And all that with OSC, MIDI, and a GUI for free. - Tied in with the above, I also kind of like the way FAUST libraries function in contrast to classical shared libraries, in that they are evaluated and optimised in the usage context as opposed to being pre-compiled blobs. It's an interesting compromise between code re-usability and performance. I think the first two points in combination (functional programming + BDA) are what I like most about FAUST. Overall FAUST seems to enable fast development, even with the compilation step (as long as the project is not too complex). As an example: I've recently tried to get into DAFx more seriously as a hobby and started off with "Effect Design, Part 1" by Dattorro. Obviously I implemented and listened to the algorithms presented (reverb, boost/cut filter, resonant low-pass), and every time it was fairly easy (almost trivial) to do. FAUST as a language "just works" for tasks like this. Also, it was cool to be able to use a normalised-ladder structure (as demoed by Julius Smith at the LAC2012) "just like that" simply by swapping iir() with iir_nl() and have the resulting filter sound better. To summarise: I'm sold :) . But now what I dislike: - Compilation times for complex projects *sucks*! Especially when there are UI controls. I mean, it's indefensible. No compiler should take anywhere near as long as the FAUST compiler does. What is going on that one of my programs takes an hour to compile (yes, *one hour*)? I honestly want to know. Furthermore, what can I do to reduce compilation time, without sacrificing UI controls? What is difficult for FAUST to optimize, and what is easy/easier? Any tips on getting DSPs to compile faster would be welcome. (in case it's unclear: I'm referring to compiling from FAUST to C) - The lack of frequency domain processing. This isn't important for me right now, but it sticks out. I also have some general questions/feature requests: - Related to the above performance complaint: are the -cuda/-opencl options in FAUST2 related to code generation (parallelisation?), or does the FAUST compiler itself then make use of CUDA/OpenCL? I suspect the former, but the --help output isn't quite clear to me. If it does speed up compilation, that might be a reason to upgrade my GPU (my Radeon HD 4650, using the r700 driver, will only partially support OpenCL, see [1]). - Would it be possible to fully vectorise recursive filters? Apparently there are many different approaches, e.g. [2] or [3]. Has any research gone into this? I think it would be a pretty cool feature to have. - Is there any consensus on what constitutes a good license for a FAUST library? I see in FAUST itself it's either LGPL or MIT-style. (Perhaps this is a silly question, but I always have a hard time deciding for myself and I usually just default to MIT.) I'm looking forward to any responses and/or answers to my questions. [0] P. A. Regalia, P. P. Vaidyanathan, M. Renfors, Y. Neuvo, and S. K. Mitra, "Tree-structured complementary filter banks using all-pass sections," IEEE Trans. Circuits and Systems, vol. 34, no. 12, pp. 1470–1484, December 1987. [1] http://dri.freedesktop.org/wiki/GalliumCompute, column "r700" [2] http://www.cosy.sbg.ac.at/~rkutil/publication/Kutil08b.pdf [3] http://ieeexplore.ieee.org/xpl/login.jsp?arnumber=116087 Greetings -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
_______________________________________________ Faudiostream-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/faudiostream-users
