[PD] sending image from of / libpd

[Mathieu Bouchard]

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