On Sun, 28 Aug 2011, Peter Brinkmann wrote:
Can you bypass many of the functions in libpd and use m_pd.h directly? Sure, but then again maybe m_pd.h is pointless because you can just hack your binaries with a hex editor. That doesn't mean that that's a good level of abstraction to work at. libpd aims to provide a high-level API at a consistent level of abstraction, and I believe that that's the correct level of abstraction for the kind of work that libpd is intended for.
Well, for the libpd message-passing, I felt like it added an API at the same level of abstraction as <m_pd.h>, except a tiny bit slower than SETFLOAT and SETSYMBOL macros, and which needed a bit more thread-safety than <m_pd.h>, as even the construction of the message has to be protected. Those are really small details, and to me, the biggie is that this API is not any easier than <m_pd.h>'s message passing to a C programmer.
The immediate motivation was to create an API that would be easy to wrap for languages like Java and Python, but I also have deeper reasons for wanting to work at this level of abstraction.
I don't see any practical difference in easiness of wrapping for other languages. I don't know how you see that.
I'm hoping that we'll see a major redesign of Pd in the not too distant future. One goal we talked about at PdCon is to allow multiple instances of Pd.
I don't see any planning about this in the way that the libpd api works, and I don't see how the libpd api currently helps for that.
Another change I'm hoping to see is a rewrite that takes advantage of multiple cores on current machines.
What's a «rewrite», and how much actual change do you wish for ? Do you have a plan for actual changes to the API ?
I also believe that such changes will be necessary to remain competitive.
If anyone really needs a big speed hike, then how about integrating SSE support in vanilla and/or libpd ? The prototype was made in 2005 or so, and then abandoned. That's a lot easier to do than to support double/triple/quad CPUs.
The libpd API is meant to be (mostly) above such implementation details, while the low-level API will almost certainly change when Pd is updated. Pd itself will be much more nimble and maintainable if developers think about it at a higher level of abstraction.
What constitutes a higher level of abstraction ?
BTW, yes, there are additions to your API that I hadn't seen, because I'm not using the latest version.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC