No UI-less variant possible anymore?
Seems any combination of undefining ENABLE_LCD_UI and / or STANDARD_LCD_I2C lead to broken code (plenty of errors, not compiling) now. So it is not possible to run UI-less anymore?
This would be useful to allow for custom UIs use all those pins tied to LCD and Encoders otherwise. I've already used this and now I am stuck to older revisions where this was working.
Hmmm, I have not paid any attention to an operation without a display so far. In this respect, it may well be that some error messages appear. That would have to be fixed somehow. I pack me on the ToDo list.
Actually there seems to be a lot of LCD code intertweened everywhere now. So it would not be easy to clean that up anymore.
But maybe it is possible to define dummy stubs for the main LCD / menu methods if ENABLE_LCD_UI is undefined. I will look into that later.
This won't work out too. The UI function names (like UI_func_chorus_level etc.) are used everywhere, so there is no way to provide a sane empty dummy implementation of the UI.
So maybe it's possible to have the UI code running, but don't read encoders and write LCD at the end. Looking into that now.
Hm, yes - the code is a little bit ugly - sorry for this. I am not the best C++ programmer, so there is much optimization possible.
It would be very nice if you have time to fix this. I would be very happy about PRs!
I think the LCDMenuLib2 is also to blame for this. It seems it is designed for small codesize and speed by using a lot of macros and implementing the menus in a very static fashion. So if one follow the path of LCDMenuLib2 by building on examples or docs, this creates a lot of "administrative" code just to get the UI running.
I would like to have some abstractions removing the need for a lot of repeated code and some of the mappings between:
UI Menu items <-> parameters <-> configuration storage location <-> MIDI CC oder SysEx parameters <-> DEXED engine parameters ( <-> DX7 voice SysEx format )
Because currently adding some parameters to the DEXED engine, that are controllable by MIDI and the UI menu would need code additions in a several locations.
This said, I would like to refactor this, but as I am only owning UI-less MicroDexeds, this is not currently not feasable. What I may try are small improvements (eg. fixing the #define bugs), but relying on you or others for testing if the UI still works.
I used LCDMenuLib2 because I had no idea how to build the menu. After the menu items and structure was growing I had to make some workarounds and now it is usable, but as you mentioned, not very portable for other displays.
Maybe it would be an option to include the code for other displays in LCDMenuLib2? But probably this is also very time consuming.
So: Would it be helpful if I sent you a I2C LCD display? Or just a complete kit (without Teensy and audio shield, so you have a reference model?
Deleting a branch is permanent. It CANNOT be undone. Continue?