Faust problems

OWL Patches
#28

I’ve been rebuilding latest Faust2 and ended up with a failure related to min/max macro clashing with some stuff from libnewlib sources. Rolling back to a version about a week older fixed it for me.

For reference, this is the error log I’ve got:

Building patch AutoWah
In file included from /usr/include/newlib/c++/5.4.1/bits/char_traits.h:39:0,
                 from /usr/include/newlib/c++/5.4.1/string:40,
                 from ./Build/Source/FaustPatch.hpp:84,
                 from ./Build/registerpatch.h:1,
                 from ./Source/PatchProgram.cpp:7:
/usr/include/newlib/c++/5.4.1/bits/stl_algobase.h:243:56: error: macro "min" passed 3 arguments, but takes just 2
     min(const _Tp& __a, const _Tp& __b, _Compare __comp)
                                                        ^
/usr/include/newlib/c++/5.4.1/bits/stl_algobase.h:265:56: error: macro "max" passed 3 arguments, but takes just 2
     max(const _Tp& __a, const _Tp& __b, _Compare __comp)
                                                        ^
In file included from ./LibSource/Patch.h:4:0,
                 from ./Source/SampleBuffer.hpp:6,
                 from ./Source/PatchProgram.cpp:3:
/usr/include/newlib/c++/5.4.1/bits/stl_algobase.h:195:5: error: expected unqualified-id before 'const'
     min(const _Tp& __a, const _Tp& __b)
     ^
/usr/include/newlib/c++/5.4.1/bits/stl_algobase.h:195:5: error: expected ')' before 'const'
/usr/include/newlib/c++/5.4.1/bits/stl_algobase.h:195:5: error: expected ')' before 'const'
/usr/include/newlib/c++/5.4.1/bits/stl_algobase.h:195:5: error: expected initializer before 'const'
/usr/include/newlib/c++/5.4.1/bits/stl_algobase.h:219:5: error: expected unqualified-id before 'const'
     max(const _Tp& __a, const _Tp& __b)
     ^
/usr/include/newlib/c++/5.4.1/bits/stl_algobase.h:219:5: error: expected ')' before 'const'
/usr/include/newlib/c++/5.4.1/bits/stl_algobase.h:219:5: error: expected ')' before 'const'
/usr/include/newlib/c++/5.4.1/bits/stl_algobase.h:219:5: error: expected initializer before 'const'
In file included from /usr/include/newlib/c++/5.4.1/bits/char_traits.h:39:0,
                 from /usr/include/newlib/c++/5.4.1/string:40,
                 from ./Build/Source/FaustPatch.hpp:84,
                 from ./Build/registerpatch.h:1,
                 from ./Source/PatchProgram.cpp:7:
/usr/include/newlib/c++/5.4.1/bits/stl_algobase.h:243:5: error: 'std::min' declared as an 'inline' variable
     min(const _Tp& __a, const _Tp& __b, _Compare __comp)
     ^
/usr/include/newlib/c++/5.4.1/bits/stl_algobase.h:246:7: error: expected primary-expression before 'if'
       if (__comp(__b, __a))
       ^
/usr/include/newlib/c++/5.4.1/bits/stl_algobase.h:246:7: error: expected '}' before 'if'
/usr/include/newlib/c++/5.4.1/bits/stl_algobase.h:246:7: error: expected ';' before 'if'
/usr/include/newlib/c++/5.4.1/bits/stl_algobase.h:248:7: error: expected unqualified-id before 'return'
       return __a;
       ^
/usr/include/newlib/c++/5.4.1/bits/stl_algobase.h:265:5: error: 'max' declared as an 'inline' variable
     max(const _Tp& __a, const _Tp& __b, _Compare __comp)
     ^
/usr/include/newlib/c++/5.4.1/bits/stl_algobase.h:268:7: error: expected primary-expression before 'if'
       if (__comp(__a, __b))
       ^
/usr/include/newlib/c++/5.4.1/bits/stl_algobase.h:268:7: error: expected '}' before 'if'
/usr/include/newlib/c++/5.4.1/bits/stl_algobase.h:268:7: error: expected ';' before 'if'
/usr/include/newlib/c++/5.4.1/bits/stl_algobase.h:270:7: error: expected unqualified-id before 'return'
       return __a;
       ^
/usr/include/newlib/c++/5.4.1/bits/stl_algobase.h:271:5: error: expected declaration before '}' token
     }
     ^
compile.mk:97: recipe for target 'Build/PatchProgram.o' failed
#29

That’s odd, I’m not seeing the same error.

I’ve just updated to latest faust2 branch, Version 2.1.1

What version of the gcc toolchain are you compiling with?

I’ve pushed a small change to OwlProgram which might help, try pulling and recompiling (changed the include file order).

#30

Did you happen to forget to push that OwlProgram update? I don’t see anything but docs update in master branch.

FYI, I did remove FaustPatch.cpp in OwlProgram after each upgrade and toolchain version used was arm-none-eabi-gcc (15:5.4.1+svn241155-1) 5.4.1 20160919

I’ve made a few tests and I think I can tell you how to reproduce this. The problem seems to happen only if I create Build/Source/FaustPatch.hpp from faust2 branch. If I compile patches with that file created on master branch of faust, everything is fine no matter which version of faust I use at patch compile time. So you have to delete FaustPatch.hpp and use faust2 in order to get this failure.

#31

For MIDI, a specific OWL native API ==> Faust MIDI layer glue has probably to be implemented (defining a owl_midi class, sub class of midi_handler). Following what is already done for JUCE and Bela (for instance…) in this folder: faust/architecture/faust/midi at master-dev · grame-cncm/faust · GitHub

This owl_midi class could then be used with the MidiUI class, or a polyphonic object (mydsp_poly class defined in faust/poly-dsp.h at master-dev · grame-cncm/faust · GitHub file)

#32

The FAUST poly midi code looks great, but I think we will have to roll our own. The FAUST version uses STL (std::map, std::vector et c) which is a bit too heavy for embedded use.

FAUST poly-dsp.h uses a method of processing in slices which is a really nice way to get sample accurate parameter changes e.g. for note onsets.

#33

Sample accurate parameter changes and sample processing is the role of timed_dsp class (in timed-dsp.h). This has been implemented with MIDI sync (clock/start/stop messages), but not yet with other MIDI messages (note on/off, controller…). But this could be done easily.

#34

Hey Martin,

Any luck reproducing the min/max macro issue on your side?

As far as I understand, it happens because patches on faust2 have #include <string> needed for a few variables defined in the dsp_factory class that appears under faust2. That class is for interpreter backend as described at http://faust.grame.fr/news/2016/06/30/faust-interpreter.html . Doesn’t look like that’s something usable on owl - in fact just commenting out that class and string library include works for me as a solution.

Maybe it should be possible to disable those includes in faust/dsp/dsp.h with preprocessor?

#35

dsp_factory is actually used for LLVM and interpreter backends. BTW, why is having a string type (and associated #include <string> a problem on OWL ? Limitations of supported C++ ?

#36

I think it’s just a clash with the include order. We define max() and min() macros for patches to use - we probably shouldn’t.

#37

The problem I’m getting is that there’s a conflict from min/max functions defined here - OwlProgram/basicmaths.h at master · pingdynasty/OwlProgram · GitHub and in newlib bundled with ARM toolchain. The latter has 3-operator form for 2 values and comparison function - error log is at https://hoxtonowl.com/forums/topic/faust-problems/page/2/#post-2942

I’ve tried various toolchain versions but it seems to be always present. I’m not 100% sure if that’s something wrong on my environment or not, since Martin said before he wasn’t getting that failure.

#38

I thought changing the include order would fix it. You can try putting #include "Patch.h" last in the includes.
Or you can try adding #undef min, #undef max, #undef abs after the Patch.h include.

#39

I don’t think any of this helps. The final FaustPatch.hpp file gets additional #include <string> below #include “Patch.h” anyway - it comes from inlined faust/dsp/dsp.h . So reordering won’t help eliminate this clash. Undefining min/max doesn’t help either - this macro is used in generated later.

So currently the only way for me to compile a patch is to manually edit FaustPatch.hpp to undef min/max before the include of string module from dsp.h and then redefine it, since it’s still being used later for constraints checks or something like that.

#40

#including it before should work because the headers are only included once.

What branch of faust are you using?

#41

I’m using faust2 branch, had no issues with their master branch for compiling on faust0. I guess that’s because there was no strings used in the patch on old version.

Regarding headers - the one that FAUST includes after the Patch.h is C++ header from #include <string>, while you seem to be talking about double include of the C #include <string.h> which is not happening here.

#42

faust2 doesn’t have the new memory management option. Is there a reason why you want to use faust2 over master-dev?

I’m having a hard time reproducing your error. With faust2 tip, OwlProgram master tip, and gcc-arm-none-eabi-5_4-2016q2 I still get no compilation errors.

#43

faust2 (on GIT) has the the new memory management option.

#44

Martin, I’m fine with either faust0 or faust2, I was mostly testing it since you’ve mentioned that you’ve been running faust2 branch before and asked me if I can find any problems with it - https://hoxtonowl.com/forums/topic/faust-problems/page/2/#post-2935 .

For reference, I’ve uploaded an example of what I get when building the patch to github, note the C++ string library that gets used later - OwlProgram/FaustPatch.hpp at 4eaf4536d6317260af21a6f646e228c00ea8e1b3 · antisvin/OwlProgram · GitHub

Would you be able to compile it?

#45

yes you are of course right, sorry, my mistake!

@stas I get the same errors as you when compiling your generated FaustPatch.hpp (but not for some reason when generating it myself).

The errors are cleared if I add #include <string> to the top of Source/PatchProgram.cpp.

Can you try that pls? If it works for you I’ll update the repo.

#46

Yes, that fixes it for me too

#47

Great, I’ve pushed that to OwlProgram faust-dynamem branch.