Deploying supercollider (sclang) standalone apps

Questions
1

SuperDirt is a very nice sampler/synthesis thingie written by @julian for TidalCycles, but beginners often have problems installing it, many of whom have never used supercollider before and don’t know what git is (and perhaps don’t want to know). SuperDirt depends on sc3plugins for extended functionality which is another hurdle. There are install scripts available for windows (via choco), mac and linux, but if there is some problem in the installer it can sometimes be hard for a even seasoned software engineers to troubleshoot and fix.

For those people it would be great to have an easy download that has everything they need to run superdirt (doing the same for tidal itself is in train…).

There is a guide for deploying standalone apps written by @adc, which looks promising although is mac only and I don’t have access to a mac to test it out. It mentions efforts by others to get something similar going under Linux by e.g. @redFrik, and this by @miguel-negrao, but these efforts don’t look current.

Ideally it would be great to have SuperDirt as something like a zipped-up download for each platform (linux/windows/mac) that can be unpacked and run from anywhere… and have this building automatically from something like a github action. There is some discussion about making this possible on this github issue that stalled two years ago.

That’s the dream… I imagine there are others with similar dreams for their sclang apps. Are there any current examples of/efforts towards achieving this, cross-platform or not?

2 Likes
2

I’ve never tried it myself but could the linux users be covered by something like flatpak/snapd? You could potentially containerize sc with superdirt in someting like that (I say this without actually knowing for sure haha). Just an idea !

I haven’t had much luck with the macOS standalone approach myself (and who knows what’s going on in windows)

1 Like
3

First question – do Tidal users tend to launch superdirt using SC-IDE?

I would guess that it’s more typical for Tidal to launch it as a background process (maybe with a terminal console?). In that case, it’s easier.

If I were doing it, I would try this:

  • Folder structure something like:

    • bin
      • sclang(.exe)
      • scsynth(.exe)
    • SCClassLibrary
      • Common, External, JITLib, yadda yadda
    • plugins
      • All base and sc3-plugins dlls
    • config
      • Empty at first, but see the next step.

  • Ship an installation script that would:

    1. NOT copy class library and plug-ins to system locations. (The whole point of this suggestion is to avoid moving things outside of the single, downloaded package.)
    2. Create ./config/sclang_conf.yaml specifying exactly and only SCClassLibrary from this bundle’s location – no systemwide paths etc.
    3. Upon sclang init, the servers’ ugenPluginsPath should be set to exactly and only plugins from this bundle’s location. (Specifying ugenPluginsPath automatically excludes systemwide or user locations, keeping control over plug-in versions).
      • One way would be to create another file, say, ./config/startup.scd, and change the platform classes’ startup files to point here.
      • Another way would be to modify Main.run manually, and the script could fill the paths into Main.sc. I think this would be harder. A startup.scd would probably be better.
    4. Probably put Tidal superdirt init into Main’s run method.
    5. Create a shell script (or batch file for Windows) launching ./bin/sclang -a -l ./config/sclang_conf.yaml -r.

  • Then Tidal invokes the script, not the executable directly.

I haven’t tried this myself – there are probably some funky details that I haven’t thought of. But, in principle, this should go nearly all the way toward keeping an entire SC environment in one location.

Admittedly this is not as slick as a Mac application bundle, but I think it has a reasonable chance of success, and it would be a lot better than “download SC, download sc3-plugins, download these quarks” etc etc.

hjh

3 Likes
4

Hello Alex,

Perhaps for Tidal including a minimal build of scsynth and sclang inside the Tidal “package” might make sense?

(I think this is James’s idea too?)

Process management in Haskell is nice, and cross-platform (I am told!)

Also there might be quite a lot of SuperCollider that you don’t need?

Ie. Qt? Scdoc? Scide? GUI? &etc.

As James noted, scsynth with -U isolates UGen loading, and sclang with -d, -a and -l isolates library loading.

(Although I’ve not worked out how to stop sclang loading the default “startup.scd”, and this can be a problem for people who have one because of “ERROR: Class not defined” &etc.)

(Relatedly, since some Tidal people will already have SuperCollider installed it may be a good idea to run the Tidal scsynth and sclang processes on non-standard UDP ports (-u) to avoid interference.)

You’d still need to handle all of the various cross-platform problems, but conceptually they’d be “within” Tidal and it might make making fixes simpler.

Best,
Rohan

Ps. I think so long as Tidal can find a valid path to the “package data” you should just be able to pass that using the relevant flags, ie.

$ ls /tmp/sc3/Plugins
BinaryOpUGens.so  IOUGens.so  LFUGens.so  OscUGens.so
$ scsynth -U /tmp/sc3/Plugins -u 57110 &
...
$ ls /tmp/sc3
min.yml  Plugins  SCClassLibrary
$ cat /tmp/sc3/min.yml
includePaths:
  - ./SCClassLibrary/
$ sclang -a -d /tmp/sc3 -l /tmp/sc3/min.yml
...
        3852 method selectors, 1834 classes
...
sc3> s.startAliveThread;
-> localhost
sc3> {SinOsc.ar * 0.05}.play
-> Synth('temp__0' : 67109864)
sc3> {SinOsc.ar * 0.05 * MouseX.kr}.play
exception in GraphDef_Recv: UGen 'MouseX' not installed
sc3> ^D
$
2 Likes
5

Pps. For clarity the “3852 method selectors, 1834 classes” line is for comparison to the “6469 method selectors, 3528 classes” of the “ordinary” class library here, and the “GraphDef_Recv: UGen ‘MouseX’ not installed” is to show that scsynth isn’t looking outside of -U.

Also, the “minimal SuperCollider” idea is only to make tidal life easier, of course everyone should have a complete SuperColldider as well!

1 Like
6

Thanks for all the input! @madskjeldgaard flatpak could work but I’m looking for a general solution really.

@jamshark70 @rdd yes this sounds good, and would match the approach we’re taking on the Haskell side. Currently we’re getting people to install the full supercollider and start superdirt by hand, but making a headless sclang that’s managed by Tidal would make sense.

I’m not sure about starting sclang/scsynth on a different port. I guess it could be an option but with getting some direct communication with custom editors going etc it would be nice to keep a standard port and make it easy for people to upgrade to the full supercollider experience with minimal reconfiguring… Needs some thought though!

It would be good to get around loading the default startup.scd for sure…

Then there’s a question of how to get this signed/notarised for the mac, but I guess there’s ways of running things without that stuff?

Thanks again!

7

If Tidal ships an all-in-one folder, including class library, then this implies that the included class library is specific to Tidal.

So, any part of the class library can be hacked as needed.

Startup file location(s) are defined in Platform, and could be changed there too.

A full installation of SC on the same machine would use a class library copy that is not customized for Tidal, and this would use the normal startup files, but that wouldn’t affect a separate, customized class library.

hjh

1 Like
8

Just to think that through: how would people move between this standalone install and a full supercollider install? There are a lot of things you can do with SuperDirt on the sclang side for which one will need some editor in which you can run that code. Also even beginners may need to edit their startup file (which of course can be done in another editor, but it may be a good entry point to learning the sclang side).

Isn’t there a way to switch between different standalone installations from the IDE, using LanguageConfig?

If that is too much, perhaps the supercollider integration in Atom is an option?

9

They can coexist. At least by what I was suggesting, the whole point is to keep the dedicated superdirt environment in a sandbox, isolated from the rest of the system. If this environment clobbered the main install, it would not be worth doing.

Tidal would launch the superdirt-only version using command line options to control what gets loaded.

The IDE would launch sclang with different command line options and ignore the superdirt-only class library etc.

hjh

10

I’d be interest to hear the outcome of this approach, if it works on Mac or not out of the box. An app could even expand a zip’ed version of all of this in some standard user location, like local cache. Could be nice to have a particular scsynth version and the sc3-plugins included in an app, even if you still permit users to select their own sc installation.

11

Perhaps Tidal could check if supercollider was already running, and only start up its own version if it isn’t. Then switching to the full supercollider experience would just be a matter of running it, whether from scide or from atom.

As an aside this is strangely common, the same user can do clean installs on two different computers, and one of them will need some scsynth limits configured higher. I’ve never worked out why one computer would need higher memory/buffer limits than another, when they’re both loading the same samples.

What I think would be best is a super quick way in to tidal, where things Just Work with minimum complexity… Some might prefer to stay in this mode (tbh I very rarely have the need/urge to get into synthesis, and just use sclang for starting superdirt and loading samples…), but I think there should be no barriers to getting deeper by running the full scide or whatever.

12

That seems like a good solution. You probably don’t mean supercollider in general, but a superdirt that listens.

13

Hi all,

Since the mailing list is gone, I decided to check this again. :slight_smile:

I also use SuperCollider from Haskell.

Currently I have a startSC.sh script with

#!/usr/bin/env bash

(
echo "includePaths:"
echo "    -  $(pwd)/SC_Startup"
echo "excludePaths:"
echo "    []"
echo "postInlineWarnings: false"
) > sclang_conf_vivid.yaml
sclang -l ./sclang_conf_vivid.yaml

and I have a StartUp.sc file in SC_Startup with

StartUpSimple {

	*initClass {

		StartUp.defer{
			var s = Server.default;

			Routine({
		
				s.options.memSize_(65536 * 4);
				s.options.numWireBufs_(64*2);
				s.options.numPrivateAudioBusChannels_(512);
				s.options.numOutputBusChannels_(34);
				s.options.numInputBusChannels_(34);
				s.options.pingsBeforeConsideredDead_(10);
				s.options.maxSynthDefs_(2048);
				s.options.maxNodes_(4*1024);
				
				s.options.numOutputBusChannels_(2);
				s.options.numInputBusChannels_(2);
				s.recChannels_(2);
				Server.local.boot;
				Server.local.bootSync;

				s.scope(2);
				s.plotTree;
				s.meter;
				s.makeWindow();
				HelpBrowser.new();
				s.recHeaderFormat_("wav");
				s.recChannels_(2);
				s.recSampleFormat_("aiff");

				"Vivid STARTUP DONE".postln;

			}).play(AppClock);

		}


	}

}

This gives me access to the documentation, server gui, node view and meters.

I code in vs code where I have an action configured to run this script.

To have a fully standalone config it is necessary to do some more tricks. I did something in that direction some time ago here for Linux.

Hope this helps,
Miguel Negrão

1 Like