[PD] check mail with pd ?

[Jonathan Wilkes]

On 02/08/2014 01:40 PM, Martin Peach wrote:
> 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.

It looks more like a prototype for a string implementation.  I'm not 
even able to do this:

[bng]
|
[str hello_world]
|
[print]

Additionally, moving the cord-inspector over the wire connecting 
displays nothing.  Those are just the first two things I tried to do as 
a user, to view a core atom type which most of the time will be holding 
readable text.

It may seem trivial to get those two things to work, but the point is 
that someone has to do it, for every single internal and external class 
which already understands and can manipulate the one string atom but 
doesn't understand the better string atom.

[str hello 32 world] isn't much fun, either.  But it's hard to improve 
that without the ability for the object box to leave the user input 
unparsed.

> 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.

I don't understand this.  If you take nearly every string manipulation I 
did in tcl for the search-plugin and put it in Pd, you are either a) 
unrolling several commands in nested square brackets and laying them out 
vertically (or inside an abstraction) or b) putting a tcl line of code 
in a box and connecting its output to the next line of tcl code in a box 
with a wire.  If "a" is troublesome to patch and read in Pd then it was 
hard to write and read in tcl.

There are of course way more complex examples of string manipulation, 
but Pd's tools don't have to be perfect to be useful.

> 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.

Read in transcript of congressional testimony on NSA surveillance.
Split into one string for each line.
Read one line every second.
If a line contains the word "terrorism" make a sound.
User takes a drink.

Totally useful. :)

What is it about boxes connected with lines that you think makes this 
difficult?

-Jonathan

>
> 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
>>
>>
>