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.
) {0xEF 0xBB 0xBF}
, which then is rejected by [route].
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 sequence0xEF,0xBB,0xBF
. A text editor or web browser misinterpreting the text as ISO-8859-1 or CP1252 will display the characters
for this.
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