Thanks Liam for your help,
I revised the patch and it was actually an error caused by the abstractions trying to read the "buffer" before it actually loaded, I solved this by setting a short delay after the [init]
cheers
On Thu, Sep 29, 2016 at 7:17 AM, José Rafael Subía Valdez < jsubiavaldez@gmail.com> wrote:
Thanks Liam,
the read instruction is in [GUI-creator]. I thought the other object need the name as a pointer, the creation arguments are written as they should be, other wise the patch wouldn't work at all, $2 inside is because it comes from the second argument written in the [cr_gui] abstraction.
thanks for your help, I will continue to revise it, but if anyone else has an idea why this is happening I am all ears,
cheers
On Thu, Sep 29, 2016 at 6:51 AM, Liam Goodacre liamg_uw@hotmail.com wrote:
The problem is coming from the "read_number_memory" subpatches, where the [text search] and [text set] objects are not linked to a text buffer. I can't tell exactly why this is. Could it be because the creation arguments are confused? ($1 in the [text define] object, $2 in the abstraction).
If not, perhaps you are misunderstanding how the text objects work. The name given in [text define] defines a buffer that other text objects can reference, but it does not point to a specific text file on your hard drive. To open a file from the hard disk, you must send a "read" message to text define. I don't see such a message in your patch, so perhaps this is the problem.
*From:* Pd-list pd-list-bounces@lists.iem.at on behalf of José Rafael Subía Valdez jsubiavaldez@gmail.com *Sent:* 28 September 2016 20:59 *To:* pd-list *Subject:* [PD] [text] question
Hello list
quick question about the [text] object, I have a patch that reads and records a text file. I use various [text] objects in the patch that access the same file, these are placed in abstractions. I have no problems when running the patch and the program works, but when I close the patch I get this error, and I can't figure out why.
text: couldn't find text buffer 'test-GUI-amount.txt'
any ideas?
last part of a 4-week project. So maybe I need a pair of fresh eyes.
Basically, it is a preset system that I am programming, I keep track of how many objects have been created, I am recording this number into a text file. And I am using a single text file for every GUI object that I am using. I don't understand why the error only comes up when closing the patch or deleting the module that contains the objects. The program works as I want it, but I would really wanna get rid of this error.
attached is the file if someone can take a look, I deeply appreciate it. To reproduce the error just open and close the patch. The [text] object is in the [GUI-creator] module and in the [pd read_number_memory] subpatch in the [cr_gui] abstraction
what is clear is that the error comes from the use of [text] in the [cr_gui] as I have 8 errors and I use 8 instances of this abstraction
cheers
-- José Rafael Subía Valdez www.jrsv.net JRSV | Official website http://www.jrsv.net/ www.jrsv.net Home. Welcome to my website, here you will find information regarding my work in different fields of research and production. Find out about my projects that involve ...
-- José Rafael Subía Valdez www.jrsv.net
On 2016-09-29 10:02, José Rafael Subía Valdez wrote:
I solved this by setting a short delay after the [init]
this (forcing events into the correct order by adding indefined delays here and there) is generally a bad idea.
a better one would be to signal via an explicit message to the readers that data is now available.
hmsdf IOhannes
definitely,
I will see if there is a better and more elegant way to do this.. I guess I can send a bang from the [text define] when the file is loaded and only then push the others to find that buffer.
I will work on this today
thanks IOhannes
On Thu, Sep 29, 2016 at 8:39 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2016-09-29 10:02, José Rafael Subía Valdez wrote:
I solved this by setting a short delay after the [init]
this (forcing events into the correct order by adding indefined delays here and there) is generally a bad idea.
a better one would be to signal via an explicit message to the readers that data is now available.
hmsdf IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list