Building SuperCollider (and plugins) on Mac M1

hi semiquaver,
does SuperCollider support Blackhole devices?

@simmania blackhole presents itself as a regular soundcard and yes, supercollider can use it like most other programs.
The are some considerations about clocking etc that are specific to blackhole (not supercollider) that should be observed when using blackhole with other devices (in short, when using blackhole as just input or output, and another soundcard as the other device, you should create and aggregate device in Audio MIDI setup, set one of those devices as clock master and the other for “drift correct”, then use that aggregate device in SC)

Hello all,
tried to compile and run SC3 plugins on a M1 and got this known error (for every plugin) when booting the server:

*** ERROR: dlopen ‘/Users/jan/Library/Application Support/SuperCollider/Extensions/SC3plugins/HOAUGens/HOABeamDirac2HOA4_supernova.scx’ err ‘dlopen(/Users/jan/Library/Application Support/SuperCollider/Extensions/SC3plugins/HOAUGens/HOABeamDirac2HOA4_supernova.scx, 0x0002): tried: ‘/Users/jan/Library/Application Support/SuperCollider/Extensions/SC3plugins/HOAUGens/HOABeamDirac2HOA4_supernova.scx’ (mach-o file, but is an incompatible architecture (have ‘arm64’, need ‘x86_64’)), ‘/usr/lib/HOABeamDirac2HOA4_supernova.scx’ (no such file)’

Is there a way to get SC3 working in the meanwhile and an instruction how to do so?
Thanks,
Jan

Is SuperCollider itself build for M1? Looks like it’s an Intel version.

It’s most probably not, i had downloaded the last release. So one would have to compile SC specifically for M1 then? Is there something specific that would work differently in that case?

The architecture of Server and plugins has to match.

Why are you compiling sc3 plugins for ARM in the first place? If you plan to run the Intel version of SuperCollider, you can simply use the Intel binaries of sc3 plugins: Releases | sc3-plugins

I was not aware the architectures didn’t match. I’d actually like to compile SC for arm but so far i’m not even sure how to do so and if it has other caveats? Is there an instruction on how to do so?
(So far any compiling with M1 has proven to be quite a challenge, presupposing quite a bit of knowledge or understanding in these matters)

If you compile SC on an M1, you should get an ARM binary by default. Just follow the usual instructions and give it a try. @MarcinP has mentioned above that he successfully compiled SC for ARM, but I don’t know how smoothly it went.

1 Like

Ok i see, thanks! @MarcinP is it very bumpy to set it up? (especially to someone not particularly fluent in command line…)

It’s not super bumpy if you use the right commands… which mostly means that you need to disable the webengine (and thus help browser). Be sure to be on the current develop branch.

Follow the regular macOS readme to get proper libraries etc. Then when configuring cmake, use

cmake -G Xcode -DCMAKE_PREFIX_PATH=`brew --prefix qt` -DSC_USE_QTWEBENGINE=OFF ..

This should run without errors. If there’s an error… then report back. If not, build, per readme:

cmake --build . --target install --config RelWithDebInfo

There might be issues, but it’s totally doable. Once built, SC runs flawlessly (though the lack of help browser is annoying). Help files can be generated in SC using SCDoc.renderAll, then you can access them with a regular browser in ~/Library/Application Support/SuperCollider/Help. I hope this helps!

3 Likes

@madskjeldgaard SC3-plugin instructions worked great, thanks!

@MarcinP your instructions worked for SC itself, thanks!

@Spacechild1 I am trying to get VSTPlugin building, I have to say that the following from the Readm leaves me slightly in the dark :sweat_smile::

cd into the build directory and run cmake .. + the necessary variables

I tried this:

cmake .. -DSC_INCLUDEDIR="../../supercollider-src" -DBUILD_HOST_AMD64=ON

And then when I do

cmake --build . -j -v

I get

/vstplugin/pd/src/vstplugin~.cpp:286:13: error: use of undeclared identifier 'error'; did you mean 'Error'?
            error("couldn't read cache file: %s", e.what());
            ^
/vstplugin/vst/Interface.h:293:7: note: 'Error' declared here
class Error : public std::exception {
      ^
/vstplugin/pd/src/vstplugin~.cpp:288:13: error: use of undeclared identifier 'error'; did you mean 'Error'?
            error("couldn't read cache file: unexpected exception (%s)", e.what());
            ^
/vstplugin/vst/Interface.h:293:7: note: 'Error' declared here
class Error : public std::exception {
      ^
/vstplugin/pd/src/vstplugin~.cpp:304:9: error: use of undeclared identifier 'error'; did you mean 'Error'?
        error("couldn't write cache file: %s", e.what());
        ^
/vstplugin/vst/Interface.h:293:7: note: 'Error' declared here
class Error : public std::exception {
      ^
3 errors generated.

I noticed your M1 branch is no longer there. Any ideas? Are there missing variables from my first cmake command?

@jarm

that’s a bug with vstplugin~ + Pd 0.52.1. I just pushed a fix to develop!

I noticed your M1 branch is no longer there.

Because it has been merged :slight_smile:

Just pull from develop and try again! BTW, if you don’t want to build the Pd version, set -DPD=OFF.

1 Like

Alright, got it built now.

I’m trying to run this:

In some cases I’m getting errors like:

ERROR: couldn't load '/Library/Audio/Plug-Ins/VST3/Vital.vst3': Can't bridge CPU architecture amd64
ERROR: couldn't open 'Vital.vst3'

And when I check the VST:

file Vital.vst3/Contents/MacOS/Vital
Vital.vst3/Contents/MacOS/Vital: Mach-O 64-bit bundle x86_64

Sure enough it’s Intel. But that means the “bridge” isn’t working, right?

Then let’s try with another VST:

file SubLab.vst3/Contents/MacOS/SubLab
SubLab.vst3/Contents/MacOS/SubLab: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit bundle x86_64] [arm64]
SubLab.vst3/Contents/MacOS/SubLab (for architecture x86_64):	Mach-O 64-bit bundle x86_64
SubLab.vst3/Contents/MacOS/SubLab (for architecture arm64):	Mach-O 64-bit bundle arm64

Different error:

probing /Library/Audio/Plug-Ins/VST3/SubLab.vst3... error! subprocess was terminated with signal 6 (Abort trap: 6)
ERROR: couldn't open 'SubLab.vst3'

Any thoughts on these issues?

Edit: and yes I did go through the macOS 10.15+ gatekeeper workarounds

@jarm I think we should move this to the bug tracker: Issues · Pure Data libraries / vstplugin · GitLab

Please list the plugins that do work and some that don’t. Also, check if there is a host_amd64 executable in the plugins folder and if yes, post the output of file.

Thanks!

1 Like

@Spacechild1 ok, done! Testing on Apple Silicon (Mac Mini M1) (#137) · Issues · Pure Data libraries / vstplugin · GitLab

1 Like

thanks, Marcin, for the detailed instructions here.

Since this is a working solution, maybe @madskjeldgaard would like to update his initial topmost post in this thread to integrate this?

:smiley:

1 Like

I added vstplugin and sc3-plugins to my easy-to-use build scripts for macos (and M1)

4 Likes

Hello,

I’ve tried to build plugins for M1, but I’ve got some issues…
I’ve cloned and changed the folder as mentioned in the ReadMe.

git clone --recurse-submodule GitHub - madskjeldgaard/sc-plugins-build-scripts: Scripts for building and installing SuperCollider plugins on MacOS
cd sc-plugins-build-scripts

But, when I try e.g. :

./guttersynth-sc x86_64

I’ve got :

zsh: permission denied: ./mi-UGens

And even with sudo and my password, it does not work:

xon@MBPdeChristophe sc-plugins-build-scripts % sudo ./mi-UGens arm64
Password:
sudo: ./mi-UGens: command not found

Do you have an idea what I do wrong and what I have to do to compile for M1 ? (not at all an expert in compilation)

Many thanks for all,

Christophe

Sorry, you need to add .sh to the command. Eg ./mi-UGens.sh x86_64

will correct readme

and if that doesn’t work, try running chmod +x mi-UGens.sh before running that command. this will make it executable for your user