So… show graphical representations of the algorithms #507
Replies: 7 comments 4 replies
-
|
Hi @patrickdowling, welcome! #418 has some discussion on the subject. We started out with 16x2 character displays (like on the original DX7). Each character there is 8x5 pixels, and as far as I know we could define our own characters. This is what is shown e.g., on https://github.com/probonopd/MiniDexed/wiki/Menu. Then @diyelectromusic added support for SSD1306 OLED I2C displays, #312. I asked at #312 (comment) about the possibility of graphical symbols, and @diyelectromusic answered
In order to not make everything much more complicated, my question would be: In order to keep things maintainable, I think we should be careful to keep support for 16x2 character displays (like on the original DX7), and largely use the same menu system on both types of displays, with only an exception when it comes to selecting the operators. If that is possible. Wdyt? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the summary! That aligns with what I had understood which is always helpful 😄 Maintenance is an issue. Supporting multiple or flexible layouts can get old quickly. I guess I’m kind of used to/spoiled by having a fixed display size and writing it directly 😛
Naively glossing over details, that would be something like
There's the if but it'd be a pragmatic way of leaving the existing text mostly untouched and remaining char-centered. It doesn't pave the way for "more" (i.e. #418) but I don't see that without layering the drivers differently. I’ll dig around the code some more, especially |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I think text mode is generally fine except for operator selection where it is not that helpful. Thanks for looking into it! 👍 |
Beta Was this translation helpful? Give feedback.
-
|
Hi there, I've been wondering about something on this general topic (graphical display of different aspects of the device state). Personally, I find visual representation to be much more than just ornamental, if executed thoughtfully— it can help to reinforce an understanding of how a system functions, allowing one to use it more effectively in the moment / breaking flow less frequently etc. |
Beta Was this translation helpful? Give feedback.
-
|
Funny you should say that... When tinkering about with a dual-MiniDexed tone expander idea, I've a test implementation that can update any of the global or Tone Generator parameters using a custom SysEx command. I've not expanded it to edit voices this way though. I was experimenting with having a single MiniDexed UI control two instances to give 16 tone generators. See: #504 A more limited approach allows some parameters to be changed over MIDI already, which is what I was doing here: #490 But I think we do need to draw a line somewhere about what is core MiniDexed and what is custom enhancements for specific projects. But being able to access all UI parameters via SysEx over MIDI does allow for a whole new set of custom UI options... And of course there is always the approach of using an external editor (e.g. Dexed on a PC) and sending the result to MiniDexed. Kevin |
Beta Was this translation helpful? Give feedback.
-
|
One of the key design decisions for MiniDexed was that it should require not much more than a Raspberry Pi and a minimal count of very cheap parts. So a fancy display interface using a separate MCU is outside the scope for this project, but should be doable. Similar to how you can already today use Dexed on a computer to program MiniDexed, a separate MCU plus display could be used instaed of the computer. |
Beta Was this translation helpful? Give feedback.
-
|
If you mean "make a drop-in replacement for the LCD, but that can show graphics" that does work but there's probably not enough context in the raw strings to get much more than an emulated text display with fancy fonts (*). So you'd have to add some kind of abstract (custom) UI protocol between the two MCUs. Which is fun opens up other options, but having done that a few times also increases complexity a good bit (two things to build, maintain, update). (*) IIRC one of the eurorack Braids clones did something similar to drive an OLED instead of alphanumeric displays without changing the firmware. |
Beta Was this translation helpful? Give feedback.
-
|
@patrickdowling interesting, I hadn't actually thought of that approach, would be ideal if it were possible I suppose, but yes, seems like a lot of additional work would need to be done, to add that on the MiniDexed side. I had assumed that MIDI would be most straightforward protocol to support something like this— basically an MCU running code to read the current device state via sysex, then displaying it on-screen, similar to various external editors from the past, such as the Roland PG-10 and PG-1000 for their LA synths from the late 80's. |
Beta Was this translation helpful? Give feedback.
-
|
My display suggestion - cheap, works well and still has a touchscreen. 3.5inch RPi Display
|
Beta Was this translation helpful? Give feedback.
-
|
This display is ~10 times as expensive as the displays we are using here. In this project, we want to use the minimal amount of inexpensive hardware possible, so this display is unfortunately not suitable for what we are trying to do. |
Beta Was this translation helpful? Give feedback.
-
|
OK! I also find this premise of being a cheap and simple project interesting. My suggestion may be for another project. |
Beta Was this translation helpful? Give feedback.
-
Is there a dedicated discussion for that subtle hint in the wiki? I found some clues in other threads but that seemed to head quickly into “full GUI” territory.
I get that it’s a) ornamental and ii) requires some restructuring -- perhaps even in Circle -- but what can I say — I’m a sucker for that kind of thing and don’t mind poking around in the low-level bits.
Beta Was this translation helpful? Give feedback.
All reactions