My experience with Faust, and some more general observations

DragonSF Am I missing something important here?

if you compiled the FAUST-generated C++ code, then you would not be loading a .dsp file at runtime, therefore the --faust filename.dsp option is not supported, but that options is probably still in your IDE settings and you should remove it.

DragonSF seems the code was too old to be compiled.

Perhaps just adding virtual void addSoundfile(const char* label, const char* filename, Soundfile** sf_zone) {} inside class BelaUI : public UI would have fixed this (I got that by comparing with the bela.cpp file mentioned below)?

DragonSF Got the latest bela.cpp from git and now, this results:

I assume you mean this. This is a regular FAUST architecture file, that will not provide just-in-time compilation features, but should be suitable if you generate some C++ code with FAUST.

DragonSF Any idea, what's missing (sorry, I have no idea about faust infrastructure, because I can't get it to work neither offline or online).

What error do you get? The text you pasted seems to only be part of the source file?

Add

	settings.setup = setup;
	settings.render = render;
	settings.cleanup = cleanup;

to your main() function, similarly to what is done here https://github.com/BelaPlatform/Bela/blob/master/core/default_main.cpp#L45-L47

There is no GUI to be expected at the moment.
I have lost track of what your project folder looks like just now, so I can only guess as to why there is no sound. If you have a render() function somewhere that looks like this, then it means that the problem is most likely in the FAUST code in use.

Maybe it requires some user input in order to generate sound?

looks like --faust is not an option for main.cpp (I'll look at that later).

DragonSF looks like --faust is not an option for main.cpp (I'll look at that later).

correct:

giuliomoro if you compiled the FAUST-generated C++ code, then you would not be loading a .dsp file at runtime, therefore the --faust filename.dsp option is not supported, but that options is probably still in your IDE settings and you should remove it.

giuliomoro no, I have removed the setting.

FAUST on Bela is meant to run without GUI, using Bela's inputs as controllers.

These lines in the faust.dsp file

freq = hslider("[1]Frequency[BELA:ANALOG_0]", 440,460,1500,1):smooth(0.999);
pressure = hslider("[2]Pressure[style:knob][BELA:ANALOG_4]", 0.96, 0.2, 2.0, 0.01):smooth(0.999):min(0.99):max(0.2);

mean (as far as I understand, as I know nothing about FAUST) that you can use either an hslider or the Bela analog inputs in order to control freq and pressure. In fact here I am playing titanic on it using a breath sensors and a slider:

In the future there may be a GUI (e.g.: as an additional tab in the IDE), which would make tweaking parameters easier during prototyping, but ultimately, I think that the final objective of running some program on Bela is to run it embedded, controlled by the sensors.

DragonSF And yes, a GUI would be awesome. If you need help with that, I'm willing to do whatever is necessary.

I think the steps needed here are to generate a web-based GUI and then serve it from a tab in the browser.
The faust playground can generate GUIs from FAUST code. I have no idea how that is done, but going through its source code you may find a way of generating the GUI and serve it as a page (either with a python server, as they do, or plugging into our node server). Once that is done, the sliders on the GUI can be hooked up to send OSC messages to the running audio backend (perhaps similarly to what we did here with NexusUI).

I don't think this is easy or straightforward, but if you really have time to dig into this, then I think the above sums it up well. @sletz - who is one of the developers of FAUST - will have a better idea than I have on the subject.

Yes, I'll try to dig into that. Have enough time at the moment.

@sletz suggests:

We already have a « server a web-based GUI to the user » model. On server side we use libmicrohttpd (https://www.gnu.org/software/libmicrohttpd/) to have the Web server running, wrapping/controlling the running DSP, delivering a HTML + SVG + CSS page to the browser. Then messages are sent/received using HTTP requests (which is a bit heavy but works…) This could be a starting point, possibly using OSC an an alternate protocol later on.

You can see this HTML + SVG + CSS code used in another context here : http://faust.grame.fr/modules/. In this case we just generated static pages, but you can see the kind of UI we get.

It may be that they are referenced here?
https://github.com/grame-cncm/faust/blob/master-dev/architecture/httpdlib/src/html/htmlpage.cpp#L122-L144

It seems that if you #define LOADSCRIPTS then a number of external .js and .css files are loaded, but if you don't, you should have in your code some variables stylesheet_len, stylesheet, jsscripts, jsscripts_len which should point to some appropriate scripts (which you are probably supposed to provide yourself?).

I'd recommend you #define LOADSCRIPTS at the top of that file and try to rebuild and see what happens.

DragonSF Do you mean render.cpp (instead of bela.cpp)?

The render.cpp that is in the bela-faust-jit repo is based on the bela.cpp that you find in the FAUST repo. The former allows dynamic loading and just-in-time compilation of FAUST code, while the latter is meant to be used with some FAUST-generated C++ code. The GUI/libmicrohttpd issue you are facing now should be independent of which of the two you use.

(remember that to get that render.cpp to work with the latest FAUST you'd need this I think:

giuliomoro Perhaps just adding virtual void addSoundfile(const char label, const char filename, Soundfile** sf_zone) {} inside class BelaUI : public UI would have fixed this.

)