[PD] some feature requests for the [text] object
liamg_uw at hotmail.com
Sun Apr 2 04:54:34 CEST 2017
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 at 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.
1. [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).
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list