i'm having some problems with [msgfile].. this is the version i have:
[msgfile] part of zexy-2.2.0 (compiled: Nov 19 2007) Copyright (l) 1999-2007 IOhannes m zm��lnig, forum::f��r::uml��ute & IEM
i got it out of _hc's pd-extended cvs.
the first time i put some data into the [msgfile]'s buffer, then "rewind" and play with sequential "goto $1"s ..... it appears to lose the data, the second time i record data, it works just fine... but it seems a little sketchy, because the third time i try it, it doesn't work again.
i'm wondering if anyone has also experienced this? i'll be the first to admit that there is a large possibility of user error :) but i can't figure myself around it.
i'm hoping to build a type of data recorder / sequencer with this.
-andy
Hallo, Andy Graybeal hat gesagt: // Andy Graybeal wrote:
i'm having some problems with [msgfile].. this is the version i have:
[msgfile] part of zexy-2.2.0 (compiled: Nov 19 2007) Copyright (l) 1999-2007 IOhannes m zm��lnig, forum::f��r::uml��ute & IEM
i got it out of _hc's pd-extended cvs.
the first time i put some data into the [msgfile]'s buffer, then "rewind" and play with sequential "goto $1"s ..... it appears to lose the data, the second time i record data, it works just fine... but it seems a little sketchy, because the third time i try it, it doesn't work again.
I suppose you have execution order bugs in your patch. Are you using enough [trigger ...] objects where necessary? Can you post a demo patch to reproduce the behaviour?
Frank Barknecht _ ______footils.org__
Frank, Thanks for responding.
Here's a very simple patch I made to share this problem... and in making this patch, I'm finding that once I play to the end of a sequence in [msgfile] that it won't rewind to the beginning.. no matter how many times i tell it to "rewind"
-Andy
Hallo, Andy Graybeal hat gesagt: // Andy Graybeal wrote:
i'm having some problems with [msgfile].. this is the version i have:
[msgfile] part of zexy-2.2.0 (compiled: Nov 19 2007) Copyright (l) 1999-2007 IOhannes m zm��lnig, forum::f��r::uml��ute & IEM
i got it out of _hc's pd-extended cvs.
the first time i put some data into the [msgfile]'s buffer, then "rewind" and play with sequential "goto $1"s ..... it appears to lose the data, the second time i record data, it works just fine... but it seems a little sketchy, because the third time i try it, it doesn't work again.
I suppose you have execution order bugs in your patch. Are you using enough [trigger ...] objects where necessary? Can you post a demo patch to reproduce the behaviour?
Ciao
Frank Barknecht _ ______footils.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Andy Graybeal hat gesagt: // Andy Graybeal wrote:
Thanks for responding.
Here's a very simple patch I made to share this problem... and in making this patch, I'm finding that once I play to the end of a sequence in [msgfile] that it won't rewind to the beginning.. no matter how many times i tell it to "rewind"
Okay, this is not related to any execution order bugs. But I cannot reproduce the behaviour you describe. Your patch on my machine works without problems. You may try to use [textfile] instead of [msgfile] in that patch, to see if it's a bug in your version of msgfile. What you do in the example can also be done with textfile.
Frank Barknecht _ ______footils.org__
I am getting similar problems like andy, and it looks like a bug. try the following: if you are at the end of the file and hit bang, then you lose all data of msgfile. marius.
Frank Barknecht wrote:
Hallo, Andy Graybeal hat gesagt: // Andy Graybeal wrote:
Thanks for responding.
Here's a very simple patch I made to share this problem... and in making this patch, I'm finding that once I play to the end of a sequence in [msgfile] that it won't rewind to the beginning.. no matter how many times i tell it to "rewind"
Okay, this is not related to any execution order bugs. But I cannot reproduce the behaviour you describe. Your patch on my machine works without problems. You may try to use [textfile] instead of [msgfile] in that patch, to see if it's a bug in your version of msgfile. What you do in the example can also be done with textfile.
Ciao
#N canvas 192 232 665 376 10; #X obj 207 245 msgfile; #X msg 146 100 add 34 45; #X obj 207 274 print; #X obj 255 272 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X msg 166 126 flush; #X msg 408 247 clear; #X msg 412 224 rewind; #X msg 181 156 bang; #X msg 405 273 _____________; #X text 221 100 1 , enter some lines; #X text 222 123 2 , click flush (outputs stored data); #X text 222 153 3 , bang outputs one row , but then stored data is gone.; #X msg 197 192 flush; #X text 243 189 4 , click flush again (no more data output); #X connect 0 0 2 0; #X connect 0 1 3 0; #X connect 1 0 0 0; #X connect 4 0 0 0; #X connect 5 0 0 0; #X connect 6 0 0 0; #X connect 7 0 0 0; #X connect 8 0 2 0;
On Mon, 2007-12-03 at 12:12 -0500, marius schebella wrote:
I am getting similar problems like andy, and it looks like a bug. try the following: if you are at the end of the file and hit bang, then you lose all data of msgfile. marius.
this description of [msgfile]'s behaviour would fit as an explanation for why this netpd-patch i was mentioning earlier didn't work properly anymore after updating zexy (it used [msgfile] to manage a scroll-list and as soon as you reached the end of the list, all entries just disappeared)
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hallo, marius schebella hat gesagt: // marius schebella wrote:
I am getting similar problems like andy, and it looks like a bug. try the following: if you are at the end of the file and hit bang, then you lose all data of msgfile.
I'm using an older version of zexy (too lazy to upgrade...) so it seems to be a new bug.
Frank Barknecht _ ______footils.org__
marius schebella wrote:
I am getting similar problems like andy, and it looks like a bug.
right. someone please file a bug-report at sourceforge and attach a bug-triggering patch. while the patch posted by andy seems to positively trigger the bug, you have to know exactly what you are doing in order to do so (there are virtually no explanations as to what to do; the few comments are (at least for me) rather misguiding)
i would favour if someone could write a simple test like the ones in CVS:externals/zexy/tests/ which would test whether msgfile behaves as expected (with regards to this specific bug)
fmgadsr IOhannes
On Tue, 2007-12-04 at 09:26 +0100, IOhannes m zmoelnig wrote:
marius schebella wrote:
I am getting similar problems like andy, and it looks like a bug.
right. someone please file a bug-report at sourceforge and attach a bug-triggering patch.
did it.
btw: how can i assign the bug to you? i couldn't figure out how to do that. it is assigned to nobody now.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Mon, 2007-12-03 at 11:16 +0100, Frank Barknecht wrote:
Hallo, Andy Graybeal hat gesagt: // Andy Graybeal wrote:
Thanks for responding.
Here's a very simple patch I made to share this problem... and in making this patch, I'm finding that once I play to the end of a sequence in [msgfile] that it won't rewind to the beginning.. no matter how many times i tell it to "rewind"
Okay, this is not related to any execution order bugs. But I cannot reproduce the behaviour you describe. Your patch on my machine works without problems. You may try to use [textfile] instead of [msgfile] in that patch, to see if it's a bug in your version of msgfile. What you do in the example can also be done with textfile.
hi all
i noticed, that one of my netpd-patches didn't work properly anymore after i upgraged from zexy 2.1 to 2.2.0. i didn't invest the time to exactly figure out what was going on, but the problem was [msgfile]. it was the only zexy objectclass i used in that patch and the problem appeared only, if 2.2.0 was loaded. i am sorry for being too lazy to properly investigate the exact cause and what exactly had changed in the behaviour of [msgfile] (because the patch was created before [list] and i found [msgfile] an ugly solution compared to a [list] based one, so i decided to just get rid of [msgfile] instead of figuring out, what was happening), but at least i can tell, that there must be a change in the [msgfile] since 2.1 . probably IOhannes can confirm this to be really sure (since i couldn't find a changelog for zexy).
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de