I have another question part of the same exercise but will post it separately to keep the information easy to find for others.
P.S.: if you enable the capabilities of users to create tags, that will improve exponentially the usability of the forum. Tried adding tags but is not working for me.
I’ll check those configs and see what I can learn. Really want to do the configuration myself Still fighting the editor a bit regarding element contexts and where/when and how things can interact with each other etc.
Is there any plain LUA editor mode where all the components are summarized in structured codebase?
TBH, the editor is a very nice feature and I much appreciate it. But when you start wanting to understand the interconnection of elements and how things really work it hides a bit all that.
For instance in the CTRL64 config it seems that you have spread the logic across the different elements (I guess that as a way of fighting the char limit and as a way of structure the code somehow). But it is confusing from a code architecture perspective as you are expecting any general functions to sit at System and then controllers would just consume whatever is defined there.
Let me know if I’m understanding that config in the wrong way.
One lesson that seems interesting is that functions defined in the setup of the controllers are shared across all of them.
BTW, I think that I found a bug regarding the NRPN block. It seems that after you configure it and save it, if you re-open the editor you cannot edit it anymore and after clicking on it the editor becomes unresponsive (clicking in other elements have no effect). Check video HERE.
Ah that NRPN bug is back huh. Please make a report of this on the Issue Tracker.
About the 64CTRL: yeah, its code is mostly a relic of the old 390 character limit which has been increased since to 899. It would require me to rework the code, since it’s kind of legacy at this point. But currently, I’m working on VSN1-related configurations so stuff like this will just have to wait.
For the 64CTRL many tricks have been employed to fit into these code limits:
functions have been split into parts across elements
variables are declared on Timer Events too, not just on Setup Events (big no-no :D)
the 256CTRL by EchoMatter has streamlined some of this code, but kept the core of it
So I would say they are not ideal for learning, but there’s a bunch of cool things in there that could teach you the basics.
Found the way of doing it, somehow managed to understand how the documentation is structured and found about event_trigger(). That did the trick and expanded my understanding of how the events and variables interact.
If I may, I really recommend an overhaul of the documentation, currently it seems that it is a bit too tangled and hard to find information if you want a specific answer.
My recommendations:
Make code related pages and editor related pages separated and searchable.
Currently the two tabs in the documentation makes hard to find the topics/sections in one or the other; I’m talking here about “About x” and “Reference Manual Entry”. If you use the search there is not way of land into the Manual Entry side of the documentation.
This paradigm becomes more confusing as you currently have the Wiki and the Reference Manual intersecting and with no clear function. If you cannot easily and unequivocally express what each of those sections are for, I guess that you have a structure issue.
What I would propose is:
API documentation style for all coding related documentation not related to the editor itself. Searchable, concise and with examples.
1.1 Include and architecture diagram and examples to illustrate the relation between the elements and make the use of the different functions clearer.
1.2 Of course this documentation should mention the scope in which the code can be executed (“Setup”, “Timer”…etc).
1.3 As the paradigm is unique, I would add here a best practices section with “no-no” cases and preferred configurations architecture.
All documentation related to the editor only covers the editor but when needed links to the API style documentation or embed, if required, fragments from there.
Documented use cases, step by step tutorials, etc. Those can reference both the API style documentation and the editor documentation when needed. They should be concise and express the concepts and best practices highlighted in the editor and API style documentation.
Separating the different elements of the documentation and embracing SRP will enable better and faster searches, clearer concepts,… The platform has an incredible potential but I think that part of it is lost in the current documentation structure and the adoption curve it creates (even for programmers).
Let me know if this is helpful, happy to provide more details.
Coded up a fix and sent a PR. Not sure on your policies regarding community proposed patches but there it is…is working for me so far so I can keep building my workflow with NPRN without issues.
Update…disregard the PR, it brings some undesired side effects in other unrelated components. I’ll try to find a solution.
Still fighting the editor a bit regarding element contexts and where/when and how things can interact with each other etc.
