Hiya,
None of the python deps for the documentation are auto-installed (yet). Life is probably simplest if you configure with -DDOCS=OFF
for now, but if you want the docs then the python requirements are here:
Hiya,
None of the python deps for the documentation are auto-installed (yet). Life is probably simplest if you configure with -DDOCS=OFF
for now, but if you want the docs then the python requirements are here:
Ok I disabled that!
New Bela builds, this time including SuperCollider, Pure Data and C++: Release flucoma-bela-feb23 · jarmitage/flucoma-bela · GitHub
Question: when I built flucoma-core
I got:
libHISSTools_AudioFile.a
libHISSTools_FFT.a
libflucoma_VERSION_LIB.a
Is that what is expected?
Yes. There will be some more static libs for a couple of the dependencies in _deps
as well.
I haven’t yet rustled up a sensible CMake target for core: it’s mostly header files, plus those few things to link to. I guess we’d want
flucoma-core
ininclude
/lib
foldersYes, that would be fantastic I think!
FYI, [declare -lib fluid_libmanipulation]
is necessary on Bela, trying to see if there’s a more streamlined way than doing that in every patch/project…
I reckon you have read how to install on pd on our learn.flucoma.org platform?
step 3 is your friend. if no gui, on the pd list there is a way to add it in the command line as you boot it.
Bela doesn’t run Pd on the CLI either, it’s through this template file: Bela/default_libpd_render.cpp at master · BelaPlatform/Bela · GitHub
It could be hardcoded in there probably, but for now I’ve concluded that [declare -lib fluid_libmanipulation]
is the most portable and user-friendly approach
Is there some way @weefuzzy that would CI this? OR does it need to be built on the bela?
The PD thing? That’s The bela platform’s own wrapper around libpd, so not ours to mess with
However, if there’s a libpd call to add things to the library call someone could try suggesting to team bela, via an issue / pr, that it would be neat if we could set an environment variable or something that it would check to add things to the libraries path. Certainly more flexible than coding-in flucoma stuff.
I meant more so producing the SC/PD binaries that @jarm did. I can see us adding it to our action pools for each release so that tinkerers can automatically get it!
Oh right. It’s possible to cross compile but not completely straightforward – you need a toolchain from the bela, and some special incantations. Plus not all the objects will work yet, IIRC.
That said, IIRC I’ve heard of folk doing CI for R-PI stuff using their own R-PI as self-hosted runner, so maybe that’s a possible path too.
I think it might be worth thinking about – its hard to know how many people it could enable if it just existed for them…
Greetings. First time poster here. I am curious if there are any updates on guidance for building for Bela. The flucoma-bela-feb-23 release requires Bela image v0.5.0alpha2 but that Bela image is listed as “v0.5.0alpha2 EXPERIMENTAL - DO NOT USE THIS IMAGE” so I am a little hesitant to try it. Thank you.
Hey you seem to have managed?
I’m posting here so @rodrigo.constanzo might get excited
Very cool!
yes, i did get flucoma running on bela, thank you.
as reflected in the github repository referenced above i am currently exploring the flucoma-sc code on Raspberry and am very excited by the prospect of having the flucoma capabilities on a tiny machine.