dnk777

I'd like to understand better two things.

First of all - where is the mousedrag sensitivity of numberboxes set?

I didn't find it in attributes and the default is very often too sensitive for me. For example, if you have numberbox for entering midi instrument number or bar length, even +-1 inaccuracy does matter a lot and having 1px = 1 of value is just crazy.

and yes, you can use keyboard to just type in, but sometimes it's more convenient to use mouse (if you already hold it) + also you need to click on it once before typing, and the numbox is so sensitive, that if you move your mouse a tiny bit while clicking (this happens when you work fast/during a performance), you'll not only select it but also change slightly by the mousedrag feature.... (then i thought that maybe i'll just disable the drag feature, but i did not find that possible. there are "cantchange" and "ignoreclick" attributes but both of them the prevent me from enter the numbers using the keyboard too (aren't they redundant?))

i even tried to hack the sensitivity thing by layering an invisible (0 alpha) numberbox with bigger range over a visible one, so that when you drag the invisible one, the values are divided and send to the visible one... this works for mousedragging, but then entering the numbers with keyboard is impossible, because you enter number into the invisible one which is then divided and you don't want it to be divided when entering using keyboard.

anyway, i believe that some sensitivity attribute in the numberboxes would be a HUGE improvement + it's not a treating backward compatibility in anyway + i believe it would be very easy to implement (max doesn't seem to be opensource so i cannot check).

i believe that while numberbox is one of the most common UI element (how many patches without any numberboxes have you ever seen?), it would deserve much much much more attention to details like this.

what is the real purpose of the triangles? only useful thing i found about it, is it's highlight colour that shows even when you just select a numberbox. i don't see why, but it's actually the only thing that changes when you select a numberbox (before entering numbers with keyboard). the text's highlight colour does show up only while dragging and same for background highlight.

in some very dense patches (where i cound pixels to fit everything) i find it quite annoying, that i have to waste space on the triangles, just so I can see when i click/select a numberbox (so i know that now i can type on keyboard). I believe having an option to have the text highlighted as well (not only triangle) when numbox is selected (=not only while dragging) would make sense, so if you're tight on space, you could just disable the otherwise meaningless and just space-wasting triangles.

or maybe setting sensitivity is possible in max and i'm just too dumb to find out how? please, let me know. thanks

I'd like to understand better two things.
First of all - where is the mousedrag sensitivity of numberboxes set?
I didn't find it in attributes and the default is very often too sensitive for me. For example, if you have numberbox for entering midi instrument number or bar length, even +-1 inaccuracy does matter a lot and having 1px = 1 of value is just crazy.
and yes, you can use keyboard to just type in, but sometimes it's more convenient to use mouse (if you already hold it) + also you need to click on it once before typing, and the numbox is so sensitive, that if you move your mouse a tiny bit while clicking (this happens when you work fast/during a performance), you'll not only select it but also change slightly by the mousedrag feature.... (then i thought that maybe i'll just disable the drag feature, but i did not find that possible. there are "cantchange" and "ignoreclick" attributes but both of them the prevent me from enter the numbers using the keyboard too (aren't they redundant?))

another detail: TRIANGLES
what is the real purpose of the triangles? only useful thing i found about it, is it's highlight colour that shows even when you just select a numberbox. i don't see why, but it's actually the only thing that changes when you select a numberbox (before entering numbers with keyboard). the text's highlight colour does show up only while dragging and same for background highlight.
in some very dense patches (where i cound pixels to fit everything) i find it quite annoying, that i have to waste space on the triangles, just so I can see when i click/select a numberbox (so i know that now i can type on keyboard). I believe having an option to have the text highlighted as well (not only triangle) when numbox is selected (=not only while dragging) would make sense, so if you're tight on space, you could just disable the otherwise meaningless and just space-wasting triangles.

or maybe setting sensitivity is possible in max and i'm just too dumb to find out how? please, let me know. thanks


numberbox-sensitivity-purpose-of-the-triangle

"Sensitivity" is controlled by where you click in the number box (left to right). So if you click all the way towards the right you will scroll 0.00001 etc...

Unless you knew that and you meant what controls the speed that the scrolling actually moves (I would imagine that would be OS based).

You can disable triangles -> Get Info, uncheck 'Draw Triangle'.

You could even use the Universal object to get rid of all triangles in a patch - I often do when space is getting tight,

You can disable triangles -> Get Info, uncheck 'Draw Triangle'.
You could even use the Universal object to get rid of all triangles in a patch - I often do when space is getting tight,
Cheers
Roger


Rodrigo: That works for me only in floatboxes. For integer boxes it does not work for me at all (max6 latest patch).

+ if it would work for integer boxes like that, then to make it really useful, we need some control over it - being able to set the lowest and highest sensitivty in attributes.

The needed sensitivity is defined mainly the purpose of the numberbox.

It's crazy to have users think (during doing 10 other things on stage) about left-right position before each dragging of the numbox. that's really just crazy. I believe that developers should be able to adjust the sensitivity for each numberbox according to it's purpose. Even constant would be ok for me. If on both (left/right) ends, then it's ok too. But being unable to adjust that is frustrating.

for example, If you have a numberbox to choose midichannel (range 1-16) then you certainly don't want 1px = +8 value even if you drag it anywhere. you want to set it precisely, because even if setting channel 11 instead of 10 is just 10% inaccuracy, it's also 100% useless to send data to midi channel 11 if your synth is listening on channel 10.

Rodrigo: That works for me only in floatboxes. For integer boxes it does not work for me at all (max6 latest patch).
+ if it would work for integer boxes like that, then to make it really useful, we need some control over it - being able to set the lowest and highest sensitivty in attributes.
The needed sensitivity is defined mainly the purpose of the numberbox.
It's crazy to have users think (during doing 10 other things on stage) about left-right position before each dragging of the numbox. that's really just crazy. I believe that developers should be able to adjust the sensitivity for each numberbox according to it's purpose. Even constant would be ok for me. If on both (left/right) ends, then it's ok too. But being unable to adjust that is frustrating.
for example, If you have a numberbox to choose midichannel (range 1-16) then you certainly don't want 1px = +8 value even if you drag it anywhere. you want to set it precisely, because even if setting channel 11 instead of 10 is just 10% inaccuracy, it's also 100% useless to send data to midi channel 11 if your synth is listening on channel 10.


roger carruthers: yes i know that, but then you don't see any change after you click/select a numberbox before typing in a number with keyboard. selecing a numbox by clicking (before entering numbers with keyb) does highlight only a triangle (why?) and not the text and makes the gui bit more confusing. i want the user to see that he selected the numberbox. right now you can't do that without the triangle. superannoying to me. would swap all the fancy hi-level (but hardwired and thus useless) objects for a REAL numberbox anytime.

That's a whole philosophical thing, but if youre performing, why are you using a mouse to control a tiny number box on the screen? Surely a midi controller, or anything else really, would be better.

Alternately you can use a float box and limit its value, and scale it to the range of ints you need.

That's a whole philosophical thing, but if youre performing, why are you using a mouse to control a tiny number box on the screen? Surely a midi controller, or anything else really, would be better. 

Alternately you can use a float box and limit its value, and scale it to the range of ints you need.


Note that in Max5 there is the live.numbox object with some useful parameters (eg. 'steps').

broc: you are right. the live.numbox seems to have this sensitivity option. too bad it's visually totally inconsistent with the ordinary max gui elements. if there isn't any workaround for adding sensitivity to the regular numbox, then i'll have to decide if i'll make my app look like some ugly amateur school project with inconsistent gui element (but ok sensitivity), or if i make it look ok, but will feel like like some crappy amateur school project with inadequate mouse sensitivity.

rodrigo: midi controllers are great for some purposes, but useless here. I prefer to work with analogue hw anyway, and I do so where i can (90%), but after spending lot of money on HW sequencers and being disappointed by all of them (and midi controllers would be useless for me in a similar way) I decided to create my own sequencer in SW, mainly because I can use mouse and monitor there. with mouse, the UI elements can be much smaller (cursor being smaller than fingers) and monitor can display so much more on the same physical area, than most physical multicolor buttons. and so you have space to put more features there.

also, in sequencer you don't control parameters in realtime, that's why I don't really need physical knobs.

but sure, it would be possible in HW too, but it would have to be custom (no midi controller from shop would do), and it would be huge and very expensive (i need to display 15 rows of 64 steps and in each step there are 15-32 possible shades of colours + ideally small symbols over some of them. would costs thousand eur at least just for the physical UI parts).

rodrigo: midi controllers are great for some purposes, but useless here. I prefer to work with analogue hw anyway, and I do so where i can (90%), but after spending lot of money on HW sequencers and being disappointed by all of them (and midi controllers would be useless for me in a similar way) I decided to create my own sequencer in SW, mainly because I can use mouse and monitor there. with mouse, the UI elements can be much smaller (cursor being smaller than fingers) and monitor can display so much more on the same physical area, than most physical multicolor buttons. and so you have space to put more features there.
also, in sequencer you don't control parameters in realtime, that's why I don't really need physical knobs.
but sure, it would be possible in HW too, but it would have to be custom (no midi controller from shop would do), and it would be huge and very expensive (i need to display 15 rows of 64 steps and in each step there are 15-32 possible shades of colours + ideally small symbols over some of them. would costs thousand eur at least just for the physical UI parts).


Personally I'm using live.* GUI objects whenever possible and find it looks quite "professional" even when combined with some other GUI elements like eg. multisliders.

broc: yes, if i would be starting the project now, i would seriously consider this, but at this stage of development it would mean weeks of work redesign and repatch gui to live.*

(ironically the patch i'm working on now has a working titles "abletophobiac" and "unable tone" :)

anyway, adding sensitivity attribute to regular interger numberbox is still needed in my opinoin. I believe it wouldn't take the developers much time. or is it somehow possible for me to do it myself? (afaik the source is totally closed?)

broc: yes, if i would be starting the project now, i would seriously consider this, but at this stage of development it would mean weeks of work redesign and repatch gui to live.*
(ironically the patch i'm working on now has a working titles "abletophobiac" and "unable tone" :)

anyway, adding sensitivity attribute to regular interger numberbox is still needed in my opinoin. I believe it wouldn't take the developers much time. or is it somehow possible for me to do it myself? (afaik the source is totally closed?)


If you hold down the shift key, there is less sensitivity.

I too have been regularly frustrated by the integer and float objects. After clicking on one of them there is no obvious indicator that you are in an edit state. A couple of times now i've accidentally typed numbers in to boxes because I didn't know they had focus. Id much rather see a standard edit state where the value is highlighted by default so I can type in a replacement value.

I imagine this was avoided due to the interaction differences between a click and drag vs a click and release, as Max appears to be almost entirely action-on-down, which makes sense. Number boxes, however, have no action on down that I can find. You could click and release a number box to enter a value-replacing edit state, and not allow drag selection of separate numbers within the value. This way any click & drag in the box adjusts the value, but a single click gives you an obvious visual selection of the entire value in a manner the user is accustomed to with text editing. Perhaps you could still allow individual number selection with the arrow keys and shift, but I haven't thought through that part much yet.

At first I thought the little triangle was a disclosure button, as thats a pretty standard graphic in interfaces, but clicking it doesn't seem to do anything different than clicking the value. Is the sole purpose of the little arrow to indicate the value is being edited? It's an "active" indicator? Why is it unique to the number boxes? Where are the active state indicators for sliders, text edit boxes, umenus, toggles, dials, etc? It is very inconsistent and confusing. Seems silly to waste pixel space on a unique graphic for a single object type to indicate it's state. Sure I can turn it off, but then I have absolutely No indication its being edited. Almost every object has a stroke and fill, why not use that for all UI objects? I believe the Tab object currently has this capability.

The float click-drag sensitivity was a little odd until I played with it a bit more and figured it out on my own. Its quite a nice little feature, and very handy once you know its there. The Help doesn't mention this, and the reference alludes to it at the top but doesn't specifically state the behavior until you get further down to the messages section, which isn't obvious to a new user. Since the integer and float values are (always?) left aligned, it may make sense to apply the same behavior to the integer box. Click drag in the right area would be like incrementing the tenths place if it were there. This might just be more confusing, as then the user may believe they are adjusting values that are not actually there. It would be a nice bonus for consistency tho.

Holding shift while dragging is interesting, as on an integer it Does appear to decrease the mouse interaction sensitivity. However, on a float, it increments/decrements the value to the left of what you selected. Again, inconsistent and confusing.

Manually setting the mouse sensitivity would be nice for all UI objects, especially when they have a small range to begin with. If given the choice, i'd rather see a global setting for those of us on rather large desktops. I think All the boxes are too fast, likely because my mouse is set to be rather fast to get around my desktop.

Im not trying to rant here, just giving feedback on my experiences. I'm a UX designer by profession, and cant help but notice and report such things when i'm passionate about the project. I've been hitting Max pretty hard the past couple of weeks, becoming even more excited by the power, documentation, and community. I'm just constantly frustrated by the inconsistent, unrefined, limited, and often confusing interface. I've worked in a number of different node based patching environments on both mac and pc. Yet, at the end of every day I spend in Max, I question what the point of a node based interface is if i'm constantly fighting it. I begin to wonder if my time investment would be better spent on advancing skills with actual written code.

I too have been regularly frustrated by the integer and float objects. After clicking on one of them there is no obvious indicator that you are in an edit state. A couple of times now i've accidentally typed numbers in to boxes because I didn't know they had focus. Id much rather see a standard edit state where the value is highlighted by default so I can type in a replacement value. 

Im not trying to rant here, just giving feedback on my experiences. I'm a UX designer by profession, and cant help but notice and report such things when i'm passionate about the project. I've been hitting Max pretty hard the past couple of weeks, becoming even more excited by the power, documentation, and community. I'm just constantly frustrated by the inconsistent, unrefined, limited, and often confusing interface. I've worked in a number of different node based patching environments on both mac and pc. Yet, at the end of every day I spend in Max, I question what the point of a node based interface is if i'm constantly fighting it. I begin to wonder if my time investment would be better spent on advancing skills with actual written code.


Some great points on here. I know a lot of the issues stem from compatibility, as number boxes are probably one of the oldest objects. "Ignore Click" came a lot later than "Can't Change", I think, so they are redundant (if I'm wrong let me know!) -- note that other objects don't have "Can't Change", but they do have "Ignore Click", which is great.

Rolling your own is probably the best bet, maybe you can work some magic with [jsui]. The examples in it have sensitivity controls which you could utilize, though you'd have to create the number display part, and I don't know about floats...also [jsui] is a lot slower when you get a lot of them going at once.

Anyway, some tidbits in the example patch below, maybe will give a few more ideas:

You are probably correct about these being some leftover behaviors from versions long past. It is tremendously difficult for a small team to push the envelope as hard as cycling is obviously doing with Max and still sweep up after themselves. Not to mention possible compatibility issues with the wealth of existing patches people have. Of the solutions I myself have been involved with in such areas, none of them are easy to implement, especially after the fact. As someone who's experienced with software development, I sympathize, as a new user to an exciting suite of tools, i'm confused and frustrated.

Those are some nice examples. I've started building up some of my own controls as clippings, which is a handy system once you are a proficient user. The jsui object seems like a great tool, but I feel a lot of this stuff should be in the common, provided elements. I get the impression that jsui is there for custom designed user-facing interfaces, where as a lot of my frustrations are with the interfaces for the developer as well.

I was going to bring up the lack of tab select as your patch highlights, but it was a little off topic and im already sounding like a negative-nancy. Tab select between values, even if only when locked, would be Greatly appreciated.

There is a nice feature to select objects themselves with the keyboard while in edit mode that I discovered while trying to find tab-select. If you hold Cmd/Ctrl+Shift and Arrow around you can select objects relative to the one you are on. Very handy, and I don't remember seeing it documented anywhere.

I was going to bring up the lack of tab select as your patch highlights, but it was a little off topic and im already sounding like a negative-nancy. Tab select between values, even if only when locked, would be Greatly appreciated. 

There is a nice feature to select objects themselves with the keyboard while in edit mode that I discovered while trying to find tab-select. If you hold Cmd/Ctrl+Shift and Arrow around you can select objects relative to the one you are on. Very handy, and I don't remember seeing it documented anywhere.


Hey, that's cool. On my mac it's just Cmd+arrow to select around, no Shift needed.

But, "lack of tab select"? I thought my patch showed that you can do that by using the right outlet. But maybe I'm misunderstanding what you mean.

You are correct, the shift isn't necessary. I was foolishly working off memory instead of using the app when posting. I should know better.

Your patch exhibits a great little trick to make tab select work when the patcher is locked on number boxes you manually set up, and i'l certainly put it to use. However, it only seems to work with number boxes; buttons, toggles, menus, etc do not understand select and don't have a "bang when tab key pressed" out. Its also very odd to have to manually string these up for every integer and float I add to a patch. Does the tab key have some other function im not aware of in Max?

I don't think the other objects have a select function simply because they don't understand key input (except jit.cellblock, textedit, others?). In other words, selecting them in Locked mode wouldn't make sense, they're mouse-driven (or programatically controlled with messages, as all objects can be).

[umenu] would be nice to accept "select", because once selected it responds to arrow-key selection and Enter to choose.

Not sure about other function for the Tab key, I'm not aware of any...but things do hide in Max... :)

aargh! I have to say that I still find the two imperfect numboxes in max so stupid and SUPERANNOYING and makes me so angry.

by superannoying, i mean that i ended up wasting hours with changing all regular number boxes into live.numboxes (with transparent background + rounded panel behind them, to match the look of the rest of the regular gui elements) in one quite big patch, only to find out, that with these live numberboxes i'm not supposed to change their Range? Working in Max I sometimes feel like throwing my computer out of a window.

PLEASE, what should I do, when I need a numberbox with less than 1px=1 of value sensitivity, but also with range that can be changed by message?

and no, i can't roll my own using something transparent over the numberbox to make lower drag sensitivity, because then i can't click on the numbox and set number with keyboard.

aargh! I have to say that I still find the two imperfect numboxes in max so stupid and SUPERANNOYING and makes me so angry. 

and no, i can't roll my own using something transparent over the numberbox to make lower drag sensitivity, because then i can't click on the numbox and set number with keyboard.


edit: (i mean integer boxes / not floats.)

- version 6 of Max (with all the fancy high-level super complex objects) still don't have any integer numboxes (regular one and live one) with sensitivity settings

- regular integer numberbox can be tricked to be less sensitive, by putting a transparent integerbox over it with n-times bigger range sending it's output to [/ n] and into the visible numberbox, but doing this you lose the option to set the number using keyboard.

- live numbox has 'steps' attribude (number of pixels you have to drag up to get from minumum value to maximum) in "float" type mode + you can trick user to think it's not float but integer by setting 'unit style' to "int", showing only round numbers, but in reality, if users sets value to 2 by dragging, it can be anything between 2.0 to 2.9 and if it's 2.8 for example, then dragging sensitivity from 2 to 3 is totally different than from 2 to 1. so it's not really sensitivity, it's a trick.

- if you decide to use the trick mentioned above, then you have to round the number + add [change] object after rounding (so it won't bang more often than necessary) and also have to beware of things you cannot do with live.numbox - for example setting range of live numbox with messages is impossible. (anything more?)

- Max is in development since 1990 and today in 2012 one of its most fundamental gui element still sucks.

numberbox sensitivity + purpose of the triangle?