[PD] sending image from of / libpd

Dan Wilcox danomatika at gmail.com
Mon Aug 29 21:15:24 CEST 2011


Whoah whoah hold on. I'm not suggesting to dump the message sending API. I'm only asking for the ability to set the max message size. In most cases 32 is plenty. The *t_atom send func is sufficient for more advanced users. I like the message API and will use it as the default anyway.

enohp ym morf tnes
--------------
Dan Wilcox
danomatika.com
robotcowboy.com

On Aug 29, 2011, at 2:51 PM, Peter Brinkmann <peter.brinkmann at googlemail.com> wrote:

> 
> 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/c0c49005/attachment.htm>


More information about the Pd-list mailing list