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.