Using an LCD display w/menu instead of tons of knobs/switches....

So for my next Arduino-based project I plan on building a drum-trigger to MIDI output type thing. Basically I'll have drum triggers (piezos on foam cones) mounted on my acoustic drums, which will drive an Arduino to generate MIDI, which will in turn drive both a sample playback unit and a sampler (two separate pieces of gear).

That's all fine and dandy but where I started to run into problems is deciding on how to map what to what. With only three drum inputs, and oodles of possible outcomes, there are lots of choices to deal with.

For example:

Trigger1 could send one of 9 specific MIDI notes (9 sample pads available), OR, send to three of them randomly, OR all of them randomly.


Trigger1 can send MIDI events to trigger audio recording, playback, playonce, start/end/window point adjustment, most with random elements.


Each trigger would have two variables that could be controlled. Threshold and Probability. Threshold would work like a noisegate (only loud strikes generate events) or ducking (only quiet strikes generate events), and then Probability would determine how often it triggered (not based on dynamics). Between the two I could generate musical and somewhat intelligent events.

Ok, so my original plan was to have a 12-position rotary switch for each input and each device (so 6 rotary switches total), so that Trigger1 would do something to each device. Then to have 2 knobs for each bank of 3 switches.
So each output device would have 5 knobs (3 rotary switches, and 2 pots).

That's a lot of hardware in terms of price, and physical real estate.

Now, I'm thinking that I could use an LCD display with a couple of buttons built in, like this:

Throw in a couple of encoders, and I should be able to do all of what I want to do (and then some).

The problem is, I've never done LCD stuff with an Arduino before. In fact my general Arduino-manship isn't too hot to begin with.
This is the most complicated thing I've made (and it's not working perfectly (mainly due to weird state changing issues in the hardware it's interfacing with ):

How "easy" is it to use an LCD shield w/buttons, set up a menu of functionality and map that to stuff? I know "easy" is a weird term here, but I saw that that above shield I linked has a library for menu stuff.

Like to be able to map two functions (selectable from multiple options) to any of the trigger inputs, and be able to control threshold/probability parameters for each, and perhaps even save presets so I can shift between multiple settings.

I plan on setting this all up on a MegaMini since I need lots of analog ins for potentiometers and trigger/piezo input, so a 'shield' format isn't important at all as I'll directly wire everything anyways.

Using an LCD and keypad is not hard at all. Once you wire them right (looking at your site you are quite mechanically and electrically inclined so no problem).

The hard part is to write some code that does the menu, input values or select from a list of functions for each input to map to, but, that can all be done with libraries such as the phi_prompt library, which I wrote.

Check out this post and videos:

FalconFour has used my library to do several of his projects. Here's one:

Thanks for mentioning the Phi-1 shield. BTW, I have updated the Phi-1 shield design and released Phi-2 and phi_prompt library to support the software side;) But as you can see from FalconFour's project, you can make the library work even without the shield, although using the shield makes things easy, and encourages me to write more codes and update libraries more often;)

I can't believe I didn't set up this thread to 'notify' me of new posts.

I've been doing plenty more research on this and it actually doesn't seem too bad. Your library seems like it would do the heavy lifting, it's just a matter of adding the actual 'meat and potatoes' of the code for what I want it to do.

I was worried briefly that I wouldn't be able to use an LCD at the same time as MIDI due to pin conflicts, but after looking at stuff that doesn't seem to be the case. And since I'm going to be using a Mega, I don't think I'll run into pin shortage.

Where I'm starting to second think things is using buttons as the sole navigating/input method. If I have 6 main things that I can add a number of functions to, it would take forever to change things on the fly. Granted that this could be circumvented by having a handful of presets saved for most of the settings I would want to use (including a "do nothing" one). Ideally I would have some immediate real-time control of certain parameters with an encoder(s), but how this folds in with an LCD/menu in terms of code/menu is something else.

Thinking on a bit further I think with enough presets I wouldn't need real-time control (I could just make new types of presets ahead of time). I'm assuming the EEPROM addition to your shield would allow for storing sets of data in terms of memory and menu/display functions?

Would different LCDs work with your shield? Like this one:

I considered just going with an LCD "raw", but having the navigation buttons on your shield would make things much simpler in terms of hardware/software.

Then there is the problem of incorporating it into an enclosure (the old "square hole" problem, and little PCB buttons with hats on them sticking through the top).

Yeah makes sense when put into clear terms that way.

I plan on implementing a bunch of operation controls with dedicated buttons/knobs, but those would be independent of the LCD/menu system completely. The LCD would only be dealing with the mappable controls.

It's also difficult trying to "think" in menu, as far as creating an interface (i.e. planning a menu interface when you've never planned one before).

Can you have a higher order menu level that exists on top of everything, then it goes into actual menu stuff (though I guess the top layer is still the menu anyways). To put it in practical terms, can when the LCD shows on startup be a big lettered "Presets" menu :

01:3trig random play

And you scroll through that (up/down), then if you want to edit a preset, or create a new one, you go into the individual parameters/menu options.

I would imagine the above is doable in terms of absolutely doable, but in terms of doable with your library.

Lastly, do you plan on making a 20x4 version of the phi-shield?


You can either use the atmega328's EEPROM (small) or an external EEPROM (up to 1Mb) on a phi-2 shield to store settings that you can recall after power on. It's nice to see all your settings are kept after power cycle :slight_smile:

The phi_prompt is not going to take over the control but instead do the heavy lifting.

Say you want menus and adjustable parameters and selectable lists, and you need real-time responding knobs and buttons. You can use phi_prompt to handle the menus parameters and lists. Once the function quits, say select_list() returns the user's choice, you have full access to all buttons and the lcd like always so you can go and do dedicated work with all the hardware. The menu system is such a construction. Each function is called if the user so chooses and within the function you can do anything you want with all the buttons and lcd. If you ever need phi_prompt functions again, call the phi_prompt library function again, like input_number() then the function will return the user selected number and returns all hardware control back to you.

You can have infinite layers of menus and you can say quit from a menu and do the highest level stuff. Then if, say a menu button is pressed, you can call up phi_prompt library function to render a menu any time. What I do now is to have a menu item that actually does the highest level stuff. :slight_smile:

Say for example, you programmed an alarm clock, what's high level stuff? Displaying the clock and making sure the alarm runs when it is time. What are lower level stuff? Adjusting the clock, the alarm, see credits, changing display parameters. So what I do is to do the following instead of having a high level:

PROGMEM prog_char top_menu_item00[]="Display clock";
PROGMEM prog_char top_menu_item01[]="Adjust time";
PROGMEM prog_char top_menu_item02[]="Set alarms";
PROGMEM prog_char top_menu_item03[]="Display settings";
PROGMEM prog_char top_menu_item04[]="Show credit";
PROGMEM const char *top_menu_items[] = {top_menu_item00, top_menu_item01, top_menu_item02, top_menu_item03, top_menu_item04};

So one of the menu items is the high level stuff and if I choose it, it displays the clock in real time and keeps an eye on button presses so it knows if it should return to the menu and allow lower level stuff to invoke. Look at this clock routine:

  int temp1;
  while (1)
    if (!clock1.alarm_is_on)
      switch (temp1)
        case 0:

The above runs the clock repeatedly while checking for all key presses with wait_on_escape() and returns (back to menu) if a key is pressed. That's how I do high/low level stuff now.

Yes, there is a larger version of phi-2 shield. I just finished soldering one of them and having fun with it right now!!! The first order already shipped today. The rest is not much different, just more display area estate. The difference is the software. The phi_prompt's all nice features can be used on larger displays.

Here's the link:

One picture:

Regarding preset menu, I would create a list of names of the presets and shove them into a select_list() function to ask the user to choose which preset to start with. It doesn't have to be a menu (each item represents a function call), just a list will do. You then decide which preset to load with select_list() return value. You can construct any menu any time any where. You can even have say items on the menu that will call the menu again to confuse yourself :wink:

Scrolling is yes, if the item is too long, you can also turn on auto scroll so the text will auto scroll within the list like an MP3 player.

Right, this is starting to make sense.

Is it possible to have user created items in a list? As in, once I finish up the code, and it's a black box, be able to add list items? I suppose I could circumvent that potential problem and create 50 presets naming all of them "New Patch" or something like that, and just create/edit them in the blackbox.

I forgot the Arduino has built-in EEPROM. It's 1kb on the 328. I don't know how much that is in data terms. All I would be storing is current present (so it turns back onto whatever it was on) and then at most 50 presets, each with say, 10-20 numbers associated with each. I guess if I run out of space I can add an EEPROM easily with your shield.

Loving the 20x4! I need to sit down and have a good think about menu interface and structure and see which one to go with (I can't imagine the 20x4). That much extra screen space might be good for showing the preset name AND certain parameters at a glance.

Right now all list item texts are from the PROGMEM, or FLASH, to save main memory, which is only 2KB. This means the content of the text stays the same.

Since the last release I've got requests to make a list that I can change the text inside. I'll add the feature to the next release. On the other hand, I can also add a render_from_EEPROM option so the main memory won't be used up by texts from a list (could be hundreds of bytes for a long list). This way you can save custom names in EEPROM and use this new render function to render them as list. I have not considered an expandable list yet as the arduino main memory is so limited. The memory management is a bit problematic with malloc, that's what I heard. You can always have your own list class and an array with addresses to each item.

Yes, the 20X4 is huge. I'm enjoying it with my new alarm clock code that expands and contracts with different screens. Right now I have it work on 16X2 and 20X4 with settings such as:

#define lcd_rows 4
#define lcd_columns 20

The 20X4 version is NICE! I will post on exhibition later.

Is the 20x4 backlit? (or the 16x2 for that matter)

The 16X2 display has back light but the 20X4 doesn't have back light. I couldn't find a good source of 20X4 displays with back light at a reasonable price so I went with the ones without back light. If one wants a backlit 20X4 display, it's a bit expensive, like this one, then one can just plug it into the phi-2 shield and the back light will turn on :slight_smile:

Here is a video:

Right, that kind of gums up the works a bit. Being that it will be living in a piece of music gear, and often stages are dim, or completely dark....

I think I might go with a blue 20x4 (with backlight) like so:

And after looking up button options for actually mounting it an enclosure I came across this, which looks awesome:

So I'm gonna go with tactile switches with white caps on them, set diagonally, for menu control. Which also means I'm going to go shieldless as it would be pointless to buy the shield, to then buy a different LCD, and then buy different buttons, as I wouldn't be using anything else on the board (I could implement the EEPROM separately if that's needed).

You could also choose illuminated buttons, which could be a nice thing for a dim stage. My shield is mainly for learning arduino and general-purpose prototyping so you're right, in your case, you could go without a shield and use all panel mount parts :slight_smile:

I plan on using some illuminated buttons elsewhere in the build (the main "do stuff like record, play, overdub" buttons) and still need to figure out what to go with.

My old one looked like this:

They work well enough but aren't sensitive enough for my liking (a soft or fast press wouldn't register).

I'm considering using some soft 'button pad' type buttons and setting them up on perfboard with LEDs under them like this: