Faust version that is forked in Rebeltech github is 3+ years old, I suppose it’s what being used in web server. It also requires an ancient version of LLVM, which makes it not really suitable for compiling on a modern desktop.
- With current version of Faust I get tons of errors even on a trivial program if I try to compile Faust patches (i.e. even compiling something like “process = 1” would fail): error.log · GitHub
Note that this is similar to issue that got fixed a while ago by including an extra header file - Faust problems
I’ve got a trivial Faust program working with this patch: broken_faust.diff · GitHub
This #include <algorithm> is being added by faust in autogenerated patch file, adding it earlier prevents the conflict but it also requires undefining min/max macros. Another option that seems to work is to remove that include from patch file manually. But it’s added by Faust and I’m not sure if this can cause some other issues.
- When compiling non-trivial patches I get more conflicts - the exact errors depend on patch contents, but seem to be caused by Faust using trigonometric functions from std namespace, while they are defined in global namespace in basicmath.h . I may not understand this issue correctly, but at least replacing manually std::cos → cos, std::sin-> sin in FaustPatch.hpp resolved it.
Example error:
In file included from ./LibSource/Patch.h:5:0,
from ./Source/SampleBuffer.hpp:8,
from ./Source/PatchProgram.cpp:6:
./Build/Source/FaustPatch.hpp: In member function ‘virtual void mydsp::compute(int, float**, float**)’:
./LibSource/basicmaths.h:98:16: error: ‘arm_cos_f32’ is not a member of ‘std’
#define cos(x) arm_cos_f32(x)
^
./Build/Source/FaustPatch.hpp:1124:35: note: in expansion of macro ‘cos’
float fSlow19 = (fConst4 * std::cos((fConst5 * fSlow18)));
^~~
./LibSource/basicmaths.h:98:16: note: suggested alternative:
#define cos(x) arm_cos_f32(x)
^
./Build/Source/FaustPatch.hpp:1124:35: note: in expansion of macro ‘cos’
float fSlow19 = (fConst4 * std::cos((fConst5 * fSlow18)));
-
There’s some weirdness in reading parameters. Let’s say I move parameter with encoder from 0 to 0.5 and stop. If I move it backwards (towards 0), I see that it jumps in old direction (i.e. to 0.55) before it starts moving in reverse. This happens in Faust patches and in factory patches. I haven’t checked if actual numeric value is changed or it’s just a quirk in how values are displayed.
-
There’s another bug that only happens in Faust patches. Some parameters (A, C, E) are either stuck on min value when patch is initialized or stuck on max value if I move to it. This happens even I don’t use those parameters in patch.
-
If I read encoder parameter as gate, it works fine. But when I receive a gate from CV in one of the inputs, it looks like the value is constantly retriggering gate in my patch. I’m not sure why that would happen, but it looks like parameter value is getting reset. Haven’t tested this outside of Faust patches yet.
-
I’ve ran into situation where my parameters didn’t appear when program was running on device. Turns out, it happened due to this code: OwlProgram/owl.cpp at master · pingdynasty/OwlProgram · GitHub . Yes, “freq” and “gain” are fairly common parameter names.
