Dear friends,
I have noticed something that seems like a bug to me: if you write on an array via a tabwrite attached to a cursor that writes both x and y data (basically doing a diagonal line), your table will be interspersed with zeros depending on the speed to which you move the slider. I went through the lists and googled over, could not find anything in this regard.
I attach a tester patch. I run a GNU/Linux box Pentium III 384 kBytes (kernel 2.6.10, Debian testing, Pd v.0.39.2).
Thank you for all your help,
Nicola
hi nicola
i'm not sure, if you can call it a bug, since the [tabwrite] does only what it was told to do. the problem is rather, that the gui-refreshrate is quite low. if you move the slider fast, it jumps over a few positions, which are not triggered and so not drawed in the array. in terms of cpu-load it makes sense to limit the gui-refreshrate (afaik). it is not too trivial to get what you want in my opinion, though. i'd do it with a counter, that counts from the old position to the new position of the slider. it's not a nice solution. maybe someone else has a better one(?)
cheers roman
"Nicola Bernardini" nic.bern@tiscali.it wrote:
Dear friends,
I have noticed something that seems like a bug to me: if you write on an array via a tabwrite attached to a cursor that writes both x and y data (basically doing a diagonal line), your table will be interspersed with zeros depending on the speed to which you move the slider. I went through the lists and googled over, could not find anything in this regard.
I attach a tester patch. I run a GNU/Linux box Pentium III 384 kBytes (kernel 2.6.10, Debian testing, Pd v.0.39.2).
Thank you for all your help,
Nicola
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
I agree with Roman, the refresh rate must be low for GUI objects, and the still slow everything down. Interpolation with line~ or vline~ seems to be the best way to smooth out your data.
~Kyle
On 5/20/06, Roman Haefeli reduzierer@yahoo.de wrote:
hi nicola
i'm not sure, if you can call it a bug, since the [tabwrite] does only what it was told to do. the problem is rather, that the gui-refreshrate is quite low. if you move the slider fast, it jumps over a few positions, which are not triggered and so not drawed in the array. in terms of cpu-load it makes sense to limit the gui-refreshrate (afaik). it is not too trivial to get what you want in my opinion, though. i'd do it with a counter, that counts from the old position to the new position of the slider. it's not a nice solution. maybe someone else has a better one(?)
cheers roman
"Nicola Bernardini" nic.bern@tiscali.it wrote:
Dear friends,
I have noticed something that seems like a bug to me: if you write on an array via a tabwrite attached to a cursor that writes both x and y data (basically doing a diagonal line), your table will be interspersed with zeros depending on the speed to which you move the slider. I went through the lists and googled over, could not find anything in this regard.
I attach a tester patch. I run a GNU/Linux box Pentium III 384 kBytes (kernel 2.6.10, Debian testing, Pd v.0.39.2).
Thank you for all your help,
Nicola
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I think the problem is not gui refresh rate, provided I understand the situation corectly. Objects without the tilde (~) in them work at a slower rate then the signal rate objects - the tilde objects. Its not a gui thing it's a control rate versus signal rate thing. Things working at the signal rate use more CPU power and so everything does not work at the signal rate.
Hope this helps, -thewade
Quoting Kyle Klipowicz kyleklip@gmail.com:
I agree with Roman, the refresh rate must be low for GUI objects, and the still slow everything down. Interpolation with line~ or vline~ seems to be the best way to smooth out your data.
~Kyle
On 5/20/06, Roman Haefeli reduzierer@yahoo.de wrote:
hi nicola
i'm not sure, if you can call it a bug, since the [tabwrite] does only what it was told to do. the problem is rather, that the gui-refreshrate is quite low. if you move the slider fast, it jumps over a few positions, which are not triggered and so not drawed in the array. in terms of cpu-load it makes sense to limit the gui-refreshrate (afaik). it is not too trivial to get what you want in my opinion, though. i'd do it with a counter, that counts from the old position to the new position of the slider. it's not a nice solution. maybe someone else has a better one(?)
cheers roman
"Nicola Bernardini" nic.bern@tiscali.it wrote:
Dear friends,
I have noticed something that seems like a bug to me: if you write on an array via a tabwrite attached to a cursor that writes both x and y data (basically doing a diagonal line), your table will be interspersed with zeros depending on the speed to which you move the slider. I went through the lists and googled over, could not find anything in this regard.
I attach a tester patch. I run a GNU/Linux box Pentium III 384 kBytes (kernel 2.6.10, Debian testing, Pd v.0.39.2).
Thank you for all your help,
Nicola
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--
http://theradioproject.com http://perhapsidid.blogspot.com
(((())))(()()((((((((()())))()(((((((())()()())()))) (())))))(()))))))))))))(((((((((((()()))))))))((()))) ))(((((((((((())))())))))))))))))))__________ _____())))))(((((((((((((()))))))))))_______ ((((((())))))))))))((((((((000)))oOOOOOO
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sat, 20 May 2006, thewade wrote:
I think the problem is not gui refresh rate, provided I understand the situation corectly. Objects without the tilde (~) in them work at a slower rate then the signal rate objects - the tilde objects.
That's not the problem either. There are two problems: first, the refresh rate of the mouse is not fine enough to have the mouse really visit contiguous pixels; second, the gui refresh rate slows down Tcl/Tk, such that Tcl/Tk may get several mouse events in a burst if one screen refresh takes too long, and I suppose that Tcl/Tk keeps only the most recent one.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Quoting Mathieu Bouchard matju@artengine.ca:
On Sat, 20 May 2006, thewade wrote:
I think the problem is not gui refresh rate, provided I understand the situation corectly. Objects without the tilde (~) in them work at a slower rate then the signal rate objects - the tilde objects.
That's not the problem either. There are two problems: first, the refresh rate of the mouse is not fine enough to have the mouse really visit contiguous pixels; second, the gui refresh rate slows down Tcl/Tk, such that Tcl/Tk may get several mouse events in a burst if one screen refresh takes too long, and I suppose that Tcl/Tk keeps only the most recent one.
Yes, that is what I thought at first too, but then I built a patch to see if I was right. I know that a 100 pixel wide slider with a value range of 0-200 will only return values for 0, 2, 4, 6, 8, etc. but using line should fix that simple problem, shoudn't it? But it doesnt. (see attached patch if you want.) I even tried using a [metro 1] attached to a [snapshot~] and used [line~] but that was silly because that is actually slower then just using [line].
As I understand it [line] is not a tcl/tk object but a PD object and it should do the interpolation that the hslider doesn't, except [line] works at samplerate/blocksize rate and so information gets skipped.
I haven't actually looked at the PD code so I might be talking out of my arse, but I have hooked a [line] (not [line~]) object up to a signalrate object as an envelope and heard the popping, and I have worked with Csound that also has control rate and sample rate 'objects'.
-thewade
On Sat, 20 May 2006, thewade wrote:
range of 0-200 will only return values for 0, 2, 4, 6, 8, etc. but using line should fix that simple problem, shoudn't it? But it doesnt.
Normally, it shouldn't. [line] works with a timer. it does linear interpolation using a hidden [metro 20]. It doesn't necessarily go over all integers. Rounding its output doesn't necessarily give you each integer once.
Telling [line] several things in a row f, and then does linear interpolation. You need to set the timer so that the interpolation will fall exactly on each integer, and you have to make sure that the next time you tell [line] something, it's already finished with its previous stuff. The killer limitation is that setting [line]'s timer is only possible using a creation argument: you can't configure it using a message.
Because of all those reasons, [line] is a very bad choice for the job.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
hi nicola,
a workaround might be to save your array as it is, with the zero data included, and then use
[tabread] | [sel 0] | [object]
to filter out the zero data when you read.
hi wade
using [line] won't help, since you cannot be sure, that it hits every integer in the desired range, when you move the slider fast ennough; same problem with [line~] and [snapshot~]. also is this soltution not a good one, because you are firing much more messages than really necessary, when moving the slider slowly (or not moving at when all using [line~]). to make sure, that you 'trigger' every cursor-position of the [tabwrite] exactly once, you would need a counter that counts in steps of 1 to the next position of the cursor.
roman
"thewade" pdman@aproximation.org wrote:
On Sat, 20 May 2006, thewade wrote:
I think the problem is not gui refresh rate, provided I understand the situation corectly. Objects without the tilde (~) in them work at a slower rate then the signal rate objects - the tilde objects.
That's not the problem either. There are two problems: first, the refresh rate of the mouse is not fine enough to have the mouse really visit contiguous pixels; second, the gui refresh rate slows down Tcl/Tk, such that Tcl/Tk may get several mouse events in a burst if one screen refresh takes too long, and I suppose that Tcl/Tk keeps only the most recent one.
Yes, that is what I thought at first too, but then I built a patch to see if I was right. I know that a 100 pixel wide slider with a value range of 0-200 will only return values for 0, 2, 4, 6, 8, etc. but using line should fix that simple problem, shoudn't it? But it doesnt. (see attached patch if you want.) I even tried using a [metro 1] attached to a [snapshot~] and used [line~] but that was silly because that is actually slower then just using [line].
As I understand it [line] is not a tcl/tk object but a PD object and it should do the interpolation that the hslider doesn't, except [line] works at samplerate/blocksize rate and so information gets skipped.
I haven't actually looked at the PD code so I might be talking out of my arse, but I have hooked a [line] (not [line~]) object up to a signalrate object as an envelope and heard the popping, and I have worked with Csound that also has control rate and sample rate 'objects'.
-thewade
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
i'd do it like that using [until] - see the patch. and there's also something for the [value] philosophers in the patch.
sven.
L Hallo, sven hat gesagt: // sven wrote:
i'd do it like that using [until] - see the patch. and there's also something for the [value] philosophers in the patch.
Hey, that use of [value] is cool. Why isn't this mention in the help-file (that I have here)?
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
L Hallo, sven hat gesagt: // sven wrote:
i'd do it like that using [until] - see the patch. and there's also something for the [value] philosophers in the patch.
Hey, that use of [value] is cool. Why isn't this mention in the help-file (that I have here)?
most likely because it is not a feature of [value] but of [expr] (though i agree that it should be in the help for [expr])
and i loved the arrow! btw, if you give each bang the _same_ send- and receive-name (e.g. "$0-bng") then you are even allowed to click on one of the [bng]s without crashing pd.
mfga.sdr IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
Hey, that use of [value] is cool. Why isn't this mention in the help-file (that I have here)?
most likely because it is not a feature of [value] but of [expr] (though i agree that it should be in the help for [expr])
I meant to refer to the expr help-file actually. It mentions how to use symbols to access arrays, but this use of value was unknown to me so far.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Sun, 21 May 2006, Nicola Bernardini wrote:
I have noticed something that seems like a bug to me: if you write on an array via a tabwrite attached to a cursor that writes both x and y data (basically doing a diagonal line), your table will be interspersed with zeros depending on the speed to which you move the slider. I went through the lists and googled over, could not find anything in this regard.
If you move the slider from (for example) 0 to 100, it won't necessarily give you all the numbers from 0 to 100. You will need a counter of some kind, to automatically fill in the skips. You could use [until] for that.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Nicola Bernardini hat gesagt: // Nicola Bernardini wrote:
I have noticed something that seems like a bug to me: if you write on an array via a tabwrite attached to a cursor that writes both x and y data (basically doing a diagonal line), your table will be interspersed with zeros depending on the speed to which you move the slider.
If it is a bug, then it would be one of the slider, not of tabwrite. If you print the numbers sent by a slider on fast movement, you will see that it not "hits" all numbers, but instead jumps over some values depending on how fast you move.
Here's a [print HSL] attached to a slider. First I'm moving slowly, then at about 10 I speed up:
HSL: 0 HSL: 1 HSL: 2 HSL: 3 HSL: 4 HSL: 5 HSL: 6 HSL: 7 HSL: 8 HSL: 9 HSL: 10 HSL: 11 HSL: 13 HSL: 15 HSL: 25 HSL: 35 HSL: 49 HSL: 59 HSL: 71 HSL: 83 HSL: 95 HSL: 109 HSL: 121 HSL: 127
All the "holes" in the list of numbers will show up as zeros in your tabwrite construct. Numberboxes behave the same, btw.
However: I don't consider this a bug but a feature! At least I quite often rely on that behaviour for easily getting at the speed of change in a slider instead of just the values. The idiom I use for this is simple:
_____________
[_____|_______] <= slider
|
[t f f]
\ /
X
/ \
[- ]
|
[print SPEED_OF_SLIDER_MOVEMENT]
This is very useful sometimes. I know, that the Right Thing to get at the speed of change is using a [timer] and all that, but often a cross-substracting slider is more than enough for my purposes.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-
Frank Barknecht -
hard off -
IOhannes m zmoelnig -
Kyle Klipowicz -
Mathieu Bouchard -
Nicola Bernardini -
Roman Haefeli -
sven -
thewade