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
No, at least not yet. Its availability depends on the availability of all dependent libraries as universal builds.
1 Like
Thanks for this!
It would be great if this script is included in the SuperCollider release package!
Sc3-plugins releases are signed/notarized and don’t need to be un-quarantined manually.
I’d say this is really kind of a hack, I don’t think it should be included in any official release… but it could live somewhere on the wiki I guess.
1 Like
Thanks! Was just trying to find an M1 compatible version of the mi-ugens extensions and this let me build one myself! Very helpful. Much appreciated.
Hej Mads! I’ve been trying to build vstplugin on an M1 mac running SC 3.13 using your scripts, but I’m running into problems…all the other scripts seem to work great, for what it’s worth! 
I have zero experience with cmake so I’m not sure what is relevant info from the terminal output, but these lines might be worth something:
.../sc-plugins-build-scripts/vstplugin/vst/VST3Plugin.h:7:10: fatal error: 'pluginterfaces/base/funknown.h' file not found
.../sc-plugins-build-scripts/vstplugin/vst/VST2Plugin.h:8:10: fatal error: 'aeffectx.h' file not found
These lines get printed a few times and are then followed by a bunch of deprecation warnings…any idea as to what I should be doing differently?
Looks like it didn’t install the VST2 and VST3 SDKs.
Looking at the script, I think
should rather be
# Get VST2
./vstplugin/.git-ci/get_vst2.sh
# Get VST3
./vstplugin/.git-ci/get_vst3.sh
Thanks for the tip, but that didn’t seem to work unfortunately - I get the same CL printout…are those files ( 'pluginterfaces/base/funknown.h' and 'aeffectx.h') supposed to be somewhere in the build folder? I can’t seem to find them…
are those files (
'pluginterfaces/base/funknown.h'and'aeffectx.h') supposed to be somewhere in the build folder?
No. They have to be downloaded and extracted to the vst folder (see README). That’s what get_vst2.sh and get_vst3.sh does.
I see the problem now. The scripts need to be called from within the vstplugin folder. The following should do the trick:
cd ./vstplugin
# Get VST2
./.git-ci/get_vst2.sh
# Get VST3
./.git-ci/get_vst3.sh
cd ..
Thanks for that! VSTPlugin builds now, but for some reason when I recompile SC I get this message:
*** ERROR: dlopen '/Users/mikemccormick/Library/Application Support/SuperCollider/Extensions/VSTPlugin/plugins/VSTPlugin.scx' err 'dlopen(/Users/mikemccormick/Library/Application Support/SuperCollider/Extensions/VSTPlugin/plugins/VSTPlugin.scx, 0x0002): tried: '/Users/mikemccormick/Library/Application Support/SuperCollider/Extensions/VSTPlugin/plugins/VSTPlugin.scx' (mach-o file, but is an incompatible architecture (have (x86_64), need (arm64e)))'
Sorry for all the noise - I feel like I’m missing something obvious here…I’m passing arm64 as the first argument to Mads’ script; is there perhaps a cmake variable that would override that argument and build for Intel?
The cmake command misses the -DCMAKE_OSX_ARCHITECTURES="$OSX_ARCH" setting. All the other scripts have it, so it’s probably just an oversight.
Line 33
cmake -DSC=ON -DPD=OFF -DVST2=ON -DVST3=ON -DBUILD_HOST=ON -DBUILD_HOST32=ON -DBUILD_WINE=OFF -DWINE=OFF -DBRIDGE=ON -DSUPERNOVA=ON -DSC_INCLUDEDIR="$SC_LOCATION" -DCMAKE_BUILD_TYPE=RELEASE -DSC_INSTALLDIR="$INSTALL_LOCATION" .. && \
should be
cmake -DCMAKE_OSX_ARCHITECTURES="$OSX_ARCH" -DSC=ON -DPD=OFF -DVST2=ON -DVST3=ON -DBUILD_HOST=ON -DBUILD_HOST32=ON -DBUILD_WINE=OFF -DWINE=OFF -DBRIDGE=ON -DSUPERNOVA=ON -DSC_INCLUDEDIR="$SC_LOCATION" -DCMAKE_BUILD_TYPE=RELEASE -DSC_INSTALLDIR="$INSTALL_LOCATION" .. && \