[PD-dev] [ pure-data-Bugs-1726171 ] packOSC does not accept LONG lists.

[Martin Peach]

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 at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>
>