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: https://github.com/grame-cncm/faust/tree/master-dev/architecture/faust/midi
This owl_midi class could then be used with the MidiUI class, or a polyphonic object (mydsp_poly class defined in https://github.com/grame-cncm/faust/blob/master-dev/architecture/faust/dsp/poly-dsp.h file)
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.
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.
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.
Any luck reproducing the min/max macro issue on your side?
As far as I understand, it happens because patches on faust2 have
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?
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++ ?
I think it’s just a clash with the include order. We define
min() macros for patches to use – we probably shouldn’t.
The problem I’m getting is that there’s a conflict from min/max functions defined here – https://github.com/pingdynasty/OwlProgram/blob/master/LibSource/basicmaths.h#L40-L45 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.
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 abs after the Patch.h include.
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.
#including it before should work because the headers are only included once.
What branch of faust are you using?
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.
faust2 doesn’t have the new memory management option. Is there a reason why you want to use
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.
faust2 (on GIT) *has* the the new memory management option.
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 – https://github.com/antisvin/OwlProgram/blob/4eaf4536d6317260af21a6f646e228c00ea8e1b3/Build/Source/FaustPatch.hpp#L84
Would you be able to compile it?
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
Can you try that pls? If it works for you I’ll update the repo.
You must be logged in to reply to this topic.