The LCD display is a relatively slow device to update. Visible blinking can be seen when there are changes. So it's not suitable for situations where the display changes rapidly.

This slowness means that some operations require relatively long delays, e.g. reset. Fortunately most are before the tick loop is entered. However a couple of functions like clear and home require a 2 ms delay. I moved the clear to the initialisation. I replaced the home in the main loop with a setcursor. However it is necessary to clear the line when the text changes, or previous text that is longer than the current text will still be displayed. I solved this by always sending 16 characters by sending the right number of padding blanks.

However this is not a general solution for long delays. If they are blocking, they will stop the MCU from other tasks. One solution would be to use Protothreads also to handle the display, by implementing a busy flag. So say when a clear is issued, the thread should set a busy flag and then wait for the timer to go off before clearing the flag. Other parts of the program would look at the flag and refrain from using the display when it's busy. For example, changing the note sets the texchanged flag, but it wouldn't be acted on in the tick loop to update the display until the busy flag indicates that the display is ready for another command.

As can be seen, even the Arduino driver suffers from the use of blocking delays, some of which are quite long, which make it unsuitable for applications where the MCU must be available for other tasks. I daresay the LCD library isn't the only one that has blocking delays internally. There is no good way to fix this short of adding some multithreading features to Arduino libraries and sketches.