He Charles,

I have just recently made this patch to format text with linebreaks and umlaute and display it letter by letter. Maybe a little chaotic but if you are interested:

cheers

-jonas

Am 18.02.2013 um 10:47 schrieb Charles Goyard:

Hi,

thanks !

I still have to figure some details, but it seems to do the trick.

I'll post my patch when it's done for future reference.

Hans-Christoph Steiner wrote:

...

I think the pdstring/moocow objects will do that for you, [any2bytes] in particular.

.hc

On 02/14/2013 01:59 PM, Charles Goyard wrote:

...

Hi,

I want to display the content of a textfile on Gem. I know text3d does linebreaks when it encounters "10" in a string message.

However, before patching this textfile-to-stringfortext3d, I wanted to know if anyone already did that and could share ?

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Hi,

i'm using coll, i must format the text file before using it, but works great. With a little script in bash it's easy format any text file.

Regards.

2013/2/19 Charles Goyard cg@fsck.fr

Hi,

almost there. But I don't know why, any2bytes converts my newlines (10) into spaces (32).

My input is like :

line1 line2 line3

So textfile returns the whole file at once, which is what I want.

Maybe mrpeach's binfile is more appropriate ?

Hans-Christoph Steiner wrote:

...

I think the pdstring/moocow objects will do that for you, [any2bytes] in particular.

...

I want to display the content of a textfile on Gem. I know text3d does linebreaks when it encounters "10" in a string message.

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2013-02-19 15:21, Charles Goyard wrote:

Hi,

almost there. But I don't know why, any2bytes converts my newlines (10) into spaces (32).

My input is like :

line1 line2 line3

So textfile returns the whole file at once, which is what I want.

[textfile] usually expects lines to be terminated by semicolons, e.g. line1; line2; line3;

if your file does not use semicolons as line delimiters, [textfile] will ignore CR/LF/CRLF and append all those lines into a single message [line1 line2 line3(, and [any2bytes] will properly insert a space (32) as the atom delimiter.

you can tell [textfile] to use CR/LF/CRLF as line delimiters by opening the file in "cr" mode, like [open file.txt cr(

then you will need to stop through the lines by [bang(ing [textfile] till the end is reached. if you want to read the entire file at once, use [until] (with the 2nd outlet of [textfile] fed back to the 2nd inlet of [until], so it stops banging once the textfile is done. convert each line with [any2bytes], use [list append] to append '10' (the newline), and append those lists using another [list append].

Maybe mrpeach's binfile is more appropriate ?

maybe. if your file is saved as a W32 or MacOS(<X) file, then your line delimiters will be CRLF resp. CR, which will show up as an unprintable character (a small rectangle). in this case you might want to replace the line delimiters with proper LF to get what you want (which is easy enough if you don't care for supporting _both_ CRLF and CR)

ghmnsdf IOhannes

On Thu, 2013-02-21 at 01:50 +0100, Charles Goyard wrote:

IOhannes m zmoelnig wrote:

...

you can tell [textfile] to use CR/LF/CRLF as line delimiters by opening the file in "cr" mode, like [open file.txt cr(

then you will need to stop through the lines by [bang(ing [textfile] till the end is reached. if you want to read the entire file at once, use [until] (with the 2nd outlet of [textfile] fed back to the 2nd inlet of [until], so it stops banging once the textfile is done. convert each line with [any2bytes], use [list append] to append '10' (the newline), and append those lists using another [list append].

Ok here's my take to this. I was unable to make it work with only two list append, so I used 1 append and 2 prepend. There sure is a more logical way to that. But at least it works :).

Please correct my patch and help me learn !

Thanks a lot for your help.

Your patch breaks when you have a line with a comma in your text file. Such a line is broken into two lines.

Regarding your insistence to do that task with Pd, I think you should reconsider your reasoning. Pd is not particular strong in string processing, exactly because of reasons like this. IMHO, your best bet is to not use character representation at all in Pd which is probably the only safe way not to get in conflict with special characters in Pd (at least as long as there isn't a proper way to escape them).

See attached example with [mrpeach/binfile] -> [text3d].

This example doesn't do any processing at all, it only passes the data "untouched" to [text3d]. If you really want to do some processing, I'd probably do that outside of Pd. There are plenty of ways to roll your own external class with any of several scripting languages (bash, lua, python, tcl, etc.). I'd probably offload all the real string processing to such an external.

Roman

On Don, 2013-02-21 at 14:13 +0100, Charles Goyard wrote:

Hey, that works. But, as you may have guessed, it's awfully slow with a "large" textfile (about 3kb). I guess it's just the message box that's slow to update.

Actually, message boxes are pretty fast. Try hiding it in a non-visible subpatch so that it is not hogging the CPU by updating the graphic representation.

Roman

On Don, 2013-02-21 at 14:57 +0100, Charles Goyard wrote:

Hi,

Roman Haefeli wrote:

...

On Don, 2013-02-21 at 14:13 +0100, Charles Goyard wrote:

...

Hey, that works. But, as you may have guessed, it's awfully slow with a "large" textfile (about 3kb). I guess it's just the message box that's slow to update.

Actually, message boxes are pretty fast. Try hiding it in a non-visible subpatch so that it is not hogging the CPU by updating the graphic representation.

That's what I meant, sorry for being unclear.

You were clear. I just wanted to point out that hiding it helps.

Roman

On Don, 2013-02-21 at 15:15 +0100, IOhannes m zmoelnig wrote:

On 2013-02-21 14:41, Roman Haefeli wrote:

...

On Don, 2013-02-21 at 14:13 +0100, Charles Goyard wrote:

...

Hey, that works. But, as you may have guessed, it's awfully slow with a "large" textfile (about 3kb). I guess it's just the message box that's slow to update.

Actually, message boxes are pretty fast. Try hiding it in a non-visible subpatch so that it is not hogging the CPU by updating the graphic representation.

that's why i usually use [list] for these kind of operations. though in reality it might be slower than an (invisible) msgbox.

The problem with the list approach is that if you want to concatenate a stream of atoms to a list, you need to pass the whole list around on every iteration. When list grows huge, it's getting really slow. With a message box you can append atoms in place, without passing the whole list around. For list lengths >3000, the message box approach is probably several orders of magnitude faster.

This whole topic has been discussed in detail back when Matju was still involved in the list.

Roman

Roman Haefeli wrote:

BTW, it's dead easy to put this into an abstraction to avoid the GUI update issue:

[inlet] | [ ( | [outlet]

Yes, I tried and it works wonder !