receiving a string from processing over network via upd and into oscdecoder.
the strings containing umlauts(ä,ö,ü,…) are encoded wrong and don’t show up. strings without umlauts are o.k. how do i have to encode with asstring and asraw to make the oscdecoder work? example is attached.
any idea?
kind regards A
osc_encoder_von_falk.v4p (13.8 kB)
forgot to say: the string coming (from processing) is bundled and sent from a macintosh. receiver is windows xp. duno if that is important for encoding…
it shouldn’t be necessary to do that. if you connect the output of UDP (Network Server) directly to the input of OSCDecoder (Network) you still get the problem?
hi joreg, even directly connected osc decoder does not display strings with umlauts. the output is always empty. because of that i tried to use the raw nodes in between (see the attached patch).
what if the umlauts in the string coming from processing via osc are broken? it is possible they are replaced by question marks. could that be the problem?
The problem is OSC itself… it uses ASCII character encoding and thus doesn’t support german umlauts or most other language specific special characters.
OSC-String: A sequence of non-null ASCII characters followed by a null, followed by
0-3 additional null characters to make the total number of bits a multiple
of 32.
http://cnmat.berkeley.edu/user/adrian_freed/blog/2008/10/06/open_sound_control_1_1_specification
indeed as foaster said osc is ascii only. but vvvv interprets strings as utf8 (which is ascii compatible). so sending/receiving utf8 strings from/to vvvv via osc works.
does sending umlauts from/to processing work?
o.k. i am sending the string from processing with iso 8859-1 encoding (strangely utf-8 does not work). so i encode the raw string in vvvv via the raw node with iso-8859-1 again(now i have the string with all the #etc… where the umlauts appear as quads/squares), then back to raw (encode system default) and into the oscdecoder node. voila, the text appears correct, only the umlauts show up as question marks.
the OSCDecoder will decode the byte sequence with an ascii encoding as defined by osc. you’ll therefor need to make sure that you do not send something different over the network than plain ascii. to achieve that you’ll need to encode the processing string to a byte sequence using an encoding of your choosing (utf-8 for example), feed that byte sequence to a base64 encoder which will return a string containing ascii characters only. send that one over the network.
on vvvv side, do as joreg said in his first post and connect the udp node directly to the osc decoder node. the osc decoder node should now return the base64 encoded strings. use the Decode (Raw Base64) node to turn that base64 encoded string into the original byte sequence and feed that to the AsString (Raw) node using the encoding you chose on the processing side (utf-8 in this example).
that should do the trick.
hi elias,
sounds good. now i use the base64 encoder on the processing side. thats fine. on the vvvv side i can’t use the Decode (Raw Base64) node cause i am on winxp with beta29.2 which does not include Decode (Raw…).
i installed vvvv_45beta30_x86 but it won’t start. crack exe says o.k. but vvvv freezes during the start process. hm…
i guess it works only with 64bit version on win7? can you confirm that or is there a way to use 64bit on win xp?
thanks, armin
shouldn’t have anything to do with x86 or x64. did you try beta30.2? otherwise search forum for startup issues or open up a new thread.
base64 nodes are only available in vvvv >= 30.
also i’d again suggest that if you managed to send the string as utf8 from processing all should be easier without the need for the base64 stuff…
beta 30.2 up and running. decode(raw base 64) shows up and running. still problems with utf-8 and umlauts. not solved yet. testing continues…
Hello armin,
it looks like that at vvvv side everything works ok. Processing sends umlauts just as umlauts, it doesn’t care that OSC understands only ASCII.
So maybe the solution in Processing is to get the bytes of the string (encoded as UTF-8) and then build the string from these bytes. Sounds longer than it is.
Here is the processing-sketch (v.1.5.1) and vvvv-patch (45beta30.2).
Works here.
Best,
Anton
Processing talks to vvvv over OSC (1.6 kB)
hi all,
i know: it is an old topic but maybe still interesting for some people ;)
in case you want to send a string with umlauts to other software than vvvv: you can try to make an html encoding in vvvv and html decoding on the reciever site!
greetz
christian