<div class="im">On Sat, Aug 27, 2011 at 11:16 PM, Mathieu Bouchard <span dir="ltr"><<a href="mailto:matju@artengine.ca" target="_blank">matju@artengine.ca</a>></span> wrote:<br></div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Sun, 21 Aug 2011, Hans-Christoph Steiner wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think with the libpd API, you can write to Pd arrays. That's probably you're best bet.<br>
</blockquote>
<br></div>
You must be meaning the pd API (m_pd.h).<br>
<br>
There's nothing libpd-specific (z_libpd.h) about arrays.<br></blockquote></div><div><br>That's not true. Recent versions of libpd come with functions for reading and writing arrays, memcpy-style.<br> <br><br></div>
<div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
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.<br></blockquote><br></div>Okay, I'll bite.<br><br>
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.<br>
<br>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.<br>
<br>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.<br>
<br>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.<br>
<br>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: <a href="http://nettoyeur.noisepages.com/2011/08/pure-data-convention-libpd-and-a-minor-epiphany/" target="_blank">http://nettoyeur.noisepages.com/2011/08/pure-data-convention-libpd-and-a-minor-epiphany/</a><br>
Cheers,<br><font color="#888888"> Peter</font>