[PD] general OSC strategies ? [was: OSC segmentation fault]

[Sukandar Kartadinata]

aaah, thanks again Martin, that makes things clearer

I'd have some follow up questions then...

I seem to remember that when I first heard about OSC, one of the 
applications it was demoed with was to send large arrays of spectral 
data around to drive STFTs, oscillator banks or phase vocoders. Which 
is exactly what I'm attempting now.
If sending e.g. an FFT frame as one big array was/is not intended, then 
I'm wondering what the general strategies are to send such large chunks 
of data. Surely I could split it up in smaller messages but then it'd 
become kinda tedious to regroup e.g. 32 lists with 32 numbers each back 
into one frame.

thanks much,
Sukandar (recompiling...)



On 18. Jun 2004, at 21:55 Uhr, Martin Peach wrote:

> In dumpOSC.c I see:
> #define MAXMESG 32768
> static char mbuf[MAXMESG];
> ... which looks like the maximum packet size is 32768.
>
> Also:
> #define MAXOUTAT 50
> sets the size of an array in the t_dumpOSC struct.
> ...so the maximum number of values the functions in dumpOSC can handle 
> in
> the packet is 50. Elsewhere the variable myargc is incremented for each
> value parsed out of the OSC packet but no check is done to see if it 
> exceeds
> MAXOUTAT, hence the segfault when memory gets overwritten. You could 
> try
> compiling dumpOSC.c with MAXOUTAT set to 1024 or more.
>
> Martin
>
> ----- Original Message -----
> From: "Sukandar Kartadinata" <sk at glui.de>
> To: <pd-list at iem.at>
> Sent: Friday, June 18, 2004 2:57 PM
> Subject: Re: [PD] OSC segmentation fault
>
>
>> hmm, thanks for the answer, I had some thoughts in that direction too,
>> but:
>> a. pd-dumpOSC already chokes on 64 floats (256 bytes)
>> b. terminal-dumpOSC receives everything correctly
>> c. there's no ethernet involved. all is local
>>
>> btw, I just tried w/o type tags - no difference
>>
>> thanks,
>> Sukandar
>>
>>
>>
>> On 18. Jun 2004, at 20:35 Uhr, Martin Peach wrote:
>>
>>> You're probably exceeding the maximum network packet length. UDP
>>> packets can
>>> have up to 65536 bytes of data but ethernet packets are not that 
>>> long,
>>> more
>>> like 1500 bytes. So your 1024 floats take at least 1024*4 bytes, and
>>> they
>>> won't get through. On the local machine, ethernet is not used so the
>>> UDP
>>> packets can be longer.
>>>
>>> Martin
>>>
>>>
>>> ----- Original Message -----
>>> From: "Sukandar Kartadinata" <sk at glui.de>
>>> To: <pd-list at iem.at>
>>> Sent: Friday, June 18, 2004 1:58 PM
>>> Subject: [PD] OSC segmentation fault
>>>
>>>
>>>> Hi,
>>>> I'm trying to send a list of 1024 floats from my app to pd via OSC,
>>>> but
>>>> always get a segmentation fault.
>>>> Shorter lists (e.g. 32) do work.
>>>> Sending 1024 floats to the terminal version of dumpOSC works too.
>>>>
>>>> I'm a little new to OSC so maybe I'm missing something obvious. The
>>>> floats are not organized in any complex structure anyway. [dumpOSC] 
>>>> is
>>>> not connected to anything that could cause the crash.
>>>>
>>>> OSC version is 0.2, freshly compiled from CVS.
>>>> pd version is 0.37.1 devel installed thru planetCCRMA as is the rest
>>>> of
>>>> the machine (Fedora Core 1 version). Low latency is enabled, but
>>>> there's no audio being computed anyway in this test.
>>>>
>>>> thanks for any ideas,
>>>> Sukandar
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> PD-list mailing list
>>>> PD-list at iem.at
>>>> to manage your subscription (including un-subscription) see
>>>> http://iem.at/cgi-bin/mailman/listinfo/pd-list
>>>
>>
>>
>> _______________________________________________
>> PD-list mailing list
>> PD-list at iem.at
>> to manage your subscription (including un-subscription) see
>> http://iem.at/cgi-bin/mailman/listinfo/pd-list
>
>
> _______________________________________________
> PD-list mailing list
> PD-list at iem.at
> to manage your subscription (including un-subscription) see
> http://iem.at/cgi-bin/mailman/listinfo/pd-list
>