I bought a Bela at the Kickstarter and have just barely used it. But I am taking an online course on Faust at Kadenze and thought I'd double check. I'd read that Faust wasn't compatible with the latest Bela API and there's not much traffic in this forum.

I do have a small Linux desktop just sitting there too but thought I'd see what could be accomplished with Faust on the Bela just to be able to dust it off.

Thanks, I will give it a shot and let you know what happens!

20 days later

OK, I think I have followed the instructions carefully and "something" is working, but not all the way. Hopefully we are close.

I launch the distcc daemon on the host. I have to set it to run in the background, which is not mentioned in the instructions.

^Z
[1]+  Stopped                 distccd --verbose --no-detach --daemon --allow 192.168.7.2 --log-level debug --log-file ~/distccd.log
gary@audio-workstation:~$ bg
[1]+ distccd --verbose --no-detach --daemon --allow 192.168.7.2 --log-level debug --log-file ~/distccd.log &

Then I checked to see if it's running. Looks like it launches 7 processes (!).

gary@audio-workstation:~$ ps ax | grep distcc
19094 pts/2    SN     0:00 distccd --verbose --no-detach --daemon --allow 192.168.7.2 --log-level debug --log-file /home/gary/distccd.log
19095 pts/2    SN     0:00 distccd --verbose --no-detach --daemon --allow 192.168.7.2 --log-level debug --log-file /home/gary/distccd.log
19096 pts/2    SN     0:00 distccd --verbose --no-detach --daemon --allow 192.168.7.2 --log-level debug --log-file /home/gary/distccd.log
19097 pts/2    SN     0:00 distccd --verbose --no-detach --daemon --allow 192.168.7.2 --log-level debug --log-file /home/gary/distccd.log
19098 pts/2    SN     0:00 distccd --verbose --no-detach --daemon --allow 192.168.7.2 --log-level debug --log-file /home/gary/distccd.log
19099 pts/2    SN     0:00 distccd --verbose --no-detach --daemon --allow 192.168.7.2 --log-level debug --log-file /home/gary/distccd.log
19100 pts/2    SN     0:00 distccd --verbose --no-detach --daemon --allow 192.168.7.2 --log-level debug --log-file /home/gary/distccd.log
19106 pts/2    S+     0:00 grep --color=auto distcc
gary@audio-workstation:~$

Next I try to compile the test program on the bela. That works ok.

root@bela:~/Bela/resources/network# distcc-clang udp-client.c
root@bela:~/Bela/resources/network# ls -l a.out
-rwxr-xr-x 1 root root 8672 May 28 18:49 a.out
root@bela:~/Bela/resources/network# ./a.out
Usage: server port
root@bela:~/Bela/resources/network#

At present (before compiling) the distccd.log contains:

gary@audio-workstation:~$ tail -f ~/distccd.log
distccd[19094] (dcc_standalone_server) allowing up to 6 active jobs
distccd[19094] (dcc_standalone_server) not detaching
distccd[19094] (dcc_new_pgrp) already a process group leader
distccd[19094] (dcc_log_daemon_started) preforking daemon started (3.3.2 x86_64-pc-linux-gnu, built May 26 2019 14:11:45)
distccd[19094] (dcc_create_kids) up to 1 children
distccd[19094] (dcc_create_kids) up to 2 children
distccd[19094] (dcc_create_kids) up to 3 children
distccd[19094] (dcc_create_kids) up to 4 children
distccd[19094] (dcc_create_kids) up to 5 children
distccd[19094] (dcc_create_kids) up to 6 children

Now I will add -c to try to use the distcc server.

Log from host now has this additional info:

distccd[19100] (dcc_check_client) connection from 192.168.7.2:59098
distccd[19100] (check_address_inet) match client 0x207a8c0, value 0x207a8c0, mask 0xffffffff
distccd[19100] (dcc_r_token_int) got DIST00000001
distccd[19100] (dcc_r_token_int) got ARGC00000005
distccd[19100] (dcc_r_argv) reading 5 arguments from job submission
distccd[19100] (dcc_r_token_int) got ARGV0000000d
distccd[19100] (dcc_r_token_string) got 'clang-3.9-arm'
distccd[19100] (dcc_r_argv) argv[0] = "clang-3.9-arm"
distccd[19100] (dcc_r_token_int) got ARGV00000002
distccd[19100] (dcc_r_token_string) got '-c'
distccd[19100] (dcc_r_argv) argv[1] = "-c"
distccd[19100] (dcc_r_token_int) got ARGV0000000c
distccd[19100] (dcc_r_token_string) got 'udp-client.c'
distccd[19100] (dcc_r_argv) argv[2] = "udp-client.c"
distccd[19100] (dcc_r_token_int) got ARGV00000002
distccd[19100] (dcc_r_token_string) got '-o'
distccd[19100] (dcc_r_argv) argv[3] = "-o"
distccd[19100] (dcc_r_token_int) got ARGV0000000c
distccd[19100] (dcc_r_token_string) got 'udp-client.o'
distccd[19100] (dcc_r_argv) argv[4] = "udp-client.o"
distccd[19100] (dcc_r_argv) got arguments: clang-3.9-arm -c udp-client.c -o udp-client.o
distccd[19100] (dcc_scan_args) scanning arguments: clang-3.9-arm -c udp-client.c -o udp-client.o
distccd[19100] (dcc_scan_args) found input file "udp-client.c"
distccd[19100] (dcc_scan_args) found object/output file "udp-client.o"
distccd[19100] compile from udp-client.c to udp-client.o
distccd[19100] (dcc_run_job) output file udp-client.o
distccd[19100] (dcc_input_tmpnam) input file udp-client.c
distccd[19100] (dcc_r_token_int) got DOTI00016dac
distccd[19100] (dcc_r_file) received 93612 bytes to file /tmp/distccd_941a833e.i
distccd[19100] (dcc_r_file_timed) 93612 bytes received in 0.011030s, rate 8288kB/s
distccd[19100] (dcc_set_input) changed input from "udp-client.c" to "/tmp/distccd_941a833e.i"
distccd[19100] (dcc_set_input) command after: clang-3.9-arm -c /tmp/distccd_941a833e.i -o udp-client.o
distccd[19100] (dcc_set_output) changed output from "udp-client.o" to "/tmp/distccd_9466833e.o"
distccd[19100] (dcc_set_output) command after: clang-3.9-arm -c /tmp/distccd_941a833e.i -o /tmp/distccd_9466833e.o
distccd[19100] (dcc_check_compiler_masq) /usr/local/bin/clang-3.9-arm is not a symlink
distccd[19100] (dcc_check_compiler_whitelist) CRITICAL! no /usr/local/lib/distcc
distccd[19100] (dcc_cleanup_tempfiles_inner) deleted 5 temporary files
distccd[19100] (dcc_job_summary) client: 192.168.7.2:59098 OTHER exit:0 sig:0 core:0 ret:0 time:229ms
gary@audio-workstation:~$ ls -al /usr/local/lib
total 11844
drwxr-xr-x  4 root root      4096 May 26 13:56 .
drwxr-xr-x 10 root root      4096 Feb  9 16:12 ..
-rw-r--r--  1 root root  11346736 May 26 09:55 ios-libsndfile.a
-rw-r--r--  1 root root    760668 May 26 09:55 libOSCFaust.a
drwxrwsr-x  4 root staff     4096 May 26 13:57 python2.7
drwxrwsr-x  3 root staff     4096 Feb  9 16:12 python3.6
gary@audio-workstation:~$

On Bela, I see:

root@bela:~/Bela/resources/network# distcc-clang -c udp-client.c
distcc[14931] (dcc_readx) ERROR: unexpected eof on fd5
distcc[14931] (dcc_r_token_int) ERROR: read failed while waiting for token "DONE"
distcc[14931] (dcc_r_result_header) ERROR: server provided no answer. Is the server configured to allow access from your IP address? Does the server have the compiler installed? Is the server configured to access the compiler?
distcc[14931] (dcc_build_somewhere) Warning: failed to distribute and fallbacks are disabled
root@bela:~/Bela/resources/network#

root@bela:~/Bela/resources/network# ls -al /tmp/distcc
total 8
drwxr-xr-x 2 root root 4096 May 28 18:55 .
drwxrwxrwt 9 root root 4096 May 28 18:57 ..
root@bela:~/Bela/resources/network#

Just to be sure, I ran the watch statements. Have to put those in the background too.

root@bela:~/Bela/resources/network# ps ax | grep watch
   10 ?        S      0:01 [watchdog/0]
14935 pts/1    T      0:00 watch -n 0.4 bash -c ps aux | grep clang-3.9-arm
15004 pts/1    T      0:00 watch -n 0.4 bash -c ps aux | grep clang++-3.9-arm
15103 pts/1    S+     0:00 grep --color=auto watch
root@bela:~/Bela/resources/network#

Setup details:
Ubuntu 18.04 host:

gary@audio-workstation:~$ cat /usr/local/bin/clang-3.9-arm
#!/bin/bash
/usr/bin/clang-3.9 -target armv7l-unknown-linux-gnueabihf --sysroot ~/arm $@
gary@audio-workstation:~$

gary@audio-workstation:~$ cat /usr/local/bin/clang++-3.9-arm
#!/bin/bash
/usr/bin/clang++ -target armv71-unknown-linux-gnueabihf --sysroot ~/arm $0
gary@audio-workstation:~$

Please note if you are following along, this is where I made my big mistake.

The final parameter in both scripts above needs to be $@ (meaning the entire list of parameters sent to the script) rather than $0 (the name of the script itself). The difference was very hard to see on my Macbook Air (both because the screen/font is very small, and because there is a slash through the zero in the default font).

Bela:

root@bela:~# ls -l /usr/local/bin/clang*
-rwxr-xr-x 1 root root 45 May 26 20:53 /usr/local/bin/clang++-3.9-arm
-rwxr-xr-x 1 root root 25 May 26 20:52 /usr/local/bin/clang-3.9-arm
root@bela:~# ls -l /usr/local/bin/dist*
-rwxr-xr-x 1 root root 253 May 26 20:54 /usr/local/bin/distcc-clang
-rwxr-xr-x 1 root root 255 May 26 20:55 /usr/local/bin/distcc-clang++
root@bela:~# cat /usr/local/bin/clang*
#!/bin/bash
clang++-3.9 $@ -stdlib=libstdc++
#!/bin/bash
clang-3.9 $@
root@bela:~#
root@bela:~# cat /usr/local/bin/distcc-clang
#!/bin/bash
export DISTCC_HOSTS=192.168.7.1
export DISTCC_VERBOSE=0
export DISTCC_FALLBACK=0 # does not seem to apply to the version of distcc in use
export DISTCC_BACKOFF_PERIOD=0
export TMPDIR=/tmp/distcc
mkdir -p /tmp/distcc

distcc clang-3.9-arm $@
root@bela:~#

root@bela:~# cat /usr/local/bin/distcc-clang++
#!/bin/bash
export DISTCC_HOSTS=192.168.7.1
export DISTCC_VERBOSE=0
export DISTCC_FALLBACK=0 # does not seem to apply to the version of distcc in use
export DISTCC_BACKOFF_PERIOD=0
export TMPDIR=/tmp/distcc
mkdir -p /tmp/distcc

distcc clang++-3.9-arm $@
root@bela:~#

    Digital-Larry t. I have to set it to run in the background, which is not mentioned in the instructions.

    Digital-Larry Just to be sure, I ran the watch statements. Have to put those in the background too.

    I keep them both open in a dedicated terminal window. I think you can send distccd to the background by removing the --no-detach bit.

    I have not tested this on Ubuntu, so it's all a bit new.

    Looking at this, it seems that you need to create the folder on the host and create symlinks to in /usr/local/lib/distcc/ to your compilers (clang-3.9-arm and clang++-3.9-arm). As noted here, this is a fix for a serious privilege escalation issue.
    Here it seems to hint at the fact that you can add --make-me-a-botnet or --enable-tcp-insecure (depending on your version of distcc) in order to avoid the need for symlinks (and also more insecure).

    Can you try one of the two solutions and report back so that we can update the guide?

    Thanks for your reply. I think I am doing the right thing, but not 100% sure.

    gary@audio-workstation:/usr/local/lib$ ls -l distcc/
    total 0
    lrwxrwxrwx 1 root root 14 May 28 17:45 clang-3.9-arm -> /usr/bin/clang
    lrwxrwxrwx 1 root root 16 May 28 17:45 clang++-3.9-arm -> /usr/bin/clang++
    gary@audio-workstation:/usr/local/lib$

    gary@audio-workstation:/usr/local/lib$ ls -l /usr/bin/clang*
    lrwxrwxrwx 1 root root 25 May 16 2018 /usr/bin/clang -> ../lib/llvm-6.0/bin/clang
    lrwxrwxrwx 1 root root 27 May 16 2018 /usr/bin/clang++ -> ../lib/llvm-6.0/bin/clang++
    lrwxrwxrwx 1 root root 25 Apr 5 2018 /usr/bin/clang-6.0 -> ../lib/llvm-6.0/bin/clang
    lrwxrwxrwx 1 root root 27 Apr 5 2018 /usr/bin/clang++-6.0 -> ../lib/llvm-6.0/bin/clang++
    lrwxrwxrwx 1 root root 29 Apr 5 2018 /usr/bin/clang-cpp-6.0 -> ../lib/llvm-6.0/bin/clang-cpp
    gary@audio-workstation:/usr/local/lib$

    The response has changed. Now, I get this on Bela:

    root@bela:~/Bela/resources/network# distcc-clang -c udp-client.c
    distcc[15408] ERROR: compile udp-client.c on 192.168.7.1 failed with exit code 127
    distcc[15408] (dcc_build_somewhere) Warning: remote compilation of 'udp-client.c' failed, retrying locally
    distcc[15408] (dcc_build_somewhere) Warning: failed to distribute and fallbacks are disabled
    /usr/local/bin/clang-3.9-arm: line 2: /usr/bin/clang-3.9: No such file or directory
    root@bela:~/Bela/resources/network# distcc-clang -c udp-client.c
    distcc[15429] ERROR: compile udp-client.c on 192.168.7.1 failed with exit code 127
    distcc[15429] (dcc_build_somewhere) Warning: remote compilation of 'udp-client.c' failed, retrying locally
    distcc[15429] (dcc_build_somewhere) Warning: failed to distribute and fallbacks are disabled
    /usr/local/bin/clang-3.9-arm: line 2: /usr/bin/clang-3.9: No such file or directory
    root@bela:~/Bela/resources/network#

    And this on the host:
    distccd[23780] (dcc_check_client) connection from 192.168.7.2:59110
    distccd[23780] (check_address_inet) match client 0x207a8c0, value 0x207a8c0, mask 0xffffffff
    distccd[23780] (dcc_r_token_int) got DIST00000001
    distccd[23780] (dcc_r_token_int) got ARGC00000005
    distccd[23780] (dcc_r_argv) reading 5 arguments from job submission
    distccd[23780] (dcc_r_token_int) got ARGV0000000d
    distccd[23780] (dcc_r_token_string) got 'clang-3.9-arm'
    distccd[23780] (dcc_r_argv) argv[0] = "clang-3.9-arm"
    distccd[23780] (dcc_r_token_int) got ARGV00000002
    distccd[23780] (dcc_r_token_string) got '-c'
    distccd[23780] (dcc_r_argv) argv[1] = "-c"
    distccd[23780] (dcc_r_token_int) got ARGV0000000c
    distccd[23780] (dcc_r_token_string) got 'udp-client.c'
    distccd[23780] (dcc_r_argv) argv[2] = "udp-client.c"
    distccd[23780] (dcc_r_token_int) got ARGV00000002
    distccd[23780] (dcc_r_token_string) got '-o'
    distccd[23780] (dcc_r_argv) argv[3] = "-o"
    distccd[23780] (dcc_r_token_int) got ARGV0000000c
    distccd[23780] (dcc_r_token_string) got 'udp-client.o'
    distccd[23780] (dcc_r_argv) argv[4] = "udp-client.o"
    distccd[23780] (dcc_r_argv) got arguments: clang-3.9-arm -c udp-client.c -o udp-client.o
    distccd[23780] (dcc_scan_args) scanning arguments: clang-3.9-arm -c udp-client.c -o udp-client.o
    distccd[23780] (dcc_scan_args) found input file "udp-client.c"
    distccd[23780] (dcc_scan_args) found object/output file "udp-client.o"
    distccd[23780] compile from udp-client.c to udp-client.o
    distccd[23780] (dcc_run_job) output file udp-client.o
    distccd[23780] (dcc_input_tmpnam) input file udp-client.c
    distccd[23780] (dcc_r_token_int) got DOTI00016dac
    distccd[23780] (dcc_r_file) received 93612 bytes to file /tmp/distccd_8008deef.i
    distccd[23780] (dcc_r_file_timed) 93612 bytes received in 0.011021s, rate 8295kB/s
    distccd[23780] (dcc_set_input) changed input from "udp-client.c" to "/tmp/distccd_8008deef.i"
    distccd[23780] (dcc_set_input) command after: clang-3.9-arm -c /tmp/distccd_8008deef.i -o udp-client.o
    distccd[23780] (dcc_set_output) changed output from "udp-client.o" to "/tmp/distccd_7fcfdeef.o"
    distccd[23780] (dcc_set_output) command after: clang-3.9-arm -c /tmp/distccd_8008deef.i -o /tmp/distccd_7fcfdeef.o
    distccd[23780] (dcc_check_compiler_masq) /usr/local/bin/clang-3.9-arm is not a symlink
    distccd[23780] (dcc_check_compiler_whitelist) clang-3.9-arm in/usr/local/lib/distcc whitelist
    distccd[23780] (dcc_spawn_child) forking to execute: clang-3.9-arm -c /tmp/distccd_8008deef.i -o /tmp/distccd_7fcfdeef.o
    distccd[23780] (dcc_spawn_child) child started as pid23789
    distccd[23789] (dcc_new_pgrp) entered process group
    distccd[23789] (dcc_increment_safeguard) setting safeguard: _DISTCC_SAFEGUARD=1
    distccd[23780] (dcc_collect_child) cc child 23789 terminated with status 0x7f00
    distccd[23780] (dcc_collect_child) cc times: user 0.000000s, system 0.000000s, 0 minflt, 0 majflt
    distccd[23780] (dcc_x_token_int) send DONE00000001
    distccd[23780] (dcc_x_token_int) send STAT00007f00
    distccd[23780] (dcc_x_file) send 84 byte file /tmp/distcc_7decdeef.stderr with token SERR and compression 69
    distccd[23780] (dcc_x_token_int) send SERR00000054
    distccd[23780] (dcc_x_file) send 0 byte file /tmp/distcc_7e01deef.stdout with token SOUT and compression 69
    distccd[23780] (dcc_x_token_int) send SOUT00000000
    distccd[23780] (dcc_x_token_int) send DOTO00000000
    distccd[23780] clang-3.9-arm udp-client.c on localhost failed with exit code 127
    distccd[23780] job complete
    distccd[23780] (dcc_cleanup_tempfiles_inner) deleted 5 temporary files
    distccd[23780] (dcc_job_summary) client: 192.168.7.2:59110 COMPILE_ERROR exit:127 sig:0 core:0 ret:0 time:221ms clang-3.9-arm udp-client.c

    ================
    It is true that there is no /usr/bin/clang-3.9 on the host.
    There is /usr/bin/clang and also /usr/bin/clang-6.0

    OK, I think I have it now.

    /usr/local/bin/clang-3.9-arm needs to point at /usr/bin/clang.

    gary@audio-workstation:/usr/local/bin$ cat clang-3.9-arm
    #!/bin/bash
    /usr/bin/clang -target armv7l-unknown-linux-gnueabihf --sysroot ~/arm $@
    gary@audio-workstation:/usr/local/bin$

    The remote compilation seems to have worked, and it created the object file:
    root@bela:~/Bela/resources/network# ls -l
    total 20
    -rw-r--r-- 1 root root 848 Oct 15 2018 network_readme.txt
    -rw-r--r-- 1 root root 1356 Oct 15 2018 udp-client-sweep.c
    -rw-r--r-- 1 root root 1196 Oct 15 2018 udp-client.c
    -rw-r--r-- 1 root root 2084 May 29 01:29 udp-client.o
    -rw-r--r-- 1 root root 1546 Oct 15 2018 udp-server.c
    root@bela:~/Bela/resources/network#

      Digital-Larry /usr/local/bin/clang-3.9-arm needs to point at /usr/bin/clang.

      Actually, it would need to point to a clang-3.9 compiler on your host. This way you are probably pointing to a much more recent one. This way, on the board you will be compiling with the recent clang from your Ubuntu, and link with the clang-3.9 that is on the board (because distcc always does the linking locally).

        giuliomoro Thanks... I'm getting a little lost with all these links and what is linking where, but I do have the following files/links on the host, and it does seem to work properly (at least remote compiling to create a .o file on the Bela). I'm less concerned about remote compilation at this point than the httplib issue I posted on another thread.

        gary@audio-workstation:/usr/local/lib$ ls -l distcc/
        total 0
        lrwxrwxrwx 1 root root 14 May 28 17:45 clang-3.9-arm -> /usr/bin/clang
        lrwxrwxrwx 1 root root 16 May 28 17:45 clang++-3.9-arm -> /usr/bin/clang++
        gary@audio-workstation:/usr/local/lib$

        gary@audio-workstation:/usr/local/lib$ ls -l /usr/bin/clang*
        lrwxrwxrwx 1 root root 25 May 16 2018 /usr/bin/clang -> ../lib/llvm-6.0/bin/clang
        lrwxrwxrwx 1 root root 27 May 16 2018 /usr/bin/clang++ -> ../lib/llvm-6.0/bin/clang++
        lrwxrwxrwx 1 root root 25 Apr 5 2018 /usr/bin/clang-6.0 -> ../lib/llvm-6.0/bin/clang
        lrwxrwxrwx 1 root root 27 Apr 5 2018 /usr/bin/clang++-6.0 -> ../lib/llvm-6.0/bin/clang++
        lrwxrwxrwx 1 root root 29 Apr 5 2018 /usr/bin/clang-cpp-6.0 -> ../lib/llvm-6.0/bin/clang-cpp
        gary@audio-workstation:/usr/local/lib$

          As I understand from the distcc docs, the point of these links in there is for distcc to know what programs it is actually safe to execute. As mentioned, you should be able to bypass this restriction by using --make-me-a-botnet or --enable-tcp-insecure.
          But if you do put some symlinks there, they should be pointing NOT to the regular clang, but to the clang-3.9-arm and clang++-3.9-arm files you created in /usr/local/bin/, and they will eventually call clang with the appropriate option -target armv7l-unknown-linux-gnueabihf, to tell it to build code for ARM.

          Digital-Larry gary@audio-workstation:/usr/local/lib$ ls -l distcc/
          total 0
          lrwxrwxrwx 1 root root 14 May 28 17:45 clang-3.9-arm -> /usr/bin/clang
          lrwxrwxrwx 1 root root 16 May 28 17:45 clang++-3.9-arm -> /usr/bin/clang++

          Is this working? I find it surprising, but I guess it may depend on how you clang has been built. This way you are simply using the regular clang on your computer, but it should need a -target armv7l-unknown-linux-gnueabihf option in order to know it should build for arm (at least, it does with mine, which I installed with macports on Mac).

          Digital-Larry gary@audio-workstation:~$ cat /usr/local/bin/clang++-3.9-arm
          #!/bin/bash
          /usr/bin/clang++ -target armv71-unknown-linux-gnueabihf --sysroot ~/arm $0
          gary@audio-workstation:~$

          just noticed that here you have a armv71 instead of armv7l. This should break!

          Anyhow, if this is working for you, leave it as it is.

            giuliomoro I'm so excited that I got the HTTPlib thing dealt with I'm not actually sure about all this. Part of the confusion I had was trying to get distcc and the host based Faust compiler working at the same time. Each one had a few issues and I think a better flow for the documents would be to (1) Get the Faust compiler working, because at least at that point it works, although slowly, ONLY then (2) add distcc to the equation so all that Faustastic nirvana can be even more efficient! I'm fairly good at debugging Linux stuff (he says) but I really appreciate the effort you put into to helping me, especially given that so few people seem to be going down this path.

            If I can, I will add that I took an online course in Faust which did a lot to help me understand it. I had looked at it briefly before and had no idea what it was trying to do. That course is here:

            https://www.kadenze.com/courses/real-time-audio-signal-processing-in-faust/info

            I have so far used Faust to make a custom delay VST for use with my DAW, and some weird Android apps that sound ike a howling banshee and are controlled by the phone's accelerometers. While I am not familiar with all the other options, I think Faust makes a perfect companion for Bela.

            You have been so helpful I would like to contribute some $$ to the Bela effort, let me know how. I think I'm going to buy a few more Belas and use one with my Eurorack, another one with my guitar, and maybe make something like the Bela Box.

              Digital-Larry I'm so excited that I got the HTTPlib thing dealt with

              that's good.

              Digital-Larry ach one had a few issues and I think a better flow for the documents would be to (1) Get the Faust compiler working, because at least at that point it works, although slowly, ONLY then (2) add distcc to the equation so all that Faustastic nirvana can be even more efficient!

              not sure. In principle, if the first FAUST project you are trying to build is "large enough", and you don't have distcc installed, that could take "forever" (i.e.: > 10 minutes) to compile, and possibly even fail after running out of memory or similar, which also is a pretty unsatisfying and confusing behaviour.
              You are the first one trying this on Ubuntu, afaik, so it was good to see what difficulties you encountered and how to fix those. I just noticed that actually the path issue (your CRITICAL error) was already covered in the guide here.
              This definitely needs to be better covered in the guide.
              I guess, in your case, things got a bit confused in that you were so excited about moving on to Faust that you forgot one step of the distcc setup (i.e.: making it the default compiler for Bela programs). Then the issues on Faust were solely due to the fact that libHTTPDFaust.zip was missing some files, but now this is fixed.

              All in all, I think the best way forward on this is to incorporate the changes needed on the board into the next release image, so that the user will only have to deal with the host-side of things.

              Digital-Larry If I can, I will add that I took an online course in Faust which did a lot to help me understand it. I had looked at it briefly before and had no idea what it was trying to do. That course is here:

              https://www.kadenze.com/courses/real-time-audio-signal-processing-in-faust/info

              I am sure this course is going to be great, I longly awaited it, but now I cannot take it as I am busy finishing off my PhD. Looking forward to going through that once I am done!

              I only understand the basics of Faust, but I used it to put together an instrument with an augmented keyboard. I combine C++ and Faust on Bela: https://github.com/giuliomoro/flute-key

              Digital-Larry You have been so helpful I would like to contribute some $$ to the Bela effort, let me know how.

              The best things you can do are:

              Digital-Larry I think I'm going to buy a few more Belas and use one with my Eurorack, another one with my guitar, and maybe make something like the Bela Box.

              then, build great things with it, spread the word, share your projects, be active on the forum! You will have seen that we have a couple of Eurorack modules out: a fully-featured one (Salt) and a passive DIY breakout (Pepper) https://shop.bela.io/modular .

                giuliomoro I will certainly be active on the Forum. I messed around a bit last night with the Bela IDE and actually cut and pasted some C++ code between different examples (e.g. to use the analog inputs in the scope application).

                I do documentation and support at my company, so I get a lot of input "this wasn't clear", "I got confused" etc. etc. about the stuff I've written and it is a big challenge esp. when your product is a tool that can be used many different ways and the level of expertise of the people using it goes from zero to eleven! So all I can share with you are my own experiences and yes sometimes I can be a little annoying about it (cough).

                Faust is cool partially because of the multiple targets possible (e.g. making a VST vs. a smartphone app vs. something just to goof around with in the web editor). But there's also probably an understanding that one code doesn't automatically work properly on all targets. So my suggestion for "getting started with Faust" would include building and trying the demo projects. I think I'll start a new thread on that.