Faust compilation error

akjmicro

Hi all, I'm getting the following error trying to compile a Karplus-Strong 8-voice render.cpp example from the Faust IDE (using MIDI and GUI):

Building render.cpp...
/root/Bela/projects/karplus/render.cpp:6783:41: error: no viable conversion from 'void (oscpkt::Message *, void *)' to 'std::function<void (oscpkt::Message *, const char *, void *)>'
            fReceiver.setup(fInputPort, oscMessageReceived, this);
                                        ^~~~~~~~~~~~~~~~~~
/usr/bin/../lib/gcc/arm-linux-gnueabihf/6.3.0/../../../../include/c++/6.3.0/functional:1868:7: note: candidate constructor not viable: no known conversion from 'void (oscpkt::Message *, void *)' to 'nullptr_t' for 1st argument
      function(nullptr_t) noexcept
      ^
/usr/bin/../lib/gcc/arm-linux-gnueabihf/6.3.0/../../../../include/c++/6.3.0/functional:1879:7: note: candidate constructor not viable: no known conversion from 'void (oscpkt::Message *, void *)' to 'const std::function<void (oscpkt::Message *, const char *, void *)> &' for 1st argument
      function(const function& __x);
      ^
/usr/bin/../lib/gcc/arm-linux-gnueabihf/6.3.0/../../../../include/c++/6.3.0/functional:1888:7: note: candidate constructor not viable: no known conversion from 'void (oscpkt::Message *, void *)' to 'std::function<void (oscpkt::Message *, const char *, void *)> &&' for 1st argument
      function(function&& __x) : _Function_base()
      ^
/usr/bin/../lib/gcc/arm-linux-gnueabihf/6.3.0/../../../../include/c++/6.3.0/functional:1914:2: note: candidate template ignored: substitution failure [with _Functor = void (*)(oscpkt::Message *, void *), $1 = void]: no type named 'type' in 'std::result_of<void (*&(oscpkt::Message *, const char *, void *))(oscpkt::Message *, void *)>'
 function(_Functor);
 ^
./libraries/OscReceiver/OscReceiver.h:39:94: note: passing argument to parameter 'on_receive' here
 void setup(int port, std::function<void(oscpkt::Message* msg, const char* addr, void* arg)> on_receive, void* callbackArg = nullptr);
                                                                                             ^
1 error generated.
Makefile:512: recipe for target '/root/Bela/projects/karplus/build/render.o' failed
make: *** [/root/Bela/projects/karplus/build/render.o] Error 1
Connection to 192.168.7.2 closed.

Any way out of this?

giuliomoro

this fixes it https://github.com/grame-cncm/faust/pull/792

akjmicro

Thanks for the quick response! I will give it a try...so, it was a trivial signature issue.

I have to see if I can figure out what they are missing from the caller...or perhaps this will need to be merged into their IDE code, b/c that might be a goose chase otherwise...?

giuliomoro

I opened a pull request to their repo. Are you using their online IDE? Not sure how fast or slow merged pull requests take to propagate to that.

In the meantime, you could make some changes to the Bela code on your board to revert OscReceiver to the old API. This should do it:

diff --git a/libraries/OscReceiver/OscReceiver.cpp b/libraries/OscReceiver/OscReceiver.cpp
index 15e6c4b67..90e2c1308 100644
--- a/libraries/OscReceiver/OscReceiver.cpp
+++ b/libraries/OscReceiver/OscReceiver.cpp
@@ -7,7 +7,7 @@ constexpr unsigned int OscReceiverSleepBetweenReadsUs = 5000;
 constexpr unsigned int OscReceiverInBufferSize = 65536; // maximum UDP packet size

 OscReceiver::OscReceiver(){}
-OscReceiver::OscReceiver(int port, std::function<void(oscpkt::Message* msg, const char* addr, void* arg)> on_receive, void* callbackArg){
+OscReceiver::OscReceiver(int port, std::function<void(oscpkt::Message* msg, void* arg)> on_receive, void* callbackArg){
 	setup(port, on_receive, callbackArg);
 }

@@ -34,7 +34,7 @@ void OscReceiver::receive_task_func(){
 	}
 }

-void OscReceiver::setup(int port, std::function<void(oscpkt::Message* msg, const char* addr, void* arg)> _on_receive, void* callbackArg)
+void OscReceiver::setup(int port, std::function<void(oscpkt::Message* msg, void* arg)> _on_receive, void* callbackArg)
 {
 	inBuffer.resize(OscReceiverInBufferSize);

diff --git a/libraries/OscReceiver/OscReceiver.h b/libraries/OscReceiver/OscReceiver.h
index 22f33573e..704dee755 100644
--- a/libraries/OscReceiver/OscReceiver.h
+++ b/libraries/OscReceiver/OscReceiver.h
@@ -23,7 +23,7 @@ namespace std {
 class OscReceiver{
 public:
 	OscReceiver();
-	OscReceiver(int port, std::function<void(oscpkt::Message* msg, const char* addr, void* arg)> on_receive, void* callbackArg = nullptr);
+	OscReceiver(int port, std::function<void(oscpkt::Message* msg, void* arg)> on_receive, void* callbackArg = nullptr);
 	~OscReceiver();

 	/**
@@ -36,7 +36,7 @@ public:
 	* @param callbackArg an argument to pass to the callback
 	*
 	*/
-	void setup(int port, std::function<void(oscpkt::Message* msg, const char* addr, void* arg)> on_receive, void* callbackArg = nullptr);
+	void setup(int port, std::function<void(oscpkt::Message* msg, void* arg)> on_receive, void* callbackArg = nullptr);

 private:
 	bool lShouldStop = false;
@@ -52,6 +52,6 @@ private:
 	std::unique_ptr<oscpkt::PacketReader> pr;
 	std::vector<char> inBuffer;

-	std::function<void(oscpkt::Message* msg, const char* addr, void* arg)> on_receive;
+	std::function<void(oscpkt::Message* msg, void* arg)> on_receive;
 	void* onReceiveArg = nullptr;
 };

or you can patch the file generated by faust before moving it to the board.

akjmicro

Followup: I got the project to compile, and it appears to be running.

However, I cannot get it to respond to MIDI, and I have verified that I am routing to hw:0,0 on the Bela for MIDI messages. I am trying to track down in the rather large render.cpp file what Faust is perhaps assuming about where to listen.

The other thing is that I cannot connect to the GUI by hitting either of the following:

http://192.168.17.1:5510 (or 5511)
http://bela.local:5510 (or 5511)

I also tried, from the IDE, opening a GUI interface from the newer IDE interface (just did a board update last night), but I suspect that isn't for Faust use-cases.

Furthermore: I am assuming running a C++ project output from Faust's online IDE is agnostic to the fact that it came from Faust at all? I figure C++ is C++, and it shouldn't matter...so I am not doing the "local way" and bringing up a faust project via faust2bela, since, in a way, the online IDE giving me a downloadable bit of C++ means I can essentially bypass caring about Faust locally (with perhaps the exception of needing the libs that HTTP broadcast the GUI?.. perhaps I need those to be updated...but I wasn't seeing any comm errors in the regard.)

Cheers and thanks for any help,

AKJ

giuliomoro

akjmicro I am assuming running a C++ project output from Faust's online IDE is agnostic to the fact that it came from Faust at all?

sure. It's just C++. However, the faust2bela script sets some flags that should be passed to the compiler in order to enable MIDI or GUI or OSC:

https://github.com/grame-cncm/faust/blob/master-dev/tools/faust2appls/faust2bela#L125-L141

This file actually embeds these #define statements in the generated file, but as an alternative you can set them by passing them to the compiler via the Make parameters in the project settings tab: add

CPPFLAGS=-DMIDICTRL -DOSCCTRL -DHTTPDGUI

For the HTTPDGUI to work you also need to link in the libHTTPDFaust library, and you can do so by passing LDFLAGS=-lHTTPDFaust to make. Your Make parameters box should therefore look exactly like this (note and excuse the ridiculous semicolon-separate syntax):

CPPFLAGS=-DMIDICTRL -DOSCCTRL -DHTTPDGUI; LDFLAGS=-lHTTPDFaust

and of course you need libHTTPDFaust installed, as explained here.

akjmicro

Excellent, will try later. Thanks for the help @giuliomoro

It might make sense to gather some of this wisdom in a "Faust troubleshooting guide" somewhere? It would beat having to search through the forum for any future folks looking to get things up and running.

Cheers,

AKJ

giuliomoro

akjmicro of this wisdom in a "Faust troubleshooting guide" somewher

well... the "official guide" says that you should use faust2bela -tobela ... Integration with a third-party web service is complicated to manage ... because that can change (or not!) without notice.

I am not familiar with the online FAUST IDE ... how do you download the file?
Is this the one you are using? https://faustide.grame.fr/ Can you explain exactly how you are downloading the files?

I clicked on "Export/compile to specific platform binary code". From there selected Platform: "bela" and Architecture: "bela".When I press "Download", I get two different files depending on whether I click or don't click on "Compile" before. These have some parts that are missing/different from the ones I tested the "Make parameters" options I mentioned above, so I am not sure they'll work as expected. It looks like the render.cpp I get after clicking "compile" should build and has those features in. Either way, the file I get claims to be built with Faust "2.40.12", while the current version is 2.46.2, so this is indeed lagging behind. That's yet another good reason to use the scripts if possible ...

akjmicro

I'm opting for the use of faust2bela now, just b/c of what you said about the online IDE approach.

It's kind of sad, TBH, how hard it is to get anything w/Faust happening....such a promising project, and I've been battling for days to get the simplest thing happening.

Anyhow, I was able to finally get the karplus project in the examples folder to build and be pushed to the board, and even the port 5510 GUI was up! But, sadly: no sound, no MIDI (and I routed my host's keyboard Alsa MIDI port to Bela's MIDI port, per usual like I would in a Csound project), and not even the 'Gate' button would produce sound. I'm guessing maybe I didn't specify -osc in the params, but then I think that's a silly oversight to have a GIU and not be able to use it via -osc....more later; still trying.

giuliomoro

hmm I am looking into this .. FAUST seems to be using the Bela default MIDI input (hw:1,0,0), which is typically an extenral USB keyboard plugged into it. If you wanted to use instead the virtual MIDI port to the host, you'd need to apply these changes:

diff --git a/libraries/Midi/Midi.cpp b/libraries/Midi/Midi.cpp
index 99f1ebcd..e1b611c3 100644
--- a/libraries/Midi/Midi.cpp
+++ b/libraries/Midi/Midi.cpp
@@ -111,7 +111,7 @@ inId(NULL), outId(NULL), outPipeName(NULL)
        setup();
 }
 void Midi::setup() {
-       sprintf(defaultPort, "%s", "hw:1,0,0"); // a bug in gcc<4.10 prevents initialization with defaultPort("hw:1,0,0") in the initialization list
+       sprintf(defaultPort, "%s", "hw:0,0,0"); // a bug in gcc<4.10 prevents initialization with defaultPort("hw:0,0,0") in the initialization list
        inputParser = 0;
        size_t inputBytesInitialSize = 1000;
        inputBytes.resize(inputBytesInitialSize);

We can look into making this automatic or selectable via parameters to faust2bela.

Note that currently you also need to pass -nvoices for MIDI note inputs to work. E.g.:

faust2bela -tobela -osc -midi -nvoices 1 ./examples/physicalModeling/karplus.dsp

works.

akjmicro

Thanks, giving this a shot now; will report later on how it went. Will also use hw:0,0 for now instead of hw:0,0,0 as you suggested since from the Bela, amidi -l reports that as the general symbolic port, and I doubt their equivalency.

giuliomoro

they are actually equivalent. I tested it with the patch above and it works.

akjmicro

Drat, so for no luck getting sound, even after trying different ports for the MIDI input AND ALSO trying directly plugging into the Bela-mini with my keyboard.

Out of ideas here...with the OSC option, should I not expect sound unless I am also sending initialization mags to each parameter? Trying w/o OSC enabled now...but maybe that makes the GUI not work either :/....

akjmicro

A key insight: the "gate" button doesn't trigger any sound for me either, outside of any MIDI issues. I think I will need verbose logging of some sort to narrow down the issues...I suspect that although the patch appears to be running, something more fundamental (and perhaps simple) isn't in place.

<edited to add more intel here>:

Also: this is proof that hw:1,0,0 (direct plug-in to the Bela-mini's USB midi port) is working for me. And FYI, I reverted the Midi.cpp file to point to hw:1,0,0 and re-built the project.

root@bela:~/Bela# amidi -p hw:1,0,0 -d

90 30 4D
90 30 00
90 32 3E
90 32 00
90 35 23
90 35 00
90 37 3B
90 37 00
90 34 32
90 34 00
90 35 3D
90 35 00
90 32 26
90 34 32
90 32 00
90 34 00

So, whatever is going on, it's not the fault of the ability to propagate MIDI signals.

giuliomoro

The gate signal from the GUI triggers a sound for me. Can you verify a regular Bela project (e.g. the fundamentals/sinetone example from the ide ) does indeed generate sound?

akjmicro

The "basic" project works -- I get the sine tone.

So, in theory, sound works. Might it be that I need the latest libHTTPD thingie?

giuliomoro

akjmicro ks. Might it be that I need the latest libHTTPD thingie

May well be ... I just noticed that the GATE button works for me only after I have sent a stream of MIDI messages. Not just one note, but several ... perhaps only after I trigger Faust's voice stealing to actually steal a voice... and the button will stop working again a few seconds after the last MIDI note has been received ... pretty buggy, but this shouldn't be anything Bela-specific. Anyhow, this http GUI has been buggy for a while and my understanding from this conversation was that it wouldn't be maintained. But looking through the git log I see it has received some attention in the last few years. So, I went and rebuilt it. It didn't fix anything as far as I can tell (the issue linked above is still there and the gate still won't work before MIDI notes are received (or ever, if you click it before any notes are received)).

On further inspection, this specific issue may not even be about the HTTPDGUI. I see that the time I can successfully press the gate button after a MIDI note was received is reduced if I increase the "damping" parameter ... This may not even be a bug but rather a "feature" of how ks_ui_MIDI , used by examples/physicalModeling/karplus.dsp is implemented in libraries//physmodels.lib, but I cannot tell by reading it as I don't really know much about FAUST ... I also see that I get a very similar issue (i.e.: no sound from on-GUI parameters if not for a brief period after MIDI notes) if I build example/physicalModeling/flute.dsp (which has no "ui_MIDI") with -nvoices X. On both karplus and flute the GATE button will work fine if you build without -nvoices X, so I'd guess that the expected behaviour is for the gate button to only really work properly when there are no MIDI voices allocated.

By the way, I have not tried the OSC interface, but it may well be that - similarly - some functionalities may not work properly when -midi and nvoices are involved

Now as to why you don't hear any sound when you receive MIDI notes, I'd suggest you try the following to ensure the program is actually reading from the port you are sending messages to:

do amidi -p hw:1,0,0 -d and verify you are getting notes. Stop it
do faust2bela -tobela -osc -gui -midi -nvoices 1 ./examples/physicalModeling/karplus.dsp and wait for the program to start
send MIDI notes to it. If it doesn't produce any sound, open a separate terminal window, ssh onto the board and do amidi -p hw:1,0,0 -d and verify it fails to start because it cannot access the MIDI device. This would suggest that the device is correctly opened by the FAUST/Bela program

akjmicro

More info:

Built the karplus patch with:

aaron@aaron-XPS-13-9350:~/Downloads/faust/examples/physicalModeling$ faust2bela  -tobela -gui -osc -midi -nvoices 4 karplus.dsp 
Send to bela
/home/aaron/Downloads/faust/examples/physicalModeling/karplus
Start communication with bela
/home/aaron/Downloads/faust/examples/physicalModeling/karplus
karplus
Checking the board is up and running at root@192.168.7.2...done
Stop running process...
Run bela now
uploadBuildRun START
Copying new source files to BeagleBone...Using rsync...
   render.cpp
Automatically detected PROJECT_TYPE: cpp 
Running on __stretch__ with Xenomai __3__
systemctl stop bela_startup || true
PID=`grep bela-audio  /proc/xenomai/sched/stat | cut -d " " -f 5 | sed s/\s//g`; if [ -z $PID ]; then [ true = true ] || echo "No process to kill"; else [  true = true  ] || echo "Killing old Bela process $PID"; kill -2 $PID; sleep 0.2; kill -9 $PID 2> /dev/null; fi; screen -X -S Bela quit > /dev/null; exit 0;
killall scsynth 2>/dev/null& killall sclang 2>/dev/null& true
echo 'Building render.cpp...'
Building render.cpp...
/usr/bin/clang++  -I/root/Bela/projects/karplus -I./include/legacy  -I./include -I./build/pru/ -I./ -I/usr/xenomai/include/cobalt -I/usr/xenomai/include -march=armv7-a -mfpu=vfp3 -D_GNU_SOURCE -D_REENTRANT -fasynchronous-unwind-tables -D__COBALT__ -D__COBALT_WRAP__ -DXENOMAI_SKIN_posix -DXENOMAI_MAJOR=3 -O3 -g -march=armv7-a -mtune=cortex-a8 -mfloat-abi=hard -mfpu=neon -ftree-vectorize -ffast-math -DNDEBUG -DBELA_USE_RTDM -I/root/Bela/resources/stretch/include -save-temps=obj -DENABLE_PRU_UIO=1 -std=c++11 -DNDEBUG  -Wall -c -fmessage-length=0 -U_FORTIFY_SOURCE -MMD -MP -MF"/root/Bela/projects/karplus/build/render.d" -o "/root/Bela/projects/karplus/build/render.o" "/root/Bela/projects/karplus/render.cpp" 
echo ' ...done'
 ...done
echo ' '
 
./resources/tools/detectlibraries.sh --path /root/Bela/projects/karplus/build
Using library Midi
Using library OscReceiver
Using library UdpServer
Using library OscSender
Using library UdpClient
make -f Makefile.linkbela --no-print-directory /root/Bela/projects/karplus/karplus
echo 'Linking...'
Linking...
/usr/bin/clang++  -Llib/ -Wl,--as-needed       -pthread -o "/root/Bela/projects/karplus/karplus" build/core/default_main.o  libraries/Midi/build/Midi.o libraries/Midi/build/Midi_c.o libraries/OscReceiver/build/OscReceiver.o libraries/OscSender/build/OscSender.o libraries/UdpClient/build/UdpClient.o libraries/UdpServer/build/UdpServer.o build/core/FormatConvert.o build/core/OscillatorBank_routines.o build/core/math_runfast.o build/core/Gpio.o build/core/I2c_Codec.o build/core/BelaContextFifo.o build/core/Mmap.o build/core/RTAudio.o build/core/PruBinary.o build/core/RTAudioCommandLine.o build/core/Mcasp.o build/core/AuxTaskNonRT.o build/core/AuxTaskRT.o build/core/board_detect.o build/core/WSServer.o build/core/AuxiliaryTasks.o build/core/DataFifo.o build/core/I2c_MultiI2sCodec.o build/core/PRU.o build/core/GPIOcontrol.o build/core/I2c_MultiTLVCodec.o build/core/PruManager.o build/core/MiscUtilities.o build/core/I2c_MultiTdmCodec.o build/core/Spi_Codec.o build/core/JSONValue.o build/core/BelaContextSplitter.o build/core/DigitalChannelManager.o build/core/IirFilter.o build/core/JSON.o /root/Bela/projects/karplus/build/render.o -lHTTPDFaust -lasound     -L/usr/xenomai/lib -lcobalt -lmodechk -lpthread -lrt -lprussdrv -lasound -lseasocks
echo ' ...done'
 ...done
echo "Running" /root/Bela/projects/karplus/karplus 
Running /root/Bela/projects/karplus/karplus
sync& cd /root/Bela/projects/karplus && /root/Bela/projects/karplus/karplus 
Started with 4 voices
Faust httpd server version 0.73 is running on TCP port 5510
ALSA lib rawmidi_hw.c:233:(snd_rawmidi_hw_open) open /dev/snd/midiC1D0 failed: No such device
initconnect
7 widgets, OSC Adresses:
/Polyphonic/Voices/Panic 0.000000 to 1.000000
/Polyphonic/Voices/karplus/params/freq 50.000000 to 1000.000000
/Polyphonic/Voices/karplus/params/bend -2.000000 to 2.000000
/Polyphonic/Voices/karplus/params/damping 0.000000 to 1.000000
/Polyphonic/Voices/karplus/params/gain 0.000000 to 1.000000
/Polyphonic/Voices/karplus/params/sustain 0.000000 to 1.000000
/Polyphonic/Voices/karplus/gate 0.000000 to 1.000000
connected

Check via ssh that the MIDI connection is busy:

root@bela:~# amidi -l
Dir Device    Name
IO  hw:0,0    f_midi
I   hw:1,0,0  KeyRig 49 MIDI 1
root@bela:~# amidi -p hw:1,0,0 -d
ALSA lib rawmidi_hw.c:233:(snd_rawmidi_hw_open) open /dev/snd/midiC1D0 failed: Device or resource busy
cannot open port "hw:1,0,0": Device or resource busy

But still no sound when I play the keyboard attached. No such issues with a Csound patch. Also, no sound after playing the keyboard and hitting the Gate button in the GUI, either. I'm about to all but give up on faust.... :/

I do wonder about:

ALSA lib rawmidi_hw.c:233:(snd_rawmidi_hw_open) open /dev/snd/midiC1D0 failed: No such device

giuliomoro

akjmicro I'm about to all but give up on faust.... :/

the "fun" thing here is that this is not FAUST's fault: FAUST is just a C++ project that uses Bela's Midi class, just like PureData and Csound and the C++ code below do. So it should work well just the same!

akjmicro ALSA lib rawmidi_hw.c:233🙁snd_rawmidi_hw_open) open /dev/snd/midiC1D0 failed: No such device

That means that there is another program using that port (this should be hw:1,0,0). Did you stop any amidi -d -p hw:1,0,0 running when you started the FAUST project? Only one program at a time can access that port.

Can you try to run the program below ? If it runs successfully, stop it and run the faust program immediately after it. Does it still show the same ALSA lib error line ?

If the error persists, to find out what process has the port open, run:

find /proc/*/fd -lname "/dev/snd/*" -exec bash -c 'ps -`echo {} | sed "s:/proc/\([0-9]*\)/fd/.*:\1:"`' \;

#include <Bela.h>
#include <libraries/Midi/Midi.h>

Midi gMidi;

bool setup(BelaContext *context, void *userData)
{
	// Initialise the MIDI device
	if(gMidi.readFrom("hw:1,0,0") < 0) {
		fprintf(stderr, "Unable to read from MIDI port\n");
		return false;
	}
	gMidi.enableParser(true);

	return true;
}

void noteOn(int noteNumber, int velocity)
{
	printf("note on: %d %d\n", noteNumber, velocity);
}

void noteOff(int noteNumber)
{
	printf("note off: %d\n", noteNumber);
}

void render(BelaContext *context, void *userData)
{
	// At the beginning of each callback, look for available MIDI
	// messages that have come in since the last block
	while(gMidi.getParser()->numAvailableMessages() > 0) {
		MidiChannelMessage message;
		message = gMidi.getParser()->getNextChannelMessage();
		message.prettyPrint();		// Print the message data

		// A MIDI "note on" message type might actually hold a real
		// note onset (e.g. key press), or it might hold a note off (key release).
		// The latter is signified by a velocity of 0.
		if(message.getType() == kmmNoteOn) {
			int noteNumber = message.getDataByte(0);
			int velocity = message.getDataByte(1);

			// Velocity of 0 is really a note off
			if(velocity == 0) {
				noteOff(noteNumber);
			}
			else {
				noteOn(noteNumber, velocity);
			}
		}
		else if(message.getType() == kmmNoteOff) {
			// We can also encounter the "note off" message type which is the same
			// as "note on" with a velocity of 0.
			int noteNumber = message.getDataByte(0);
			noteOff(noteNumber);
		}
	}
}

void cleanup(BelaContext *context, void *userData)
{
}

akjmicro

Ok, I'm happy to report I finally got MIDI triggering and sound!

But, it wasn't via hw:1,0,0, which for some reason stubbornly resisted my attempts. For all I know, it might be a faulty bit of hardware in the USB port of the Bela. Like, a bad contact or something....however, when I forwarded MIDI bytes over the network Alsa midi connections, and read from hw:0,0, and then sanity-checked with:
amidi -p hw:0,0 -d ...after having linked the bytes to forward from my M-Audio KeyRig 49, and also double checking the Bela MIDI-reading with your .cpp above, it all seemed to work.

Now, the issue I'm having is the karplus code itself; mainly the default release time on a NoteOff is a bit much. But I can continue to hack further and explore from here.

Thanks for all the help!

-AKJ