[PD] port used by sendOSC

[Mathieu Bouchard]

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?

3. an IOByteStream object is just an InByteStream object and an 
OutByteStream object at the same time. There is no conflict between the 
two.

4. 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.

5. 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.

6. 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