[PD] check mail with pd ?
Jonathan Wilkes
jancsika at yahoo.com
Sat Feb 8 07:10:11 CET 2014
On 02/06/2014 01:53 AM, Chris McCormick wrote:
> On 06/02/14 06:29, puredata at 11h11.com wrote:
>> but pd is not really good with strings afaik
> Maybe soon:
>
> https://sourceforge.net/p/pure-data/pure-data/ci/8a02332a5fb68edc2899e2f13513c77f0796d21b/
>
> https://sourceforge.net/p/pure-data/pure-data/ci/49ffcf8ba5cdde7660e82f1e190fcee7c6fa5627/
>
> :)
One of the reasons (I think) the string manipulation libs in Pd extended
haven't caught on is because they seem to force users to care directly
about character codes. If I want to pass the string "hello{world}"
around in Pd, I should not have to know the codes for curly braces just
to create that string in an object box.
To work, this will require a new set of GUI classes that allow the user
to type strings that get saved underneath as character codes, as well as
display lists of character codes as a string in the patch. I don't know
any externals that do this, but it shouldn't be hard if you're sending
the text to the GUI as floats. Also, you need i/o classes to read from
and write to files without having to pass through lists of symbols and
floats as intermediaries. Otherwise, you will lose data on the read.
Finally, you can't leverage any of the extant symbol manipulation tools,
because then you run into symbol-table growth, dollsym
substitutions/escapes, and all the other problems that I assume are the
reason for introducing lists of character codes. Otherwise you're just
pushing the current problems users have with symbols to the edges of the
new string library.
I understand the desire for this approach, and it's probably less work
than making symbols deallocatable. But if the user has to stare at
character codes just to get around the limitations of symbol atoms,
they'll probably just use symbol atoms and work within Pd's current
limitations for string processing.
-Jonathan
More information about the Pd-list
mailing list