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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
