1st a style note: when you have a bunch of wires from one pin to many pins all over you patch, it is time to look into using busses. They are basically invisible wires you can label. You can have one to-bus with a given name, and any number of from-buses that use the same name. Given a descriptive name for the wire, it can make your code easier to read and self-documenting…it can also make things hard to trace out if over-used. The balance between the two is going to be a personal choice. As I show below, you can have multiple wires from a from-bus; you don’t need a new from-bus for each input pin that uses them.
Having each line of your display update based on clock ticks seems very inefficient if the display only changes on button presses. There might be other reasons you want to base it on clock tickets, but just to “make sure it updates after button press” is probably not a good reason. Just update entire display if any button is pressed (or you are booting).
Unless you are having the display spin, I don’t think you want to rotate or invert the display on a loop either…seems like things that only need set on boot…
I don’t have hardware to test, but it seems to me something like this should work. If boot or any button pressed, clear display, draw text for each line, then send-buffer.
This is only a part of your code. There might be reasons why my code works for this part, but breaks your program as a whole, so my comments above about your “inefficiencies” might not apply in your case. Sometimes the simplest solution for one part of the program makes the program as-a-whole more complicated; if you don’t use the shortcut for this part, you might be able to reuse code or calculated values for another part of your program.
Back to styling notes: in this case, I only have one from-bus-OLED…it would have been just as easy to use a jumper node in place of the from-bus-OLED to force that wire to the left side of the patch and allow multiple wires to branch from there. A jumper node is just a dummy node that become a part of your wire so it can be pinned to a location to force the wire to route through a specific path, or allow you to branch off at a specific location. The same could be done in your example to force most of the wires to run between nodes instead of through the middle of them and just a couple wires coming off the device node and branching off later.
There are also only one each of B1 & B2 from-bus, but using them allows button code to be split off from display code, making it easier to show control code versus code to just update display. Again…usage will be dependent on personal preference, and is likely to change based on complexity of surrounding code and other factors. Just know that these alternatives are available to help you manage the appearance and readability of your code.
If you are displaying a lot of lines of text, you probably want to change layout so each draw-text node isn’t taking up 2 rows. One option might be to put B2 to the right of the 1st draw-text. It is a little less obvious at first glance what you are doing, but it is more compact, and repeating patterns are easy to parse once you see the pattern.
One advantage of splitting off sections of code (like “update-display”) is that it can be pulled out into your own custom patch so it is not cluttering up your main program. In this case, you could probably create a patch that just needs DEV, each line of text to display, and an UPD pin (and you might not need the UPD pin if you add pulse-on-change nodes to the input pins–it depends how YOU want to use YOUR patch. Moving more inside the patch makes the calling code cleaner, but might remove flexibility you want/need. You can hard-code X,Y,SIZE,COLOUR,WRAP for each line, but that means you need a new patch just to change those values, so it is not likely to be as useful to reuse on your next project. A best-of-both-worlds solution might be to create a generic node that allows you to specify most or all of those values, then write a wrapper for it specific to this project that only has pins for data you change & hard-code the rest of the data into the wrapper.)
If (for example) you had a project with 2 displays showing similar information, it makes even more sense to pull the display code into its own node. Now instead of duplicating the display code, you just duplicate the one node & pass in 2 different DEV values to control the displays separately.
If you want more discussion on style, layout, and encapsulation, my library gweimer/traffic-light-advanced — XOD is an extension on the original traffic light tutorial that explores more XOD features & their usage as well as design/usage considerations and thought processes involved in creating code (like starting simple and building on success; it is REALLY hard to write a complex project that “just works” and trying to jump straight to a completed project is likely to be very frustrating.)
