Hi,
I’m in intermediate coding level in Python, and from now I need to know if it is possible to create expansions (plug-ins or Ugens of SC) in Python, or there is only possible in C++ or Java, I know the creator of SC uses C++ and Smalltalk, the second one is not more in use, but anyway:
It is possible to develop for SC in Python yes or not?
Thanks.
J.
scsynth’s has a C++ plugin interface. In practice, the vast majority of Server plugins are simply written in C++. However, you may use code that is written in other languages, as long it can be called from C++.
In general, Server plugins can only be reliably implemented in low-level languages with precise control over memory management (C, C++, Rust). This means that Python is off the table.
or there is only possible in C++ or Java
You certainly wouldn’t write a UGen in Java 
I know the creator of SC uses C++ and Smalltalk
That’s a misunderstanding. sclang and scsynth are implemented in C++. sclang itself is heavily inspired by Smalltalk, but there is no actual Smalltalk code anywhere in the SuperCollider code base.
In this context, it is worth mentioning Faust, a language for musical synthesis, it compiles to C++ code which can be used to compile SC Ugens:
Understand that there is no possibility to code Ugens or Plugins with Python, but:
1: I found this website; there is like for controlling Routines, patterns and arguments with Python:
2: There is in YouTube this:
3: As the FoxDot site says; there is the possibility to control SC with Python. Instead of coding Ugens and so…
Thanks,
J.
As well as the Marc Evanstein software of SCAMP controlling SC. It is Python via OSC.
Yes, you can control scsynth from other languages via the OSC interface. There are in fact several Python supercollider clients. But that’s something completely different from what you’ve asked…
Examples:
I didn’t know you could write it in C. I only know c++, or faust-generated c++ code.
How about Rust? How that works?
I made a proof of concept Sawtooth oscillator in Rust:
and then NessStretch UGen in the BufFFT library:
uses Rust dsp code to function. In both cases the UGens end up being much larger scx files. But efficiency seems consistent with C++.
I imagine we could even use libpd and embed the c++ bindings into SC plugins. Has anyone tried that?
Sam
@smoge thanks for compiling this list of clients.
I’m thinking… might it be nice to list these somewhere on the SC page for reference?
It’s listed there already.
The only thing I’m not sure is about the communities around those clients. Would be nice to know more about it.
Well, the DSP units are still written in C as well. It might work well, since a lot of scientific code in C is used a lot in python nowadays, there is a lot of high-quality work embedding C code in python.
But real-time audio synthesis is something very specific, so I’m not sure.
I found some examples of the pyo python side here:
How about Rust? How that works?
You basically need a C++ wrapper that calls into your Rust code, like in @Sam_Pluta’s examples.
If scsynth actually had a pure C plugin interface, this layer of indirection would not be necessary since most languages can directly interface with C. This has been in my head for quite some time now and I’ve finally opened an issue on GitHub: Convert server plugin API to C · Issue #6145 · supercollider/supercollider · GitHub
I’ve read somewhere that Rust is the only other language (other than c & assembly) that is supported in the linux kernel development. That’s quite an achievement, it should bring one’s attention. If it reduces unnecessary complexity/complication/unsafety of c++, that’s probably the future of low-level audio dsp programming.
I mean if someone would really want to go crazy there is GitHub - pybind/pybind11: Seamless operability between C++11 and Python or https://swig.org/ which would allow to wrap all scsynth C++ objects as Python objects - this would allow to make the OSC communication unecessary which could lead to really interesting possibilities? And it would allow to declare new UGens via Python (but I’d consider the C++ part not the “heavy” part in DSP code but rather the memory management and necessary speed).
Libraries like Tensorflow or PyTorch are based on the same principle - a C++ core which is managed by a Python frontend.
But thinking about a realtime audio process managed by the Python GIL already gives me headaches. But it could be a very fun project 
I personally don’t think Python is particularly expressive to experiment with sound and music. But, anyways, there is a reason it became the ‘lingua franca’ in many areas. I took a look at the pyo code, I had the impression of a well-behaved and boring version of, for example, supercollider.
We actually use many small “languages”, to build synthdefs, patterns, or something like tidal, etc… Sound synthesis and music composition are a very rich territory, and generality as a principle is probably not the best approach.
That is an interesting take and an interesting paper, thanks for sharing!
OT, but I think Python offers some capabilities that I really miss everyday in sclang and I am always on the verge to leave sclang behind and switching to Python/TS/Julia/… for the following reasons:
In an ideal world all these features could be build into sclang, but it seems like sclang has been more in a maintenance state for decades rather than experimenting with new features - but this is another topic.
IIUC sclang was conceived b/c there were no viable alternatives at the time - and I think sclang still provides some really interesting ways of “de-constructing programming”.
At the same time I think the lacking features slows down building (reusable) abstraction within sclang or even blocks it - either I write non-reusable .scd files or start writing .sc files which will take a lot of strain on the cmd shift l shortcut.
Even after 4 years I have yet to see a good solution for this - it seems everyone just accepts this struggle? 
The only thing where Python really lacks is speed, anonymous functions/lambdas and custom infixes.
Using hacks like sys.trace would probably even allow to implement the ProxySpace syntax into Python.
Of course, Python is a lot more verbose than sclang, but I think I am faster at expressing myself within Python b/c I get introspection and help from type inspection and the LSP, so I rarely need to type much stuff and instead just say which crossing to take instead of writing down the whole path. And I think that this “guided abstraction” is one thing that gets disregarded very often in creative coding b/c the used tools often don’t have these features - and I think this is one of the few usecases where AI could be indeed interesting, managing vague but guided abstractions.
It seems you simply prefer python, personally. You gave the opposite points I did and the hudak take on this.
No language can compete with Python in terms of “interface with the outside world” and “tooling”, you just can’t compare. Python just dominates the scientific and corporate world. That’s A LOT OF RESOURCES.
On types, I think it’s a much deeper discussion than this, and a “typing system” by itself, means very little.
BTW, declaring classes on the fly is not safe, at least, I was told so. If you are using mypy for “safety” (is that the reason?), what is the point?
A very interesting relationship exists between a strongly-type language like Haskell and other languages (possibly embedded in Haskell or not) that does not expose types but actually perform type-level operations on the highest level. APL is an extreme example (apparently with no “types”, but it operates on the type level). That’s abstraction in a higher form as a domain specific expression.
Anyway, there is a lot of Haskell code that work on a type-level context (I’m not talking about just type classes here (which is basic practice today, and things like java and rust use it already; that’s something else, they call it “kinds”). All this discussion goes a bit deeper than just a “typing system,” which can be many unrelated things.
I don’t know where it goes, but maybe one thing remains. KEEP SUPERCOLLIDER WEIRD, don’t turn it into boring python))) We already have Python.
Maybe we just need NEW ideas, not fallback into generalization. That’s my point.
I found a good solution for my own needs for this problem almost 20 years ago, wrote it up in the SC Book even, but nobody noticed 
hjh
It really should have been a much more annoying problem 20 years ago. But nowadays, I think some simple tools could significantly improve class programming. The simplest would be a “file-watch”, which would react to every change in the file and could trigger tests or something similar.
Later, with the development of LSP, this could be an exciting help too.
I’m a bit indifferent to something as “declaring classes on the fly”, as if that were something trivial. It would never be simple.