Right now, there is no way to distribute an scd file and class library code, hand them off to someone else, and have them easily run the code in a way that isolates the runtime from whatever else the user has installed. It’s a bunch of little things that add up — problems with relative path support in in sclang_conf.yaml, the IDE’s interface for language config being pretty tucked away and inconvenient, etc. — but I am optimistic that they could be fixed fairly quickly to produce an “isolated run” feature with a nice one-click IDE interface. I’m not able to assist with this but if I were strategizing ways to improve SC’s packaging situation, I would make something like this a top priority.
It seems that having sclang.conf.yaml accept relative paths is a first step - @miguel-negrao was working on this many years ago!!
looking at Miguels commits 85f5f09a1e499012555d0b71d173e52cc0a67096:
sclang and class lib: implements projects
removes sclang -a cmd line option and adds 'excludeDefaultPaths' and 'project' boolean keys to sclang config file.
When 'project:true':
- Relative paths in the config file are resolved relative to the directory containing the config file.
- Quarks download to the directory containing the config file.
- if a file named 'startup.scd' file is present in the same directory as the project file it is run at startup.
When 'excludeDefaultPaths:true'
- user and system standard directories are not searched for class library files.
- default startup file is not run.
Paths in the lang config file containing "%ResourceDirectory%", %SystemExtensionDirectory%" or "%UserExtensionDirectory%" get that substring substituted with the equivalent directory.
I wonder if this code will still build/work… anyone inspired to test? (@nathan)
Thank you for keeping this alive. I want to stress again that a lot of SC’s biggest long-term problems are due to its lack of modularity, and this would be an important and long overdue step towards that. Unfortunately I’m not actively involved in SC development anymore and I don’t have the bandwidth or motivation to offer direct help.
I just built and started testing this on Mac … relative paths working so far! Thanks @mraethel. The multiple conf files is actually pretty neat too at first blush… now if plugins could be handled the same way…
Currently when you boot the server it searches a set of paths. If for example we want to have the server load a plugin on next reboot (without having to copy it to one of the default paths) we can invoke scsynth with the -U flag set. From the lang this is done by setting the ServerOptions ugenPluginsPath.
…But if you do that the built-in plugins are not loaded which breaks most things! So there is no practical way to share work that relies on a plugin without asking the user to install the plugin separately.
Scsynth finds plugins:
initialize_library in SC_Lib_Cintf determines the following rules:
If the -U command-line parameter is specified, it is searched.
Otherwise:
If the compile-time definition SC_PLUGIN_DIR is set, it is searched (can be set through CMake using cmake -DSC_PLUGIN_DIR= …).
By default, this is not set except on Linux, where its default value is ${CMAKE_INSTALL_PREFIX}/lib${LIB_SUFFIX}/SuperCollider/plugins.
The directory /plugins/ is searched.
The System Extension Directory is searched.
The User Extension Directory is searched.
If the environment variable SC_PLUGIN_PATH is set, it is searched.
The “search” operation looks for all files ending in .scx (on Windows or macOS) or .so (on Linux).
Nice hint and sorry for the delayed response! This actually seems quite like the way lang configs are currently handled.
I assume that sclang at some point calls scsynth when being run… does it then make sense to have a lang config (file) option for this on top of scsynth being able to pass multiple plugin dirs (and resolve relative paths)? I’ll take a closer look.