[PD-dev] pd 0.52-2 release plan

IOhannes m zmoelnig zmoelnig at iem.at
Mon Mar 28 10:29:29 CEST 2022


On 3/28/22 09:13, cyrille henry wrote:
>> you need a network analysing tool to see the difference. (I use 
>> wireshark)
> oh, well no. It was to early in the morning!
> pd~ did not use a socket, so you can't see anything with wireshark.

while the tool was wrong, the methodology was correct.

alexandre said:
 > I tried the flag and I couldn't really see any difference

how did you test? more specifically, how was your test patch designed to 
show a difference between ascii and binary mode?

both modes are designed to get the data from the parent process to the 
subprocess (and vice versa), so from a user perspective there shouldn't 
be *much* difference, if you just look at the messages on a patch level.

an example from the internet:
you can access both http://puredata.info and https://puredata.info - the 
two sites are equivalent, more: they are the same. (except that the 
browser might indicate that you are using an insecure connection (or 
not); but in pd~'s ASCII mode there is also a big fat '-ascii' flag in 
the [pd~] invocation indicating that you are using non-binary mode).
but that is only from a user's perspective.
if they are the same: why would anybody want https:// instead of http://?
because what the user does not see is that with https:// the data is 
transmitted encrypted, whereas with http:// it's transmitted as simple text.
so if you care for privacy, you should use https://.
but if things don't really work and you want to see which data is 
actually transmitted (and you think that the encryption part is not the 
problem), then you might launch a simple 'telnet' session that connects 
to your webserver and see what data it sends. it help's tremendously in 
debugging, if this data is not some encrypted binary blob, but just 
simple text.

similar for pd~.
the result will be *quite* the same (within limits), but you lose some 
capabilities only the binary transport can guarantee:
- higher transport speed (you don't really want to spend all those 
CPU-cycles you gained by using a 2nd Pd process on decoding the data)
- precision: textual representations of numbers will inherently lose 
some information - depending on the actual number (*some* numbers can be 
represented with the same precision in text and binary form). if you 
want your numbers to be bit-for-bit identical between you must use 
binary mode.¹

don't use '-ascii' unless you *know* that you need to.

 > Miller also said "/one should always use the default, binary
 > connection./" so I really don't know what to do here...

i'm not sure i can follow. how about just following the advice you got?


vmnasdr
IOhannes


¹ this also hints at a simple way to show a difference between the two 
transport modes. send a number to the subprocess where the binary and 
the textual representation differ noatbly. e.g. 1/3 (btw, this number 
cannot be represented precisely in both text and floating point). on the 
"other side" multiply that number by 3, which should give you roughly 1 
in both representations, but note how the result actually differs.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20220328/af32c208/attachment.sig>


More information about the Pd-dev mailing list