Mathieu Bouchard:
> BTW, anyone looked at SWIG ?
Yepp, I've used it some times.
> It could provide a multilanguage interface to
> Pd's API and/or Flext's API. SWIG generates wrappers from C++ code to
> Python, Ruby, Perl, Java, C#, Tcl, PHP, Lua, and several kinds of LISP
> (Guile, AllegroCL, CMUCL, ...).
>
> SWIG might be the key to unifying the Pd API in various programming
> languages (currently, PyExt, GridFlow, k_guile, all do things quite
> differently from each other). Note that I don't want a "common
> denominator" API which would prevent from using any special features of a
> given language in the Pd API for that language. Nevertheless I would like
> language-specific APIs to be easy to guess (deduce) so that it's easy to
> start writing externals in language X for someone who has general
> experience in language X and experience in writing Pd externals in
> language Y.
Well, do you think theres so many different functions that we should
invovle a common API set? Perhaps its a good idea, but theres only about
10-15 very essential functions and various, eh, esoteric ones, that hardly
anyone use. Anyway, when making k_guile, I did follow the API of PyExt
naming, so at least those two should be quite common. (by the way, k_guile
is soon going to be marked as obsolete, the snd external is far superior).
Regarding SWIG, its a beast that creates totally crazy code. I have used
it for radium, ceres and mammut, but its doing too much, I think. At least
for this. But maybe its worth looking into. The challenge about external
language externals is anyhow threading, garbage collection, time
spent doing things, and other things that can ruin dsp operations,
not the API.
So, I think that a more sober approach would be to make some kind
of official guide-lines for making external languages externals, and put
it into some kind of official documentation.