Re: Running SuperColliderAU
[email protected] Tue, 30 Mar 2021 15:59:22 +0000
| Newsgroups | gmane.comp.audio.supercollider.user |
|---|---|
| Message-ID | <JL1Fx3-Z6q97Dt4nJ2dIGAmEXOsNq7XkDSOJOJUJB4vZ6-vOhUfJlMwC1wpPGn49Y_is11qCNkyk4YAefgnKiung02dgY44ox00PqQr__ao=@brianlheim.com> |
Hi David, I reviewed your earlier messages, and realized you are not running version 3.11.2, you are running something from the develop branch. Your earlier error message had this in the stack trace: Object:doesNotUnderstand arg this = nil arg selector = 'protocol' arg args = [*0] Meta_Server:remote arg this = <instance of Meta_Server> arg name = 'scau' arg addr = <instance of NetAddr> arg options = nil arg clientID = nil var result = <instance of Server> But options.protocol isn't called on the options object in 3.11.2: https://github.com/supercollider/supercollider/blob/Version-3.11.2/SCClassLibrary/Common/Control/Server.sc#L380-L385 It is after this commit on develop from a few months ago: https://github.com/supercollider/supercollider/commit/c1eb86075c77293c29b9cb6020f06d7e5132f9fb If you want a stable build, and one that actually corresponds to an "official" release, build from a version tag. This is generally a good rule for compiling any git-managed project. There are a few takeaways I see: - the documentation could be clearer about how to make a stable build and what the difference is - this is a bug in Server.remote that should be reported and fixed - when asking / answering what version of SC someone is running, we should be very explicit and if the project was compiled on the user's machine, *always* use the commit hash -- there is too much room for confusion here otherwise. (This can be found in the IDE by opening the "about" dialog.) - we should adopt the "coarse versioning" scheme in Marcin's RFC, which would have made it clear from the start that you are not running 3.11.2, but in fact "3.12.0-dev": https://github.com/supercollider/rfcs/blob/51f246cd6e820ab10161cd25f8a6876b9a91f15b/rfcs/0016-scversion-improvements.md Regards, Brian ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, March 30, 2021 3:15 PM, <[email protected]> wrote: > Hello Brian, > > No, Server.defaultOptionsClass does not seem to be nil. If I just execute > Server.defaultOptionsClass; > it returns > -> ServerOptions > > Server.all; > returns > -> Set[ localhost, internal ] > > -David > > On Tue, Mar 30, 2021 at 8:52 AM <[email protected]> wrote: > >> Is Server.defaultOptionsClass is nil for you after startup? I asked this in my previous email. I don't want to assert that what I say is the real problem without an answer to this. >> >> Regards, >> Brian >> >> -------- Original Message -------- >> On Mar 30, 2021, 2:47 PM, < [email protected]> wrote: >> Hello Christof and Brian, >> >> No errors on startup, and localhost server starts up normally with s.boot. No extensions installed at the moment and no special scripts in use. It's a fresh install, built from source. I don't even have any quarks installed yet - wanted to eliminate any variables while playing with SCAU.