A few years ago I implemented a patch for strings in Pd that adds a string or blob type that allows (I think) for what you are describing. I believe it's still part of Pd extended, but Miller didn't like it for some reason. I prefer to manipulate strings in a another language as it just seems like a lot of work to make it happen with boxes and wires when you can just call string functions in a high level language. Kind of like building a Turing machine holes-in-paper-tape version of a program, it can be an interesting exercise but practically it's useless.
Martin
On 2014-02-08 03:14, Jonathan Wilkes wrote:
On 02/08/2014 01:26 AM, Martin Peach wrote:
You can manipulate strings in pdlua and only export the symbols you want; yes you need to learn lua but it's not very hard.
That's good practical advice for getting work done with strings atm. But it's irrelevant to getting decent string manipulation within Pd, meaning using boxes connected with wires.
The reason for wanting to do string manipulation within Pd is just as obvious as the question that I didn't have to ask and which you addressed after your semicolon.
-Jonathan
Martin
On 2014-02-08 01:10, Jonathan Wilkes wrote:
On 02/06/2014 01:53 AM, Chris McCormick wrote:
On 06/02/14 06:29, puredata@11h11.com wrote:
but pd is not really good with strings afaik
Maybe soon:
https://sourceforge.net/p/pure-data/pure-data/ci/8a02332a5fb68edc2899e2f1351...
https://sourceforge.net/p/pure-data/pure-data/ci/49ffcf8ba5cdde7660e82f1e190...
:)
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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list