Thanks for the feedback so far, much appreciated!
No - I think the current path of SC is to make things more modular to reduce maintenance work within the core, but there are some plans make working with such modules easier.
There are also no licensing issues. Using BSD licensed code in a GPL context is totally fine - the other way around would not be allowed.
No plans on doing that - sc3 plugins is already massive and I don’t want to put additional stuff in it - modularity is the way to go.
Since it needs to contain a binary it can’t/shouldn’t be distributed as a quark - but there are plans to make the installation and management of modules - such as quarks, server extensions and the 3.15 feature of sclang-extensions aka gluons - much more easy. Hopefully this will be part of the next 3.15 release, so stay tuned for further information on that.
This extensions does not have any kind of EEL2 support for sclang. You pass a string with EEL2 code from the language to the server, but in this way sclang has support for any language. As hjh pointed out, I don’t think that EEL2 support for sclang would be that interesting since it wouldn’t you enable to do new things, but there are plans on embedding tidal cycles into sclang → Embedding Tidal cycles in sclang
EEL2 syntax allows for strings, but currently it is not enabled within DynGen since I don’t know what it would be useful since the server has no way of handling strings.
A bit OT, but I think it is better to not tie ourselves too much on HTML for documentation since a web browser is a big dependency which I’d ideally like to remove at some point so we can have a smaller footprint of SC installs.