I thought maybe the socket could be on a different system / host. That -u flag is the port of sclang of course…, which does have a port as well… Sure, it can get funky I realize now. If I send a OSC msg to Supercollider, I’ve to send it to sclang (the client), not the server. Does the IDE also send it’s code to sclang using OSC?
Another question bumps up is if one can send a custom startup.scd file to sclang as command line flag. It doesn’t seem to be possible looking at sclang -h, but I can imagine that could be useful when working with multiple clients and servers.
If you’re running a script with sclang, the script can override whatever settings it needs to.
I.e., what’s the benefit of myCustomStartup.scd setting s.options.numOutputBusChannels and myScript.scd using that, vs myCustomStartup.scd setting to a standard value and myScript.scd overriding it?
Not having to copy and change it in multiple files. Tmux can load a custom configuration file, while it’s fully scriptable. Puredata can also load one I think, so it’s certainly not uncommon.
Now I’m using a different startup file for Tidal Cycles for instance which can be annoying. Ok I probably could make a script for that, but I can also imagine startup file changes for different soundcards.
What I’m saying is that it’s possible to implement in sclang, without asking a dev to add a new commandline option and waiting for it to (maybe) happen.
A script can run code in another file, so, a configuration that’s shared across multiple scripts could be written into one file (not copy/pasted) and used where needed by String:load.
If you want both the configuration and the script to be commandline parameters, SC has thisProcess.argv = an array of strings which are the commandline tokens after sclang. So you could write sclang script.scd config.scd and the script would sort it out.
Not that it would be a bad thing to have a custom startup.scd, but I’m suggesting things that are possible today rather than waiting for a PR.
No, that’s not what you where saying, nor what I was asking. I was just wondering, while thinking about the best possible options for a more ‘standalone’ setup for SC.
I’m quite new to such a setup in SC and this raises some questions, which I ask. You ask me rightfully in return why it would be useful and I try to explain how I think it could be useful. Which could be convincing or not.
In general these problems / questions I face now as novice and while running a less common workflow could help to improve a workflow where SC is more used in a sort of standalone setup I think. Even without talking about PR’s yet. Looking around the forum, people seems to be struggling in general to get this done (not sure if Tidal cycles already found a solution for a more standalone approach for instance).
Thanks for the information about the current possible ways to do such sort of things, this helps me a lot already.
I don’t disagree with any of that actually – it’s a good feature request and probably not that hard to do (apart from the fact that reviews of code changes are so far behind that good intentions won’t be enough).
I think part of the struggle is that we as a community haven’t been very interested in topic documentation. “Standalone usage” would be a great topic doc but we don’t have it. So everybody hacks through it on their own and a best practice hasn’t quite emerged.
Actually – it only just occurred to me – what if the user has a startup.scd file, which they use to configure audio devices, color schemes, or whatever, and an sclang process is started from the command line with a (now hypothetical) --startup myInit.scd flag? Should the commandline flag completely replace startup.scd, or run the default startup.scd first and the commandline one second? We don’t know what the user has put in there, for what reason – it might be rude to suppress the user’s, but it might also result in confusion to run both of them. (Should the flag support multiple custom startup files?)
Again, not saying that a commandline switch is a bad idea, just that there are some decisions to be considered.
By convention, command line flags normally overwrites previous settings (config files, environment variables) I think. Clear and simple is best probably, so completely replace startup.scd I would say.
One can ‘import’ files in startup.scd right? So then a user could modularize it already isn’t it?
Hypothetical: a user has setenv instructions in startup.scd, which they need for their audio interface to work. (Simplest like that would be default JACK channel mapping in Linux, but one could imagine other scenarios.) If a custom-startup script skipped this file, then the user says “I tried this standalone script but it ignored my audio configuration.”
So I still think it’s tricky. We don’t know what the user put into startup.scd and why – which means 1/ we don’t know if it’s something essential that can’t be skipped and 2/ we also don’t know if it’s something that will interfere with the script, and should be skipped. So every one-size-fits-all rule will sometimes not fit.
The user could put the audio interface related stuff in a dedicated file and ‘source’ it in the default startup file as well as the standalone script isn’t it?
You seems to talk more from the perspective of a third party provided script, while I was more thinking about the scenario where the user did make the script themselves and so has the responsibility over what is put in the script.
If a second file overwrites settings in a first file, it might get confusing and one looses control over what is happening I’m afraid and in the case of a third party provided script, it might as well goes against the preferences of the user, all though I see your point. There seems to exists some global settings (applicable everytime) and some local, session specific settings maybe… hm.
Adding something to the default startup file in a custom startup file passed by command line, might be doable, but removing or disabling stuff is much harder. The user might have loaded samples in the startup file, you can’t unload them in the second startup file.
The startup.scd file is not a common configuration file, a user can put everything in it, not only predefined options. So as I see it now, a custom startup file should be loaded without loading the default startup file first. If you want more general / global options / preferences you might need to add a pre startup.scd phase / file, which will be loaded before any startup file. But then you end up with two files and then both can be loaded via the command line to?
Note, no definite answers here, just thinking out loud.
Given the fact that you can write your own standalone script, one could also think of a command line option to skip the startup.scd file. Ok, you can make a empty startup.scd file (and if it would possible, pass it on the command line as flag), but not sure if that’s the cleanest way to do it.
Not sure if the startup.scd file is a good idea for multiple “setups” at all tbh.
Some SC.start or Tidal.start; classmethod might work better. It then can load some standard setup files (soundcard setting) in the ~/.config/SuperCollider. This could become some kind of template, where the class loads predefined files from the config directory. A user can pass arguments to the class or add methods to class for custom setups (like Tidal), without fiddling around with the startup.scd file.
For now I removed my startup.scd file. Let’s see if this makes sense.
I was just wondering, while thinking about the best possible options for a more ‘standalone’ setup for SC.