I’ve been a long time SuperCollider user for over 8+ years now, and it’s one of my favorite languages for prototyping tools and instruments for generative music and sound design.
But the dilemma I always face when deciding if I’ll embark on a new project with SuperCollider is its lack of support to easily take the work I prototype in SuperCollider to other platforms or languages (e.g. no official support for exporting to audio plugin formats, C++, Raspberry Pi, etc.)
Has the SC Dev community considered adding official support for exporting SCLang projects to any such platform or language(s) at some point in the future? Or if not, have there been efforts to poll the wider SC community if there’s interest in this?
I can appreciate the technical hurdle this probably represents given SC’s server/client architecture and how it would likely be a large undertaking to support well.
But in understanding that SC is written in C++, would some kind of support for exporting to C++ at least be technically feasible?
And given the “code once, deploy everywhere” direction that many other audio development languages and APIs are going in these days (i.e. Max RNBO, FAUST, JUCE, etc.), I imagine I’m not the first person to have desired similar capability from SuperCollider.
In theory, yes, it is possible. The original author is presently developing a system that deviates from the SynthDef model, generating C++ code, compiling at runtime.
However, it’s important to note that this capability would likely apply specifically to SynthDef and not to the sclang language. And it’s unlikely it will be implemented, it would be a major change in the project.
There is a project called SuperColliderAU that connects SC as AudioUnit in MacOS. In theory, this could also be improved and include other formats.
It’s worth mentioning that there are various clients implemented in different programming languages that interact with the synthesis server (scsynth), including Python, Scala, Haskell, Scheme, and more. Maybe that is a way for you.
The original author is presently developing a system that deviates from the SynthDef model, generating C++ code, compiling at runtime.
That’s exciting news, I wasn’t aware, but am all caught up now unless there’s more documentation about this somewhere else online
However, it’s important to note that this capability would likely apply specifically to SynthDef and not to the sclang language. And it’s unlikely it will be implemented, it would be a major change in the project.
Understood, even that would be very useful.
There is a project called SuperColliderAU that connects SC as AudioUnit in MacOS. In theory, this could also be improved and include other formats.
Yes, I’m aware of that, but it looks like it hasn’t been maintained for awhile.
It’s worth mentioning that there are various clients implemented in different programming languages that interact with the synthesis server (scsynth), including Python, Scala, Haskell, Scheme, and more. Maybe that is a way for you.
libscsynth already exists Unfortunately, it has one problem that severely limits its usability: audio input/output always goes through actual audio drivers! For example, this means that you cannot embed it in a plugin because a plugin never interacts directly with audio devices. (SuperColliderAU uses a dedicated “driver” implementation.)
What libscsynth ultimately needs – and what libpd already does – is expose a “raw” process function that reads from input buffers and writes to output buffers. (In fact, this has been on my to-do-list for a while.)
I don’t think so, for the reasons mentioned in my last post (and partly also because of the licensing, but that is a different story).
Based on feedback from users, libpd significantly enhances their preference for Pure Data.
To be fair, I don’t think that the average Pd user cares about libpd, let alone knows what it is. Personally, I do care, though, and I think it is a strong selling point (for particular use cases).
What libscsynth ultimately needs – and what libpd already does – is expose a “raw” process function that reads from input buffers and writes to output buffers. (In fact, this has been on my to-do-list for a while.)
This would also potentially make more testing and unusual uses of scsynth possible.
Does supernova also provide anything like libscsynth? I can’t find anything with a quick browse of the source.
No! The reason is that Supernova is a singleton, i.e. it only allows a single Server instance. It has not been designed to be embeddable. It could expose a C API, but with the following limitations:
you can only create a single instance
Supernova owns the audio device, i.e. no “raw” process function. (Supernova needs to control the thread affinity of the audio callback.)
This would make it completely unsuitable for plugins, for example. The only advantage would be that you wouldn’t have to send OSC messages over the local network, instead you could send them right into Supernova with a function call.
Reading Tim’s article (BTW, it should be mentioned in the SC wiki), I think it’s clear that he never thought of supernova as a replacement for scsynth in all situations. He even points out cases where scsynth would be a better choice.
libscsynth has a future ahead of it, it just needs to be set free. I’m glad you will make it possible)))
I mean, supernova is a drop-in replacement for scsynth in terms of functionality, but in some situations it won’t deliver better performance. Like other things, one needs to make compromises here and there to achieve significant improvement in other cases. In supernova case, it was optimized to deal with many Nodes in parallel.
If you have privileges, please include a link to his papers and thesis in the wiki.
It was his article for Linux Audio Conference 2010. Slides and video are available too.
As explained in Section 5.2 the audio callback
wakes up the worker threads before working on
the job queue. The worker threads are not put
to sleep until all jobs for the current signal block
have been run, in order to avoid some schedul-
ing overhead. While this is reasonable, if there
are enough parallel jobs for the worker threads,
it leads to busy-waiting for sequential parts of
the signal graph. If no parallel groups are used,
the worker threads wouldn’t do any useful work,
or even worse, they would prevent the operating
system to run threads with a lower priority on
this specific CPU.
Ok, but as long as (single-threaded) performance is not worse than scsynth, it would still be a drop-in replacement. (Of course, there are also incompatibilities, bugs, missing features…)
Thanks for the link to the talk! I haven’t seen it before.
If no parallel groups are used,
the worker threads wouldn’t do any useful work,
or even worse, they would prevent the operating
system to run threads with a lower priority on
this specific CPU.
Seems like the talk is a bit out of date (it is from 2010 after all). Supernova only wakes up as many DSP helper threads as needed (none if there are no ParGroups).
@Spacechild1 Some users complain that they do not see a performance benefit. I wonder one thing: to obtain these benchmarks, wouldn’t you have to have a computer with a real-time Linux kernel just like Tim did when he developed it? Because those users are mostly on mac I think. He was a performance freak also tweaking the operating system.
What if there are several ParGroups with very few nodes? That would not be a bad choice still today?
Some users complain that they do not see a performance benefit.
First off, as a user you need to know what you are doing. Unfortunately, multithreading in Supernova is not as transparent as in modern DAWs. There are a few things to keep in mind.
Unfortunately, it has one problem that severely limits its usability: audio input/output always goes through actual audio drivers! For example, this means that you cannot embed it in a plugin because a plugin never interacts directly with audio devices. (SuperColliderAU uses a dedicated “driver” implementation.)