On Sun, 18 Dec 2005, Hans-Christoph Steiner wrote:
I just had the same thought. It seems to me that Pd's OSC objects could be implemented so that they just do the protocol, then we'd have separate network objects that handle all of the networking. It would be a much more flexible system, and there would be less overlap in code to maintain (i.e., you would only have network code in the network obects, and OSC code in the OSC objects)
Let me propose this:
------------------8<--------cut-here--------8<------------------
1.1. a OutByteStream object is one that accepts those messages on inlet 0:
- float: seen as a byte (0..255)
- list of floats: seen as a sequence of float messages.
- symbol: seen as a \0-terminated string.
- bang: forces buffer-flushing if there's a buffer.
1.2. a OutByteStream object may also optionally respond to string
messages, in my dreams. However, in the meanwhile, it may be more
appropriate to use a new special C function that accepts a pair of
int and const char * (\0 is not honored: the int specifies the size).
This is so that there is no speed disincentive to switch to decoupled
I/O objects.
2.1. an InByteStream object is one that accepts those messages on inlet 0:
- bang: polls for more input (unlimited size).
- float: treated as int. polls for at most N bytes.
- auto 0: requires bang for getting more input.
- auto 1: uses a t_clock (hidden [metro]) for auto-polling.
2.2. an InByteStream may produce those messages:
- float: seen as a byte (0..255)
- list of floats: seen as a sequence of float messages.
and when in "auto 0" mode, it will only send it when receiving a bang or float.
2.2. an InByteStream object may also optionally produce string messages, in my dreams, etc. What would the C function(s) look like in this case?
- an IOByteStream object is just an InByteStream object and an
OutByteStream object at the same time. There is no conflict between the two.
there would be object classes called [tcp] and [udp] which would be InputOutputStream objects (supporting in, out and bidi connections).
They would also respond to "connect" and "disconnect" (or maybe "open" and "close" instead) and also "listen" for enabling server mode.there would be an object class called [fudiin] which would be an
OutByteStream and [fudiout] which would be an InByteStream. Thus, to get a bidirectional [netsend] [netreceive], use this triad:
| [fudiout] | [tcp] | [fudiin] |
Leaving out the first or the last object gives you [netsend] and [netreceive] respectively.
- a [tcp]<->[fudiin] pair can replace the server-side of the GUI connection as long as the [tcp] object supports char* input as suggested in part 1.2. (if the rest of this proposal is not implemented, then use a slightly modified [netreceive] instead)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada