I’m still getting a bunch of SIMD errors from ConvolutionTools and I can’t reproduce how I managed to work around those like last time.
On the plus side I’ve done some Bela config refinement which makes it much less painful to iterate on this.
The change to the HISSTools commit we’re pulling is quite possibly only on dev , yes.
The error you’re seeing on dev is from the dependency we’re using to handle different memory allocators for us. I suspect it’s a cross-compiling gremlin. Looking at the CMake for this dependency, it does a bunch of test compiles to determine the alignment for different types, and gets these by grepping compiler output (!).
It’s looking for a string like align_of< ... but not finding it, and that seems to be because the compiler output it’s seeing is
Change Dir:
/root/flucoma-sc-nov22/build/_deps/memory-build/src/CMakeFiles/CMakeTmp
Which is obviously wrong
I’ll see if staring at their code and sobbing a bit makes it apparent why this should be
1 Like
/thread 
Updated my README here: flucoma-bela/README.md at main · jarmitage/flucoma-bela · GitHub
Right, if I deliberately make make my CMake fail by running their command and then bailing from CMake, I can see the sort of output they’re expecting.
What I did was to add the following to my flucoma CMakeLists file. Not sure it matters where in the file particularly, because it deliberately halts the process. Perhaps around line 42 for the SC one.
try_compile(align_result ${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_CURRENT_BINARY_DIR}/_deps/memory-src/cmake/get_align_of.cpp
COMPILE_DEFINITIONS "-DTEST_TYPE=bool"
OUTPUT_VARIABLE align_output
CXX_STANDARD 11
CXX_STANDARD_REQUIRED TRUE
)
message(FATAL_ERROR ${align_output})
This calls the compiler in the same way as the memory module, prints the error and then causes CMake to stop.
I get the following output. It starts in the same way as what you quoted above, but then goes on to include the align_of that the module is searching for.
If you do the same, do you see full output like this, or does it get truncated? I’m wondering if there’s some bad interaction with distcc here where it’s stopping harvesting the compiler output after the first new line.
[cmake] Change Dir: /Users/owen/dev/flucoma-core/build/CMakeFiles/CMakeTmp
[cmake]
[cmake]
[cmake]
[cmake] Run Build Command(s):/usr/local/bin/ninja cmTC_01a10 && [1/2] Building CXX
[cmake] object CMakeFiles/cmTC_01a10.dir/get_align_of.cpp.o
[cmake]
[cmake] FAILED: CMakeFiles/cmTC_01a10.dir/get_align_of.cpp.o
[cmake]
[cmake] /usr/bin/clang++ -DTEST_TYPE=bool -stdlib=libc++ -isysroot
[cmake] /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk
[cmake] -mmacosx-version-min=10.8 -std=c++11 -MD -MT
[cmake] CMakeFiles/cmTC_01a10.dir/get_align_of.cpp.o -MF
[cmake] CMakeFiles/cmTC_01a10.dir/get_align_of.cpp.o.d -o
[cmake] CMakeFiles/cmTC_01a10.dir/get_align_of.cpp.o -c
[cmake] /Users/owen/dev/flucoma-core/build/_deps/memory-src/cmake/get_align_of.cpp
[cmake]
[cmake]
[cmake] /Users/owen/dev/flucoma-core/build/_deps/memory-src/cmake/get_align_of.cpp:6:3:
[cmake] error: static_assert failed due to requirement '1UL == 0' "this should
[cmake] fail, the purpose of this is to generate a compile error on this type that
[cmake] contains the alignment value on this target"
[cmake]
[cmake] static_assert(alignment == 0, "this should fail, the purpose of this is to generate a compile error on this type that contains the alignment value on this target")
[cmake] ^ ~~~~~~~~~~~~~~
[cmake]
[cmake]
[cmake] /Users/owen/dev/flucoma-core/build/_deps/memory-src/cmake/get_align_of.cpp:16:25:
[cmake] note: in instantiation of template class 'align_of<bool, 1>' requested here
[cmake]
[cmake] get_align_of<TEST_TYPE> dummy
[cmake]
[cmake] ^
[cmake]
[cmake] 1 error generated.
[cmake]
[cmake] ninja: build stopped: subcommand failed.
[cmake]
[cmake]
[cmake]
[cmake]
[cmake]
[cmake] Not searching for unused variables given on the command line.
[cmake] -- Configuring incomplete, errors occurred!
[cmake] See also "/Users/owen/dev/flucoma-core/build/CMakeFiles/CMakeOutput.log".
If it is a distcc burp, then all is not lost (I hope).
Per this GH issue, the memory module should only need to try and go through this dance once, if at all (I’m still not 100% what it’s actually for 
)
Basically, it needs to see a generated header, container_node_sizes_impl.hpp at
_deps/memory-build/src/.
In the GH issue the dev says it should work wiht just an empty file, but it’s not happy if I try that here.
So an option is to configure without distcc, just using the local compiler, and then harvest the generated header before switching back to distcc.
Just checking in to check with @weefuzzy as to whether dev either removes any dependence on the SIMDSuprot.hpp from HISSTools library, or pulls in the latest versions (and uses SpectralProcessor.hpp, rather than ConvolutionTools.hpp which is defunct). The latest change in HISSTools library should support ARM in both 32 and 64 bit, as I needed that to work for a project elsewhere.
Assuming the latest hs been pulled in then my part of things should be sorted, and Owen will unfortunately have to do all the sobbing on this one, and not me…
@a.harker Yeah, you’re off the hook, I think. We’re puling what’s currently the head of main (559b5c8) and convolution tools is no more.
Kind of tangential to the more technical/implementation discussions here, but is it possible to run the pd external versions of FluCoMa on a bela? (i.e. be able to code up a pd patch using the FluCoMa externals, and then run that on the bela)
Or do you have to use the CLI/C+±y implementation of FluCoMa stuff to do it on a bela?
Should be possible, given a bela compile of the flucoma pd externals. I can’t remember offhand what the dance is for getting the bela pd to load / find third party externals (but I seem to remember it being A Thing)
1 Like
Yeah, had some googling about on the bela forum and such but didn’t find an immediately obvious answer. I did see something about uploading things via the IDE, but didn’t know if it was restricted to certain known/special versions of externals since I guess the pd runs “headless” on the bela once it’s up there.
@jarm explains it all here Compiling PureData externals for Bela · GitHub
tl;dr, yes it’s perfectly possible – all the stuff in this thread still applies (like you need to compile flucoma-pd for bela, which implies a certain amount of setting up). I’m not sure what the state of building on bela is just ATM. The last I saw was some badness with one of our dependencies.
Ah right. So the pre-compiled versions (via the download link) won’t work as is. It’s still a bit before I’m wrestling with the code of this as I need to work out some hardware to scale the 5v CV outs to 12v (for use with a Landscape NOON), but wanted to start getting some brain juice bubbling in the background in preparation.
No, there’s only pre built binaries for a limited number of platforms, bela not among them (different cpu architecture, kernel and what have you from the Ubuntu binaries at that link)
1 Like
I do plan on trying to build the Pd externals for Bela, hopefully in the next month - Ideally I would like my repo to feature C++, SuperCollider and Pure Data builds.
The linked Gist was correct at time of writing, hopefully nothing has changed there!
That’s at least two hopefully’s.
3 Likes
Right right, I guess I assumed that Linux covered it, but it’s more specific than that.
Fantastic.
This is a noob-ish question, but are ‘builds’ transferrable? Like if I download your build of the pd externals for bela, can I just put those on mine, or do I personally need to have the build process run on the bela?
The short answer: if your Bela operating system + general guts are exactly the same version as what was used to build, you’re golden. If yours are newer, you’re probably golden. If they’re older, then you’re probably not.
The fly in the ointment here is that, IIRC, flucoma needs a bleeding edge, still experimental image to build.
1 Like
@rodrigo.constanzo’s middle name is bleeding-edge-build
1 Like
Fortunately Bela images are painless to flash these days: Managing your SD card - The Bela Knowledge Base
1 Like
Back again…
[ 51%] Making SC docs
Traceback (most recent call last):
File "/usr/lib/python3.9/runpy.py", line 197, in _run_module_as_main
return _run_code(code, main_globals, None,
File "/usr/lib/python3.9/runpy.py", line 87, in _run_code
exec(code, run_globals)
File "/root/flucoma-sc/build/_deps/flucoma-docs-src/flucoma/MakeRef.py", line 16, in <module>
from flucoma.doc import render
File "/root/flucoma-sc/build/_deps/flucoma-docs-src/flucoma/doc/render.py", line 14, in <module>
from jinja2 import Environment, FileSystemLoader, select_autoescape
ModuleNotFoundError: No module named 'jinja2'
make[2]: *** [CMakeFiles/MAKE_SC_REF.dir/build.make:78: CMakeFiles/MAKE_SC_REF] Error 1
make[1]: *** [CMakeFiles/Makefile2:534: CMakeFiles/MAKE_SC_REF.dir/all] Error 2
make: *** [Makefile:149: all] Error 2
Any idea why this dependency is missing?