- switch to the voice assignation page
- turn knob 1 to display “Part 2”
- turn knob 3 to set the ‘low’ value
- then slightly thereafter hit a keyboard key to assign that particular note to ‘low’,
suddenly the voice part number is set automatically to “part 1”…
I consider it a bug since continuing to manipulate knob 3 would actually set ‘low’ for part 1 instead of the part that you want to control.
I tried to track it down in the sources but to no avail.
Does anybody else experience this behavior?
ok I think I got it.
commented out this line…:
ui.h:196 //queue_.AddEvent(CONTROL_REFRESH, 0, 0);
…makes it work as expected (the voice assigner UI stays at e.g., “Part 2”), except of course for the refresh, which is done when the ui is idle.
This may be due to the value of CONTROL_REFRESH which is 4.
When adding the event to the queue here:
avril/ui/event_queue.h:62 v.bytes = (U8ShiftLeft4(control_type) << 2) | (id & 0x3f);
the call to U8ShiftLeft4 followed by another left shift by 2 bits make the value equal to 0, which is the same than… CONTROL_POT.
When handling the event, the wrong handler is called, which might lead to the buggy behavior.
Meanwhile I just commented out the addEvent, which is sufficient for my needs. I leave the actual solution to the author as it might need more architectural change.
Weird - on my branch CONTROL_REFRESH = 0xff and the bug does not occur.
Got it. Merge accident between anushri’s (in which there are 4 control types and up to 64 IDs per control - to handle the knobby UI) and ambika’s avrlib branches (in which there’s a fifth control type - the dummy event that causes a UI refresh).
Well it might because of me actually: a while ago I tried to compile your github head version of the ambika firmware, but you forgot to update the github avril tree (no CONTROL_REFRESH).
Hence I fixed it by myself by assigning CONTROL_REFRESH to a new available value (4), and requested you to fix it (and I sent the offending line of code)…
Sorry for that.