Current state of cpp binding
Closed this issue · 5 comments
Is your feature request related to a problem? Please describe.
IIUC there seems to be a cpp binding available as SHM Server? I did not find much information on this, mainly a test https://github.com/josiah-wolf-oberholtzer/supriya/blob/main/tests/realtime/test_shm.py and an import in the CI.
Having a CPP binding for scsynth would be crazy, allowing for a much nicer interaction with scsynth: better debugging and exchanging samples would be really easy - having a sync handle into the server rather than an async via network is really interesting - maybe this would even allow for python unit generators? (While these will probably be not fast enough for audio synthesis these could be really cool for control rate.)
Maybe one could look at e.g. tensorflow or pytorch, which also bulid and run a graph in CPP and create handle such that python can interact with it.
I don't know if this is out-of-scope for this project or what the plan is on the cpp binding.
Describe the solution you'd like
Is there some discussion/issue/docs on the current state?
Describe alternatives you've considered
I know that there is https://github.com/pybind/pybind11 which can be used to interact between CPP and Python. But maybe this is harder as I think because scsynth needs a realtime environment and does some tricky/raw memory operations in its ugens.
Additional context
This gets into territory where the MIT license of this project clashes with the GPL2 of SuperCollider?
-
The SHM interface only supports a subset of what sclang's SHM interface already supports: reading control buses. It's based of a version from here: https://github.com/supercollider/supercollider/blob/main/common/server_shm.hpp. If sclang ever gets more complex bindings, we can look into supporting them, but this is really a question for the original SuperCollider project.
-
I'll cross the license bridge if it ever comes up.
Re: license, looks like I need to adjust mine to match what sonic-pi is doing: keep it MIT, but add a GPL acknowledgement.
Just out of curiosity - why not GPL2?
Regarding the SHM - I thought that maybe it would be feasible to wrap scsynth into a python library via e.g. pybind instead of communicating to with it via OSC messages, making data exchangable from python <-> scsynth and providing function hooks - in the end it would overcome the "client vs server" separation.
But I know that the memory management of SC is rather advanced and I am unsure if pybind or else goes along so easily with this.
Why not GPL? Slightly silly answer, but there are a lot of corporate environments where GPL code is forbidden but MIT isn't. I'll leave it at that.
Re: bindings, again that depends on if SC exposes anything that can be bound. I can't answer that question, unfortunately.
If need be, I'll remove the SHM code and repackage as a separate library on PyPI, making it an optional dependency of Supriya, so as to maintain the MIT license.