Bugs item #1726171, was opened at 2007-05-26 11:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1726171...
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: externals Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: packOSC does not accept LONG lists.
Initial Comment: since OSCx crashes with long lists (>50) i tried out the mrpeach/osc/ externals as replacement.
unfortunately, this object has also some limitations, since the maximum number of arguments in a list is hardcoded to 2000. (nevertheless this object checks whether this limit is reached and refuses to crash ;-)
i do not see a reason for this limitation (apart from ease of coding), afaik OSC does not impose a maximum number of list arguments.
the attached diff makes packOSC use dynamic memory management.
----------------------------------------------------------------------
You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1726171...
SourceForge.net wrote:
since OSCx crashes with long lists (>50) i tried out the mrpeach/osc/ externals as replacement.
unfortunately, this object has also some limitations, since the maximum number of arguments in a list is hardcoded to 2000. (nevertheless this object checks whether this limit is reached and refuses to crash ;-)
i do not see a reason for this limitation (apart from ease of coding), afaik OSC does not impose a maximum number of list arguments.
so i have checked the osc documentation again and it does not seem to impose any restrictions on the number and length of the messages (apart from being 4byte aligned)
while my patch removes the hardcoded maximum _count_ of list atoms, it does not remove the maximum buffer size (which limits the usefulness of my patch). it would be great if this limitation could be removed too.
on the receiving side (unpackOSC) there is a maximum list length too, but this is set higher (65536)
imo, this limitation should be removed too. (unless pd can only handle lists of a maximum length of 65536 atoms, which i have not checked)
mfa-sdr IOhannes
IOhannes m zmoelnig wrote:
SourceForge.net wrote:
since OSCx crashes with long lists (>50) i tried out the mrpeach/osc/ externals as replacement.
unfortunately, this object has also some limitations, since the maximum number of arguments in a list is hardcoded to 2000. (nevertheless this object checks whether this limit is reached and refuses to crash ;-)
i do not see a reason for this limitation (apart from ease of coding), afaik OSC does not impose a maximum number of list arguments.
OK, I applied your patch and changed it somewhat to support the possible use of typetags without arguments (T, F, I and N).
so i have checked the osc documentation again and it does not seem to impose any restrictions on the number and length of the messages (apart from being 4byte aligned)
Although most users are running UDP, which is limited to 65536 by the size field in the UDP header, TCP can split the message into multiple packets.
while my patch removes the hardcoded maximum _count_ of list atoms, it does not remove the maximum buffer size (which limits the usefulness of my patch). it would be great if this limitation could be removed too.
I could add a [bufsize( message for those who need a lot of room. I think the default should not be too large or it will become a memory hog for no reason, since most users send short messages (< 1kB) most of the time. I notice that the buffer is declared outside the t_packOSC struct in file scope. This might cause problems if multiple packOSCs are running, I believe they will use the same buffer. So...I plan to allocate the OSC buffer at startup and save the pointer in the pack_OSC struct, which will also allow the size to be changeable via the [bufsize( message.
on the receiving side (unpackOSC) there is a maximum list length too, but this is set higher (65536)
imo, this limitation should be removed too. (unless pd can only handle lists of a maximum length of 65536 atoms, which i have not checked)
I suppose the same approach would work here, dynamically allocating storage for the list, or else sending out sub-lists of up to 65536 until all the data has passed. Thanks IOhannes, for the patch and feedback.
Martin
mfa-sdr IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-
IOhannes m zmoelnig -
Martin Peach -
SourceForge.net