[PD] check mail with pd ?

[Martin Peach]

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 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
>>>
>>>
>>> _______________________________________________
>>> Pd-list at iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>>
>>
>>
>> _______________________________________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>