Thanks Roman and Antoine--looks like you both go the answer at the same time!


This explanation makes sense, however I am using non ASCII characters in the textfile (not the one attached, but the one I'm working on), so I guess that I need the BOM to stay there. I've rigged up a system which will split the dead characters off beginning of the first term, so it's working for now.


Would this be considered normal behavior for PD, or should I file a bug report?

From: Antoine Rousseau <antoine@metalu.net>
Sent: 07 February 2017 08:11
To: Liam Goodacre
Cc: PD list
Subject: Re: [PD] un-routable output from [text get]
 
Your text file has been UTF8 encoded, and starts with a "byte order mark" (BOM) {0xEF 0xBB 0xBF}, which then is rejected by [route].

see https://en.wikipedia.org/wiki/Byte_order_mark#UTF-8 :
en.wikipedia.org
The byte order mark (BOM) is a Unicode character, U+FEFF BYTE ORDER MARK (BOM), whose appearance as a magic number at the start of a text stream can signal several ...


The UTF-8 representation of the BOM is the byte sequence 0xEF,0xBB,0xBF. A text editor or web browser misinterpreting the text as ISO-8859-1 or CP1252 will display the characters  for this.




2017-02-07 8:34 GMT+01:00 Liam Goodacre <liamg_uw@hotmail.com>:

I'm getting some strange behavior when reading a .txt file with [text define], where the output from [text get] isn't routeable like a normal list. See the attached file for an example. Do other users experience the same thing?


[text fromsymbol] reveals that there are some extended ASCII  characters junking around in front of the problematic term. Is PD accidentally reading some meta-data from the text file?


Currently, it only seems to be happening on the first line of the file. I think I remember having the same problems throughout a textfile, although I can't replicate this now.


Any suggestions?


_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list