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?
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.
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…
JCollider duplicates some of SCLang’s client side representation classes to simplify the building of Java based clients (project is beta state): JCollider Readme
Processing
P5_SC is a Processing client for SC Synth. It replicates the main classes of SC-lang, e.g., Bus, Group, Buffer, Bus, etc
Scala provides type safety, and at the same time offers compactness that makes UGen graph creation look very close to their sclang equivalents http://github.com/Sciss/ScalaCollider
Clojure
Overtone is a Clojure based musical generation and manipulation system for live-coding and more.
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:
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:
a moderately interesting, optional typing system
futures/promises for async
dependency/release management
module logging
a much wider interface to the outside world
dev tools like debugging, coverage testing or profiling
namespaces and declaring classes on the fly
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.
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.