Sometimes when i enter the Track Quantize-Settings - press “2ND + Track#” - i cannot change any setting with the Encoders.
It’s completely random.
I already reported it to Squarp.
Can someone test if it appears for him too?
create new project or just start Hapax
go to Quantize Menu - press “2nd + Track#” - try to change Quantize to 1/16 - notice how it scrolls instead of changeing the quantize setting ?
if i press that quickly 3 times while holding 2nd it always works
I expedited this last night. No idea what sequence causes it. I’ll give your steps a try.
i did a few more tests , it seems only to happen on Track 1-3 … i tried for each track 10 times… for Track1 it usually happens within 3 trys … for tracks > 4 i never managed it.
Could be a hardware issue.
it seems fine here…
that said im not quite sure what you mean by
do you mean the right window is scrolling, as if the root note is chaining (!)
as if the 2nd+Tracks menu is not displayed/active,
if so this is interesting, as whilst I cannot reproduce it with your steps…
I did once have this in the beta… though with the track IO menu.
but it was only once and was (unfortunately) completely random,
Id been using the hapax for a while, so switch views, been in and out of the Track IO dialog, all fine.
then, suddenly this happened… id go to change the import port, and the notes view scrolled instead.
it felt like the hapax didn’t know the track io window was open… yet was displaying it.
I reported, but its was so random, really nothing to go on… as I could never reproduce it.
on the surface, seems doubtful… as the 2nd+track is bring up the dialog, so buttons working, and if the encoder is scrolling something, then it too is working
that said, I wonder if theres some odd ‘debouncing’ behaviour?
do your track 1-3 buttons feel any different, do they feel like they are moving freely or getting stuck?
if it is a debouncing issue, I could be it will be different tracks on different units. unless it related to the proximity of 2nd and T1-3?!
(good news is debouncing issue, can often the resolve in firmware tweaks.)
Ive just got my production unit, and have noticed the buttons feel a bit closer/tighter to the faceplate than my early unit (*) … BUT it could just be that Id ‘worn’ the other unit in a bit, as it does feel like they are already loosening on this unit.
(*) in fairness, I could rephrase this and say the production unit is better fitting … which is what you’d expect 
yes exactly… Hapax “thinks” he’s still in the default window not track window…
i’m in closer contact with the support now - i’ll post updates in this thread.
however it would be interesting if other people experience that too
yeah, so thats what I had… but only once ages ago, but just assumed it was a software fault, as it never happened again. (which of course, may also be true!)
and nope, tried really hard to reproduce here… (and on every track) couldn’t reproduce it.
btw: might be interesting to see if you can get the same with the track io window… so just press track , then change the input port…
if it happens there, this would
a) eliminate the 2nd button from the equation.
b) not fixed to the track settings (quant) dialog
no the track window works in 10 of 10 trys correctly
this kind of speaks against there is a hardware issue because:
EXCEPT there is something happening when pressing both button together , because they are physically closer to each other
yeah, feels like a debounce issue (*) , thats probably not being picked up in the firmware correctly.
(the fact its unit dependent , and also certain buttons - are tell tale signs)
so seeing a second press of the track button very quickly after the first(debounce),
whats odd, seems like one bit of the code is acting correctly (dialog) , and another isn’t (encoder assignment) - hence the discrepancy.
debounce code is quite easy to implement and improve but its a pain in the neck to test, as different units will behave differently (not so much a fault, rather manufacturing tolerances and all that)… so almost impossible to reproduce.
with a bit of luck they can just up the debounce time a little, basically make it a bit more ‘conservative’ … and it’ll be solved.
(*) proximity can affect travel, hence why I said it may be a part of the issue
worth being tested … i mentioned this thread to the support… maybe they can prepare a certain firmware for me to test it
interestingly the same just happend in the patterns screen when trying to adjust the Track settings - Midi Channel - instead of changing the Midi Channel it changed the Mode from perf to Song
yeah, as above, not surprised at all really… its expected behaviour for a debounce issue, which is generally dealt with at a lower (code) level than a particular UI function.
so whilst unfortunate seeing it causing issues elsewhere, it does help to isolate/focus where the issue is, and so hopefully get to a speedy remedy.
same just happened to me too.
goung to another track, just for test, helped,
going again to another track, again: not working
I am also having a few different “random” malfunctioning things like this.
Quantize, Effect on/off, etc.
Here and there, from time to time, things don’t work as they should.
I submitted a report, and was asked to try to document these quirks and send them in via video clip so they can see what’s happening when it’s happening.
Naturally nothing weird has happened since… but I’m ready!
I suggest you join me, and when something goes weird, before you clear it out, make a little clip of it and send it in to HQ so they can see, and help correct these.
i already sent them a video …
I totally recommend everyone doing that too, just to help them understanding the issue.
ideally, you need to show what leads up to the issue… rather than it actually happening.
i.e. devs will believe you that it occurs, thats not needed to be proved 
what they really want to find is a way of reproducing it for themselves so they can debug it!
if my suspicions are correct, I think important aspects of this are:
the encoders are more a side effect as far as I can tell, some bit of hapax thinks its in a different mode, and the encoders are working on that basis… but its the buttons that put it in that ‘mode’.
so the question is why is there a mixup on mode?
so which modes are involved , and what buttons get there.
what will be interesting here is… if different users (and so hapax units) have different buttons being affected… ie. so, different users have different combos , and cannot (generally) reproduce each others.
this will help, identify that is less likely to be a ‘functional’ issue, but rather the lower level button handling.
one thing Ive noticed is, my production unit has a tighter finish on the faceplates to the buttons.
Ive seen occasionally, buttons sticking.
this is completely impossible on my prototype unit (likely hand finished), they just fit differently, which was used for beta testing.
I do a feeling this is improving as the production unit is used, feels like its ‘wearing in’.
(I did consider getting fine oxide sandpaper to clean edges a bit see if this helps, but id not recommend it, as it might mark the faceplate… and not covered by warranty!)
note: as above, if anything, Id say the production unit faceplate is finished better, better fitting… but
thats interesting.
i was several times under the impression, that pressing the track buttons, has had an influence if something changed “its mode of operation” …ie. working/or not.
while never any other type of buttons gave me such “feel”.
allways the track buttons
This bug will be fixed in an upcoming firmware update.