It's very easy to use--basically the same as a regular hsl, except that the output is a list. Hold down the SHIFT key to move just one variable, and CTL key to jump to a position. (Presumably this won't work on a mac--you'll have to change the key selection in the [route] in the main patch). Use creation arguments to set the limits, and to turn off colour fading, if desired.

I hope you enjoy it!

xyslide.zip

I hope you enjoy it!

I do!

And one more problem that I found recently: after creating [xysl], if I move it somewhere else by clicking and dragging it, the object keeps changing the x and y positions (and feeding them to Pd). The same is not true when moving it via the keyboard arrows.

Anton
Do you have the Zexy library installed? There's a [zl rev] object in the main window that might be giving you trouble. Otherwise, it might be that the [iemguts] object, which receives all information sent to the canvas, gives a different output on windows than it does in Linux (my OS). To test this, make the following patch:

[iemguts/receivecanvas 0]
|
|
[print]

Press the control and shift buttons and see what you get. I get:

key 1 Control_L 0 = left control button pressed
key 0 Control_L 0 = left control button depressed
key 1 Shift_L 0 = left shift button pressed
key 0 Shift_L 1 = left shift button depressed

and correspondingly with the right buttons.

If you get a different message, you'll have to adjust the code accordingly. This is set in the route object in the main window, which looks like this:

[route Control_L Control_R Shift_R Shift_L]

The objects above it, including the aforementioned [zl rev], might also need altering.

gsagostinho:

I can't think what your CTRL problem is, especially because this is the simplest move function out of the three. Could it also a problem with the CTRL button being read differently by [iemguts]? This function is in the [pd mover3] subpatch, if you want to take a look.

As for your first problem, that the bars change when the object moves, I have noticed this also recently, but only under certain circumstances. For me it only happens when I switch to a different Ubuntu workspace, and then try to move the xysl canvas. I also find that scrolling the slider once resets this, so that I can move it normally again. Does it work like that for you, or do you get this problem every time you try to move the object?

Thanks for your reply. I cannot create the object [iemguts] on my system, nor it is present in [pd mover3]. I just made some new experiments with your object, and it turns out that I always have to hold Ctrl, click and then move at least 1 single pixel in any direction in order to be able to use this function on my system.

As for the other problem (moving axes when dragging your object), for me it happens all the time, not only under the circumstances you mentioned. I am running pd-extended on a Linux Mint 64-bit, and I am working 99% of the time with a single workspace.

More about this problem: when I open pd, create a new patch, add [xysl] and try to move it, it display the problem mentioned. But if I open the help patch you created and I try to move one of the two [xysl] you have there, they move perfectly fine. Also, when I duplicate a [xysl], if I drag one the other is also influenced by this bug.

Take care!
Gilberto

There is not [iemguts/receivecanvas] object in [pd mover3] because it is in the main patch (xysl.pd), at the very top. You can just put a [print] object here, then open the xysl-help.pd file and see what happens with the CTRL and SHIFT buttons.

Thanks for your help with the movement bug. You are right that any newly created [xysl] is affected by this, although moving the slider sets it straight. I believe that this is something to do with the loadbangs, although I cannot be sure. I'm pretty sure that it's fixable, though, and I'll look into it as soon as I get the time.

print: key 1 Control_L 0
print: mouse 215 144 1 2
print: mouseup 215 144 1
print: key 0 Control_L 0

But still it does not move the cursor to the current mouse position. On the other hand, if I move the mouse at least one pixel, I get:

print: key 1 Control_L 0
print: mouse 215 144 1 2
print: motion 216 144 2
print: motion 216 144 2
print: mouseup 216 144 1
print: key 0 Control_L 0

And then your object snap to the cursor's position.

Thanks again for your efforts, take care!
Gilberto