I’ve started trying to explore the FluCoMa toolset in SuperCollider and am experiencing some issues with a lot of the UGens provided. Before I get into the details, I want to give full disclosure: I am a little bit dumb. Just kidding. But I’m very new to programming (SC is my first and really my only language) and even though I’m on a Linux machine, I am very much NOT a poweruser. So sorry if my descriptions are lacking or unclear. I’m doing my best!
First, the specs - my computer is running Fedora 41 with a custom kernel (surface-linux), SuperCollider 3.12.0 & 3.13.0, FluCoMa 1.0.7 & 1.0.8.
I have monkeyed around in Flucoma, using things like FluidSines, HPSS and TransientSlice to great success. However, I wanted to start doing some stuff using FluidBuf UGens, Datasets and MLP and that was where my trouble began. Initially I was trying to use FluidBufAmpSlice to do some basic separation of large files into smaller chunks. Whenever I tried to run the routine with FluidBufAmpSlice SC would crash, giving Server 'localhost' exited with exit code 0. server 'localhost' disconnected shared memory interface in the post window. I also tried the same script using FluidBufAmpGate and FluidBufOnsetSlice, both producing the same error. However, a quick test of FluidAmpSlice seemed to work just fine, so it seems like the issue is just with FluidBuf UGens and not their counterparts.
I came across this thread about files with 96khz sample rates crashing SC so I tried using 48khz files instead but continued to get the error. I also looked through this about SC crashing when loading buffers, especially larger filesizes/number of samples. I figured I would try using smaller files but still got the crash. My problem wasn’t really with loading buffers anyway, and I could playback buffers with very long and large files with no problem. I t was just when I tried to use FluidBuf Ugens that the error would occur.
Reading a bit more, I remembered seeing something about Boost issues between SC and Flucoma, so I decided to try and do a fresh install of SC. I had been running Supercollider 3.12.0 (the version downloaded using dnf install from the Fedora package manager) but I decided to try and install 3.13.0. I had never built anything from source before and I had a really hard time with, almost entirely because of Boost. I went through a lot of different avenues but to cut to the chase, I eventually was able to successfully build and install SC-3.13.0 by installing Boost-1.83.0 via their website AND using dnf install boost-devel (which also installs 1.83.0). I am sure this is wrong!!! But it was the only way I was able to successfully build SC with SYSTEM_BOOST on. And the new version works, aside from the FluCoMa packages I mentioned. At this point I even tried to just assign a variable to a FluidDataSet (~timbredata = FluidDataSet(s);) and SC immediately crashes again.
Any idea whats going on here? I really think it might be something with Boost, but I didn’t really know how to navigate CMakeLists and whatnot. Also I would love to post this on scsynth but unfortunately I tried to sign up months ago and still haven’t gotten mod approval. But my issue really does seem to stem specifically from FluCoMa.
Thanks for the report. I think you’re on the right track with Boost, but you’re missing one piece: it’s not the specific version of Boost that matters but that SC and FluCoMa are using the same version.
So, having got SC working with SYSTEM_BOOST the simplest thing to do is probably to build FluCoMa against the same Boost. Shamefully that’s still not been documented, but you can use the same flag (SYSTEM_BOOST).
git clone https://github.com/flucoma/flucoma-sc.git
cd flucoma-sc
mkdir -p build && cd build
cmake -DSC_PATH=</path/to/sc source code> -DSYSTEM_BOOST=ON ..
make install
and some time later you should have a package in release-packaging/FluidCorpusManipulation. I would suggest that you just replace the .so files in your existing installation, rather than building the documentation as well, because that involves some extra mucking about with python.
Sorry, would you mind walking me through this step? While trying to install flucoma I do get an error wrt documentation (it can’t find a python module) and this stops the entire install…
Also, a quick question: does the SYSTEM_BUILD flag actually enable boost or just tell your build to use your systems version of boost rather than some version that might come packaged with/get installed by the source? Wondering if I could maybe just rebuild SC without SYSTEM_BUILD and just use Flucoma via the SC extensions folder, since I initially encountered my error while using SC-3.12.0 and Flucoma 1.0.7 (which I’m guessing was released against SC-3.13.0?) Thanks so much for your quick answer, I was despondent! Hopefully I can get it up and running soon.
Edit: Ah! Running cmake -L I see there’s a flag for DOCS=ON, I’ll try rebuilding with that switched off.
Okay, so the build and install went smoothly once I set DOCS to off…However SC is now throwing Class not defined errors on all Flucoma objects. Is the issue that -DSC_PATH needs to be pointing to SC’s install path? I set it to point to the path with the actual source code and build folder I used when installing SC, but maybe that was wrong? Although I followed this same procedure when building sc3 plugins from source and SC_PATH was pointing to the same folder, so I don’t think thats it. Again, really appreciate any help!
Also sorry if this kind of goes outside the scope of this forum, I know it would probably be better to try and ask over at scsynth. I’ll try and make a new account so I can see if anyone has and advice over there.
The default behaviour is that it will use the Boost that is included with the SC source code. If SC is built with SYSTEM_BOOST then it will look for one in /usr/local or similar, and so flucoma needs to do the same. The reason for all this awkwardness is that we’re having to cheat a bit, in advance of some new functions getting added to the SC API.
Glad you found the DOCS thing. Apologies – I thought it defaulted to off rather than on
That said, not sure about the error. It sounds like it’s language side rather than server side.
Did you replace the whole lot with new stuff, or just the compiled plugins?
Have you restarted SC / rebuilt the class library?
SC_PATH should only really be relevant for compiling. Thereafter you should have some working binaries, ready to be put into SC’s search path (but you’ll still need the SC class files and help files from the existing installation as well)
Aha! Total brain fart on my end. I just had the rebuilt plugins in my SC extensions folder, sans class files. All seems well so far! Thank you so much for your help
