[PD] sending image from of / libpd

[Peter Brinkmann]

On Sat, Aug 27, 2011 at 11:16 PM, Mathieu Bouchard <matju at artengine.ca>wrote:

> On Sun, 21 Aug 2011, Hans-Christoph Steiner wrote:
>
>  I think with the libpd API, you can write to Pd arrays.  That's probably
>> you're best bet.
>>
>
> You must be meaning the pd API (m_pd.h).
>
> There's nothing libpd-specific (z_libpd.h) about arrays.
>

That's not true.  Recent versions of libpd come with functions for reading
and writing arrays, memcpy-style.


It's a good thing, because IMHO, many of the functions whose name start with
> the letters «libpd» are pointless, as they can already be done using
> typedmess() and such.
>

Okay, I'll bite.

Pointlessness is in the eye of the beholder.  You may find many of the libpd
wrappers pointless because you're working in C and you're already familiar
with the functions in m_pd.h, but that's not the use case that I had in mind
when writing libpd.

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.

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'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.  Another change I'm hoping to
see is a rewrite that takes advantage of multiple cores on current
machines.  I also believe that such changes will be necessary to remain
competitive.

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.

In case you're interested, I recently added a few more functions to libpd,
and I wrote up my reasoning behind them in a blog post:
http://nettoyeur.noisepages.com/2011/08/pure-data-convention-libpd-and-a-minor-epiphany/
Cheers,
     Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20110828/29021264/attachment.htm>