Change encoder function based on LCD case

I stumbled on sstaub's multi-parameter box and tried uploading it through platformIO as recommended here(https://community.etcconnect.com/etclabs/f/lighthack/29787/would-it-be-possible-to-have-the-encoders-control-the-intensity-and-color-instead-of-pan-tilt). Now I have all the parameters, but only one of my encoders is working. I tried reloading the original box src to check if it was a hardware issue, but with that sketch the second encoder functioned correctly, so the issue is caused by the new code. In the comment chain sstaub mentions the UNO has a slow/low USB capability, I think this is probably the culprit since the code is reported to work on a teensy.

I'm not sure how to troubleshoot this. When I checked in the diagnostic tab for incoming OSC the second encoder wasn't registering anything. I then tried to open the serial monitor in PlatformIO, but that crashed the box. Is there a way to monitor the serial i/o while connected to Eos to see if the messages are being sent or not? What's my next step is sourcing the issue?

You can't use the serial monitor and a connection to EOS at the same time.
The problem comes up after limited number of parameters, this should tested step by step
by increasing the numbers of parameters and depends also on the name length of the parameters.
Maybe also the implicit messages overflows the Arduino buffer.
The best way is to use a Teensy www.pjrc.com/.../ 
He is is more powerful and there is no real limit of parameters.

Ok, Arduino Uno is no fun, I personaly use a Leonardo or Micro board beause the build in USB is much better and works with up to 16 parameters, but for extented experience the Teensy is the best solution.

Hi, I was wondering if you could help me out again. I picked up a leonardo off aliexpress. It seems to be working fine when I plug it into my macbook, but when I try to use it on my PC Nomad it doesn't recognize it. I appear to be having the same issue described here: https://community.etcconnect.com/etclabs/f/lighthack/24767/using-an-arduino-micro-genuino-with-lighthack-with-nomad-win10

However I can't seem to even find a boards.txt, nor do I know if the PID/VID of the Micro would work for the leonardo. I've looked in the arduino15 folder and have a preferences.txt, but no hardware folder and no boards.txt. Should I just create one?

On macOS the boards.txt is hidden inside the Arduino.app
But the best way is to use Teensy.

Appreciated. I've found boards.txt and edited it with the PID/VID values for the micro, didn't work. I tried copying the values from the Uno, but that also failed. Out of curiosity, how would I go about deciphering what the correct PID/VID to get the PC to recognize my Leonardo? I'll be looking into teensy for all future builds, but I'd like to get this one working since it's already built, and works on my mac.

Some boards can't properly spoof an uno.  If they don't use existing "normal" windows usb drivers it won't matter what you tell the computer they are it won't connect properly.  I know you can spoof teensy boards as Uno boards but I don't think a leonardo will work... I would be happy to hear differently if anyone has done this.  When I get some time I will try some additional leonardo tests to see what needs to happen to make it work.

Much obliged, I was afraid that might be the situation. Guess I'll be picking up some teensy now.

teensy is good.  If you just need loads of pins you can use an mega2560 and it should work with the console.

The issue isn't pins it's the serial connection, I think. Admittedly this is reaching the limit of my understanding, but it was suggested in another post that because of how the serial is setup on the Uno it isn't able to map multiple functions to one encoder. It was also mentioned that a Leonardo was able to handle multiple pages per encoder. Since the Leo is cheaper than a teensy I went with the Leo, but am running into issues with Eos recognizing it. 

Long story longer - do you happen to know if the mega will support multiple encoder pages, or will I have to hard link functions to encoders? I'm happy to go with a teensy, but if megas are cheaper then that would be a good option for the tool bag.

The problem is the USB connection of UNO/MEGA, it is to slow to handle the connection to the console,
also the ring buffer is a problem. Personally I've never used a Micro/Leonardo on a console only for Nomad. A Teensy 3.5 will be the best choose because the chip is fast enough to handle the connection.
On a beta version of the Eos software it was possible to connect the serial with a lower speed like 9600 baud, which also helps, but it doesn't work any more on Nomad.

I've currently got an 18 encoder with 18 button device running on a mega 2560 with no issues.  The teensy do work better especially when you are moving multiple encoders at the same time but the Uno and mega can handle many of the simpler setups people want to do. The micro, leonardo, and many clones that need custom drivers to do usb serial is that the console either doesn't have the drivers or the console software isn't looking for them to connect.  

I made a list of micro controller models and their response with the ETC test sketch on ETC's light hack GitHub.  These were all made connecting to a console and documenting whether the console attempted to connect and if it did attempt did the micro controller send a response back.  After doing those tests the underlying Osc library was updated which made a few additional boards work properly.

I've currently got an 18 encoder with 18 button device running on a mega 2560 with no issues.  The teensy do work better especially when you are moving multiple encoders at the same time but the Uno and mega can handle many of the simpler setups people want to do. The micro, leonardo, and many clones that need custom drivers to do usb serial is that the console either doesn't have the drivers or the console software isn't looking for them to connect.  

I made a list of micro controller models and their response with the ETC test sketch on ETC's light hack GitHub.  These were all made connecting to a console and documenting whether the console attempted to connect and if it did attempt did the micro controller send a response back.  After doing those tests the underlying Osc library was updated which made a few additional boards work properly.

See your trick, you filter out the eos/out messages and subscribe only the messages you actual need. I will give it a try.