I confirm, everything works! But what have you changed? 
I saw what was changed, but how? 
One would be to create the nodes and clone the one of the library, but in this case combine the project with the library but editing the files manually.
Sometimes I use two or three XOD instances and Notepad ++
It looks like cesars has found a solution to the original issue but I’m taking some time now to review that whole project as there are some additional things I’d like to improve, e.g. the button-presses that are detected from those integrated LCD-boards on an analog pin via analogRead sometimes seem unreliable, now that XOD allows easy inclusion of Arduino libraries in C+±defined patch nodes there is probably a better library available for that task. Or I could write a lil state-machine that should improve it.
At minimum the patch node for the input that reads the analog pin for the button-voltages shouldn’t have “Loop” as an input for its clock as I have it in the example, it should be clocked at a more reasonable frequency like 50 or 100Hz or something. But the simplistic voltage-comparator way I have it written would still allow the possibility of picking up invalid transitional-states from say switch contact bounce even at a lower sampling frequency.
There is a very complete Marco Colli library but my head can’t understand it haha.
Nice! I will definitely look it over. My XOD-implementation is more simplistic and it’s rather inflexible, a bit of a “proof of concept.”
The ideal would be something more resembling a model-view controller and state-machine sort of thing to define menu transitions and effects of inputs, with more flexibility on what kind of inputs a given sub-menu could accept, what data it could display, and hand off to the “back-end” model.
How to translate that to something appropriate for XOD that could be expressed with patch node interconnections and have low storage overhead would take some thought 
For a limited subset of inputs (one XOD “number”-type from a pot or something) the way I’ve done it is amenable to a model-view type of arrangement but essentially you have to build the “model” in XOD with storage and feedback nodes yourself; making the menu nodes abstract and having several overloads that could accept different types of data might be a useful improvement.