A pure C library to read and write SuperCollider synthdefs, using a Lua-based DSL

Hi, gang. I was working on connecting Swift to scsynth with the idea of making a Mac-native MIDI application, and I needed an easy way to make and try out synthdefs. I then realized that if I did this in C, lots of other languages (Swift, Ruby, Python, etc.) could import it, and it might be useful to others besides me. It seemed like the easiest solution was to embed Lua, and I now have a proof-of-concept toy version working, in that this Lua code:

controls = { Control("out", 0), Control("freq", 440), Control("amp", 0.125) }
osc1 = Mul(SinOsc(controls[2]), controls[3])
return Out(controls[1], osc1, osc1)

gets parsed to a byte-for-byte identical SynthDef data blob as this sclang code:

{  |out=0, freq=440, amp=0.125|
    var osc = SinOsc.ar(freq) * amp;
    Out.ar(out, [osc, osc]);
}

I’ve put the library up on GitHub at GitHub - doubtfulpalace/SuperColliderSynthDefLib, and I’d love to get feedback, specifically:
–Is there anything like this out there already? I know about Lua2SC, but this is quite different.
–Is this something that people would find useful?
–Feedback on the code or the DSL would be very welcome.

2 Likes

26 posts were split to a new topic: SynthDef optimization strategies (esp wrt non-sclang clients)

I believe some (most?) of the clients implement something similar. Multichannel expansion and graph optimization are some of the things that need to be redesigned in the new language.

Can you point me toward a client that defines a C library for creating synthdefs? python-supercollider doesn’t define defs, hsc3 does it in Haskell. I’m sure there are clients I don’t know about, though.

I should included this bit of the README in my post:

The many things remaining to be done include:

Multichannel expansion
Special operators such as * and +
Reassignment of node values
Error handling
Defining the full suite of unit generators
Optimization of SynthDef graphs (e.g. removing redundant constants, controls, and UGens)

A C library usable from any language (a shared library with a C API that can be accessed through Foreign Function Interfaces)? I think not.

FWIW sclang itself does not have a working FFI interface. (That would be a good enhancement project)

Nice project.

Just curious: How mce would increase the complexity of the C code and memory management? Do you have some sketches?

Also, the Lua and C syntax would use an explicit representation of graphs (in contrast to the implicit style used in sclang, which requires some interpretation to process them correctly)?

One would need to write a C wrapper because the interface is C++. Right? (Unless it’s a higher-level binding not using a C interface)

We crossed in the mail. :slight_smile:

1 Like

Since the idea is to design something easily shared/exchanged:

I considered using an “intermediate” explicit graph representation between different programs. I initially thought of using something more like a scheme (or scheme-like syntax) or JSON. I did a basic GUI program to generate a scheme-like format but haven’t tested it much since.

It would be nice to have an interchange format that is both human- and machine-readable, for sure.

Yea, I thought the scheme version would be an ideal balance

I’ve split the discussion because I think details of SynthDef optimization should not overshadow the announcement of a new tool to assist non-sclang clients.

hjh

2 Likes