Supports any version of csound. At import time the correct API is loaded. This makes it possible to decouple the csound version installed from the version of libcsound.
Supports both csound 7 and csound 6 with the same source. libcsound is aware of the changes made to the API from csound 6 to csound 7 and provides methods to write code compatible with both versions.
can be installed via pip. This makes it possible to integrate into a normal python workflow, allowing to declare libcsound as a dependency of other projects.
One incompatible difference is how these bindings are distributed. libcsound is conceived to be external to csound in order to be installed as a normal python package. It supports different python versions, virtual environments, etc. and can be updated independently and receive bug fixes independent of csound’s own release cycle.For this to work it needs to be independent of the csound version installed in the host system and thus needs to support all csound versions >= 6.18. It also makes an effort to enable code to target both csound 6 and csound 7 without changes. In this sense it deviates from ctcsound, which explicitly follows the csound API verbatim.
I would be happy to incorporate any contributions or share ideas back to ctcsound, but I also think that these two bindings can happily coexist.
i am also ot happy about this lack of discussion and collaboration. and i don't think that putting things into pip solves everything. i just tried to install on a mac, and it complaints about a numpy version required which conflicts with a numpy version used for mediapipe. (of course it can be solved but the ctcsound version i have on this computer runs without issues.)
another difference is that françois changed the function names for the CS7 version to snake case to comply with python style guide. this is not the case in edurado's wrapper, so we will have two different languages in using the csound api from python.
I've been involved in Csound dev for a while now, and even longer as a user. There was a time when forks were flying left, right, and centre. It wasn't conducive to a great community experience.
Since 5.0, things have stabilised significantly, I think last time we had a situation was when Istvan left in a huff because his code had been reformatted by a script, and attempted his own C++ fork which failed miserably.
I am not against forking code per se, but I think in some cases this is more beneficial as a short-term measure to test the viability of ideas, eventually leading to a contribution to the codebase.
Joachim has pointed out a key issue in this: if there are parallel versions it can be confusing for users. The fact that this conversation started from a conflation of two sets of bindings is a good indicator.
If we can work together in merging the best ideas of the two projects, I think it would be ideal. Generally, that's how we are trying to proceed with the development of the system.
On a general unrelated note, I think the new processes have helped us a lot, we have had some great contributions from people who have stepped in with their expertise in specific areas.
Python is a very important element in the Csound ecosystem. It would be great to put it in a firm ground so that Csound can be leveraged in areas like scientific research (e.g. ML, tensorflow, etc).
If there are any conflicts, please do report them and I can look into them. libcsound is tested on mac but not with every combination of packages. In your specific case, mediapipe seems somewhat out of date and requires numpy < 2. I just checked and for libcsound the numpy version can be relaxed so if you update to the latest version (0.9.1) that problem should be gone.
Regarding naming conventions, one explicit goal of libcsound is to support both csound 6 and csound 7 with the same codebase, as long as the API makes that possible. The switch to snake case just makes this much more difficult, that’s way I decided to stay with the previous convention.
so we will have two different
languages in using the csound api from python.
As long as you don’t need to use ctcsound within a python virtual environment, integrate it with other libraries or publish packages which depend on it, you can and probably should stick to ctcsound. It is very well thought and follows the API very closely. libcsound just proposes an alternative for those use cases.
Python binding to the Csound host API has a long history. 15 years ago a swig interface to Python 2 was shipped with each release of Csound. I wrote an article in the Csound Journal (https://csoundjournal.com/issue14/realtimeCsoundPython.html) in 2011 showing how to use this interface in the IPython console with the benefit of numpy for binding the Csound buffers data to numpy ndarrays. This inspired people to produce nice applications, notably Andrés Cabrera with his icsound test notebook for sonification.
Ten years ago, I wrote ctcsound to simplify the data structures used in the binding and, at the same time, to make it work with Python 3. I reused André’s icsound to write a python class called ICsound, as a proof of concept. Joachim did a lot of work with his students around this material.
I agree with Victor that there should be only one interface to avoid confusion, and that we don’t have to distribute bindings with the core Csound. I propose that Edouardo’s libcsound should be tested with the maximum of examples/applications that already use ctcsound, and if these tests are successful, then we could remove ctcsound from the core Csound, like we did years ago with the swig interface. I’ve absolutely no problem with this.
I think that the important thing is that the use of numpy arrays is kept still evident for people, because numpy is the base of lots of modules used in scientific Python and in ML