hi,
i want to minimize the data stream send through an UDP connection
by sending 'coded' bytes; the receiver(s) will decode them.
i'm unsure about the meaning of 'raw data' in the helpfile of [udpsend].
does [1 2 3( represent bytes with the octal vaue 001 002 003,
or the integers 1 2 3 which will be 'translated' into the octal bytes 061 062 063 ?
it's a bit ambigious for me, especially comparing the helpfiles of [iemnet/udpsend] and [mrpeach/udpsend].
with the iemnet version one cannot send files directly, it's necessary to use [binfile].
does it mean that the mrpeach version recognizes that a file is used for input;
wow that [binfile] is embedded in its [udpsend]?
rolf
Am 24. Mai 2020 13:31:53 MESZ schrieb rolfm@dds.nl:
hi,
i want to minimize the data stream send through an UDP connection
by sending 'coded' bytes; the receiver(s) will decode them.
i'm unsure about the meaning of 'raw data' in the helpfile of [udpsend].
does [1 2 3( represent bytes with the octal vaue 001 002 003,
yes (although i would habe chosen a hexadecimal representation, rather than octal)
or the integers 1 2 3 which will be 'translated' into the octal bytes 061 062 063 ?
no. that's not very "raw", is it?
it's also what you get when using the vanilla [netsend]
in "binary" mode.
does it mean that the mrpeach version recognizes that a file is used for input;
iirc, you can tell it to read data from a file (no recognition magic involved).
mfg.hft.fsl IOhannes
Hi,
the meaning of 'raw data'
It's bytes.
does [1 2 3( represent bytes with the octal vaue 001 002 003,
yes
does it mean that the mrpeach version recognizes that a file is used for input;
yes
BTW, I strongly recommend using [iemnet] over [mrpeach]'s netobjects! The former has a much better threading model and gets more frequent updates.
Christof
On 24.05.2020 13:31, rolfm@dds.nl wrote:
hi,
i want to minimize the data stream send through an UDP connection
by sending 'coded' bytes; the receiver(s) will decode them.
i'm unsure about the meaning of 'raw data' in the helpfile of [udpsend].
does [1 2 3( represent bytes with the octal vaue 001 002 003,
or the integers 1 2 3 which will be 'translated' into the octal bytes 061 062 063 ?
it's a bit ambigious for me, especially comparing the helpfiles of [iemnet/udpsend] and [mrpeach/udpsend].
with the iemnet version one cannot send files directly, it's necessary to use [binfile].
does it mean that the mrpeach version recognizes that a file is used for input;
wow that [binfile] is embedded in its [udpsend]?
rolf
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Sun, May 24, 2020 at 8:07 AM Christof Ressi info@christofressi.com wrote:
BTW, I strongly recommend using [iemnet] over [mrpeach]'s netobjects! The former has a much better threading model and gets more frequent updates.
I find the mrpeach net objects work just fine for a simple setup. The problems seem to arise when lots of connections are being made and broken at high speed. The patches required to do this are apparently so complex that noone has yet posted an example that will crash the object(s), which makes it hard to debug.
Martin
Hi,
ok, I checked again, looks like [mrpeach/udpsend] and [mrpeach/tcpsend] is actually single-threaded. Not a deal-breaker, but worth noting. The real problems I see in [tcpclient], but I'll write you off-list.
BTW, I still heavily use and recommend your other stuff like the OSC objects, [midifile] and the SLIP objects, so no offense! :-)
Christof
On 24.05.2020 16:08, Martin Peach wrote:
On Sun, May 24, 2020 at 8:07 AM Christof Ressi info@christofressi.com wrote:
BTW, I strongly recommend using [iemnet] over [mrpeach]'s netobjects! The former has a much better threading model and gets more frequent updates.
I find the mrpeach net objects work just fine for a simple setup. The problems seem to arise when lots of connections are being made and broken at high speed. The patches required to do this are apparently so complex that noone has yet posted an example that will crash the object(s), which makes it hard to debug.
Martin
If it's a question of efficiency, to be really really sure, maybe read the UDP packets off the wire/port with tcpdump, which despite its name is quite happy to capture and show UDP too.
tcpdump -i lo udp port 9000 -vv -X
You'll see any byte order munging or padding due to some NIC/network stack setups. On my Debian systems it is indeed plain bytes.
a.
On Sun, May 24, 2020 at 01:31:53PM +0200, rolfm@dds.nl wrote:
hi,
i want to minimize the data stream send through an UDP connection
by sending 'coded' bytes; the receiver(s) will decode them.
i'm unsure about the meaning of 'raw data' in the helpfile of [udpsend].
does [1 2 3( represent bytes with the octal vaue 001 002 003,
or the integers 1 2 3 which will be 'translated' into the octal bytes 061 062 063 ?
it's a bit ambigious for me, especially comparing the helpfiles of [iemnet/udpsend] and [mrpeach/udpsend].
with the iemnet version one cannot send files directly, it's necessary to use [binfile].
does it mean that the mrpeach version recognizes that a file is used for input;
wow that [binfile] is embedded in its [udpsend]?
rolf
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
thanks Andy,
in my case i'm sending to NodeMCU's (a breakoutboard with ESP8266 chip). so..
rolf
Andy Farnell schreef op 24-05-2020 14:26:
If it's a question of efficiency, to be really really sure, maybe read the UDP packets off the wire/port with tcpdump, which despite its name is quite happy to capture and show UDP too.
tcpdump -i lo udp port 9000 -vv -X
You'll see any byte order munging or padding due to some NIC/network stack setups. On my Debian systems it is indeed plain bytes.
a.
On Sun, May 24, 2020 at 01:31:53PM +0200, rolfm@dds.nl wrote:
hi,
i want to minimize the data stream send through an UDP connection
by sending 'coded' bytes; the receiver(s) will decode them.
i'm unsure about the meaning of 'raw data' in the helpfile of [udpsend].
does [1 2 3( represent bytes with the octal vaue 001 002 003,
or the integers 1 2 3 which will be 'translated' into the octal bytes 061 062 063 ?
it's a bit ambigious for me, especially comparing the helpfiles of [iemnet/udpsend] and [mrpeach/udpsend].
with the iemnet version one cannot send files directly, it's necessary to use [binfile].
does it mean that the mrpeach version recognizes that a file is used for input;
wow that [binfile] is embedded in its [udpsend]?
rolf
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 24.05.20 16:07, rolfm@dds.nl wrote:
thanks Andy,
in my case i'm sending to NodeMCU's (a breakoutboard with ESP8266 chip). so..
not a problem, you can listen at any node in the ethernet connection.
just change the -i parameter to the interface running the connection to your board.
get the list of interfaces with ifconfig or ip addr.
rolf
Andy Farnell schreef op 24-05-2020 14:26:
If it's a question of efficiency, to be really really sure, maybe read the UDP packets off the wire/port with tcpdump, which despite its name is quite happy to capture and show UDP too.
tcpdump -i lo udp port 9000 -vv -X
You'll see any byte order munging or padding due to some NIC/network stack setups. On my Debian systems it is indeed plain bytes.
a.
On Sun, May 24, 2020 at 01:31:53PM +0200, rolfm@dds.nl wrote:
hi,
i want to minimize the data stream send through an UDP connection
by sending 'coded' bytes; the receiver(s) will decode them.
i'm unsure about the meaning of 'raw data' in the helpfile of [udpsend].
does [1 2 3( represent bytes with the octal vaue 001 002 003,
or the integers 1 2 3 which will be 'translated' into the octal bytes 061 062 063 ?
it's a bit ambigious for me, especially comparing the helpfiles of [iemnet/udpsend] and [mrpeach/udpsend].
with the iemnet version one cannot send files directly, it's necessary to use [binfile].
does it mean that the mrpeach version recognizes that a file is used for input;
wow that [binfile] is embedded in its [udpsend]?
rolf
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Sun, May 24, 2020 at 10:09 AM rolfm@dds.nl wrote:
thanks Andy,
in my case i'm sending to NodeMCU's (a breakoutboard with ESP8266 chip). so..
I have used it the other way, sending sensor data from an ESP8266 to a Pd patch. Using UDP I was getting about 30% dropped packets, so I switched to TCP and now I get less than 1% packet loss. Since UDP is send and forget and WiFi is noisy, while TCP retries until the packet gets through (mostly). Since I have only one connection going, the threading stuff is irrelevant.
Martin