Building SuperCollider (and plugins) on Mac M1

Development
62

No, at least not yet. Its availability depends on the availability of all dependent libraries as universal builds.

1 Like
63

Thanks for this!

It would be great if this script is included in the SuperCollider release package!

64

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
65

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.

66

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! :wink:

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?

67

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
68

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ā€¦

69

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 ..
70

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?

71

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" .. && \
72

Looks like that worked! Thanks so much for your help and patience @Spacechild1 - and thanks for making VSTPlugin! :slight_smile:

1 Like
73

Cool! Maybe open an issue at @madskjeldgaardā€™s GitHub repo.

1 Like
74

Hi folks,
Unfortunately Iā€™ve not yet had the experience of working out how to do a build install of SC etc. and my installation of SC is via the binary download option.
Iā€™m now running the 3.13 ARM version (at least itā€™s showing up as apple in activity monitor) but canā€™t quite follow the various instructions here to allow my X86-64 plugins to run (iā€™m getting the usual error codes). @madskjeldgaardā€™s instructions suggest that it is possible to recompile the plugins for M1 (GitHub - madskjeldgaard/sc-plugins-build-scripts: Scripts for building and installing SuperCollider plugins on MacOS) but iā€™m not clear where i should run the code included at the bottom:

git clone --recurse-submodule https://github.com/madskjeldgaard/sc-plugins-build-scripts
cd sc-plugins-build-scripts

This is clearly not SC codeā€¦ if someone could clarify what the process is for transferring plugins into ARM mode that would be really wonderful. Thanks!

75

You would type the lines of code into operating systems terminal - Applications/Utilities/Terminal.

Just note that the first line of code: git clone --recurse-submodule https:// .... etc etc will create a folder with the entire repository in whichever folder the terminal window is currently pointed to. Typically, when just opening the terminal itā€™ll point to Mac HD > Users > yourUserName, which is typically displayed as ~/. To point it somewhere else, type cd location/of/folder/here.

76

Thanks @thresholdpeople! (I though it was something to do with CMake - thanks for clarifying).

Step 1 seems complete but next step seems unclear. I see the newly created folder Extensions/ PortedPlugins. Yet these Ugens donā€™t work after recompiling library. I get:
exception in GraphDef_Recv: UGen 'HarmonicOsc' not installed.

I imagine this is because i still need to do:
Step 2: So running each of these ./guttersynth-sc.sh arm64 translate the .scx files into ARM versions? Iā€™ve tried running this in the Terminal but to no effect. Where or how does one take these ported plug ins and make them ARM native? Or does SC thinks its in ARM native mode and its actually in Rosetta but its confused?

Finally, I donā€™t see the mi-Ugens in the PortedPlugs but yet there is discussion above about these and there is clearly some reference to them in @madskjeldgaardā€™s GitHub.

Sorry Iā€™m a totally newbie on this sort of thing (non code-based composer background).

77

What did you do to make PortedPlugins appear in your Extensions folder?

What happens when you perform step 2? Do you get an error message?

78

I pasted: git clone --recurse-submodule https://github.com/madskjeldgaard/sc-plugins-build-scripts

This created a temporary folder and also generated the folder PortedPlugins into my SC extensions folder.

Iā€™m unsure what step 2 involves. I thought that it meant adding a full file path to say guttersynth (in the Extensions folder) and then adding ./guttersynth-sc.sh arm64 (though its not clear if that means ./ or just /). But its completely unclear quite what is meant by the statement ā€œThen run one of the build scripts like so to build and install a plugin package:ā€ which mads includes in his instructions. At any rate if i try the above then it simply says: no such file or directory.

To be honest, Iā€™m not sure quite what Step 1 did apart from generate the portedplugins folder. Why these remain unported is not clear.

79

Hmm, it shouldnā€™t be generating the PortedPlugins folder until you actually do something - eg step 2.

Also that folder should be temporary. Clone the folder into some place you can reference later - downloads or desktop, or wherever makes sense organizationally (it doesnā€™t have to be in the Extensions folder, and likely better that it isnā€™t, from an organizational sense).

After you clone the sc-plugins-build-scripts folder, go into if by typing cd sc-plugins-build-scripts in terminal. Then you need to type ./guttersynth-sc.sh arm64. sc-plugins-build-scripts contains a script called guttersynth-sc.sh, you typing the previous command activates it, and arm64 is a variable that you feed into it. It should then go through the process of building the plugin for the M1 processor and automatically move it to your SC extensions folder.

The only one of those I havenā€™t been able to get to work is VSTPlugins, but I havenā€™t tried what the previous few messages before your post have discussed yet.

80

I must have added both steps 1 and 2 in the one go and this resulted in that behaviour. Iā€™ve deleted everything and restarted the process. Excellent, i have the build script folder at 877Mb which is better than before! But now Iā€™m wondering if Terminal permissions are an issue.
Your Terminal suggestions just result in:

cd: no such file or directory: sc-plugins-build-scripts

./guttersynth-sc.sh arm64 also gives me:

zsh: no such file or directory: ./guttersynth-sc.sh

This is relatively new M1 based laptop. Iā€™ve tested permissions and canā€™t see any issues but Terminal does not seem to want to play ball.

81

I donā€™t think itā€™s a permissions thingā€¦ cd means to go to a directory, and it canā€™t seem to find the location.

Try dragging and dropping the sc-plugins-build-scripts folder into the terminal window. It should cause the folder address to pop up.