I am trying to get Flucoma working on my El Capitan machine (2008 Mac Pro 8 core beast that would be perfect for parallel processing)… but I get this error:
FAILURE IN SERVER /cmd failed
Not sure what that means, but it implies that this won’t work on El Capitan…what thinks ye?
this is bizarre, since we have very little os dependencies, but @weefuzzy will be able to confirm. I thought we compiled everything for 10.7+ Are you certain of your SC version (we compile for 3.9+)?
this is probably some kind of sc issue. the server won’t boot when the .scx files are in the Extensions folder. any ideas?
OK. I think it is something you are doing. The .scx files are the problem. When they are in the Extensions folder, the server won’t boot. I also have this problem with Harker’s FrameLib, but with nothing else. SC3Plugins are fine.
This looks like a SC version issue, but I’m sure you’ve checked that. Except if they changed something. We are compiling against 3.9 sources here, so if your SC version is 3.8 it won’t work (they made a big change then) @weefuzzy might have other wisdom, and so might have @a.harker here…
and is this a 64-bit version of SC?
Google your machine and see if the processor support AVX. I bet it doesn’t.
By the way I would suspect that the server boots and immediately crashes, and you should have a crash log in your console somewhere.
Damn you and your AVX! I guess I dug this 2008 Mac pro up from the basement and spent 2 days installing El Capitan for nothing.
Maybe not for nothing, although I don’t know where to remove all the compile flags. Have you tried the CLI compiles on that machine? They might bow differently…
AVX is on for all builds of fluid everything at the moment (and FrameLib). It so happens that I’ve just today been reviewing framelib for whether to require AVX or not (jury is out), so it is at the forefront of my mind. It’s not a fundamental requirement of either sets of code, but in theory it makes things faster so we set it on. Unfortunately, shipping versions that would work either with or without AVX would add a significant layer of complexity (and binary size) because you need to compile the same code multiple times, avoid symbol crashes and then dynamically load the correct one for your architecture at runtime to dispatch to the right binary code. That’s a bit of a pain.
All the code can be compiled without the compiler flags, but this is all done via cmake, which is supposed to make your life easier but in experience thus far just reminds me of this:
https://xkcd.com/1671/ @weefuzzy will inform me if this is not cuddly enough for public consumption.
I suppose one can also just turn the flags off in Xcode after generating the project and compile a non AVX version.
PA - to make this happen you need to go to the Xcode project and delete the -mavx flag from every target in the SC project (including the FFTLib). Everything else is headers so that should work, but if the flag is on anywhere the binary may fail to load. Sadly the flag is set at target level, and not for the project, meaning one must set individually per target. I’m not sure what the situation is with the other SSE settings for that machine (I’m not even sure if the settings can be made individually as they are), but it’s not too lengthy a job to generate a build with different flags.
I’m fine with it…but it was going to be fun getting this old horse to crunch some numbers. This machine has 8 true cores. Basically designed for this stuff. For now I will just use the 12 core trash can instead…haha. That one goes to 12.
Sam
thanks @a.harker for your wisdom and hints. I’m fighting a Pd helpfile war now, but as soon as I’m done I can try this for @spluta …
I’ll do a build in a moment when I’ve sorted more pressing matters and float it to the internet.