Alas, the bug is different. If you open the properties window of the
table and adjust the y range to be from 1000 to 0. You will get
over that problem. Then you'll be able to see that only half the
table entries are updated. Also, the wrong values are in the slots
-- off by one. Also, of course, you can just look at the list. On
OS X, all of the table entries are updated as expected.

On Feb 21, 2007, at 1:02 PM, Miller Puckette wrote:

So, (on Fedora 2) what I get is that the five tables (assuming I opened them before whacking the "440" button, e.g.) have all their
points fly far above the visible region of the window. The bug I then see is the long-standing one, which is that for teh life of me I can't
figure out how to get the scroll-bars to update to reflect moving contents, except by making a TK call which takes so long to compute that it
frequently messes up the audio.

cheers Miller

On Wed, Feb 21, 2007 at 11:05:15AM -0500, David F. Place wrote:

...

Since my last message morphed from a plea for help to a bug report, I guess I should give the relevant info.

Mac OS X 10.4.8 / Pd 0.39-2 Fedora 4 / Pd 0.39-2

--o-------o-o-o---o-o-o--- David F. Place mailto:d@vidplace.com

---

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

--o-------o-o-o---o-o-o--- David F. Place mailto:d@vidplace.com

David F. Place wrote:

Alas, the bug is different. If you open the properties window of the
table and adjust the y range to be from 1000 to 0. You will get

so for simplicity i suggest you add the attached patch to yours. this should properly initialize your table-ranges.

over that problem. Then you'll be able to see that only half the
table entries are updated. Also, the wrong values are in the slots
-- off by one. Also, of course, you can just look at the list. On
OS X, all of the table entries are updated as expected.

i cannot reproduce this.

• your x-bounds seem to be wrong: you have 12 values, with x-coordinates

0..11; therefore the x-bounds should be 0..11 too, instead of 0..12 (which will give you another "empty" slot; probably this is what you mean by "not getting updated")

• what do you mean by "off by one"? the index "0" should be at the left

edge of the table.

• both the list and the table get updated correctly.

mfga.ds IOhannes

#N canvas 173 281 450 300 10; #X msg 99 77 pcToPy-1 , pcToPy-2 , pcToPy0 , pcToPy+1 , pcToPy+2 ; #X obj 99 105 symbol; #X obj 99 55 loadbang; #X msg 99 133 ; $1 bounds 0 440 11 0; #X connect 0 0 1 0; #X connect 1 0 3 0; #X connect 2 0 0 0;

On Wed, 2007-02-21 at 20:19 +0100, IOhannes m zmoelnig wrote:

IOhannes m zmoelnig wrote:

...

i cannot reproduce this.

oh, and i forgot: i am on debian(etch/sid) on an amd64 in i386 mode

are you by chance running a 64bit OS? (i guess FC3 does not support x86_64 but who knows...)

does the problem still exist with pd-0.40? pd-0.41?

I'm running pd-0.40 on Ubuntu Edgy (i686), and I can't reproduce the problem. All of the values get _set_ correctly in the tables, they just don't get displayed nicely because of the table ranges.

Jamie

David F. Place wrote:

On Feb 21, 2007, at 2:19 PM, IOhannes m zmoelnig wrote:

...

are you by chance running a 64bit OS? (i guess FC3 does not support x86_64 but who knows...)

Yes, I am running a 64bit OS. I'll try upgrading to 0.41 too.

this explains everything! (and tells us, how good it is to tell the architecture of your system - esp. when it is not yet "mainstream")

your problem has only been fixed in 0.41 confirm http://sf.net/tracker/index.php?func=detail&aid=1085018&group_id=557... http://sf.net/tracker/index.php?func=detail&aid=1532439&group_id=557...

(these are 2 links, if the lines get broken by the mail transport, you have to assemble them yourself)

mfg.asdr IOhannes

On Feb 21, 2007, at 2:06 PM, IOhannes m zmoelnig wrote:

• your x-bounds seem to be wrong: you have 12 values, with x-

coordinates 0..11; therefore the x-bounds should be 0..11 too, instead of 0..12 (which will give you another "empty" slot; probably this is what you mean by "not getting updated")

On OS X when I View List of pcToPy0 I see the correct table:

0. 241.778
1. 258.188
2. 272
3. 286.551
4. 306
5. 322.37
6. 344.25
7. 362.667
8. 387.281
9. 408
10. 429.827
11. 459

Under linux (now upgraded to Pd 0.40.1) I see the following. Note
that the values are stored in a slot corresponding to 2*i. (0->0,1->2,2->4,3->6, etc....)

0. 241.778
1. 272
2. 306
3. 344.25
4. 387.281
5. 429.827
6. 0
7. 0
8. 0
9. 0
10. 0
11. 0

Obviously, I don't care a hoot about the Tk display of the graph.
Sorry I didn't give this level of detail right off the bat.

--o-------o-o-o---o-o-o--- David F. Place mailto:d@vidplace.com

Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:

So, (on Fedora 2) what I get is that the five tables (assuming I opened them before whacking the "440" button, e.g.) have all their points fly far above the visible region of the window. The bug I then see is the long-standing one, which is that for teh life of me I can't figure out how to get the scroll-bars to update to reflect moving contents, except by making a TK call which takes so long to compute that it frequently messes up the audio.

I get the scrollbars updated correctly here just fine on Debian/testing. (Although non-updating scrollbars happen at other times here, too.)

As a hint to the original poster: It is possible to check the content of a table with the "View list" button in the array's Properties menu. An the arrows on the bottom of the "View list" menu actually scoll through the list, if it is very long.

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__