blob: 5ed2bf254562035cc7dd40b94443250c283718a1 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
|
------------------8<--------cut-here--------8<------------------
Dec 26 2005
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)
|
