[PD] port used by sendOSC

[c]

> 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: