SuperCollider 4: First Thoughts

I fully agree with this – I’d even go so far as to say that an already overworked dev team might very well choose not to tackle step debugging etc and simply drop SC language in favor of another language that already has step debugging etc.

I say this even though that would cost me a huge chunk of time to rewrite my tools. I don’t want to have to do that, but I don’t see any movement in the area of interpreter internals – probably because it would be a massive investment of time just to take the first few baby steps.

hjh

1 Like

I’d love VST support

SC server can host VST plugins: Pure Data libraries / vstplugin · GitLab

SC can’t currently act as a VST in another host, as far as I know.

hjh

That’s what I want… to be able to compile SC → VST

Probably correct. Also, I just started using VSCode and GitPod for some stuff, and those IDE tools are just amazing. We could move to using these kinds of tools (I know there are some vim people out there), because then it would be super easy to switch between SC, rust, python, etc, with the added benefit of not having to worry about maintaining the IDE.

I think having the IDE is such a boon though!

Speaking to some comments on this thread, and the overlap with “Some observations” thread, and as a beginner myself – it’s hard enough getting one’s bearings I think. The additional overhead of setting up a different text environment that doesn’t automagically just work, that requires a lot of configuration, is an additional hump - often non-trivial - on the learning curve.

I’m all for progress, and I think the ability to use languages other than SClang with the same amount of control sounds super interesting and might open up a lot of things for a lot of people. But I think there needs to continue being a cake with the ability to eat it - the IDE in this case - if you want not only new users but also non-power users or experienced programmers, etc.

It seems that, thanks to a lot of hard work by people running parallel to the core development team there is currently the ability to set up in a different editor just fine.

As some one who in the last couple has tried to set up comfortable environments, first in Atom and then Vim, using those existing plugins, instructions, etc, as someone very much from the GUI world of software, Vim, for me, was just very hard to install with all the plugins, customizations etc.

I’m pausing on it, the thought of having to learn how to use a slick text editor while learning SuperCollider made me chuckle and also face palm. Eventually I’d love to though, and am all the time running into moments where that speed would be helpful, but it isn’t worth while for me yet.

I also would love to see something like that,
and It would be nice to have inside the language all the tools needed by a composer that work with algorithms, I mean a solid native Computer-aided algorithmic composition library Flexatone HFP | An Open Design for Computer-Aided Algorithmic Music Composition: athenaCL it would be very handy, also a Timeline and a player that work well without spending a bunch of time on these “simple” things.

since it’s all written in C++ , I’m sure it must be possible…

One problem has been licensing. Currently there is an “Open-source GPLv3” licensing option for the VST SDK. I am not sure when this license was introduced. I vaguely remember that, in the past, the VST SDK was not GPL-compatible, making SuperCollider-as-VST legally problematic. (It is unfortunate that it isn’t enough for it to be technically possible – it must also be legally allowed.) It seems that’s no longer an issue, but it does mean there were some years where nobody was working on it.

Then – SC’s architecture is difficult to embed into the VST model. Maybe others have good ideas how to do that, but I don’t.

hjh

On the other hand, if SC switched to a different language and editor, then it would become SC’s responsibility to provide an editor package that does “just work.”

Currently we can say the IDE is our main responsibility, and other editors are (to some extent) on your own. We ship Emacs and vim plug-ins but certainly the Emacs sclang-mode doesn’t receive as much developer attention as the IDE. (I haven’t tried it lately.) Vim might fare a bit better.

But if there is no sclang or SC-IDE, then developer focus would change. So I don’t think we can quite extrapolate from the current situation with editors such as atom that are not officially supported. If one of those is the official IDE, then we would have to make it just work.

hjh

1 Like

All respect, thank you as always… we all appreciate you here, utmost.

What will SC4 look like, if you had to predict ?

Rainer
May 31

All respect, thank you as always… we all appreciate you here, utmost.

What will SC4 look like, if you had to predict ?

Can we change roles? What moves you to ask this question, vision, ideas, desires, concerns? I’m quite curious.

Anyway, here are mine:

  • MIDI in the server (yes) to have more coupled timing with audio and autonomous patches.

  • A transport mechanism (maybe with osc scores) in real time.

  • JIT compiled ugens from a dynamic language.

  • Standardized OSC messages.

  • A better and documented server command plugin API.

  • More care about supernova than scsynth, its code base was a substantial update from scsynth.

  • Vectorize everything every possible instruction, maybe internally as part of the plugin API.

  • Better FFT interface, I don’t know how, but more versatile for doing specific processing.

  • Improve the implementation of UGens people complain about (e.g. not state of the art).

  • Official android and ios packages of the engine.

  • Maybe other things.

LV2 is a open format, slowly being adopted, now by Reaper for instance: https://lv2plug.in/

Maybe something via using Faust is possible

With PureData it’s possible to generate a JACK application:

If you could ‘wrap’ a simple GUI around it and add NSM support, one could use it in a NSM environment maybe, which is based on OSC. Non Session Manager | Non
This would then mainly work for Linux though.

That’s cool, but wouldn’t handle the SC-as-an-Ableton-plugin case. Reaper is (almost) uniquely cool among DAWs for taking Linux technology seriously but… for instance Cubase users wouldn’t expect Steinberg to provide an equal degree of support for a plugin protocol that competes with their own. Like it or not, VST will have wider reach for the foreseeable future.

OTOH using LV2 to solve the plugin problems would probably get 90% of the way toward solving them for VST as well.

To be honest, I don’t have a lot of ideas about that.

I guess the one most valuable thing for us to consider is interoperability (going along with that, modularity). The wish lists of features are at risk of trying to make SC all things to all people – if it becomes too bloated and diluted, then it loses some of its distinctive identity.

A major weakness in SC now is that it has limited capacity to work with other environments: island unto itself. For instance, a few weeks ago I was recording MIDI into Reaper. Couldn’t sync the timeline. What if SC clocks could follow a DAW? That would simplify the workflow of creating source elements in SC and editing/mixing in a DAW. (DAWs are large, complex beasts. Why should SC do a bad job of imitating them?) A plugin bridge would handle a lot of those problems.

My live coding setup runs Rack alongside SC, automatically loading a MIDI bridge and patching audio through JACK. It works but it’s… complex (and possible only because JACK provides Unix commands to connect/disconnect). Would be nice if this were within nearer grasp.

It would be good to have some options to embed SC into other projects. That may be a non-starter as changing SC’s licensing would require a sign-on from all past contributors, and some are no longer available (and, the last time this came up, one of those said unequivocally that they were not interested in licensing their code under any terms other than GPL). Still, at risk of opening a can of worms, the strict prohibition against linking to non-GPL code reinforces the “island unto itself” ethos and, in that sense, isn’t fully ideal.

hjh

1 Like

To chime in on the topic “SC as VST plugin”: I think the easiest solution is to take the existing SuperColliderAU and port it to JUCE, which supports all major plugin formats (some forks also include LV2 support). The free version of JUCE is licensed as GPLv3.

1 Like

:pray: :pray: :pray: :pray: we are all praying for the space child to bring us this miracle :rofl: :rofl: :rofl:

I have to add that it would be also necessary to add a generic plugin driver to scsynth, similar to SC_AUAudioDriver, but independent of any specific framework. This is something I’ve always wanted to do and hopefully I’ll get around it some time. I think it would help embedding libscsynth into other environments tremendously. However, I’ll probably leave the grunt work of porting SuperColliderAU to JUCE to someone else :slight_smile:

2 Likes

Just curious about, would this be easier than allowing export SC files as a standalone app (on mac, windows and linux like Processing does) ?

There is a quark for that:

Does such a exported standalone have jack support?
Does it needs to have the SuperCollider server to run?
Maybe a newbie question, but it is possible to run the SuperCollider server from the shell (in Linux)?