Bug? Bug: Can't click to directly type values in controller Min/Max value fields

6stringscott

Inspired
It's been there for a few releases at least, and it always annoys me but never stops me from what I'm trying to do. Other fields you can click the mouse and directly type in a number, but these ones you have to use the mouse to "turn the knob" by left-click and dragging up or down. That is a little extra work (I use a laptop touch pad, not a real mouse), and it's hard to get the *exact* value. The exact value doesn't matter for the sound but it shows I might have a touch of OCD when I see "-5.97" when I want "-6.00". And it's annoying for multiple drags of the mouse to go from -80 dB as the min value to something like 0dB as the min value when using a controller to adjust the level of the Wah (e.g. so you can turn down the level a bit as the treble spikes on the Wah to take the sharp edge off- sometimes I do 0dB for min and -6dB for max to achieve this).

I'm pretty sure it is the top leftmost two values in the controller edit screen... but sorry if my description is vague. I'm not in front of the unit right now and going from memory. I never want to stop and report the problem when I'm in front of the unit and editing stuff and I encounter it.
 
i know what you mean and it's been bugging me for ages too. you can get fine control by holding down the ctrl key (on a mac, don't know what it is on a pc), so you can get precise values, but it is pretty frustrating, i agree...
 
It's related to the way those values are set and queried on the hardware. Not so much a bug as the-way-it-is. It's been reported and turned down in the past.
 
Regardless of what AxeFx hardware limitations may exist, or what protocol limitations between AxeFX and AxeEdit may exist, these things are mostly independent of the user interface software in AxeEdit for how to present data or manipulate it.

The only dependency I can imagine would be if the AxeFX doesn't allow every discrete value of .01 increments and you try to type in such a value. It would be a simple case of catching that and rounding up or down if the user clicking on the field and typed a value between the supported discrete values.

So it may not be a high priority to fix compared to software issues that break a user's workflow, but this is a legitimate annoyance that would be a very simple fix only on AxeEdit side with zero dependencies for code in AxeFX firmware.
 
It does seem like a limitation of the GUI to me also.

Would love to be able to keyin values in modifier dialogs.
 
So it may not be a high priority to fix compared to software issues that break a user's workflow, but this is a legitimate annoyance that would be a very simple fix only on AxeEdit side with zero dependencies for code in AxeFX firmware.
Having known both the developer of Axe-Edit and the developer of the Axe-Fx's firmware for quite some time now, I feel pretty confident saying if it was possible it would have been done. Neither are people who shy away from a technical challenge. Your armchair assessment that it's simple is baseless.
 
Maybe they forgot about it? Don't remember any reaction from the boss on it.

It is a nuisance. Also weird that those are just about the only parameters that can't be typed in. Very frustrating for an autist like me...
 
Having known both the developer of Axe-Edit and the developer of the Axe-Fx's firmware for quite some time now, I feel pretty confident saying if it was possible it would have been done. Neither are people who shy away from a technical challenge. Your armchair assessment that it's simple is baseless.

I don't know the developers. I do understand software design principles, having been involved in the development of a variety of distributed computer and networking systems within silicon valley startups and leading global hi-tech equipment vendors for the last 20 years, using web and application-based GUIs and a variety of back-end protocols between different system elements with different constraints for latency, jitter, and data integrity. I think I can conclusively say that NOTHING in a back-end communication protocol or limitation in an external system element can cause a GUI slider data entry mechanism to be acceptable where direct numerical keypad entry would be unacceptable.

I say this not to be inflammatory or start a pissing contest, but rather to separate real from spurious technical obstacles to resolving the reported issue. Fixing this type of problem is truly trivial compared to other signal processing tasks that AxeFX performs- both in terms of conceptual complexity and in terms of coding complexity. Everything in AxeEdit is much simpler than what AxeFX must perform, so this may not be trivial compared to other AxeEdit bugs or features, but it is still pretty easy. AxeEdit already has the libraries/routines to provide the desired GUI handling (click on box, type desired value), but may require a new simple routine to round the entry up or down to the nearest discrete value supported by the back end variable. Maybe there is greater complexity if one desires to solve the problem generically by querying the AxeFX to discover every possible valid value for a specific variable upon clicking that variable box, rather than maintaining an array/database of enumerated possible values for every variable. But keeping a local database/array in the AxeEdit would be a more reasonable approach if AxeFX does not already have an optimized queryable or bulk download mechanism to gather this data.

Anyways, this stuff is NOT hard compared to the other awesome stuff that the product team has done. I still understand if it is not highest on the priority list, and I'll wait until they get to it. But I won't accept an answer that it's impossible or too hard because it's not.
 
I just realized I was not using the latest release version of AxeEdit (I was on 3.1.1 rather than 3.3.1), and thought perhaps I was making a fuss for an already-fixed issue. But I just upgraded and checked: the problem is still there, but I observe a clarifying pop-up note saying "Min and Max cannot be edited through direct entry. Their range of values depend on the parameter being modifed."

I can see that approach when in a triage mode trying to get the software out and fix core functionality bugs, but this CAN be fixed in a better way, and I want to keep it on the radar.

Two ways that would be better to fix it:
(1) Let GUI entry of Min/Max values be entered between 1-10, and converted to the back-end variable's range
(2) Have a lookup table of enumerated values acceptable for each variable, and perform that data integrity check at the time of user pressing return after entering a value.

Option 2 would be preferred, because then users can set the exact value range based on the numbers they are accustomed to using for the variable when not using a controller.

In any case, this problem of translating from min/max 1-10 to the underlying variable number range was solved one way or another as part of implementing the slider approach. Maybe it is all a bunch of spaghetti code with a bazillion if or case statements in the slider function libraries and a hassle to separate out? Pure speculation on my part, but not relevant. The problem can be fixed, it's not a real technical/systemic limitation.

Thanks in advance- I'm not trying to be a nuisance, just trying to give honest feedback on what would make a great product even better.
 
Back
Top Bottom