returning to the --project idea…
could we add a new .scproj ft/dispatch? With installed SuperCollider, double click foo.scproj and sclang opens with --project and the relevant folder expecting to find everything? .scd files open as usual… Folder could include multiple .scx files per architechture.
Or would a separate SCPlayer.app be better? could has some facility for non-technical user to interact with ServerOptions for example?
This was exactly what I was thinking (down to the .scproj!). One issue would be getting all the class library directories to point into this folder (like Platform.userAppSupportDir) as we really want everything to be self contained (we shouldn’t need help files or things like that though!)… but I think that could be done with primitives.
Or would a separate SCPlayer.app be better? could has some facility for non-technical user to interact with ServerOptions for example?
I’d leave this up to a quark to implement, perhaps even an official supported quark (a first?). You might not want to include the qt stuff and it would be good to keep this as a feature of the sclang executable. Authors might also want to involve complex cueing systems or rehearsal marks that you can jump to, so I think we’d struggle to come up with a good one size fits all.
I don’t think this should involve the IDE at all as it it kind of defeats the point of a standalone. This is for giving to performers to ‘click (minor setup with a GUI) and go’.
This sound great, but I think it is for fetching dependencies, not sharing finished projects with perhaps many audio/media files.
I understand why that seems intuitive, but I’m not so sure based on experience. It’s common to have to do minor debugging when moving to someone else’s environment, or in the process of refining a ‘piece’ with someone. Also a standalone could be a live coding environment, parasite language, etc.
I think it would be nice to be able to have the IDE as an option.
It’s common to have to do minor debugging when moving to someone else’s environment, or in the process of refining a ‘piece’ with someone.
I think this could all be accomplished by editing the project in the IDE. The IDE would know how to load, understand and interact with projects, but isn’t required to run it.
The IDE would start sclang as sclang --project "directory" --no-auto-launch then the user would have the same experience as they do now, but with all the classes loaded from the project directory.
Yes, I was thinking something like this would make sense. So would the IDE still be the ‘launcher’ in this scenario (for users who don’t use cl)? There could be menu items like ‘Launch Project’ and ‘Open Project in IDE’?
That sounds good!
The IDE should also support the creation of projects.
I don’t know what the default would be. I quite like the idea of just double clicking on a .scproj file and having the thing run. This way, if you do happen to have a project that doesn’t require editing, users don’t even have to look at the code, or know anything about supercollider.
Using the IDE would be the preferred way of doing live coding though (unless someone wanted to implement their own text editor in qt collider).
This would differ from the existing approaches which bundle everything up inside the mac application (which is why they were always mac only) as all the work would be done in sclang. I think this is more sustainable.
Yeah that sounds good!
agree that the default should be “click to run w/o IDE”. So how best to handle live-coding or other projects that do want access to the IDE?
The problem is what should such a standalone look like for sclang? A standalone only has one entry - should it boot the server, should it show the IDE, should it show just a terminal, should it run headless, should it show just a GUI? It is hard to reason about this b/c there are many ways what a sc project actually is.
Ideally one could think that sclang should be able to start the IDE if necessary, e.g. IDE.start("myFile.scd") - but this would reverse the order of language starting the IDE, starting the language?
Also: clicking on a .scd file, at least on macOS, is not really helpful here either since it may use the wrong sclang/scsynth version, which will definitely lead to problems.
I think it is feasible to do this cross-platform w/ the path suggested above, which I think will be as easy, but more reliable.
magnet could then create cross-compiled standalones by downloading and copying the appropiate binaries and files (though the difficulties stated above remain).
Or simply act like rustup/pipx, though we could ofc have a gui for this instead of relying on CLI exclusively.
This is essentially the idea of the proposed project manifest, see magnet.yaml spec, though obtaining the scx for every platform can be really difficult.
IMO there is no separation between a Quark and a Project - each assume an environment to run in, which is currently handled implicitly by SuperCollider. As we see, this approach gets you only so far, so we should keep track of our environment so another person knows what is necessary to run this code/project.
See the spec regarding the managing of multi-media files.
This is also already part of the magnet design spec^^
I think the only way to do this properly and get rid of all this stuff once and for all is via a package manager which takes care of the environment. Copying files can work, but I think this is way more hacky than it should be in 2026 IMO.
Having multiple SC versions installed is somehow brittle, and since OSes and dependencies are moving faster and faster, this creates a huge span of platform and versions to support. We should tackle this for many reasons, and standalones are just one by-product of having such a way to explicitly define our environment.
edit: I would recommend to do as few as possible of this within sclang, as sclang is actually hard to run (try to run it in a CI etc) - the tool should take care of bootstrapping SC if necessary, see rustup/pipx. This allows e.g. to work w/ those files even when the class library got into a non-compilable state through a dependency. This doesn’t mean that we can’t provide bindings for this tool from sclang side.
The problem is what should such a standalone look like for sclang? A standalone only has one entry - should it boot the server, should it show the IDE, should it show just a terminal, should it run headless, should it show just a GUI? It is hard to reason about this b/c there are many ways what a sc project actually is.
That’s a good point and I don’t really have an easy answer at this point. I guess that it varies from project to project. However, in most cases you probably want to launch sclang with some GUI, which in turn allows the user to start the Server.
With Pd, standalones are mostly trivial because IDE, language, GUI and the audio engine are all a single program. (Well, the GUI actually runs as a separate process, but that’s not really relevant to end users.)
Having multiple SC versions installed is somehow brittle
Yes, but ideally it really shouldn’t.
I think the fundamental issue with SC is that there are no scoped project environments. By default, classes and Server plugins are loaded a.) unconditionally and b.) from global search paths. For other resources like .scd files, sound files, etc. there is no well-defined search mechanism at all. If users want to load such resources from a relative path, they have to manually obtain an absolute path, e.g. with resolveRelative, and then continue from there. This is problematic because the output of resolveRelative depends on the current document.
Imagine a readSoundFile function implemented in ./foo/utils.scd that is called from ./bar/module1.scd and ./baz/module2.scd and with media files located in ./media: on each call site you have to obtain the correct absolute path to the sound file. Ideally, you would rather want a common search environment that is shared between all these files.
In Pd, every patch/abstraction has a so-called “canvas environment” which defines which search paths are considered and in which order. The [declare] object allows to specify additional (relative or absolute) search paths. Abstractions inherit the canvas environment of the parent canvas. The canvas environment is considered practically everytime something needs to be located on disk:
It’s probably not hard to see how this makes it very simple to create self-contained projects: you just put all your stuff (including any dependencies) relative to the main patch and add the necessary (relative) search paths – if any – with the [declare] object.
I really think that SC needs a document project structure with (inherited) search environments. I imagine something like a resolvePath method that takes a relative path and tries to find the first match in a list of search environments. The actual file operations, in particular on the Server, could still do with absolute paths; the user only needs to call resolvePath to locate a resource in the project tree. Similarly to Pd’s [declare] object, there should be a way to add paths to the search environment. We should establish a parent/child relationship between documents so that the search environment can be inherited.
Finally, there should be project-based search paths for class files and Server extensions. The former can already be emulated with the language config file resp. LanguageConfig.addIncludePath, but the latter is pretty painful.
(You can set the UGen plugin search path with ServerOptions.ugenPluginsPath, but this actually replaces all the default search paths and therefore also excludes the built-in plugins… In practice, you need to do something like this:
s.options.ugenPluginsPath = [
Platform.resourceDir +/+ "plugins",
"deps/plugins".resolveRelative
];
Another thing: Pd externals have platform specific extensions, so you can even distribute binaries for all platforms in a single bundle.
In fact, I have been thinking about proposing a bundle structure for Server extensions so that projects may contain plugin binaries for multiple platforms. The VST3 spec also has such “merged bundles” and I think these are better than just platform-specific extensions. Since SC 3.15 already contains several big changes to the plugin API, it might be a good chance to also introduce a bundle structure. Obviously, this needs to coordinated with your efforts on magnet since it would affect the packet structure.