Go Down

Topic: Using an LCD display w/menu instead of tons of knobs/switches.... (Read 2 times) previous topic - next topic


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 :)

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. :)

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:

Code: [Select]
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:

Code: [Select]
  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: http://www.inmojo.com/store/liudr-arduino-and-physics-gadgets/item/phi-2-interactive-arduino-shield-2004/

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 ;)

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.

Go Up