Going way out on a limb here, maybe add a Python tab for completely arbitrary behavior? How would that, plus a code generator, compare to where the Macro tab is heading?
A user may not know the syntax or system management to be able to type out something new, hence the CodeGen, but they can probably read and understand existing (clean!) code well enough, and modify it from there. That's definitely where I am with Python, yet I made an auto-producer work between two instances of OBS, by "script-kiddy-ing" two examples together that both worked on their own as-is.
If I were to take this over (not planning to), I'd be tempted to still maintain the various "starting point" tabs, as long as they stay within their named functions, and replace the Macro tab with an arbitrary-text-based thing. Plus a CodeGen to get people started with it. You can recycle most of the Macro's UI to make the CodeGen, it's just that the output is different: Python source code instead of your own byte code.
---
The reason I say this is because I effectively had an equivalent of the Macro tab in a custom theatrical lighting rig. I spent a TON of effort on it, and by the time I got it to do everything I wanted, it was slow to run and hard to use. It looks to me like you're going down the same path, trying to balance increasingly arbitrary functionality, all of which has a good reason to support, with ease of maintenance and a sensible graphical UI from both sides of the screen. I've been there, and it's nearly impossible to actually do that. You have to sacrifice something, be it functionality, user experience, or backend maintenance.
I decided that if I were to do it again, I would replace both my bytecode interpreter and the mouse/touch-based GUI editor, with a decent text editor and a *really good* code generator. Maybe even use C++ in there, include the g++ compiler with the software, and spend my efforts to make the whole process appear seamless. The accept button recompiles the code, and if successful, updates the pointer to the new void user_main(struct all_data* data); // (struct all_data {...}; is in a read-only header file)......
That next version never happened, but if I do end up doing something similar, I really want to try that approach. C++ is probably a bit much for most users, and the compilation and linking steps would also add some difficulty; but Python might just take off and fly, as an already-optimized interpreted language that doesn't need those steps and has a huge userbase already for support.
If you did that, then you could have a code generator that is optimized for user experience and backend maintenance at the expense of functionality, and then get that functionality back by running the CG's output through a user-modification step in a standard language. (the user can simply accept it as-is if desired, which is always valid code) Then it's *that* code that runs, not necessarily the CG's direct output.
Thoughts?
A user may not know the syntax or system management to be able to type out something new, hence the CodeGen, but they can probably read and understand existing (clean!) code well enough, and modify it from there. That's definitely where I am with Python, yet I made an auto-producer work between two instances of OBS, by "script-kiddy-ing" two examples together that both worked on their own as-is.
If I were to take this over (not planning to), I'd be tempted to still maintain the various "starting point" tabs, as long as they stay within their named functions, and replace the Macro tab with an arbitrary-text-based thing. Plus a CodeGen to get people started with it. You can recycle most of the Macro's UI to make the CodeGen, it's just that the output is different: Python source code instead of your own byte code.
---
The reason I say this is because I effectively had an equivalent of the Macro tab in a custom theatrical lighting rig. I spent a TON of effort on it, and by the time I got it to do everything I wanted, it was slow to run and hard to use. It looks to me like you're going down the same path, trying to balance increasingly arbitrary functionality, all of which has a good reason to support, with ease of maintenance and a sensible graphical UI from both sides of the screen. I've been there, and it's nearly impossible to actually do that. You have to sacrifice something, be it functionality, user experience, or backend maintenance.
I decided that if I were to do it again, I would replace both my bytecode interpreter and the mouse/touch-based GUI editor, with a decent text editor and a *really good* code generator. Maybe even use C++ in there, include the g++ compiler with the software, and spend my efforts to make the whole process appear seamless. The accept button recompiles the code, and if successful, updates the pointer to the new void user_main(struct all_data* data); // (struct all_data {...}; is in a read-only header file)......
That next version never happened, but if I do end up doing something similar, I really want to try that approach. C++ is probably a bit much for most users, and the compilation and linking steps would also add some difficulty; but Python might just take off and fly, as an already-optimized interpreted language that doesn't need those steps and has a huge userbase already for support.
If you did that, then you could have a code generator that is optimized for user experience and backend maintenance at the expense of functionality, and then get that functionality back by running the CG's output through a user-modification step in a standard language. (the user can simply accept it as-is if desired, which is always valid code) Then it's *that* code that runs, not necessarily the CG's direct output.
Thoughts?
