Hi list,
I succeed in sending UDP messages to an ESP8266 (Wifi Module with Arduino IDE) with Pd-Vanilla [netsend -u]. But if I would like to send OSC messages, I have to use [ [, sendtyped /led i $1, ] < message with [packOSC] --- [udpsend].
The OSC library in Arduino receive "Bundle" messages so I wonder how to send this kind of messages in Pd-Vanilla and [oscformat].
Just to finish, thanks for developing the OSC communication inside PD-Vanilla. Here is an example in an artistic installation : https://vimeo.com/204155167
Best,
On Mit, 2017-02-22 at 09:26 +0100, Jérôme Abel wrote:
Hi list,
I succeed in sending UDP messages to an ESP8266 (Wifi Module with Arduino IDE) with Pd-Vanilla [netsend -u]. But if I would like to send OSC messages, I have to use [ [, sendtyped /led i $1, ] < message with [packOSC] --- [udpsend].
The OSC library in Arduino receive "Bundle" messages so I wonder how to send this kind of messages in Pd-Vanilla and [oscformat].
I think you can't. From the help of [oscparse]:
"oscparse and oscformat make no attempt to deal with timetags or aggregates of packets, nor with streaming OSC."
Roman
P.S. It's a funny help file anyway: "OSC is a complicated networking protocol" - No, it's not. It's rather a transport agnostic protocol. "(FUDI, as used in netsend/netreceive is simpler and better but less widely used)." - I totally agree ;-)
On 2017-02-22 09:41, Roman Haefeli wrote:
I think you can't. From the help of [oscparse]:
"oscparse and oscformat make no attempt to deal with timetags or aggregates of packets, nor with streaming OSC."
the help-file goes on: "you can alternatively use the OSC objects from mrpeach which have more features than these."
so if you want bundles, use mrpeach's osc library.
gamsdr IOhannes
hi, a more general question about internal network communication:
which method would you say is the "best" way to communicate between PD and other applications like MAX, GEM, VVVV in terms of speed and reliability ?
i'm asking for a huge project that should be able to send/receive time-critical messages (for video-synching) AND also big lists of filenames etc. across applications.
maybe it's better to use [OSC] for the latter and [netsend] for single floats (f.e. to send a time-synch message) ?
is it better to open more than one port (or is it a socket ?) for this purpose or will that make things worse ?
should i use vanilla's [netsend] or are there other externals better suited for this task ?
what are your experiences in this regard ?
thanks a lot !
oliver
maybe it's better to use [OSC] for the latter and [netsend] for single floats (f.e. to send a time-synch message) ?
OSC is just a way to format your data and is independend from the actual protocol you use for transmitting the data. Most of the time you'll find OSC over UDP (e.g. [packOSC] -> [netsend -u -b] etc.) but it can also be TCP ([packOSC] -> [netsend -b]) or SLIP for sending over a serial connection ([packOSC] -> [mrpeach/slipenc] -> [comport]). I've once worked with an Ion lighting console which expected SLIP encoded OSC over TCP (wtf!).
OSC itself just provides some convenience, it can be more efficient or not, depending on the message type. If you're just sending a single number, then FUDI* might make more sense. The difference might be neglectible, though.
As you probably know, UDP is faster but error-prone, e.g. packages might get lost or be received in the wrong order. TCP has a handshake mechanism which makes it slower but very reliable.
The rationale is this: If a message *must* arrive (like going to the next scene in a show) and your network connection is unstable or quite busy, use TCP. Otherwise go for UDP.
Now some personal and second-hand experiences:
I never had a problems when sending UDP via localhost. However, I met a guy who got UDP package loss even on his localhost. Personally I never experienced this but it might happen if you send too much data.
I did experience package loss when sending UDP packages via network, more often with Wifi but also with Ethernet, but either the network was busy or the amount of data was quite large. When I switched to TCP everything was fine.
For sending big lists of filenames I'd definitely go for TCP. Regarding the video syncing, it depends. If packet loss is theoretically acceptable - although it's certainly not desired -, go for UDP, otherwise TCP.
Unfortunately, not all programs can handle OSC over TCP...
Regarding your question if you should use internals or externals: IIRC the iemnet objects are threaded (also true for the mrpeach net objects?) whereas the internal objects are not and may therefore block Pd on heavy traffic. IOhannes or others may please correct me!
Christof
*simple protocol used by Pd in [netsend]/[netreceive] (without the -b flag!) https://en.wikipedia.org/wiki/FUDI
Gesendet: Mittwoch, 22. Februar 2017 um 11:57 Uhr Von: oliver oliver@klingt.org An: pd-list@mail.iem.at Betreff: [PD] netsend/netreceive questions ...
hi, a more general question about internal network communication:
which method would you say is the "best" way to communicate between PD and other applications like MAX, GEM, VVVV in terms of speed and reliability ?
i'm asking for a huge project that should be able to send/receive time-critical messages (for video-synching) AND also big lists of filenames etc. across applications.
maybe it's better to use [OSC] for the latter and [netsend] for single floats (f.e. to send a time-synch message) ?
is it better to open more than one port (or is it a socket ?) for this purpose or will that make things worse ?
should i use vanilla's [netsend] or are there other externals better suited for this task ?
what are your experiences in this regard ?
thanks a lot !
oliver
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 2017-02-22 15:16, Christof Ressi wrote:
OSC is just a way to format your data and is independend from the actual protocol you use for transmitting the data. Most of the time you'll find OSC over UDP (e.g. [packOSC] -> [netsend -u -b] etc.) but it can also be TCP ([packOSC] -> [netsend -b])
no, this is broken by design.
or SLIP for sending over a serial connection ([packOSC] -> [mrpeach/slipenc] -> [comport]). I've once worked with an Ion lighting console which expected SLIP encoded OSC over TCP (wtf!).
SLIP-encoding is the only proper way to transmit OSC over TCP. TCP/IP is a stream-based protocol (like the serial-line used by [comport]), whereas OSC is a packet-based protocol. to transmit packets over a data stream, you must somehow packetize it; SLIP is the suggested format for doing that.
OSC itself just provides some convenience, it can be more efficient or not, depending on the message type. If you're just sending a single number, then FUDI* might make more sense. The difference might be neglectible, though.
FUDI takes 1 to 9 bytes to transmit a single float, OSC always takes exactly 4 bytes.
OSC transmits the float with full precision, whereas FUDI will truncate and whatnot.
For sending big lists of filenames I'd definitely go for TCP. Unfortunately, not all programs can handle OSC over TCP...
UDP-packets are limited in size (maximum 65536 bytes). so if you are sending large amounts of data, make sure that a single message doesn't exceed this size. (e.g. use multiple messages)
speaking of filenames: if you want to transmit strings/symbols with spaces (filenames on w32), OSC is certainly the better protocol (FUDI will split on the space).
IIRC the iemnet objects are threaded (also true for the mrpeach net objects?)
both are threaded. but iemnet uses a single worker thread to send the data, whereas mrpeach/net spins up a separate thread for each message.
afaict, this makes iemnet perform much better when dealing with large amounts of data. e.g. you can use it to saturate a 100MBit connection without audio dropouts (that is: without dropouts from the transmission itself; doing anything with that data will most likely clog your CPU). at least IIRC (i'm pretty sure about being able to saturate the connection; less sure about now audio dropouts)
mrpeach/net should block less than the built-in object, but in theory it might still block when spinning up to many threads. also mrpeach/net is prone to race-conditions, where one sending thread can overtake another sending thread (so the order of data arrival is not guaranteed). obviously mrpeach/net doesn't always exihibit that problem (else nobody would use it), but iirc i was able to trigger that behaviour in a lab situtation.
fgsdr IOhannes
On Mit, 2017-02-22 at 15:41 +0100, IOhannes m zmoelnig wrote:
mrpeach/net should block less than the built-in object, but in theory it might still block when spinning up to many threads. also mrpeach/net is prone to race-conditions, where one sending thread can overtake another sending thread (so the order of data arrival is not guaranteed). obviously mrpeach/net doesn't always exihibit that problem (else nobody would use it), but iirc i was able to trigger that behaviour in a lab situtation.
netpd - as an example of a non-lab situation - does trigger such problems with mpreach/net. Last time I checked, it presented incoming data as lists which suggests that it uses some auto-magic internal delimiting function, but it does not, it relies on pure chance. It's a misconception that the author refuses to address.
As far as I can tell, mrpeach/net suffers issues that iemnet does not. I don't see any advantage in using mrpeach/net besides the fact that Pd-l2ork / Purr Data - due to their Pd-extended heritage - come with mrpeach and not with iemnet.
Roman
(so the order of data arrival is guaranteed).
Well this is a design feature of UDP: there is no guarantee of whether packets are going to be received or in what order. If you use UDP, you MUST write your program in such a way that it is resilient to data loss and data order. If you don't, then you may encounter problems later down the line, when you are in less than ideal conditions. This said, it seems that [mrpeach/net] is designed in such a way that out-of-order delivery occurs more often than with other systems. Good to test the resiliency of your system. My brief experience with net objects (I could be wrong, but this is what I remember): [netreceive] / [netsend]: they do the socket job in the audio thread. This gives the following deterministic behaviour: the message is written to the socket before the audio callback is performed. What it does not give is any deterministic guarantee about when the packet is going to go out of your interface or be delivered. So given the latter, I am not sure why the former matters. [iemnet/udpsend] / [iemnet/updreceive]: threaded, for [udpsend] the packets are stored in memory from the audio thread. A worker thread reads them and writes them to the socket. Issue is the audio thread uses malloc() to store the stash the values in memory, so it may occasionally hang while waiting for the kernel to provide more memory. [mrpeach/net] have not looked at the code in person, but it has been mentioned here that it uses multiple working threads. If threads are created within the audio thread (as opposed to using a fixed pool of workers that get "activated" from the audio thread), then this also will occasionally hang while waiting for the kernel. None of the approaches above is workable on the platform I am working on (Bela), as - running under Xenomai - the usual constraints that apply to audio programming (no I/O, no allocation, no creating threads in the audio thread) are even more strict (i.e.: you REALLY need to follow these principles).My tentative approach was to turn [netreceive] into a threaded object, using a lock-free queue beween the threads (the one provided by libpd), using ifdefs to reuse most of the existing vanilla code. https://github.com/giuliomoro/pure-data/commits/Bela-net I am not quite happy with it yet: the code looks like a mess with all the ifdefs, and [netsend] is not working atm, but [netreceive] now can be safely used. I guess it would be better if I were to package it as an external, removing the ifdefs. Giulio
From: Roman Haefeli <reduzent@gmail.com>
To: pd-list@lists.iem.at Sent: Wednesday, 22 February 2017, 15:19 Subject: Re: [PD] netsend/netreceive questions ...
On Mit, 2017-02-22 at 15:41 +0100, IOhannes m zmoelnig wrote:
mrpeach/net should block less than the built-in object, but in theory it might still block when spinning up to many threads. also mrpeach/net is prone to race-conditions, where one sending thread can overtake another sending thread (so the order of data arrival is not guaranteed). obviously mrpeach/net doesn't always exihibit that problem (else nobody would use it), but iirc i was able to trigger that behaviour in a lab situtation.
netpd - as an example of a non-lab situation - does trigger such problems with mpreach/net. Last time I checked, it presented incoming data as lists which suggests that it uses some auto-magic internal delimiting function, but it does not, it relies on pure chance. It's a misconception that the author refuses to address.
As far as I can tell, mrpeach/net suffers issues that iemnet does not. I don't see any advantage in using mrpeach/net besides the fact that Pd-l2ork / Purr Data - due to their Pd-extended heritage - come with mrpeach and not with iemnet.
Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
SLIP-encoding is the only proper way to transmit OSC over TCP.
thanks! didn't know that. makes sense now.
Gesendet: Mittwoch, 22. Februar 2017 um 15:41 Uhr Von: "IOhannes m zmoelnig" zmoelnig@iem.at An: pd-list@lists.iem.at Betreff: Re: [PD] netsend/netreceive questions ...
On 2017-02-22 15:16, Christof Ressi wrote:
OSC is just a way to format your data and is independend from the actual protocol you use for transmitting the data. Most of the time you'll find OSC over UDP (e.g. [packOSC] -> [netsend -u -b] etc.) but it can also be TCP ([packOSC] -> [netsend -b])
no, this is broken by design.
or SLIP for sending over a serial connection ([packOSC] -> [mrpeach/slipenc] -> [comport]). I've once worked with an Ion lighting console which expected SLIP encoded OSC over TCP (wtf!).
SLIP-encoding is the only proper way to transmit OSC over TCP. TCP/IP is a stream-based protocol (like the serial-line used by [comport]), whereas OSC is a packet-based protocol. to transmit packets over a data stream, you must somehow packetize it; SLIP is the suggested format for doing that.
OSC itself just provides some convenience, it can be more efficient or not, depending on the message type. If you're just sending a single number, then FUDI* might make more sense. The difference might be neglectible, though.
FUDI takes 1 to 9 bytes to transmit a single float, OSC always takes exactly 4 bytes.
OSC transmits the float with full precision, whereas FUDI will truncate and whatnot.
For sending big lists of filenames I'd definitely go for TCP. Unfortunately, not all programs can handle OSC over TCP...
UDP-packets are limited in size (maximum 65536 bytes). so if you are sending large amounts of data, make sure that a single message doesn't exceed this size. (e.g. use multiple messages)
speaking of filenames: if you want to transmit strings/symbols with spaces (filenames on w32), OSC is certainly the better protocol (FUDI will split on the space).
IIRC the iemnet objects are threaded (also true for the mrpeach net objects?)
both are threaded. but iemnet uses a single worker thread to send the data, whereas mrpeach/net spins up a separate thread for each message.
afaict, this makes iemnet perform much better when dealing with large amounts of data. e.g. you can use it to saturate a 100MBit connection without audio dropouts (that is: without dropouts from the transmission itself; doing anything with that data will most likely clog your CPU). at least IIRC (i'm pretty sure about being able to saturate the connection; less sure about now audio dropouts)
mrpeach/net should block less than the built-in object, but in theory it might still block when spinning up to many threads. also mrpeach/net is prone to race-conditions, where one sending thread can overtake another sending thread (so the order of data arrival is not guaranteed). obviously mrpeach/net doesn't always exihibit that problem (else nobody would use it), but iirc i was able to trigger that behaviour in a lab situtation.
fgsdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Mit, 2017-02-22 at 15:16 +0100, Christof Ressi wrote:
maybe it's better to use [OSC] for the latter and [netsend] for single floats (f.e. to send a time-synch message) ?
OSC is just a way to format your data and is independend from the actual protocol you use for transmitting the data. Most of the time you'll find OSC over UDP (e.g. [packOSC] -> [netsend -u -b] etc.) but it can also be TCP ([packOSC] -> [netsend -b])
No, that's not a workable solution, even if it might seem to work for you. Since TCP is a stream oriented protocol and doesn't have any notion of packets, you need to implement some mechanism to delimit packets. OSC 1.0 proposed a 4-byte header to be prepended to each OSC packet that reflects the packet size. However, once the reading side gets it wrong, it will never able to the find the correct start of a packet again. That's why OSC 1.1 proposed SLIP encoding for serial / stream-oriented transports.
or SLIP for sending over a serial connection ([packOSC] -> [mrpeach/slipenc] -> [comport]). I've once worked with an Ion lighting console which expected SLIP encoded OSC over TCP (wtf!).
Absolutely no WTF. See above.
OSC itself just provides some convenience, it can be more efficient or not, depending on the message type. If you're just sending a single number, then FUDI* might make more sense. The difference might be neglectible, though.
I don't see a reason for OSC when both sides are Pd. FUDI isn't as common as OSC, though.
Roman
No, that's not a workable solution, even if it might seem to work for you. Since TCP is a stream oriented protocol and doesn't have any notion of packets, you need to implement some mechanism to delimit packets.
That's correct! I was just wondering, why I thought that would work... I checked again and it turned out I was using [mrpeach/tcpsend] and [mrpeach/tcpreceive]. With these objects I can reliably send and receive OSC data. The help file explicitly states:
"tcpsend sends bytes over a tcp connection. Used in conjunction with packOSC will send OSC over tcp".
OTOH, the iemnet objects with the same name don't support that. And [netsend -b]/[netreceive -b] don't either, as you correctly pointed out. I guess, the mrpeach tcp objects use some kind of protocol internally to delimit messages... interesting...
Gesendet: Mittwoch, 22. Februar 2017 um 16:08 Uhr Von: "Roman Haefeli" reduzent@gmail.com An: pd-list@lists.iem.at Betreff: Re: [PD] netsend/netreceive questions ...
On Mit, 2017-02-22 at 15:16 +0100, Christof Ressi wrote:
maybe it's better to use [OSC] for the latter and [netsend] for single floats (f.e. to send a time-synch message) ?
OSC is just a way to format your data and is independend from the actual protocol you use for transmitting the data. Most of the time you'll find OSC over UDP (e.g. [packOSC] -> [netsend -u -b] etc.) but it can also be TCP ([packOSC] -> [netsend -b])
No, that's not a workable solution, even if it might seem to work for you. Since TCP is a stream oriented protocol and doesn't have any notion of packets, you need to implement some mechanism to delimit packets. OSC 1.0 proposed a 4-byte header to be prepended to each OSC packet that reflects the packet size. However, once the reading side gets it wrong, it will never able to the find the correct start of a packet again. That's why OSC 1.1 proposed SLIP encoding for serial / stream-oriented transports.
or SLIP for sending over a serial connection ([packOSC] -> [mrpeach/slipenc] -> [comport]). I've once worked with an Ion lighting console which expected SLIP encoded OSC over TCP (wtf!).
Absolutely no WTF. See above.
OSC itself just provides some convenience, it can be more efficient or not, depending on the message type. If you're just sending a single number, then FUDI* might make more sense. The difference might be neglectible, though.
I don't see a reason for OSC when both sides are Pd. FUDI isn't as common as OSC, though.
Roman_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 02/22/2017 06:56 PM, Christof Ressi wrote:
"tcpsend sends bytes over a tcp connection.
which is correct.
Used in conjunction with packOSC will send OSC over tcp".
which is only half-correct.
it is only guaranteed to work if you use SLIP.
it *might* happen to work if you messages are small enough so they don't get fragmented during delivery (i think the main problem is, that most tests are done with smallish packets over local connections, where the chances are low that fragmentation will occur).
the problem is, that if you rely on this to work, you are relying on things outside of your control (the TCP/IP stack of all the network devices involved in transmitting your data). you could as well use UDP and hope that no collisions and congestion will happen.
the only way to make it work reliably is by adding an extra packetizing layer. the OSC specs recommend to use SLIP.
gfmasdr IOhannes
On Mit, 2017-02-22 at 18:56 +0100, Christof Ressi wrote:
No, that's not a workable solution, even if it might seem to work for you. Since TCP is a stream oriented protocol and doesn't have any notion of packets, you need to implement some mechanism to delimit packets.
That's correct! I was just wondering, why I thought that would work... I checked again and it turned out I was using [mrpeach/tcpsend] and [mrpeach/tcpreceive]. With these objects I can reliably send and receive OSC data. The help file explicitly states:
"tcpsend sends bytes over a tcp connection. Used in conjunction with packOSC will send OSC over tcp".
OTOH, the iemnet objects with the same name don't support that. And [netsend -b]/[netreceive -b] don't either, as you correctly pointed out. I guess, the mrpeach tcp objects use some kind of protocol internally to delimit messages... interesting...
I don't think so. Even with a TCP connection being a stream, TCP is transported by IP packets. I believe what happens is that mrpeach/net objects output each incoming chunk as a whole, or spoken from Pd view as list. There is no guarantee whatsoever that those chunks are received in the same configuration as they have been sent. While it seems to work when you test on localhost, it might miserably fail with some other network setup. TCP only guarantees that byte x[n+1] follows byte x[n], but not that one chunk of data is also received as one chunk of data. It might be split into two chunks, or two chunks are received as one. iemnet's tcp* objects make this nature of TCP explicitly clear by outputting only single bytes, a.k.a stream of bytes.
Roman
I believe what happens is that mrpeach/net objects output each incoming chunk as a whole, or spoken from Pd view as list.
...
iemnet's tcp* objects make this nature of TCP explicitly clear by outputting only single bytes, a.k.a stream of bytes.
You're absolutely right!
The help patch for mrpeach/tcpsend is really misleading because instead of [packOSC] it should rather mention [packOSCstream] (which is just an abstraction with [packOSC]+[slipenc]). It really managed to fool me into thinking that OSC + TCP is possible... although via localhost, I have to send OSC messages with more than 4000 float args to make it break. Anyway, I think I never actually used OSC + TCP without SLIP encoding in a project (otherwise I would have gotten occasional errors from [unpackOSC]) - and I certainly won't in the future :-).
Gesendet: Mittwoch, 22. Februar 2017 um 23:11 Uhr Von: "Roman Haefeli" reduzent@gmail.com An: pd-list@lists.iem.at Betreff: Re: [PD] netsend/netreceive questions ...
On Mit, 2017-02-22 at 18:56 +0100, Christof Ressi wrote:
No, that's not a workable solution, even if it might seem to work for you. Since TCP is a stream oriented protocol and doesn't have any notion of packets, you need to implement some mechanism to delimit packets.
That's correct! I was just wondering, why I thought that would work... I checked again and it turned out I was using [mrpeach/tcpsend] and [mrpeach/tcpreceive]. With these objects I can reliably send and receive OSC data. The help file explicitly states:
"tcpsend sends bytes over a tcp connection. Used in conjunction with packOSC will send OSC over tcp".
OTOH, the iemnet objects with the same name don't support that. And [netsend -b]/[netreceive -b] don't either, as you correctly pointed out. I guess, the mrpeach tcp objects use some kind of protocol internally to delimit messages... interesting...
I don't think so. Even with a TCP connection being a stream, TCP is transported by IP packets. I believe what happens is that mrpeach/net objects output each incoming chunk as a whole, or spoken from Pd view as list. There is no guarantee whatsoever that those chunks are received in the same configuration as they have been sent. While it seems to work when you test on localhost, it might miserably fail with some other network setup. TCP only guarantees that byte x[n+1] follows byte x[n], but not that one chunk of data is also received as one chunk of data. It might be split into two chunks, or two chunks are received as one. iemnet's tcp* objects make this nature of TCP explicitly clear by outputting only single bytes, a.k.a stream of bytes.
Roman_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Wed, Feb 22, 2017 at 6:26 PM, Christof Ressi christof.ressi@gmx.at wrote:
I believe what happens is that mrpeach/net objects output each incoming
chunk as a whole, or spoken from Pd view as list. ...
iemnet's tcp* objects make this nature of TCP explicitly clear by outputting only single bytes, a.k.a stream of bytes.
You're absolutely right!
The help patch for mrpeach/tcpsend is really misleading because instead of [packOSC] it should rather mention [packOSCstream] (which is just an abstraction with [packOSC]+[slipenc]). It really managed to fool me into thinking that OSC + TCP is possible... although via localhost, I have to send OSC messages with more than 4000 float args to make it break. Anyway, I think I never actually used OSC + TCP without SLIP encoding in a project (otherwise I would have gotten occasional errors from [unpackOSC]) - and I certainly won't in the future :-).
TCP is supposed to deliver its packets in order, even if they arrive at
the interface out of order. So [tcpclient] or [tcpreceive] will always output packets in order. TCP may also wait for more data before sending a packet, so you could have more than one OSC message in a TCP packet if you're sending rapidfire to the same port. Right now, [unpackOSC] only accepts lists, which must be complete OSC packets. I could make it accept lists, or single floats, with no output until it has a complete packet or a definite error, although [slipdec] already does this with less overhead (it doesn't need to keep parsing a packet until it's complete). A problem with OSC is that the correct packet length is unknown until after the typetag string has been read in, and oldstyle OSC messages with no typetags are completely indeterminate.
Martin
https://lists.puredata.info/listinfo/pd-list https://lists.puredata.info/listinfo/pd-list
On 2017-02-23 02:39, Martin Peach wrote:
Right now, [unpackOSC] only accepts lists, which must be complete OSC packets. I could make it accept lists,
i think that [unpackOSC] behaves as it should. esp. i don't think that it should attempt to form packets out of a bytestream by itself.
this is clearly the task of a lower-level protocol: the original OSC-1.0 specs didn't mention any means to do the packetizing on stream-based protocols (most likely an omission), only later SLIP was *recommended* (rather than *mandated*) [citation needed]. afaik, there are still implementations out there that do not use SLIP for packetizing (but rather prefix each OSC-packet with a 4 byte length field [citation needed]).
or single floats, with no output until it has a complete packet or a definite erro
the problem with this is, that there is no way to know when an OSC *bundle* (rather than a message) has finished (if you don't have a end-of-package marker). so if you received a time-tagged bundle with two messages A & B, and immediately after that a plain message C, unpackOSC wouldn't have a way to auto-sense the difference between B and C (either B would be output as "immediate" without a timetag, or C would be timetagged; both are wrong)
fgamf IOhannes
https://en.wikipedia.org/wiki/Binary_Golay_code
On Thu, Feb 23, 2017 at 3:10 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2017-02-23 02:39, Martin Peach wrote:
Right now, [unpackOSC] only accepts lists, which must be complete OSC packets. I could make it accept lists,
i think that [unpackOSC] behaves as it should. esp. i don't think that it should attempt to form packets out of a bytestream by itself.
this is clearly the task of a lower-level protocol: the original OSC-1.0 specs didn't mention any means to do the packetizing on stream-based protocols (most likely an omission), only later SLIP was *recommended* (rather than *mandated*) [citation needed]. afaik, there are still implementations out there that do not use SLIP for packetizing (but rather prefix each OSC-packet with a 4 byte length field [citation needed]).
or single floats, with no output until it has a complete packet or a definite erro
the problem with this is, that there is no way to know when an OSC *bundle* (rather than a message) has finished (if you don't have a end-of-package marker). so if you received a time-tagged bundle with two messages A & B, and immediately after that a plain message C, unpackOSC wouldn't have a way to auto-sense the difference between B and C (either B would be output as "immediate" without a timetag, or C would be timetagged; both are wrong)
fgamf IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
On Mit, 2017-02-22 at 11:57 +0100, oliver wrote:
is it better to open more than one port (or is it a socket ?) for this purpose or will that make things worse ?
I don't think that opening more than one socket has any positive impact on data throughput or latency. I'd stick with one connection since it makes things a lot easier when everything sent is received in the same order reliably.
Roman
-
Billy Stiltner -
Christof Ressi -
Giulio Moro -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jérôme Abel -
Martin Peach -
oliver -
Roman Haefeli -
zmoelnig＠iem.at