(splitting conversation off from Quark Versioning thread)
@Nathan wrote:
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!!
2 Likes
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)
1 Like
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…
3 Likes
Hey @semiquaver, I’m glad you’re enjoying the features and good to know that it works on Mac! I’ll see if I can do anything about plugins.
Regarding plugins…
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.
from @Nathan’s gist Path searching · supercollider/supercollider Wiki · GitHub it seems like it might be possible to append paths to SC_PLUGIN_PATH …
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).
1 Like
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.