Patrice Colet wrote:
Hello IOhannes,
good to see that it helped you
From what I've understood it wouldn't be possible anyway to use ascii codes (I didn't understand how to use functions provided by the moocow patch that is supposed to convert ascii code for [textXd] class objects,
it's not that complicated. basically it is about enumeration of glyphs.
like in the ascii table you have a glyph "a" which has the number "97". this basically means that you can represent the string "aaa" as a sequence of numbers "97 97 97" and this is exactly what moocow's pdstring library does: it converts a symbol "bla" into a list of numbers "98 108 97"
this has several advantages: 1. pd normally does not use "strings" but only "symbols" which are all stored for later use; each symbol is created the first time it is used and never freed again (if you have a list "aaa bbb aaa", pd will create 2 symbols for you "aaa" and "bbb"; internally the list will be stored as 'symbol#1 symbol#2 symbol#1' (or similar); this is good as it is fast; this is bad if you are dealing with real text that has loads of different "words", as you can run out of memory... (usually this is not a big problem; but moocow is a linguist and does analysis of big text corpora...) (lists of) numbers are more dynamic and get freed properly after use. 2. since we express glyphs as numbers in an enumeration and there are plenty of numbers we can express a lot of glyphs. (more than it is possible with a keyboard). in Gem you can address about 65535 glpyhs in this way. in standardized fonts these usually map to the first 2^16 unicode glyphs. e.g. "∈" ("is element of") is defined as unicode 8712. so you can send a message "string 105 32 8712 32 87" which should render to "i ∈ N" (if your font has all the necessary characters)
mfg.asdr IOhannes