Yes I know! My point was to use that when possibly preparing the standalone template.
Here’s the branch I was working with to move toward a “launchable” standalone as part of the regular build pipeline:
It probably doesn’t make sense as a pull request, but possibly stepping through the commits will provide some ideas. Some of the required changes are quite simple and small - e.g. allowing the IDE to point to EITHER an sclang binary OR an app package containing an sclang binary (https://github.com/supercollider/supercollider/commit/400cd565bca82c684294bd30b22135e5e3147e8e), enabling running sclang without a stdin, which is the case when it’s launched from an app package (https://github.com/supercollider/supercollider/commit/5b2132340c175efec15f24a7676c55830a9c8a10).
The once piece that was slightly tricky: for a “regular” packaged SC IDE, we don’t want duplicate QT libraries for both the IDE and the embedded sclang app package. So, there’s a final stage as part of install where we just symlink the required QT libraries into sclang.app from the SC ide app that contains it (https://github.com/supercollider/supercollider/commit/80de1caf8876bcfca55f36d3dd26de9a8e11b6cd).
IIRC this branch was 95% working when I did it, but the QT library fixup step and signing were both still problems. Probably these things have changed in the intervening years anyway - hopefully in ways that make them work better 
but at a minimum in ways that would require changes to how I was handling it.
2 Likes
Hi all, interesting topic, thanks Scott!
Crossplatform standalones would be fantastic of course,
would be really happy to see that, and will try to help in any way I can.
For completeness, I tested making one with Standalone quark, and yes, this is not working anymore as it did :-/ The app fails to open, likely because the renamed internal binary looks suspicious / trips the code-signing check:
LSOpenURLsWithRole() failed with error -10810 for the file /Users/adc/Desktop/MyLittleLony.app,
and luckily -101810 is " kLSUnknownErr" :
https://developer.apple.com/documentation/coreservices/3074489-anonymous/klsunknownerr?language=objc
oh well …
In case this is helpful, the hairiest part of the Standalone quark was making sure the standalones are really fully independent from SuperCollider, and also from each other.
For macOS, that involved renaming the SuperCollider binary file to a unique name for each standalone, (and copying that name into internal info.plist), which leads the app to create its own independent userAppSupportDir and userExtensionDir when first started. Once that works, there is no accidental crosstalk between quarks, synthdefs, or any other data that SC and standalones read and write.
While a generic SCStandalone app would be great first step, I think people would soon put multiple standalones on the same computer (packaged pieces / setups), and then independence between these standalones becomes really crucial.
For simplicity, I would agree to turn off the newly made extension folders completely.
All quarks to include can go into an InternalExtensions folder (inside the app on macOS).
Most of my standalones for various projects ended up with this folder structure:
Standy/
- Standy.app/
- startup.scd ← just redirects to a project loadMe file
- projects/
– proj1/
— 00_loadMe_proj1.scd
… code files & folders …
– proj2/
2c, adc
1 Like
Yeah, my idea is that a standalone is basically just a normal sc install that doesn’t look to or create support directories. In effect there would be local folders for extensions and app code (in the same folder probably rather than bundle for simplicity and in case the OS looks for bundle modification). IIUC I think that should have no issues, and would allow multiple standalones to coexist without conflicts.
I think just getting that working would be a great first step, and hopefully stable. We could add bells and whistles later if desired.
1 Like
and would allow multiple standalones to coexist without conflicts.
That is very important. I think in the past there were some methods for standalones that would run but the system would still see as the SuperCollider app.
Glad to see interest in solving this! 
Every few months I give another try to fixing sc_osx_standalone but I can’t figure it out…
2 Likes
Cross platform standalones would be amazing!!
- it would be nice to have an option to exclude the IDE entirely and just launch sclang.
1 Like
Just out of interest does anyone have a recent Standalone I could mess around with?
I have a couple of projects I’ve been working on and I’m thinking of putting them out there for every1 to play with.
2 Likes
Here is the relevant commit FYI: sclang: add terminal standalone option · supercollider/supercollider@a9a96c1 · GitHub
It’s not immediately clear how Miguel intended this to work. @miguel-negrao can you clarify?
Just to let you know that I got sc_osx_standalone working again though I have only tested it on my machine for now. For anyone interested in the topic, I think it is worth having a look at the run.sh file to see the hoops I had to jump through to get this to work. I don’t know if I am missing something but I would love sclang and scsynth to be capable of running as individual command line utilities in a manner that is agnostic towards the SuperCollider.app.
1 Like
I was just trying to get this working a couple of days ago to no avail, so I am very grateful for your work! I tested it now on my machine with the white noise “hello world” code you provided, and it works. It plays the white noise, however I am getting a few warnings before the server boots. I’m not sure if they are significant, but I thought it was worth bringing to your attention. Here is the output I get before the server boots:
readlink: illegal option -- f
usage: readlink [-n] [file ...]
run.sh: line 32: SystemOverwrites/plusOSX.sc: No such file or directory
compiling class library...
Found 855 primitives.
WARNING: Could not open directory: 'SystemOverwrites'
To resolve this, either create the directory or remove it from your compilation paths.
Compiling directory 'SCClassLibrary'
WARNING: Could not open directory: 'plugins'
To resolve this, either create the directory or remove it from your compilation paths.
numentries = 834570 / 12202144 = 0.068
5428 method selectors, 2248 classes
method table size 13289448 bytes, big table size 97617152
Number of Symbols 12163
Byte Code Size 364647
compiled 327 files in 2.19 seconds
compile done
localhost : setting clientID to 0.
internal : setting clientID to 0.
Class tree inited in 0.01 seconds
Thank you for reporting this! I think it is fixed now so could you remove all the previous files, re download and test. Don’t use the previous version cause most probably it was running from the defaults so not very standalone 
You should get the macOS popups to allow for scsynth and sclang the first time you run it as it is the usual process with unsigned apps.
If you keep having trouble post an issue on GitHub so we don’t flood this thread.
1 Like
Thanks @Dionysis for your work on this. I’ve just tried again and am experiencing some issues. Report filed here: Example file doesn't play · Issue #13 · dathinaios/sc_osx_standalone · GitHub
@miguel-negrao As there’s been no answer on this, I’m going to assume that this just doesn’t work, and proceed with reworking the implementation to something more sensible. I’ll try to get together a proof of concept quickly.
1 Like
I’ve got something similar to this - there’s a command line incantation you can use to run an scynth instance with a startup command like so:
/usr/bin/sclang -d ${RUNTIME_DIRECTORY} -l ${YAML_CONFIG} ${STARTUP_FILE} 1> ${STD_OUT} 2> ${STD_ERR}"
So long as the SC file contains all of the imports/etc. you need, it should be enough to get a job running by itself.
Thanks. My goal is to get a very simple version of this working (we can add bells and whistles later). Simple enough that intermediate users can easily work with it. I started poking around yesterday in a new branch, and it’s just about working.
1 Like
Okay seems to be working so far.
PR up for comment here: New standalone approach by muellmusik · Pull Request #5898 · supercollider/supercollider · GitHub
I can put up a binary later, though note it won’t be code-signed as I don’t have a pro Apple dev account at the moment.
1 Like
Okay, hold off on the binary. Got a build issue…
1 Like
Hi Scott,
I’m sorry for the very long delay, I haven’t checked here in a while. The original pull-request was just to be able to disable all built-in locations, indeed that wouldn’t be enough for a distributable standalone.
Later on I worked on a “projects” concept which would also allow distributable standalones in linux, but a script was still needed to setup some things (see below). The relative paths in language config was already working, I believe in this PR: SuperCollider projects V2 by miguel-negrao · Pull Request #3278 · supercollider/supercollider · GitHub . Perhaps that code can be of use.
The script I was using with the PR above in Linux was:
#!/bin/bash
SCRIPT_DIR=$(dirname "$0")
echo "script dir is $SCRIPT_DIR"
export PATH="$SCRIPT_DIR/bin":$PATH
export XDG_CONFIG_HOME="$SCRIPT_DIR/config"
"$SCRIPT_DIR/bin/scide" -style=gtk
Also, check this repo: GitHub - miguel-negrao/scStandalone: A template for a sclang based SuperCollider standalone. To be clear, I’m no longer maintaining the “projects” branch, it has been abandoned.
Best regards,
Miguel Negrão
1 Like
Okay build up again now. I had to manually dequarantine it. It ran but was translocating so didn’t find the standalone folder.
xattr -d com.apple.quarantine /path/to/SuperCollider-Standalone
Or just build yourself!
2 Likes
Hi all just wanted to bring your attention to this pr this PR #6068 which adds support for relative paths in sclang_conf.yaml as well as supporting multiple config files…