Number object too sensitive!!!
Does anybody know a way to reduce the sensitivity of number objects when using a mouse? Or is there an alternative object hidden away in a package somewhere?
I have several number objects in my interface that only cover small ranges of numbers, e.g. 0 -23 for hours, 0-59 for minutes and 1-64 for patch names. I'm finding it hard to control their values because even tiny mouse movements rip through the numbers so fast.
Also, has anybody else noticed that whilst the documentation lists a right justify parameter, it doesn't actually exist in Max 8.2!
It would be amazing if there exists an alternative somewhere out there with more parameters.
Thanks.
What about another transparent numberbox on top?
Yes. Thank you. I already have such an arrangement of invisible overlapping number boxes in place to prevent infinite loops occurring in the patch so adding a divisor in the loop would work I guess.
I got that working ok, thanks. Took quite a bit of reworking as so many things input to and output from these objects in my patch. It's a bit of a sledgehammer to crack a nut but it does the job I suppose.
why don't you simply type the value into number
Yes, I can and do when I know which patch I'm looking for but as I need to point the mouse at the box to activate it in the first place and the object responds to mouse movements, it's a bit daft if it doesn't work like it should. Plus, it links directly to controls on my MIDI controller that use buttons and dials for input rather than numbers. Anyway, I have a solution now that works, albeit with a lot of extra code around it.
Makes not much sense to me.
If you anyway have to click on number then it is selected, and you type
what you want.
There is also option to send only on mouse release,
if last value is all you want.
If used as real time control, slowing down or send only on mouse up is a wrong thing.
But if you hold shift key while mousing in number - it will slow down.
At least it does so on Mac.
incdec
Source Audio - remember that this a GUI reproduction of what my control desk does and so I want it to work in the same way, not least so that both show exactly the same info at the same time whilst I’m scrolling through the options. Doesn’t make sense to me to have two totally different methods of doing the same thing. I’ll try the shift method but, as I have already said, I have worked a solution by putting in a scale factor of 10 around the number object, as suggested by 11Olsen.
Roman Thilenius - Thank you. Yes, I have done that already to match the up/down buttons on my controller.
Not being able to type into number is bad thing in my eyes.
And that is so if you place that / 10 over number .
setting 10 or more instances only by moving mouse is too much work.
click and type is so much faster.
But if that is ok for you, it is perfect for me, just keep it so.
Each to his own I guess. I’d rather not have to use the keyboard if I already have the mouse in my hand.
It probably doesn’t help that I have a high precision mouse in a smallish space so the speed is a bit higher than average (although I still can’t get from one side of the screen to the other without picking it up, and it’s not even halfway up the speed scale). Even so, just holding the button down was enough to make the numbers leap up 5 or more! Taking the value on mouse up is no good as I need to see the names of the patches I’m scrolling through on the control desk.
a mouse tracking multiplication would make it easier to hit a certain number, but i think in any case, i.e. also for a bigger range, using the mouse to scroll in a numberbox is not the fastest way to set a specific value.
plus we have scaling in max (and many other software) these days, which brings up new questions.
otoh i understand that it can make a difference when you want to use "output only on release" or when you dont have a keyboard connected.
btw the other way round is more difficult: recreating the default numberboxes´ mouse tracking behaviour in jitter or lcd seems impossible. if i am not able to recreate it, the original must be really, really good. :)
you know you could "set" the numberbox from its own output?
i did that for n^2 and primes, the latter using a coll as lookup table.
compared to using a second numberbox for the mouse you dont loose keyboard input options that way.
that is a bit strange.
If in system settings mouse is set to middle
it should scroll numbers on per pixel basis.
one can test that by resetting mouse vertical position to 0
on click and watching number and mouse progress in pixels.
would you try this patch
maybe your mouse is having too high resolution,
but than it should be able to make full screen travel easy.
What is your screen size ?
here my mouse and screen settings, I can make the full screen travel with the mouse on 2560 wide screen without lifting it, just by rotating my wrist
and number moves according to pixels.
Just checked my mouse settings (Logitech MX Master 3) and in fact the Logitech settings app DOESN'T alter the system mouse settings. In fact they seem to supplement each other and are not independent. Nevertheless, lowering the system setting whilst raising the Logitech one doesn't make any difference to the overall effect on the number boxes for the same mouse pointer speed. I'm working on a standard laptop (1920x1080) at the moment but when my new studio comes into being it will be across a triple monitor display!
The shift key trick works! Seems to slow the selection speed down by a factor of around 5 (I'm on Windows). Pity that's not documented somewhere.
There are plenty of ways that I could "modify" how the number selection works. The problem is that I'm controlling relatively small number ranges - 1-64 for patches, 0-23 for hours and 0-59 for minutes - and every number increment is necessary. So compared with the sort of ranges that other selections might be used for, it does get pretty sensitive.
It also doesn't help that my GUI controls are programming functions and a display on my control desk and buttons and a dial on the desk are controlling the same things on my GUI, (both displays need to be synchronous) so preventing infinite loops has been a challenge - a few gates were needed.
shouldnt it also travel by pixel when its set to faster? just faster? ;)