Hi @alto777, thanks for your reply.
alto777:
I don’t see why you don’t just track the one physical rotary encoder, however you decide, and then use what it tells you to control values elsewhere defending on the state of your program.
Simply put, I don't know how to do that yet!
Of course your advice makes perfect, logical sense, and it's something that I will need to learn how to do.
If the rotary value changes, adjust whatever parameter(s) you are talking to at the moment.
I initially tried to do something along those lines, but ended up getting into all kinds of knots!
So I thought I'd dump all the counters into the ISR....and we know how that turned out!
If you use an ISR, all it needs to do is handle one thing. It is overkill maybe. If you can manage a look at the encoder every millisecond or so in your main loop you be fine.
Of course you're right, it is overkill, but it's the only way I know (so far) to get clean increments/decrements, all the other methods I've tried seem to either only count in one direction (whichever way I turn it) or not count cleanly.
I know this is almost certainly related to switch bounce (and a distinct lack of knowledge on my part), and for sure I will learn how to debounce them more efficiently.
Explain why you’d need to handle, wherever, all six things always.
I don't need to, but I'm struggling to find a way to avoid it.
I really am in need of some nudges in the right direction!
Thanks for the advice @pcbbc.
pcbbc:
Firstly, rotary encoders debounce themselves if done correctly. They output a two bit grey code, and only one bit changes at any one point in the rotation. So there’s no need to do your own debounce, unless you want to make life difficult.
Thanks for the good advice pcbbc, duly noted.
The key part of your sentence however, is '...if done correctly.'
This is the bit I'm struggling with!
That said, it seemed fairly straightforward to add a simple debounce to the ISR.
It works well enough, and I think I can understand it.
Secondly, when you don’t know how to do something, start with one of them and, when you have that working, extend to handle switching between 6 of them.
Quite right. I initially thought I was getting somewhere when I achieved a decent result using a single value, so maybe I tried to 'run before I could walk' when I expanded it to six values.
I would also suggest ditching the ISR, at least until you get the rotary encoder working. Just check the two inputs from the encoder each time through loop, check for changes since last time, and by comparing the grey codes detect the direction of rotation.
Good advice, but I had spent quite a while trying to achieve satisfactory results without using an ISR, and it drove me round the bend!!
I realise that this is mainly because I don't know enough yet...something I am addressing as we speak!
However, when I moved to an ISR, everything just worked perfectly!
I really do appreciate your advice, and the time taken to respond -
There are many libraries available for handling encoders, but if you want to roll your own (good learning exercise, so I’ve no problem with that), however I would suggest studying first to see how it works.
Good advice again, thanks.
So I shall pare down my code again, and start with a single encoder/single value but I think I will be sticking with the ISR approach for now...it just seems more efficient to me so far.
Hi @MarkT, thanks for replying.
MarkT:
void isr () {
static unsigned long debounceLast = 0;
Forgot to declare debounceLast as volatile....
Does it need to be volatile, when it is only used inside the ISR?
Or have I grossly misunderstood the meaning of 'volatile'?
(This is entirely likely!)
Thanks to everyone that has taken the time to offer advice, it is most appreciated! 
