Re: [sc-dev] Buffer:free

[Jan T <sc3@xxxxxxxxxxxxxxxxx>]

yes, i think freeMsg should only provide the message (as the method name suggests). everything else could be in free, i think.

On Dec 14, 2008, at 11:20 PM, James Harkins wrote:

cache/uncache has nothing to do with buffer numbers. It's just a mechanism to get b_info replies from the server. Buffer numbers come from the bufferAllocator.

The question is whether it's correct to deallocate the buffer number at the same time that you generate the freeMsg. It could be argued that you just want the message, and it's wrong to release the number until you actually send the freeMsg. Then the user is responsible for calling server.bufferAllocator.free(bufnum) at the time of sending the message.

That might be OK. If you're using freeMsg, probably we can assume you know what you're doing.

hjh

On Dec 14, 2008, at 5:12 PM, Jan T wrote:

Hi

i'm doing some NRT rendering with Buffers. And i'm using Buffer's methods to generate osc messages. In my case it's not very convenient how Buffer:free works.

It uncaches in the freeMsg, which means when i use this method when generating osc messages and Scores, my Buffer number is always 0. 

Could we move this.uncache to free? 

Like:

free { arg completionMessage;

this.uncache;

server.listSendMsg( this.freeMsg(completionMessage) );

}

freeMsg { arg completionMessage;

server.bufferAllocator.free(bufnum);

^["/b_free", bufnum, completionMessage.value(this)];

}

Jan

: H. James Harkins

: jamshark70@xxxxxxxxxxxxxxxxx

: http://www.dewdrop-world.net

.::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:

"Come said the Muse,

Sing me a song no poet has yet chanted,

Sing me the universal."  -- Whitman