Over the last weeks, we learned about the Nextion active protocol parse mode in general, about the MIDI protocol in Detail, and we got a first and simple demo project which taught us how the Nextion HMI could send MIDI messages or commands in standalone mode. Today, things become a little more complex: We want to receive and to decode MIDI messages and commands. For this demo project, we'll implement two functionalities: Soft-through, which means that received, decoded and validated commands are then re-sent, and a MIDI monitor which should show us the MIDI data stream in a human readable form. Afterwards, it might be up to you to to add other functions like GPIO triggers or visual effects, or even filtering, transforming, and re-sending the midi data for additional effects like transposition or adding sub-harmonics (octavider), based on this framework.

Two weeks ago, we talked about data protocols and the active protocol parse mode of the Nextion HMI. Last week, we looked deeper into the protocol and data structure of the MIDI protocol which allows to exchange messages between electronic music instruments. You guess it, it can not only be handled in Nextion language, but using a Nextion HMI as a MIDI controller in standalone mode, which means without an external MCU like Arduino etc. has many advantages. Typically, most MIDI controllers (if this aren't keyboards) have a status display or multiple rows of LEDs and many, many knobs and buttons. That isn't forcibly ergonomic, especially when you are live on stage and you want just quickly change a single setting. In such situations, an intuitive GUI and dematerialized knobs, buttons and sliders give simpler usage, less production cost and make the "apparatus" ways more robust.

Back more than a year, when the Nextion firmware allowed more different baud rates, among them 31250 baud, I understood already that I'd have to think about using Nextion HMI as a MIDI device, sooner or later. By the way, the same applies to 250000 baud and DMX, but that's for later. MIDI is some years old and used initially a rather simple protocol. Over the time, additional functionalities like SysEx messages, (non-)registered parameters and time codes have been added. We will look into all that, so that afterwards, everybody might decide by themselves what to implement (or not). Before we start writing code to transform a Nextion HMI into a fully fledged MIDI controller which can receive, decode and interpret MIDI messages on one side, and generate and transmit MIDI messages on the other side, we need to fully understand the MIDI protocol, hardware- and software-wise. That's what this article is about.

As we are all more or less experienced Nextion HMI developers, we are familiar with the default operational mode of our displays: Without any additional effort, data which comes in over the serial port is parsed and interpreted as if it were one or more instructions in Nextion language, for example in a local TouchPress or Timer event handler. Furthermore, when preceded by commands like addt or wept, we can transmit data over serial bulk-wise towards a Waveform component or towards the internal EEPROM. Finally, when using the appropriate protocol, our Nextion handles even a complete firmware update without requiring us any action on the Nextion side. But what if you want your Nextion HMI to handle data streams which do not follow the Nextion protocol by terminating every sequence by the terminator 0xFF 0xFF 0xFF? What if bulk data arrives and is not intended to land either in a Waveform component or in the EEPROM? As always, many paths lead to Rome. You might feel inspired to write code for an external MCU (for example an Arduino or a Raspberry Pi) to receive or generate these "unsuitable" data streams, to filter and process them, and to send them out in an appropriate form towards a Nextion HMI. This approach is probably efficient and meaningful for complex data streams like CAN bus data where much information arrives at high speed but you need to display only a small subset of these. For simpler data structures, our Nextion HMIs have a less know functionality, called active parsing mode or protocol reparse mode as my Canadian colleague Patrick prefers to name it. It allows to handle and to interpret incoming data your own way, even in a Nextion standalone setup, without external MCU. With this short series of articles, I want to shed some light on this mode, show what can be (meaningfully) done with it and where it is (probably) better to avoid it.

After we saw last week in this article how we can display or visualize data in an ergonomic circular form, similar to a gauge or a progress bar, we'll extend it today into a fully interactive control, close to a (circular) slider. To make our "custom control" more interactive, which means allowing to set the temperature (in our example project) not only with the (+) and (-) buttons, but also by touching the corresponding position on the circle, a few arbitrations are necessary. Following the "keep it simple and safe" principle, I decided for a touch raster approach.

Sometimes, it may happen that you need elements for your GUI but you can't find an appropriate component in the Nextion Editor. That's the moment to remember  what you've already read multiple times in this Sunday Blog over the last two years: "If you don't have an appropriate component at hands, build it yourself!" And that's what we'll do today. In this first step, we want a clock or rotary potentiometer like component which, besides displaying a numeric set value, does also display it for more ergonomic visualisation with a spot on an almost full circle.