[PD] [hsl]/[vsl]: unexpected behaviour (bug?)

Roman Haefeli reduzierer at yahoo.de
Wed Nov 28 17:18:42 CET 2007


while working with on a gop patch, i encountered a weird problem.
whenever i instantiated the gop abs in a patch, the scroll bars of the
patch window got very tiny and all the objects of the patch moved to the
right, until the rightmost object hit the right edge of the window. when
i moved the objects away from the right border, all objects shifted
again to the right border of the window until the rightmost object hit
the border. it took me some time to figure out what was going on. 

it turned out, that [hsl] and [vsl] were the cause of the problem,
respectively what i sent them. if the range is set  to the same value
for left and right, respectively for top and bottom, and  a 'set
<somevalue>' message is sent to hsl/vsl, the 'handle' (black bar)
disappears and the scroll bars of the patch get very tiny. i assume this
is because the 'handle' jumps far out of the window. 

to trigger it just do:

[range 0 0, set 0(

and move some object around to trigger the 'jumping to the right' and
tiny scrollbars.

when you now save the patch now, while the 'handle' disappeared and have
a look at the pd-file, you'll see something like this:

#X obj -77 118 hsl 128 15 0 0 0 0 empty empty empty -2 -8 0 10 -262144
-1 -1 -2.14748e+09 1;

i actually couldn't figure what the last arguments are used for.
however, i figured out that the second last argument most often is 0,
but after i triggered the 'handle' to disappear, the second last
argument is:


matju told me, that this is the lowest possible int32 value. i am not
quite sure, if it affects anything at all, but somehow i believe, this
value isn't supposed to be this big/low.

one might ask, what is the meaning of sending 'range 0 0' and 'set 0'.
the reason why i sometimes use 'range n n' is because i sometimes abuse
a slider as a 'step through' button. the 'set 0' is just a side effect
of using netpd-abstractions (they usually initialize the gui object, so
that it represents the correct init value).

it turned out, that it is actually not a serious problem. i first
expected some serious bug (pd.tk?), because i couldn't find a way to
avoid this problem for quite some time, because i didn't know the exact
reason. now that it is known, it is very easy to workaround. however, i
thought it should be reported anyway.


Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

More information about the Pd-list mailing list