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