Hey Ron, On 11 Nov 2004, at 14:40, Ronald J. Kuivila wrote:
Why? When you allocate a buffer or bus with Buffer or Bus, you have iton the server immediately (since they are preallocated). basicNew createsa client side representation of a Node 'before' it is created on the server.
I agree with you about Bus, and don't propose changing it in this way, but Buffer is different, as although the number of buffers is set when the server boots it still requires an asynchronous command to allocate the memory. In this way it is more like the Node classes. i.e. I would say that basicNew creates a client side representation without automatically sending an OSC message to do whatever server-side stuff needs to be done.
As well, it seems to me that as a general rule, it would be consistent to have *new function as the general case, rather than the exception as it does in the case of Buffer. i.e. Buffer(s, 1024) should send the OSC message, IMO.
A potential consistency issue is how client side code isalerted a buffer or bus has been deallocated. (I use dummy OSC commandsin OSCpathResponder. I have not proposed that as a general solution as all the OSCresponder classes need a second look.)
I agree here as well.Another issue (which I may have raised before) is that currently the Bus and Buffer allocators (PowerOfTwoAllocator) don't have the same protected ranges as the node allocator does. In a multi-client + multi-server situation, this could be an issue, but it's not immediately clear to me what the best way to configure things is. There may be cases where you want to share busses and buffers, and there may be cases where you want to have protected ranges.
Of course there may be cases where one wants to be able to control nodes created by another client as well, in which case you need a scheme for sharing id numbers. One could just do the same with busses and buffers. Probably it would be best to have the option of protected ranges if desired.
S.