cSounds.com |
|
Should another/special set of python bindings be developed?
Submitted by gregt on Tue, 02/26/2008 - 06:29.
I've been looking around for documentation on the current python bindings. If no one is supporting them or actively developing them, I wouldn't mind developing a set for the XO. I could enable a number of features that are lacking in the current set. E.g. The following may currently exist, but I haven't found a solution/example for the following greg |
Support cSounds.comJoin with these Generous Csounders and make a donation to help cSounds.com keep going and growing. Thanks so much!
Another way to help is by purchasing a copy of The Csound Instrument Catalog. User loginShop
 Podcast
latest entries:
- browse all the entries - browse by tag - feed URL  - Instructions for listening and submitting your own tracks Recent blog postsActive forum topics
Search |
Is another necessary
Hi Greg,
I think the additions you propose are very welcome. Do you think another set is neccesary? Could the existing bindings not be extended for what you propose?
I'm just wondering, to try to minimize duplication of efforts.
Cheers,
Andrés
Re: Is another necessary
Essentially, I agree with you, however, it is my understanding that the bindings for Csound are generated by SWIG. Some work was done to customize the process, but it also left out a handful of important functions. It also doesn't seem like they are currently being maintained or documented.
For development purposes, I believe creating a separate set of bindings makes sense. It's easier for me to work on them this way. If the new bindings prove to be useful, stable and provide the original set of functionality as well, then it could replace the old bindings or at least be integrated with them.
In the worst case, they'll just be another option for Csound users.
greg
I guess swig was used to
I guess swig was used to facilitate maintenance, but if you can provide another solution, I'm sure it will be very welcome.
Cheers,
Andrés
Re: Is another necessary
Essentially, I agree with you, however, it is my understanding that the bindings for Csound are generated by SWIG. Some work was done to customize the process, but it also left out a handful of important functions. It also doesn't seem like they are currently being maintained or documented.
For development purposes, I believe creating a separate set of bindings makes sense. It's easier for me to work on them this way. If the new bindings prove to be useful, stable and provide the original set of functionality as well, then it could replace the old bindings or at least be integrated with them.
In the worst case, it will just be another option for Csound users.
greg
Hi Greg, I think I would
Hi Greg,
I think I would rather see the SWIG bindings updated in Csound rather than new ones. That said, a simpler solution may be to use ctypes which now comes with Python 2.5, though I don't know if you are using 2.5 or not. I used a similar thing to ctypes but for Java called JNA instead of the SWIG bindings, but found that the SWIG bindings very much more performant so am targetting that now. ctypes though might be enough to get past what you need.
steven
SWIG should do the job
I think SWIG would do the job alright. I know more
or less how to solve the console output problem.
I think ftables are there as well (they are in
the C API).
Victor
SWIG and callbacks
I think I got the SWIG part of supporting Python
callbacks sorted. The problem is that multithreading
has some difficulties. But this would be a problem
in a new set of non-SWIG bindings as well, because
it's to do with Python, not SWIG.
It'll require a few hours of work to devise some
solutions. I have solved it for a callback function
in the CsoundPerformanceThread class, but it seems
to be harder when the callback belongs to Csound
(not sure why, as both would be called in the same
thread).
Victor