[PD] sending image from of / libpd

[Peter Brinkmann]

On Mon, Aug 29, 2011 at 1:23 AM, Dan Wilcox <danomatika at gmail.com> wrote:

> No, I'm talking about sending a list or typed message with libpd as in:
>
> [list 1 2 3 4 ... 32 <
> |
> [s toC++]
>
> The print messaging isn't limited as far as I know.
>

That's right.  The only part that imposes a limit on the message size is the
simple message assembly mechanism for sending lists to Pd.  Lists that are
created elsewhere have no such limitation.


I think it's reasonable to limit the message size, but 32 may be too small
> for some. It would make sense for libpd to have a call that would allow
> users to set the max message size, akin to how you can set the max packet
> size on sockets etc
>

Hmm.  I'm reluctant to add a call for changing the array size because this
entire message assembly API is really just there for the purpose of
simplifying the creation of language bindings.  Any additional complexity
would make it even harder to justify.  So far I've felt that it was
justified because it seemed good enough and I believe its simplicity has
helped the adoption of libpd.  If it turns out to be too limiting (and this
thread suggests that that may be the case), then I'll have to bite the
bullet, deprecate this approach, and write the manual type conversions for
Java and other languages that I'd been trying to avoid.  The good news is
that the latest version of libpd already comes with a new pair of message
passing functions that are not limited in this way.

The current limit was chosen in the following highly scientific fashion:  I
tried to think of the longest list I might want to send as a message, and
the biggest thing I could realistically think of was an OpenGL
transformation, i.e. 4x4 = 16 numbers.  Then I doubled that count and hoped
that that would be enough for everybody.

Maybe we can have a poll and come up with a better estimate.  Here are a few
questions:

1. What sort of use case for long list messages to you have in mind?
2. Exactly how long would you need the list to be?
3. Is this really a use case for list messages or would it make more sense
to write to an array instead?

If we converge to a reasonable number, that'll be the new limit.  Otherwise,
the entire approach may have to go.



> Also, I imagine you don't have this limitation using the new *t_atom
> sending func. Is this true Peter?
>

That's right, there's no intrinsic limitation in the functions.  With the
new approach, you're responsible for creating the t_atom arrays that you're
sending; if you can create it, then the new functions can send it.
Cheers,
     Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20110829/ae296d8d/attachment.htm>