Hallo, Axel Balley hat gesagt: // Axel Balley wrote:

Thank you for your answer. However, I already know that : what I want
precisely is to find out which port is used by sendOSC (the local
port used to connect the remote one), so I can listen on that port
for replies using the dumpOSC object. This is because I want to send
OSC messages to a SC3 server (on port 57110), and display the replies
it sends back to pd : for that, I need to know which port is used by pd.

[sendOSC] itself is not using a "local port" or source port, it just connects to the remote host's destination port, sends its messages, but doesn't read anything back. That's the job of [dumpOSC].

SC3 automatically uses a specific port, but Pd doesn't. Note that for OSC using the UDP protocol, you can only run one application on one machine's port. So if you run SC3 on port 57110, you will not be able to create a [dumpOSC 57110] in Pd anymore, as that port, 57110, already is taken by Supercollider. Instead you'll get a 'Address already in use' error or something like that. Of course you can create [connect localhost 57110( --- [sendOSC] chains, but you already did that.

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__

Yes, I'm aware of that. Besides, there's no point in using the dumpOSC object on the 57110 port when SC3 is running, since there exists a way to display incoming OSC messages in SuperCollider.

-SC3 uses two ports: one for SCLang, the other for SCServer.

AvS

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................

` |Schreck Ensemble . . . . . . . . . . . . . . . . . . . . +

`  |# -laboratory for live electro-acoustic music- #            |
   |             http://www.schreck.nl/                         |
   |             http://www.xs4all.nl/~schreck/                 |
 ` *===========================================================++
 ` |Compositions http://www.xs4all.nl/~schreck/html/compo.html  |
 ` |Samples      http://www.xs4all.nl/~schreck/html/samp.html   |
 ` |Patches      http://www.xs4all.nl/~schreck/html/pat.html    |
 ` |Videos       http://www.xs4all.nl/~schreck/html/video.html  |

 ` |Scores       http://www.xs4all.nl/~schreck/html/scores.html |

   *===========================================================++

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................

Hallo, Axel Balley hat gesagt: // Axel Balley wrote:

Le 17 déc. 05 à 12:05, Frank Barknecht a écrit :

...

[sendOSC] itself is not using a "local port" or source port, it just connects to the remote host's destination port, sends its messages, but doesn't read anything back. That's the job of [dumpOSC].

AFAIK, any transmission of data between a client and server implies
the use of 2 ports : one on the client side (in that case, the
sendOSC object in pd), and one on the server side (here, the 57110
port SC3 listens to). That's why I wanted to know if there was a way
to display which port was used by the sendOSC to connect to SC3. I
actually found that port number using the netstat command, however I
couldn't create a dumpOSC object to listen on it : probably because
it's already used by the sendOSC object so a new socket cannot be
created.

As I understand the UDP specification, you can choose if you want to specify a source port or not. As UDP is stateless, you will often see UDP clients which do not use a specific source port. (See e.g. http://en.wikipedia.org/wiki/Udp) sendOSC, AFAIK, works like that and leaves all receiving up to dumpOSC.

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__

actually I just figured out that it wouldn't work, as the dumpOSC object can't listen on the port that's being used by sendOSC.

OSCx is half duplex. if you are unsatisfied with using seperate ports to send and recieve , you could look into enabling liblo in pd via Flext, or some of the OSC reflectors/managers like OSCgroups and a couple others whose name i can't recall..

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)

.hc

B. Bogart wrote:

Hey,

Can [netclient] be used to replace sendOSC and dumpOSC and then use only routeOSC for the routing?

I've not had a need for full duplex OSC yet...

b.

c wrote:

...

...

actually I just figured out that it wouldn't work, as the dumpOSC object can't listen on the port that's being used by sendOSC.

OSCx is half duplex. if you are unsatisfied with using seperate ports to send and recieve , you could look into enabling liblo in pd via Flext, or some of the OSC reflectors/managers like OSCgroups and a couple others whose name i can't recall..

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

---

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

mmmmmmmmmmmmmmm

I like the direction we're going here...

Also a full-duplex OSC would be pretty neat for the remote discovery features of OSC. Not to mention stuff like a single socket "telnet" connection to PD that does both sending and receving of data...

I've already used telnet sessions to control nogui patches, but some feedback in the terminal sure would be nice..

Ok enough thinking aloud, back to work...

.b.

c 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

i agree, further 'just do the protocol' should mean an abstraction, not C (or C++ + Flext), given how simple OSC is (see http://www.cnmat.berkeley.edu/OpenSoundControl/OSC-spec-examples.html ) but i must learn more C first (the upper-case kind) unless someone else steps up to the plate first...

23:48 c why is there not some kind of 'bytestream ' format 23:48 matju but please, don't send cocaine. i have already enough of a *caffeine* problem 23:49 matju c: bytestream? 23:49 c yeah, as a data type 23:49 matju c: you mean, like a TCP socket? or a raw file? 23:49 chumon my dad is not in the cocaine businness anymore 23:50 c untyped bytes, let the user or objects decipher it 23:50 c oh 23:50 matju c: like [comport] too? 23:50 c well, hes lkucky 23:50 chumon but i started selling drugs at parties 23:50 matju chumon: is he still your dad anymore? 23:50 c matju: yeah i gues i wanted to implement OSC as a PD patch, using byte objects a la TCL's "binary format" and "binary scan" 23:50 chumon because he dont want to send me more money 23:51 c matju: and presumably it would facilitate easier video-formats conversion between pdp/gem/qt/MSV but maybe i have no clue what im talking aout 23:51 c matju: anywyas c u. dont freeze 23:51 matju c: i think it should be done. i don't want s_inter.c to survive and instead i would like [netsend] and [netreceive] to be responsible for the pd<->tcl connection 23:52 matju c: and so an overhaul of netsend/netreceive would be in order

...

, 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)

so we want a nice 'connect' and 'transport' object, which has adjustable backends like UDP socket, named-pipe, and shared-memory depending on topography..then whether its carrying netsend-protocol, or OSC, or 32bit audio is up to the user? sounds good...

...

.hc

B. Bogart wrote:

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Le 18 Décembre 2005 14:56, c a écrit :

so we want a nice 'connect' and 'transport' object, which has adjustable backends like UDP socket, named-pipe, and shared-memory depending on topography..then whether its carrying netsend-protocol, or OSC, or 32bit audio is up to the user? sounds good...

Maybe a solution based on netcat would be a good start: http://www.vulnwatch.org/netcat/ -- Marc

On Tue, 20 Dec 2005, Frank Barknecht wrote:

Hallo, Hans-Christoph Steiner hat gesagt: // 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)

For a start, I just did a big cleanup of OSCroute.c and relatives. With that OSCroute is a single source file external and can be compiled without any dependencies to the rest of the OSC externals, especially it doesn't deal with any networking code anymore.

It was possible before to compile the OSC objects as single externals, the Pd-extended.app have included them like this for a long while. Maybe it didn't work on GNU/Linux. Was there a problem with the OSCroute file that I setup?

I also moved the stuff from OSC-pattern.[c|h] to OSCroute.c. This might not be a good idea, it was just done to simplify compiling even further to basically just

$ cc -c -o OSCroute.o OSCroute.c $ cc -shared -o OSCroute.pd_linux OSCroute.o

The code is not in CVS, however I'd love to hear some comments on this approach (and tests on Windows as well, as I removed some stuff there, too, like the __declspec(dllexport) in the original code, which better goes to a makefile, I think.)

I say leave this code as is, for the most part, except to get it building properly and to fix bugs. OSCx (this current OSC lib) is kind of a hack. It would be nice to see some clean OSC objects, perhaps with the networking handled by a separate object.

But ultimately, I don't have a strong preference, as long as it compiles, installs, and works when I cd packages && make install

.hc

zen
   \
    \
     \

On Wed, 21 Dec 2005, Frank Barknecht wrote:

Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:

...

It was possible before to compile the OSC objects as single externals, the Pd-extended.app have included them like this for a long while. Maybe it didn't work on GNU/Linux. Was there a problem with the OSCroute file that I setup?

No, nothing was wrong, OSCroute always built fine in the past. What I would like to achieve is a clearer separation of OSCroute, which is just a simple, but very useful Pd message external, with nothing specific to OSC about it at all actually, and the UDP networking and scheduling code in OSCx. Even when somebody starts doing a new implementation of the networking code, OSCroute will be a pretty important external and it doesn't need to change much.

So basically all I did was remove the OSC-common.h header from OSCroute.c, as that is also used in the other OSC externals, to make OSCroute stand-alone and to make it possible to move it anywhere else in the future.

...

I say leave this code as is, for the most part, except to get it building properly and to fix bugs. OSCx (this current OSC lib) is kind of a hack. It would be nice to see some clean OSC objects, perhaps with the networking handled by a separate object.

OSCroute isn't a hack, it's a pretty normal Pd external, it just has collected a bit of dust, which I'm trying to shake off. For that I cleaned up the code a bit, removed a lot of commented Max code and some practically unused variables and some code paths, that were just taken if TRUE == FALSE. This wasn't a lot of work actually.

I mean to say that the OSCx lib is kind of a hack because its basically just Pd ports of the command line OSC apps, sendOSC and dumpOSC, instead of being objects specifically designed for Pd. I think that the interface could be much nicer, and how it fits into Pd.

.hc

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

zen
   \
    \
     \

Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:

It was possible before to compile the OSC objects as single externals,

Just to add this: I made it an external with a "single source file", not just a single external. (Removed abstractions and replaced them with subpatches?)

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__

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