Lighter approach to standalones?

Development
21

@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
22

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.

23

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
24

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
25

Okay, hold off on the binary. Got a build issue…

1 Like
26

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
27

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
28

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…

29

Hi all, I wondered if there has been any progress on this? A cross-platform standalone would be a wonderful things for all kinds of SC projects! (including installations or just passing SC instruments to other people who may not be so comfortable with code, etc…).
I’m working on a new TX Modular release and it would be great to have this in the future.
Sorry I don’t have the dev skills to help - all I can offer is warm encouragement and big gratitude to all the developers for the AMAZING tool that SuperCollider is!
Best,
Paul

2 Likes
30

Nothing except that I’m hoping to get back to it. It was close. That said, I’m thinking that a kind of project file approach, on the lines or similar to what Miguel and others have suggested, might be near as good and less finicky to work on increasingly locked down OSs. Basically a file or bundle that specifies a language config and a startup file. The idea is you’d click on it and it would launch in vanilla SC, ex-/in-clude as needed and run your project. Not strictly speaking a separate app, but effectively similar and reliable.

3 Likes
31

That would be great! :grinning:

32

I think this path is well worth pursuing for the good of the community.

33

Hi Paul, I’m similarly working on porting a quite large standalone project from 3.6 to support modern MacOS. Just to say that Dionysis standalone project works for me in MacOS 14, using Platypus as described in the github page. Platypus can set a custom icon to the app and also provides its own “post window”. There are some annoyances with having to go into MacOS system settings and give permission to not only the app but also sclang, scsynth and sc3plugins separately and I need to give scsynth permission to use the microphone (twice for some reason) on every launch. Apart from that is seems to run well, although I have yet only tested it on one machine.

34

Thanks, that’s good to know.

35

Okay, started to work on this project bundle approach, which I do think is better than a separate build as it’s more flexible and less tied to the IDE. I’m thinking of a bundle structure like this:

Bundle.scb
	bundleConfig.yaml - contains info on user startup file, libconfig file, and possibly other options. Should note bundle spec version
	config
		langconfig.yaml
	lib
		all extensions and optional core
	user
		usercode and data
	synthdefs?
	?

On Mac it should be trivial to have this appear as a single double-clickable file, which I think is very desirable for sharing. I don’t think that’s so simple in Windows or Linux, but am happy to take advice. Would still be useful and would just require an Open Bundle menu command or similar.

I think what’s nice about this is that it is easily extensible if we need to support something else and can be langclient agnostic to a large extent. Double click could open in IDE, but would be easy to add a command line option to pass a project bundle to sclang directly, and/or support other editors/langclients. A simple cross-platform launcher client would also be possible; just needs a post window basically, though I’m not sure that’s needed.

Anyway, I’ll try to get something simple and working together. Comments and suggestions welcome.

6 Likes
36

On Linux, creating a double-clickable bundle isn’t as straightforward as macOS, but there are several approaches, each with different levels of complexity:

think the options could also be:

  1. AppImage (May need permissions setup for audio, probably simpler)

  2. Flatpak (maybe more robust?)

  3. Or, if the priority is long-term viability and archiving (looking for something to run in 10+ years), you could set up a docker image, a raw system image, or a bootable image. (here. many things to decide)

37

One of the suggestions I saw was just use a compressed format. That may make sense.

1 Like
38

Yes, maybe. But it can not be quite portable. You will need the user-installed JACK, for example. Another shell script can check those things and post information.

While with Flak, for example, you could include jack, qt, and anything necessary for full portability because:

Self-contained runtime environment;
explicit dependency;
Sandboxed

39

The goal with this is not to include a runtime environment.

2 Likes
40

I see. But something may need to change since scsynth is compiled with libjack.so (Jack client lib). There is at least one major ABI incompatibility (1.9.x and 2.x).

We can assume all systems will have a working audio system with jack2.

But I remember someone managing to do a Flak package somewhere. Maybe it would be nice to check that.

EDIT: Just one clarification, when we say “runtime environment”, it is in a minimal sense. Flatpak is a tool that manages and deploys applications along with their required runtimes (for example, libraries and frameworks), and it is not a complete system.