Yes, it would be a lot of work to add that functionality into the format that presently exists. Hence the completely different format, and the note that that different format already exists, so why not use that.
Keep the GUI, mostly as-is - maybe even simplify it: remove the more confusing parts, or the harder things to maintain - and have it be a "Lite" version that is still graphical. Easy to use, and kept that way. Intentionally limited to avoid confusion. Then have the python tab that can do absolutely anything at all, but requires knowledge of python (and in the more complex cases, software management) to do it.
If you do *remove* functionality though, then you'd need a migration tool that converts an old macro into an equivalent chunk of python code. Given the limited nature of the macros by comparison, that shouldn't be *too* hard once you get going, but it's not trivial either. Good design up front would make a big difference, and would almost certainly become a tradeoff between up-front translation, and ongoing ease of use and maintenance.
(Mile-long string of parameters in a single function, vs. several functions to build up an underlying state that is used by the final function, for just one example. The latter of those options would probably be more readable, and allow keeping the same state across many "final" uses, not that the automated translator needs to know about the reuse. It can rebuild the state every time, and I'd call that "okay".)
Generally, it's a good amount of work up front, for hopefully a lot less work later if you do it right! New functionality, if you want it to appear in both places, then involves the GUI once, and the underlying code once. Both are inherited by both tabs, in different ways: the macros as they are now (possibly with the "complex software" functionality removed), and python as the code generator and library function(s).
That would be a good workaround at the moment, if you're really against the python tab.
But I think there'd have be *two* separate macro selections. One to run the actions of and one to check the conditions of, not necessarily the same. That avoids a maintenance nightmare on the user's end, with a big pile of macros that all have identical actions and different conditions or vice-versa.
And it also solves the problem of these macros just running on their own, since they have both conditions and actions. Now they don't have to: conditions with no actions does nothing on its own, and actions with no conditions also does nothing on its own. Then use this new functionality in the Macro action to put them together.
Of course, if you only had a checkbox and not a second selection, the maintenance problem could still be lessened if all of the condition macros had a single Macro action, that pointed to the actual code to run, but that's getting pretty silly and convoluted. And they'd all have to be paused, and their conditions as checked in the Macro action would still have to work when they're paused.
Not that that wouldn't be a workable chip design, along with a C or higher-language compiler that sorts it all out for you in the background...but it gets pretty clunky on a "chip" that you're designing to be directly hand-programmable in assembly, as Adv. SS macros kinda are.
I'd still consider it to be a non-ideal workaround though, mostly because the complete conditions and complete actions are not directly visible next to each other in context. That's also a problem in other languages when you share behavior across different parts of the code: a poorly-named function (macro in this case) that's used everywhere leaves you scratching your head about what it does, and you have to go track it down and read its code to find out.
Last edited:
