Since 0.48 is coming up, I thought I would bring up some requests I have for the text family of objects. Some of these I brought up at the conference and some of them have only occurred to me since then. There are a lot of text storage objects out there and some of them still do things which can't be done in Vanilla. But IMO the implementation of the [text] is so successful that it deserves a few more features.
[text define] should send out a bang when the text window is saved. I mentioned this in a recent post. As it stands, there is no way of sensing when the text has been manually edited. It would be very useful to have this information if you ie. wanted to send the text to a list. A bang to the left outlet, or a new right outlet, or even a special receive channel would all work perfectly well here (ie. [receive mytext] gets a bang when [text define mytext] is edited).
A way to append text to the end of a line. [text set] has the third inlet to determine the field number on a given line, but it won't let you append text beyond the given line length. Is there a reason for this? Compare with "add2" from [textfile]. It seems to me that there should be a way of increasing a line indefinitely.
[text tolist] and [text fromlist] should accept customs separators. As it stands, the only accepted separator is ; , which is very awkward to work with from inside the patch. It would be great if both objects had an optional argument which specified the separator, so ie. [text tolist mytext &] would create list "list item 1 & item 2 & item 3 &", and [text fromlist mytext &] would accept the same list. Of course, leaving the argument blank would give the current ; separator.
3.1 I would also propose that we consider an option for specifying no separator for [text tolist], ie. the whole file comes out as one big list. This would break the symmetry with [text fromlist], but would still be useful in some circumstances.
A "flush" message to [text get] outputs each line of text iteratively, all at once. This of course can be done with [until], but I would love it if it was possible in one shot.
A flag on the read command that interprets commas as symbols, not line ends. ie. "read -a text-with-commas.txt". This would be useful when using [text] to read and print plain English files, ie. for help messages and such. Right now I'm having to write a whole lot of instructions without using commas. It's an interesting creative exercise, but something I'd rather avoid! [msgfile] can read commas correctly, so zexy has the upper hand here.
I hope that these are useful suggestions, and that some of them can be implemented without difficulty.
Liam
First of all, happy new year to everyone!
I second on your thoughts about [text]. some comments from my side:
2.) This would be really nice. Just like a line number beyond the range will append a line, a field number beyond the range could append fields. Since this is an error right now (and not handled silently), it won't break patches if we allow it in the future.
4.) This can already been achieved with [bang( -> [text sequence]
Two more suggestions:
a) since Pd 0.47 we have the very helpful 'delete' method which deletes lines of text. what about an equally helpful 'insert' method to insert lines of text?
b) a simple mechanism to pop the text window. Right now I'm using a hack with mouse messages, but a more elegant way would be very much appreciated :-).
Christof
Gesendet: Montag, 02. Januar 2017 um 17:55 Uhr Von: "Liam Goodacre" liamg_uw@hotmail.com An: "PD list" pd-list@lists.iem.at Betreff: [PD] some feature requests for the [text] object
Since 0.48 is coming up, I thought I would bring up some requests I have for the text family of objects. Some of these I brought up at the conference and some of them have only occurred to me since then. There are a lot of text storage objects out there and some of them still do things which can't be done in Vanilla. But IMO the implementation of the [text] is so successful that it deserves a few more features.
2. A way to append text to the end of a line. [text set] has the third inlet to determine the field number on a given line, but it won't let you append text beyond the given line length. Is there a reason for this? Compare with "add2" from [textfile]. It seems to me that there should be a way of increasing a line indefinitely. 3. [text tolist] and [text fromlist] should accept customs separators. As it stands, the only accepted separator is ; , which is very awkward to work with from inside the patch. It would be great if both objects had an optional argument which specified the separator, so ie. [text tolist mytext &] would create list "list item 1 & item 2 & item 3 &", and [text fromlist mytext &] would accept the same list. Of course, leaving the argument blank would give the current ; separator. 3.1 I would also propose that we consider an option for specifying no separator for [text tolist], ie. the whole file comes out as one big list. This would break the symmetry with [text fromlist], but would still be useful in some circumstances. 4. A "flush" message to [text get] outputs each line of text iteratively, all at once. This of course can be done with [until], but I would love it if it was possible in one shot. 5. A flag on the read command that interprets commas as symbols, not line ends. ie. "read -a text-with-commas.txt". This would be useful when using [text] to read and print plain English files, ie. for help messages and such. Right now I'm having to write a whole lot of instructions without using commas. It's an interesting creative exercise, but something I'd rather avoid! [msgfile] can read commas correctly, so zexy has the upper hand here. I hope that these are useful suggestions, and that some of them can be implemented without difficulty. Liam _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
4.) This can already been achieved with [bang( -> [text sequence]
Ah, of course.
> b) a simple mechanism to pop the text window. Right now I'm using a hack with mouse messages, but a more elegant way would be very much appreciated :-).
This can be done with "click" and "close" messages.
Gesendet: Montag, 02. Januar 2017 um 17:55 Uhr Von: "Liam Goodacre" liamg_uw@hotmail.com An: "PD list" pd-list@lists.iem.at Betreff: [PD] some feature requests for the [text] object
Since 0.48 is coming up, I thought I would bring up some requests I have for the text family of objects. Some of these I brought up at the conference and some of them have only occurred to me since then. There are a lot of text storage objects out there and some of them still do things which can't be done in Vanilla. But IMO the implementation of the [text] is so successful that it deserves a few more features.
[text define] should send out a bang when the text window is saved. I mentioned this in a recent post. As it stands, there is no way of sensing when the text has been manually edited. It would be very useful to have this information if you ie. wanted to send the text to a list. A bang to the left outlet, or a new right outlet, or even a special receive channel would all work perfectly well here (ie. [receive mytext] gets a bang when [text define mytext] is edited).
A way to append text to the end of a line. [text set] has the third inlet to determine the field number on a given line, but it won't let you append text beyond the given line length. Is there a reason for this? Compare with "add2" from [textfile]. It seems to me that there should be a way of increasing a line indefinitely.
[text tolist] and [text fromlist] should accept customs separators. As it stands, the only accepted separator is ; , which is very awkward to work with from inside the patch. It would be great if both objects had an optional argument which specified the separator, so ie. [text tolist mytext &] would create list "list item 1 & item 2 & item 3 &", and [text fromlist mytext &] would accept the same list. Of course, leaving the argument blank would give the current ; separator.
3.1 I would also propose that we consider an option for specifying no separator for [text tolist], ie. the whole file comes out as one big list. This would break the symmetry with [text fromlist], but would still be useful in some circumstances.
A "flush" message to [text get] outputs each line of text iteratively, all at once. This of course can be done with [until], but I would love it if it was possible in one shot.
A flag on the read command that interprets commas as symbols, not line ends. ie. "read -a text-with-commas.txt". This would be useful when using [text] to read and print plain English files, ie. for help messages and such. Right now I'm having to write a whole lot of instructions without using commas. It's an interesting creative exercise, but something I'd rather avoid! [msgfile] can read commas correctly, so zexy has the upper hand here.
I hope that these are useful suggestions, and that some of them can be implemented without difficulty.
Liam _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list ________________________________
This can be done with "click" and "close" messages.
Nice! :-D It's not in the help patch... Thanks a lot!
Gesendet: Montag, 02. Januar 2017 um 20:03 Uhr Von: "Liam Goodacre" liamg_uw@hotmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "PD list" pd-list@lists.iem.at Betreff: Re: [PD] some feature requests for the [text] object
> 4.) This can already been achieved with [bang( -> [text sequence]
Ah, of course.
> b) a simple mechanism to pop the text window. Right now I'm using a hack with mouse messages, but a more elegant way would be very much appreciated :-).
This can be done with "click" and "close" messages.
Gesendet: Montag, 02. Januar 2017 um 17:55 Uhr Von: "Liam Goodacre" liamg_uw@hotmail.com An: "PD list" pd-list@lists.iem.at Betreff: [PD] some feature requests for the [text] object
Since 0.48 is coming up, I thought I would bring up some requests I have for the text family of objects. Some of these I brought up at the conference and some of them have only occurred to me since then. There are a lot of text storage objects out there and some of them still do things which can't be done in Vanilla. But IMO the implementation of the [text] is so successful that it deserves a few more features.
2. A way to append text to the end of a line. [text set] has the third inlet to determine the field number on a given line, but it won't let you append text beyond the given line length. Is there a reason for this? Compare with "add2" from [textfile]. It seems to me that there should be a way of increasing a line indefinitely. 3. [text tolist] and [text fromlist] should accept customs separators. As it stands, the only accepted separator is ; , which is very awkward to work with from inside the patch. It would be great if both objects had an optional argument which specified the separator, so ie. [text tolist mytext &] would create list "list item 1 & item 2 & item 3 &", and [text fromlist mytext &] would accept the same list. Of course, leaving the argument blank would give the current ; separator. 3.1 I would also propose that we consider an option for specifying no separator for [text tolist], ie. the whole file comes out as one big list. This would break the symmetry with [text fromlist], but would still be useful in some circumstances. 4. A "flush" message to [text get] outputs each line of text iteratively, all at once. This of course can be done with [until], but I would love it if it was possible in one shot. 5. A flag on the read command that interprets commas as symbols, not line ends. ie. "read -a text-with-commas.txt". This would be useful when using [text] to read and print plain English files, ie. for help messages and such. Right now I'm having to write a whole lot of instructions without using commas. It's an interesting creative exercise, but something I'd rather avoid! [msgfile] can read commas correctly, so zexy has the upper hand here. I hope that these are useful suggestions, and that some of them can be implemented without difficulty. Liam _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Something else I've noticed: if you send a list of numbers to [text get], the object breaks. It gives an error message and then persists with this even if you send it a float. I know that a list is invalid input, but it would probably be good to protect against it in some other way.
From: Pd-list pd-list-bounces@lists.iem.at on behalf of Liam Goodacre liamg_uw@hotmail.com Sent: 02 January 2017 16:55 To: PD list Subject: [PD] some feature requests for the [text] object
Since 0.48 is coming up, I thought I would bring up some requests I have for the text family of objects. Some of these I brought up at the conference and some of them have only occurred to me since then. There are a lot of text storage objects out there and some of them still do things which can't be done in Vanilla. But IMO the implementation of the [text] is so successful that it deserves a few more features.
[text define] should send out a bang when the text window is saved. I mentioned this in a recent post. As it stands, there is no way of sensing when the text has been manually edited. It would be very useful to have this information if you ie. wanted to send the text to a list. A bang to the left outlet, or a new right outlet, or even a special receive channel would all work perfectly well here (ie. [receive mytext] gets a bang when [text define mytext] is edited).
A way to append text to the end of a line. [text set] has the third inlet to determine the field number on a given line, but it won't let you append text beyond the given line length. Is there a reason for this? Compare with "add2" from [textfile]. It seems to me that there should be a way of increasing a line indefinitely.
[text tolist] and [text fromlist] should accept customs separators. As it stands, the only accepted separator is ; , which is very awkward to work with from inside the patch. It would be great if both objects had an optional argument which specified the separator, so ie. [text tolist mytext &] would create list "list item 1 & item 2 & item 3 &", and [text fromlist mytext &] would accept the same list. Of course, leaving the argument blank would give the current ; separator.
3.1 I would also propose that we consider an option for specifying no separator for [text tolist], ie. the whole file comes out as one big list. This would break the symmetry with [text fromlist], but would still be useful in some circumstances.
A "flush" message to [text get] outputs each line of text iteratively, all at once. This of course can be done with [until], but I would love it if it was possible in one shot.
A flag on the read command that interprets commas as symbols, not line ends. ie. "read -a text-with-commas.txt". This would be useful when using [text] to read and print plain English files, ie. for help messages and such. Right now I'm having to write a whole lot of instructions without using commas. It's an interesting creative exercise, but something I'd rather avoid! [msgfile] can read commas correctly, so zexy has the upper hand here.
I hope that these are useful suggestions, and that some of them can be implemented without difficulty.
Liam
As a recent thread pointed out, [text search] is incapable of finding more than one instance of a matching line of text--it will only ever find the first match. Here's a simple suggestion for expanding its capabilities so that you can search for multiple instances.
Remembering that numbered arguments in [text search] let you search through specific fields, I propose that the argument -1 should let you search the line number. For instance, if you search "4 my search text" into [text search txt > -1], it will search for instances of "my search text" after the 4th line. Since [text search] gives a line number, you could easily rig this up so it searches recursively for the first instance, then the second, etc.
Voila, a method of using [text search] to search a whole text file, without breaking backwards compatibility. Is there any chance that this could be implemented in 0.48?
From: Liam Goodacre liamg_uw@hotmail.com Sent: 02 January 2017 16:55 To: PD list Subject: some feature requests for the [text] object
Since 0.48 is coming up, I thought I would bring up some requests I have for the text family of objects. Some of these I brought up at the conference and some of them have only occurred to me since then. There are a lot of text storage objects out there and some of them still do things which can't be done in Vanilla. But IMO the implementation of the [text] is so successful that it deserves a few more features.
[text define] should send out a bang when the text window is saved. I mentioned this in a recent post. As it stands, there is no way of sensing when the text has been manually edited. It would be very useful to have this information if you ie. wanted to send the text to a list. A bang to the left outlet, or a new right outlet, or even a special receive channel would all work perfectly well here (ie. [receive mytext] gets a bang when [text define mytext] is edited).
A way to append text to the end of a line. [text set] has the third inlet to determine the field number on a given line, but it won't let you append text beyond the given line length. Is there a reason for this? Compare with "add2" from [textfile]. It seems to me that there should be a way of increasing a line indefinitely.
[text tolist] and [text fromlist] should accept customs separators. As it stands, the only accepted separator is ; , which is very awkward to work with from inside the patch. It would be great if both objects had an optional argument which specified the separator, so ie. [text tolist mytext &] would create list "list item 1 & item 2 & item 3 &", and [text fromlist mytext &] would accept the same list. Of course, leaving the argument blank would give the current ; separator.
3.1 I would also propose that we consider an option for specifying no separator for [text tolist], ie. the whole file comes out as one big list. This would break the symmetry with [text fromlist], but would still be useful in some circumstances.
A "flush" message to [text get] outputs each line of text iteratively, all at once. This of course can be done with [until], but I would love it if it was possible in one shot.
A flag on the read command that interprets commas as symbols, not line ends. ie. "read -a text-with-commas.txt". This would be useful when using [text] to read and print plain English files, ie. for help messages and such. Right now I'm having to write a whole lot of instructions without using commas. It's an interesting creative exercise, but something I'd rather avoid! [msgfile] can read commas correctly, so zexy has the upper hand here.
I hope that these are useful suggestions, and that some of them can be implemented without difficulty.
Liam