Support for a 'back' button?

[IrregularShed]

Hi everyone

I've been playing with this for a few days and love it (even if my handy AKAI MPK Play can't control it properly - I think it confuses things by not being a proper MIDI device when it gets powered on by USB, but that's something for another day).

I know the idea is to keep the circuitry required as simple as possible, and I've seen some discussions/issues about clicking/double-clicking confusion and tweaks. My idea is to add support for an optional 'back' button that could be enabled in the minidexed.ini, so you could do single clicks with the rotary encoder switch to select settings in the user interface and use a different button to go back up a level. I started trying to work out how to code this but sadly I just don't have the time at the moment to learn enough about Circle to try and tackle it myself.

What do you think?

[eLuSiVeMiTe]

Up down L and R would also work well.

DOWN to open. Up to back out. L&R to scroll. Wheel to enter value hold encoder button and L/R to skip op/TG

But I spend a lot of time programming on an MPC so that's my default navigation.

[IrregularShed]

I'm trying to imagine that and struggling! I assume you're using a classic MPC because on my MPC One it's all touchscreen 😀

[probonopd]

Maybe we can trigger equivalents of the click and double-click events when certain MIDI messages are receievd, so you could use any buttons on MIDI controllers for this purpose.

[IrregularShed]

That's a good idea as long as you have buttons to spare! I'm using a Korg nanoKEY2 at the moment, seeing as the AKAI isn't working, and that's not got anything that I could use 😕

[JohnConnor84]

I was looking a 4x4 membrane keypad...it connects direct to the GPIO ports and it looks very 80s. Do you guys think it can be configured as 4 navigation arrows, back button and the rest assigned to other basic functions? My idea would be the membrane keypad at the left side of the LCD and the rotary encoder at the right, so you could easily navigate through.

[probonopd]

It's software, so everything is possible. How much work would it be to implement it? I don't know.

[dcoredump]

I am a big fan of creating a touch UI for a external HDMI screen (#62). If you don't need a programming interface (e.g. on stage) you don't need to add a screen, but in your studio you have the full access to all parameters.

Circle supports LVGL and there are free editors for creating a LVGL UI available (also commercial like squareline which looks very promissing, but maybe supports not enough widgets in the free version).

Regards, Holger

[probonopd]

Wouldn't you run Dexed on the PC in the studio anyway? And then sysex voices over to MiniDexed?
Or use a phone/tablet app as a "programmer"?

[dcoredump]

In fact: no. I am personaly not a friend of "OS based software synths". I have a UI24 as mixing snd recording device, so I really prefer a haptic or UI interface per synth. I really prefer to have the same hardware in studio and on stage.

My concern is that an update or changing any setting on the computer will mess up my performance on stage or create stress in advance.

[probonopd]

Makes sense. Well, I assume you are familiar with @positionhigh https://codeberg.org/positionhigh/MicroDexed-touch? Is that roughly what you would have in mind? Probably someone with suitable hardware and enough dedication and time could port it to MiniDexed. Personally I lack the required hardware and think of MiniDexed more of a headless device operated by other MIDI devices, but surely I wouldn't stop anyone fro such an undertaking.

[dcoredump]

Makes sense. Well, I assume you are familiar with @positionhigh https://codeberg.org/positionhigh/MicroDexed-touch? Is that roughly what you would have in mind? Probably someone with suitable hardware and enough dedication and time could port it to MiniDexed. Personally I lack the required hardware and think of MiniDexed more of a headless device operated by other MIDI devices, but surely I wouldn't stop anyone fro such an undertaking.

Sure, Mark and I were working on MicroDexed together since a year.

For me a programmer like DT-7 would be very cool. This can be done with a HDMI display which can be connected only when needed.

I am not a friend of tablets and editor software due to bad experiences: in ten or twenty years they may not work anymore. You must know that I used my old DX7II until 2020 on stage... Now it's to heavy for me and that's the reason why I created MicroDexed.

[probonopd]

I am not a friend of tablets and editor software due to bad experiences: in ten or twenty years they may not work anymore.

Exactly my line of thinking. That tablet stuff tends to break after a couple of years because everything is constantly being upgraded. Until it doesn't run on your device anymore.

[craigyjp]

An editor I built for the Futur3Soundz XFM2 synth. I'm sure with a little work it can be used to edit the minidexed

[probonopd]

Mind blown!

[positionhigh]

An editor I built for the Futur3Soundz XFM2 synth. I'm sure with a little work it can be used to edit the minidexed

This really is impressive. At microdexed, our live FM Sound modulation currently can only do some quick attack/release modifications :_) But i think we could fit something like this on the 320x240 display with touch.. Let me know if that is of any interesting to you.

Here is a quick video how that is going:
https://youtu.be/4rvezoD7iu8

[JohnConnor84]

Hey guys I bought a pack of 5 membrane 4x4 keypads with 8 GPIO pins. Would any of you be (within Germany) interested to get a free spare one and test it? Just PM me and I send you one for free by Post.

[probonopd]

Thanks @JohnConnor84. If someone implements the code for it then I'd be happy to receive one for testing. But I fear I won't be able to write the code for it, so it's not worth sending me one unless we find someone who volunteers to write the code.

[stevelittlefish]

I too would like a separate button to replace double clicking. In fact the fiddliness of having to double click the encoder is the only thing making me not want to build one of these!

I'm not very experienced with embedded programming on this scale - this is a fair bit more complicated than things I've worked on. Looking at the code though, it seems like there's a very simple event system that could be used.

In userinterface.cpp there is this:

{
	switch (Event)
	{
	// SNIP
	case CKY040::EventSwitchDoubleClick:
		m_Menu.EventHandler (CUIMenu::MenuEventSelect);
		break;
	// SNIP
	}
}

Would it be possible to monitor / poll one of the other GPIO pins and call this event handler whenever the button is pressed?

Ideally I think I would use a non-clickable encoder, and wire up 2 buttons. One of them would be wired as the encoder click, and the second would be set to trigger the double click event.

I'm more than happy to help out if someone can nudge me in the right direction!

[stevelittlefish]

@probonopd @diyelectromusic

I want to checkout @diyelectromusic's branch, and then merge the master branch from MiniDexed into it to try to get it to build properly and fix the screen issue. What's the best way for me to do it?

Should I fork @diyelectromusic's project? I want to get commits from both projects and combine them.

Edit: I've managed to merge this branch in the main branch locally - it works fine with no conflicts once an assertion is deleted (see below)

[stevelittlefish]

@diyelectromusic I connected the raspberry pi up to a monitor and it gives the following error message:

uibuttons.cpp(120): assertion failed: !m_pEventHandler

If I comment out the assertion everything seems to work though. Is it safe to just delete the assertion? Would it be easiest for you to fix it in your repository ready to be pulled into the main repo?

I've tested the select and back button and they work as expected. I had a couple of double triggers of the back button but I think this might just be the poor quality push button I am using to test it.

I've so far only tested the UI - I haven't wired up my sound card yet but am assuming it won't affect the audio.

What do we need to do next to get this merged into the main codebase?

[probonopd]

What do we need to do next to get this merged into the main codebase?

Please see #271.

And it needs testing in different configurations.

[diyelectromusic]

m_pEventHandler

If that is happening then it probably means something is trying to register the event handler twice which sounds like a bug to me, although I can't see where that would be happening in the logic unless something is trying to initialise the UI twice further up. We'd probably need a call trace to see what was calling what at the time...

Update: Perhaps it it uninitialised - I suspect it should be set to null in the CUIButtons constructor...

Kevin

[stevelittlefish]

m_pEventHandler

If that is happening then it probably means something is trying to register the event handler twice which sounds like a bug to me, although I can't see where that would be happening in the logic unless something is trying to initialise the UI twice further up. We'd probably need a call trace to see what was calling what at the time...

Update: Perhaps it it uninitialised - I suspect it should be set to null in the CUIButtons constructor...

Kevin

Yeah it was uninitialised. I've fixed it in my branch.

[positionhigh]

just wanted you guys to keep updated how the things are going on the teensy front.
First PCB has arrived and is currently in testing, also a case - it looks so simple but there are a lot of issues to concider.

https://youtu.be/G6lSqf8H_4g

[sou7611]

The interesting part of this as a solution is there are display modules that actually come with four arrow buttons on them

…

On Tue, May 24, 2022, 6:58 PM Stephen Brown ***@***.***> wrote: I would personally just like a "select" and "back" button Agree. We already have the "select" button (the button built into the rotary encoder - could also wire up some other button using that same pin instead). So what we'd really need to do is add support for a secondary button, which would take the role of the "back" button. (In case the user opts into a two-button system.) This is exactly what I had in mind! This way we can add the back button with only a single GPIO pin. The other thing I was thinking is that we can add support for 4 way arrow keys by allowing the other 2 buttons to just use the encoder pins. Then there can be a setting in the ini file which tells it to use those pins as buttons instead of encoder inputs. This way we can support the current scheme, or an encoder with an additional back button, or 4 buttons, all with just one extra pin. — Reply to this email directly, view it on GitHub <#172 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABNBVNGGM3GWTJVMJ4NFLATVLVNITANCNFSM5UJIKZVQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[JohnConnor84]

I still have some membrane keypads with GPIO conectivity to giveaway . My original idea was to assign the pads to arrows and menu buttons. El mié., 25 may. 2022 8:45, Kevin ***@***.***> escribió:

…

The other thing I was thinking is that we can add support for 4 way arrow keys by allowing the other 2 buttons to just use the encoder pins. Then there can be a setting in the ini file which tells it to use those pins as buttons instead of encoder inputs. Almost like we'd need an up/down/left/right/select type interface.... oh wait ;) This way we can support the current scheme, or an encoder with an additional back button, or 4 buttons, all with just one extra pin. That is the whole point. At the end of the day it is just buttons on pins tied to actions (no matter what we call them), all configured in the ini file...? This was just a "minimum viable option" after spending several evenings hacking about with an unfamiliar codebase to get the raw structure in place for a "button user interface" to try out some ideas... Things to think about, if this seems useful (but happy to be told not, so I don't waste my time): - Fix the physical button logic (it's the wrong way round I realised this morning). - Add support for the Circle GPIO manager which is the way to make it interrupt driven (I'm not convinced it is needed, polling seems ok on limited testing). - Try some actual hardware measurements to see how sophisticated the code debouncing needs to be (again, it is the most basic that might work for now). - Add a "two button" option - that is just the naming of items in the config file really, now the core glue code is in place. - I might also be nice to tie these same events to MIDI... I also have one of those shields mentioned elsewhere on order - I had that in mind from the start (I agree it would be nice to plug in a cheap, off the shelf shield and have a crude user interface straight away). Which means there is also a future option to consider other button IO schemes. So far I've seen the following: - Direct GPIO (which is what I'm using here) - many cheap add-ons do this. - I2C IO expansion (might not be worth the effort if I'm honest) - an Adafruit add-on uses this. - Analog "voltage divider" buttons - I've seen at least one add-on that just uses A0 and resistors to "decode" 5 buttons. I don't know if this would be worth it tbh... Anyway, back to the original question - is there value in this or is someone else already thinking about it? — Reply to this email directly, view it on GitHub <#172 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AYYVQS37FYFT3EHO2AUBGDTVLXEBVANCNFSM5UJIKZVQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[diyelectromusic]

I still have some membrane keypads with GPIO conectivity to giveaway . My original idea was to assign the pads to arrows and menu buttons.

If they have a common GND and then just four or five IO pins (one per button), then they should just work with this... Do you have a link to them so I can have a look?

[JohnConnor84]

Just google Arduino 4x4 membrane keypad. If you are based in Germany or EU I can send you one because I have 4 extra . El mié., 25 may. 2022 14:17, Kevin ***@***.***> escribió:

…

I still have some membrane keypads with GPIO conectivity to giveaway . My original idea was to assign the pads to arrows and menu buttons. If they have a common GND and then just four or five IO pins (one per button), then they should just work with this... Do you have a link to them so I can have a look? — Reply to this email directly, view it on GitHub <#172 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AYYVQS3JY66WYG4UEGEH4ELVLYK67ANCNFSM5UJIKZVQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[diyelectromusic]

Arduino 4x4 membrane keypad

Ah sorry I misunderstood, you mean those common 16 button matrix type things like a phone keypad? No this isn't supported at it requires "scanning" as rows and columns and there isn't anything in the code to do that. It could be added of course if someone was really interested in having it.

In principle you could just use one column of course, having a single common GND pin and then four pins for each button. What were you thinking of using it for? Could you wire it up to an Arduino and use it as a MIDI controller for example (e.g. as a numeric keypad to select patches or something like that)?

[JohnConnor84]

Yes that was the idea. Assigning each number to OSC, LFO, EG, etc plus arrow buttons to navigate and access menu. Maybe an Arduino nano would work but Im not a programmer. El mié., 25 may. 2022 14:47, Kevin ***@***.***> escribió:

…

Arduino 4x4 membrane keypad Ah sorry I misunderstood, you mean those common 16 button matrix type things like a phone keypad? No this isn't supported at it requires "scanning" as rows and columns and there isn't anything in the code to do that. It could be added of course if someone was really interested in having it. In principle you could just use one column of course, having a single common GND pin and then four pins for each button. What were you thinking of using it for? Could you wire it up to an Arduino and use it as a MIDI controller for example (e.g. as a numeric keypad to select patches or something like that)? — Reply to this email directly, view it on GitHub <#172 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AYYVQS7ENB3W7GXI2LUX243VLYONRANCNFSM5UJIKZVQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[dcoredump]

Yes that was the idea. Assigning each number to OSC, LFO, EG, etc plus
arrow buttons to navigate and access menu. Maybe an Arduino nano would work
but Im not a programmer.

Why not adding a lvgl and touch based GUI via HDMI? Only an additional touch screen is needed (and some programming skills for creating the UI), see #62

[Kirtai]

A UI compatible with the mt-32pi hats like ClumsyMIDI would be nice. Same hardware for both systems.

[diyelectromusic]

A UI compatible with the mt-32pi hats like ClumsyMIDI would be nice. Same hardware for both systems.

That's dependent on ssd1306 display support in Circle I'm afraid... (and Clumsy MIDI has now buttons/encoder), but when it happens, it is possible, see #169 (comment)

[positionhigh]

kind of out of topic, but don't know where else to post.
some new development on the teensy front:
https://www.youtube.com/watch?v=WFc2IrTSYDQ&list=PLHTypoMU1QoGOXPli8bjR6MknPiQpubHl&index=4

[probonopd]

Feel free to open a new thread in https://github.com/probonopd/MiniDexed/discussions/categories/show-and-tell if you like (even if it's about a "MiniDexed Friends" project and not MiniDexed itself).