Building SuperCollider (and plugins) on Mac M1

Thanks mem!!

This is a great news !
I just did an update of brew qt5 and it works ! Apparently the new version of QT5 WebEngine works on M1 ! I guess now it’s possible to make an official version of SuperCollider for Apple Silicon !

Best

1 Like

Can confirm, it works perfectly.

The only thing that I’m unable to build for M1 is vstplugin extension. The script doesn’t work for me and I can’t figure it out by myself. Does anyone have any step-by-step guides?

I think you still need to checkout the m1 branch for vstplugin: Files · m1 · Pure Data libraries / vstplugin · GitLab

So, after having git cloned it you can run git checkout m1 before proceeding.

I haven’t tried it myself but it seems to be the way to go.

1 Like

VSTPlugin v0.5.4 (= current master) should already build on M1. The “m1” branch is not stable - please don’t use it!

Thanks. I successfully compiled supercollider on m1. But I have strange things about performance, on rosetta (official release) I’ve got about 0.17%-0.20% of system load, but on m1 native I have 18%-22%. Look at the screenshots. Startup config is the same.

Hey, I do not know what 60 synths run on your server. In my case I did not see any problems with performance. But honestly, I do not run very CPU heavy stuff.
In idle I get 0.04% 0.12%.
Running some of my typical audio work I get performance better then I used to on other hardware (just few %). What synth are running on your machine on the screenshot?
If you want to, then send me your startup, then we can compare.

I did not add any additional synthesizers. This is the default installation ,just assembled according to the instructions above. As I sad recently, I have two version of supercollider. Official release and compiled on my m1 Mac with 19-20% in idle - cpu usage.
Here the screen of cpu usage on official release (rosetta)

This is strange. I have just 1 synth running after boot.
I attach my status screen for comparison.
You should investigate what is running there on your server I guess.

Did you do a debug build, perhaps?
Josh

/*
Josh Parmenter
www.realizedsound.net/josh
*/

I first did with --config option RelWithDebInfo . Then I did with cmake --build . --target clean --config Release . No difference, same 18-20% cpu.

It does look there’s something starting these synths when you start SC - either in startup.scd or in one of the quarks.

EDIT: I see that the same runs on the release build with lower cpu usage. It would be useful to know what are the synths that you’re running.

2 Likes

It’s just simple default startup file from tidalcycles docs:

(
s.reboot { // server options are only updated on reboot
    // configure the sound server: here you could add hardware specific options
    // see http://doc.sccode.org/Classes/ServerOptions.html
    s.options.numBuffers = 1024 * 256; // increase this if you need to load more samples
    s.options.memSize = 8192 * 32; // increase this if you get "alloc failed" messages
    s.options.numWireBufs = 64; // increase this if you get "exceeded number of interconnect buffers" messages
    s.options.maxNodes = 1024 * 32; // increase this if you are getting drop outs and the message "too many nodes"
    s.options.numOutputBusChannels = 2; // set this to your hardware output channel size, if necessary
    s.options.numInputBusChannels = 2; // set this to your hardware output channel size, if necessary
	s.options.sampleRate = 48000;
    // boot the server and start SuperDirt
    s.waitForBoot {
        ~dirt = SuperDirt(2, s); // two output channels, increase if you want to pan across more channels
        ~dirt.loadSoundFiles;   // load samples (path containing a wildcard can be passed in)
        // for example: ~dirt.loadSoundFiles("/Users/myUserName/Dirt/samples/*");
        // s.sync; // optionally: wait for samples to be read
        ~dirt.start(57120, 0 ! 12);   // start listening on port 57120, create two busses each sending audio to channel 0

        // optional, needed for convenient access from sclang:
        (
            ~d1 = ~dirt.orbits[0]; ~d2 = ~dirt.orbits[1]; ~d3 = ~dirt.orbits[2];
            ~d4 = ~dirt.orbits[3]; ~d5 = ~dirt.orbits[4]; ~d6 = ~dirt.orbits[5];
            ~d7 = ~dirt.orbits[6]; ~d8 = ~dirt.orbits[7]; ~d9 = ~dirt.orbits[8];
            ~d10 = ~dirt.orbits[9]; ~d11 = ~dirt.orbits[10]; ~d12 = ~dirt.orbits[11];
        );
    };

    s.latency = 0.3; // increase this if you get "late" messages
};
);

It would be nice if someone also ran the version with rosetta and the native version with this config to understand what the problem is.

So I guess it is some external / 3rd party plugin?
I think you should troubleshoot there first. Or at least do some ‘vanilla’ sc3 performance test comparison on both architectures, to detect if the problem is really the sc3 or perhaps the plugin.

I get:
ERROR: Class not defined. SuperDirt

So if I am not mistaken, what ever it is, it is not vanilla sc3.

My mistake, sorry for that, you need to recompile quarks:
Quarks.checkForUpdates({Quarks.install(“SuperDirt”, “v1.7.3”); thisProcess.recompile()})
or

include(“SuperDirt”);

you need to recompile quarks:

Not trying to be picky, but since it might be confusing to others:

  • quarks == “language extensions” which provide new classes, they do not need to (cannot) be (re)compiled. They get loaded/interpreted when sclang starts. However, you might need to update them, which the post above suggests.
  • plugins - they need to be compiled for the same platform (OS/CPU) the server is compiled for. One example is the “sc3-plugins” suite. They do come with some classes (i.e. sclang extensions) to provide interface to interact with the plugins.
2 Likes

Hello,

Do you how to compile the sc3-plugins Universal binaries so I can use in both the intel and M1 version of SC?

Thanks

Generally, it should be enough to do add -D CMAKE_OSX_ARCHITECTURES="x86_64;arm64" to the cmake configure step (e.g. cmake -G Xcode -D CMAKE_OSX_ARCHITECTURES="x86_64;arm64" ..)

Also, github actions for sc3-plugins now builds a universal binary. It will be released in 3.13, for now you can download it from github actions, e.g. https://github.com/supercollider/sc3-plugins/actions/runs/3034431991
One caveat is that you need to manually un-quarantine these plugins…

I used a following script for that

#!/bin/sh

PLUGINS_PATH="/Users/user/Library/Application Support/SuperCollider/Extensions/SC3Plugins"

find "$PLUGINS_PATH" -print0 | while IFS= read -r -d '' file
do
    if [[ -f "$file" ]] && [[ "$file" == *".scx" ]]; then
        basename=$(basename -- "$file")
        echo "un-quarantining ${basename}"
        xattr -rd com.apple.quarantine "$file"

    fi
done

You can save this as unquarantine.sh, make it executable and then run it. Make sure to update PLUGINS_PATH.

4 Likes

Nice! Thanks Marcin !!
Is there a Universal Binary version of SC?

Best