I’m no expert on this at all, but in Windows, could you have a Batch file which called the IDE with a command line option to set the Config file? - although the IDE currently doesn’t seem to allow this so it would have to be changed. Sorry in advance if this is not helpful.
Thanks anyway for your work on this.
Best,
Paul
1 Like
Just wondering if there has been any progress with this - reading this thread again, it all sounded so possible back in 2022.
Hoping it hasn’t got forgotten - it would be a fantastic thing to have.
Best,
Paul
1 Like
Well, there is sc.wasm now which runs in the browser - a standalone can now be a shareable URL, if you don’t require quarks/extensions, GUI or network - though quarks already work (experimental) and GUI or network can be adapted for JS/browser.
Beyond that: I am working on a package manager called magnet, which ideally also mimics the behavior of rustup / pipx / uv, so the package manager could be used to bootstrap the necessary environment and then call a script (e.g. magnet run start.scd), so while this would not be a compiled standalone like in max/msp, this would be a one-line-command to start any given project once the package manager has been installed, which then would install the necessary sclang/scsynth/supernova/ide version for the project if not present - and ofc all necessary quarks/extensions for the given platform/architecture.
I already have a prototype and some technical documentation for it, but got sidetracked by more fun stuff…
Personally I don’t think that a true standalone is a good approach - compiling sc w/ qt is really hard, and then it will be limited to a platform/architecture (which becomes hard to overcome w/o dealing w/ VMs etc), and then you still have to deal w/ notarization on macOS.
I think there’s a misunderstanding. A standalone should not require the author to compile SC! The idea is rather that you can simply grab the SC app and modify it so that it automatically runs a particular project. (This also involves copying all the necessary dependencies.) You can already do that in Pd.
I think the first step would be better support for portable installations. It’s already possible, but you have to manually configure all the necessary paths.
1 Like
That’s really what I had in mind. I think all we basically need is some way to tell a particular copy of SC to read from a local directory with a relative path, and ignore lang config files in the user directory. I think the most flexible way would be to read a local lang config file. There’re a number of ways that could be approached, but that’s basically a standalone that you can share, no need to code sign etc.
When that’s done we could add other things like not launching the IDE (may or may not be wanted) if we like.
2 Likes
This sounds a lot like a project/directory based approach rather than using the global/user settings.
myProj/
ClassLibrary/
... class library copy, possibility modified ...
Classes/
... user classes, including quarks ...
Plugins/
...
launch.sc ... loaded at start ...
... other user files/directories ...
What is the point of a lang config file? Could we just tell sc to load the directory as everything would be there with the exception of the sclang and scsynth executables.
sclang --project myProj
Yes, this is what we had discussed.
I guess it’s just slightly more flexible? I don’t personally need it but I can imagine some people wanting to access global sets of Quarks, etc. But perhaps this just adds unnecessary complexity. Though of course scaling is already setup to process config files, so maybe it’s easy. Would just need to add launch file option to the config, which might be useful anyway.
In any case I guess the question is how to tell sc to use the local stuff rather than global/user. I can imagine:
- load locally if a config file or directory structure is in the same directory as sc, otherwise user/global
- a separate build that does this.
- other approach?
I think I’d prefer 1 as just seems easier.
This would mean what the executable does varies depending on what is in the directory you launch it from. I’m not a fan of this because its very implicit and might cause issues if you don’t know exactly what file(s) it is detecting — basically you’d need to read the code to know what the executable does, which might change between versions. The flag --project in my example would turn on this behaviour, it would not use any global/user data and you wouldn’t be able to use a custom conf yaml file.
I don’t personally need it but I can imagine some people wanting to access global sets of Quarks, etc.
We should have a way of copying in all the user data into a directory to ‘freeze’ it into a project. That way this is unnecessary.
is already setup to process config files,
Not very well unfortunately!
1 Like
I understand. Perhaps you’d care to propose a solution? Bear in mind most users don’t launch sc from command line.
I don’t really have an opinion on standalones, but this discussion seems to intersect with some other issues relating to, say, multiple builds on the same (linux) machine and the general path searching bonanza in sc.
I think something like a yaml config file, but including not just the class library but all or most of the paths relevant for sc is probably reasonable and feasible; like the current lang config file, there could be a scide gui option as well to pick out paths manually. Probably there could also be a portability/“standalone” helper that makes copies of all those directories within one directory, produces a config that links them, and zips the whole thing or something.
(It would be good to not have this rely exclusively on the scide, at least for scnvim users…)
Ah okay - I still think this is not a path we should go since such a solution is still platform dependent and just introduces all kind of “bad practices” such as copying dependencies.
Well, you need not just Quarks but also Server Extensions. I think while lang config file was made w/ good intentions, but it was not well designed since it manages environments which are tied to projects, but the lang config file is attached to the user installation instead of the project. And these environments are not even isolated, i.e. I can’t use v1 in environment A and v2 in environment B. We could fix this in retrograde, but I’d rather fix some other problems we have on making sc actually reliable and reproducible regarding dependencies and environments.
IMO the best approach is this to introduce a file which states the environment of the project like any other programming language is doing - this can be then used recursively for projects, quarks or server extensions.
This allows to be platform-independent and resolves all the current problems we have around quarks, server extensions (which will be a big problem w/ 3.15), projects and also stand-alones by using something rustup/pipx like or just to create standalones for every platform through a simple command.
I have written down a draft for a design spec some months ago: Magnet design specification - HedgeDoc
Currently I am a bit stuck by the YAML format which is not really supported well in most languages (i.e. C++, Rust - I think almost all implementations are incomplete or lack crucial features once you get really into the details of YAML and want to modify it and not just parse/write it). The only alternative would be to use JSON (w/ comments?) but I think this is not user-friendly. TOML looks really interesting and is replacing yaml more and more, but would be “yet another format for sclang”. Lets see.
3 Likes
Yes plugins are another issue of course!
As usual these days there are a number of overlapping issues and complications. (and a number of opinions haha)
This looks very interesting and could address a range of issues, including this one.
I don’t get your point. That’s literally how applications work on Windows and macOS. Of course it’s platform dependent, but why is that an issue? A typical use case for standalones is shipping a patch to a performer or ensemble. Ideally, they just unpack the .zip file, double click and start playing.
Maybe the IDE could have an “export” feature that creates a standalone from the application itself + a list of quarks/extensions + one or more .scd files?
The important point is that the standalone should be plug’n’play, i.e. recipient should not have to run any tools.
4 Likes
I just wanted to chime in - yes, for me this is the textbook reason to have standalones. I’m in favor of bringing that functionality back.
3 Likes
Could Platform.userAppSupportDir be changed to a class variable, or exposed through getter and setter methods? This would allow the official release, developer builds, and any SC‑Standalone to operate independently without interfering with one another. If sclang or SC‑IDE eventually implements the export feature, creating SC‑Standalone builds would become extremely straightforward.
I previously proposed this idea here:
Including the build number may be excessive, but including the version would already allow SC3.13.x, SC3.14.x, SC3.15.0‑dev, etc. to maintain independent environments.
Combining these two ideas — a user‑configurable Platform.userAppSupportDir and a version‑specific hard‑coded default — would be an improvement over the current situation.
Since I see movement here once again (we seem to try to resolve this every few years 
) I returned to my own attempt and tried a different approach. It is Mac only and ‘Works on my Machine™’. If anyone would like to test or contribute try it out at:
Make sure you check the new README cause the process has changed:
2 Likes
I can’t help feeling that this would greatly increase the number of people who heard about and used SC. It might even attract some new developers!
Best,
Paul
2 Likes
When it comes to popularizing SC, I think @dscheiba’s WASM port will be the real game changer. That being said, desktop standalones are still important for sharing non-trivial projects. There is only so much you can do in a browser.
1 Like
Also, a question:
Should the following folders be in the Platform.userAppSupportDir?
- Extensions
- downloaded-quarks
If they exist in Platform.resourceDir by default, creating a standalone would be easier.
A: it’s complicated (depends on OS I think)
Path searching · supercollider/supercollider Wiki · GitHub is the most complete summary of where what goes on which OS
1 Like