cl-collider
cl-collider copied to clipboard
byulparan
How to handle the server object
Love this project!
It's not clear that the user must use *s* for the "session".
Some functions allows you to pass the server optional like sc:buffer-read,
and others assume that s has a value like sc:synth.
Should we allow the option to pass the server on the functions that need,
or, we can just add something to the documentation about the *s*?
*s* is the global special variable for the server object. The docstring for *s* says:
Special symbol bound to the default scsynth server. If functions do not specify a target server, that message is sent to the *s* server.
Maybe that could be rephrased to be more clear though.
Additionally it looks like README.md only shows the following line in the "Usage" section:
(setf *s* (make-external-server "localhost" :port 48800))
So the readme could probably also be more clear about the purpose of the variable.
It also sounds to me like a good idea to add server as a &key argument for the synth function, for consistency with other functions. It doesn't seem likely that server would be used as a normal parameter in synthdefs, and we already use to and pos for special purposes, so there is precedent.
@defaultxr See #121. I've added a little bit of wording on the README about the s.
It also sounds to me like a good idea to add server as a &key argument for the synth function, for consistency with other functions. It doesn't seem likely that server would be used as a normal parameter in synthdefs, and we already use to and pos for special purposes, so there is precedent.
I don't know if there is a use case where it would be good to allow users to deal with server directly. So, we have 2 options:
- Make the server s internal for this project
- Add the &key to every call that works with server and default it to s.
*s* is careless design. I just followed usage to s of sclang.
If we should be improve it, I vote second option.
because sometimes we need use it *s*. especially when you make and use multiple server.
Yeah...totally make sense (realise it later). I'll see what I can do to help. Thanks for the feedback.