Supercollider Engine

[mossheim]

this PR adds a SuperCollider script engine. closes #8.

i have tested this on my machine only (macOS 10.14.6).

couple of notes:

• i'm not sure if this is a bug in my code or not, but it seems every time a script is reloaded, the engine is constructed and SC class library compilation happens twice, which effectively doubles script reload time
• the Make integration is hacky but it's the best I could do with my current knowledge. I spent some time web searching and asking in build system chatrooms but nobody was really able to offer any simpler solution than this, which is my own devising
• please let me know if there is any additional documentation i should add
• i did not implement a separate "display" command for the sclang API -- all stdout/stderr from the language process is redirected to the plugin, so users can simply use 'post' or 'postf' to display messages. are you ok with this?
• as discussed, because sclang uses global state there can only be one running instance at a time
• this currently relies on a special branch in SC. i would like that not to be the case, and have opened a PR for the branch to develop (https://github.com/supercollider/supercollider/pull/4686)
• the engine works by dynamically writing and reading a configuration file to the dep/supercollider directory, which is one of the distributed directories. because the paths in the configuration file need to be absolute paths, i cannot hard-code them in advance. is that OK?

i am having the engine construct a string literal to be interpreted by sclang -- a further optimization would be to set up the stack so that it matches the VM state directly prior to calling ~vcv_process. but, i'm not sure how easy that would be, and i'm already satisfied with the latency i'm getting. on my machine (Macbook Pro, macOS 10.14.6, 2.5 GHz Intel i7 processor) gain.scd according to my timing code runs with an average latency of 260us, with a worst case of 1.5ms (my guess, GC jitter aligning with unfortunate thread scheduling). IMO, not bad for a first pass.

this is to my knowledge the first time sclang has been integrated in another application this way, so the integration is naturally not very smooth and i hope that's all right. i would certainly like to make it less painful in the future! anything you can suggest there, just let me know.

[mossheim]

ah, forgot to mention -- against your suggestion, i am still linking the library from within the SC build folder. i really do not want to run make install because that would necessitate building extra executables and libraries (scsynth in particular), and i already need a bunch of other static libraries that get built in there anyway.

also, to explain the makefile hackery a bit -- what i'm doing is applying a patch to the SC build system that defines a special target. building that target creates a file which lists the library dependencies of libsclang. i run that target and then cat the resulting file as part of the LDFLAGS. this seemed like the most robust way of doing things, since there are about 10-20 dependencies depending on your OS and build flags, and some of them are system libraries that can be found in various locations.

speaking of which, the system dependencies here are at least:

• libsndfile
• readline (optional, but i haven't tested without it)
• alsa, librt on Linux
• pthreads

are any of those new?

[mossheim]

finally, I have tested this on macOS but no other platforms yet. if there are other platforms you'd like me to test on, just let me know. i have [kinda dusty] environments set up for Windows and Linux.

[jamshark70]

@brianlheim it might be a couple of weeks before I could try it, but I've also tinkered with Rack in Linux and I'd be very happy to kick the tires of this setup in Linux :D