hi @sletz, thanks for the response!
here’s just to say that i use faust in exactly this way for corporate clients - build a custom architecture “template” and UI class, and generate blocks for a larger c++ application as part of a build step. it has been a tremendously helpful tool esp in a rapid iteration/r+d context, when i can use other architecture files to e.g. generate matlab data for the same .dsp.
but there various issues large and small which prevent the wider use of the language in the application development process in my case [*]. a large-ish one is multirate support; i understand that it is WIP and am very grateful for the effort. but (for example) for super-low-groupdelay requirements i have to use weird non-uniform polyphase filters which are just a total mess or impossible to implement in Faust.
a minor but kinda expansive issue is the amount of post-processing that stilll seems inevitably necessary and has led to some ugly tooling after the faust compilation step. for (just one) example with small buffer sizes i end up having to factor out
virtual for performance. i haven’t had the bandwidth to make deeper changes than using a custom UI class and a custom architecture template.
and finally a kinda blue-sky wish is to incorporate better leverage of SIMD instruction sets in the output. currently as i understand it the output is pretty generic (which is great for other reasons) set of like: add, sub, div, mul, load, store, and a few std function calls like
powf (which i end up having to post-process or redefine with approximations appropriate to the variable range in question.) it adds up to a lot of faff after the cpp generation step.
but really, my complaint isn’t that it’s impossible or unfeasible to use faust for the building blocks (it’s great for that) - but, i always have a nagging feeling that the graph analysis stuff would do an even better job if it could “see” all the blocks at once. but when i try and factor some complicated routing/logic structure into Faust i just fail. because my brain is not good enough? functional paradigm is only a good match up to a point? a combination?
this and the last post are my extremely long-winded way of agreeing that any environment that completely forbids imperative/procedural programming is a hard sell for purely pragmatic reasons.
anyways sorry this is rather OT in a way but in another way it seems maybe valuable to compare/contrast existing approaches for JIT-compiled domain-specific DSP languages. i happen to be using Faust pretty frequently these days for different applications than academic/creative, so hope my thoughts are at least a little useful.
gen~ i find helpful for kinda other applications, like when it already makes sense to use max, but also it’s more immediate as a scratch/playground area and nice that it can work transparently in a phase vocoder.
[*] to be more specific: i’m working in the hearing-enhancement / hearing-aid area. the DSP has to run on processors ranging from x86, to minimal ARM with NEON, to webASM, and its great to have something that at least gets me 75% there. (there are proprietary DSP targets too, but thankfully my responsibilities end before that point.)