Joshua Kit Clayton

On Oct 22, 2006, at 3:45 PM, jennek geels wrote:

> but is it safe to usurp "FullPacket" messages output by [udpreceive].

> Or will the usurped FullPacket never be freed from memory?

I don't believe this will be safe. I would suggest you use something 

like the following instead (i.e. use jit.qball after 

OpenSoundControl). Or have some means of the client acknowledging the 

I also might plug the udpsend/recv objects which are now standard in 

the distribution, or using jit.netsend/recv which can also send 

> [udpreceive]
>   |
> [jit.qball]
>   |
> [OpenSoundControl]
>
> but is it safe to usurp "FullPacket" messages output by [udpreceive].
> Or will the usurped FullPacket never be freed from memory?

I don't believe this will be safe. I would suggest you use something  
like the following instead (i.e. use jit.qball after  
OpenSoundControl). Or have some means of the client acknowledging the  
data before transmitting new data.

> [udpreceive]
>   |
> [OpenSoundControl]
>  |
> [jit.qball]

I also might plug the udpsend/recv objects which are now standard in  
the distribution, or using jit.netsend/recv which can also send  
messages (using tcp).

re-is-it-safe-to-usurp-opensoundcontrol-fullpacket-messages

On 25-okt-2006, at 17:56, Joshua Kit Clayton wrote:

> On Oct 22, 2006, at 3:45 PM, jennek geels wrote:

>> but is it safe to usurp "FullPacket" messages output by [udpreceive].

>> Or will the usurped FullPacket never be freed from memory?

> I don't believe this will be safe. I would suggest you use 

> something like the following instead (i.e. use jit.qball after 

> OpenSoundControl). Or have some means of the client acknowledging 

> I also might plug the udpsend/recv objects which are now standard 

> in the distribution, or using jit.netsend/recv which can also send 

I have just found the time to run a test:

- send OSC packets at 60 fps from computer A

- recieve them on computer B. keep the receiving max patch busy so 

Using Apple's Activity Monitor to watch real memory, there is a 

memory usage increase of 1.5 Mb per minute.

This is not acceptable for a patch that should run all day long.

This seems bad news, but actually it made me discover something 

I had to look for another spot in the patch to put the jit.qball in.

And I found out that there is a much better one than between 

The strategy I was after (drop frames as they enter the patch) is wrong.

The incoming frames build up state in the receiving patch, state 

This state is rendered to video and audio.

It is OK to slow down rendering, but it is a flaw to drop state changes.

So now I keep the updreceive generated events at high priority, up to 

Next I pass the bang that drives all the rendering thru jit.qball. 

the renderer may drop from 60 fps to whatever, without freezing the 

I have been struggling with this for over a week now, and today it 

- your article "Event Priority in Max (Scheduler vs. Queue)"

- Trond Lossius' pointer to the java goodie 'WhichThread.help'

Both are great resources that deserve much more attention.

I hope they will make it into a Max Topics chapter one day.

What a wonderful resource this community is.

On 25-okt-2006, at 17:56, Joshua Kit Clayton wrote:
> On Oct 22, 2006, at 3:45 PM, jennek geels wrote:
>
>> [udpreceive]
>>   |
>> [jit.qball]
>>   |
>> [OpenSoundControl]
>>
>> but is it safe to usurp "FullPacket" messages output by [udpreceive].
>> Or will the usurped FullPacket never be freed from memory?
>
> I don't believe this will be safe. I would suggest you use  
> something like the following instead (i.e. use jit.qball after  
> OpenSoundControl). Or have some means of the client acknowledging  
> the data before transmitting new data.
>
>> [udpreceive]
>>   |
>> [OpenSoundControl]
>>  |
>> [jit.qball]
>
> I also might plug the udpsend/recv objects which are now standard  
> in the distribution, or using jit.netsend/recv which can also send  
> messages (using tcp).
>
> -Joshua

Joshua,
thanks for your answer.
I have just found the time to run a test:
- send OSC packets at 60 fps from computer A
- recieve them on computer B. keep the receiving max patch busy so  
that half of the packets are dropped.
Using Apple's Activity Monitor to watch real memory, there is a  
memory usage increase of 1.5 Mb per minute.
This is not acceptable for a patch that should run all day long.

This seems bad news, but actually it made me discover something  
important.
I had to look for another spot in the patch to put the jit.qball in.
And I found out that there is a much better one than between  
udpreceive and OpenSoundControl.

The strategy I was after (drop frames as they enter the patch) is wrong.
The incoming frames build up state in the receiving patch, state  
which accumulates over multiple frames.
This state is rendered to video and audio.
It is OK to slow down rendering, but it is a flaw to drop state changes.
So now I keep the updreceive generated events at high priority, up to  
the point where they have
fully propagated to the client state.
Next I pass the bang that drives all the rendering thru jit.qball.  
Thus the frame rate of
the renderer may drop from 60 fps to whatever, without freezing the  
patch or missing state transitions.
This is with max in overdrive.

I have been struggling with this for over a week now, and today it  
all fell into place.
Key ingredients:
- your article "Event Priority in Max (Scheduler vs. Queue)"
- Trond Lossius' pointer to the java goodie 'WhichThread.help'
Both are great resources that deserve much more attention.
I hope they will make it into a Max Topics chapter one day.

What a wonderful resource this community is.
-jennek


Re: is it safe to usurp OpenSoundControl FullPacket messages?