No UI-less variant possible anymore? #33

Open
opened 1 year ago by dronus · 7 comments
dronus commented 1 year ago

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.

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.
Owner

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.

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.
Poster

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.

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.
Poster

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.

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.
Owner

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!

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!
Poster

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 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.
Owner

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?

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?
Poster

I can try to rework the UI code to make it optional and easier to maintain.
Would be cool to have a complete kit then (with casing).

But I am quite busy in the following weeks, so I have to come back later to this, I will notify you when I am ready to start.

I can try to rework the UI code to make it optional and easier to maintain. Would be cool to have a complete kit then (with casing). But I am quite busy in the following weeks, so I have to come back later to this, I will notify you when I am ready to start.
Sign in to join this conversation.
No Label
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.