To quote(rather paraphrase) Berry’s own words, that’s the beauty of open source, you can take it and do what you want with it.
So, you my man, you are not completely out of luck. By the way, I love your philosophy. I am assuming you are running an overpriced Mac, withn even more overpriced slave contracts called subscription models for propreaenter and more. You are so very welcome in the land of freedom and liberty called open source. Somtimes it’s a wild west but it’s also a land of promise of feature, dreams of stability, and opportunity to make it your own … New world, you know.
Ok, trolling and historical references aside. I after reading your post I had a few ideas. More like 3 proposals. I would love to say in a very gypsy style “you are to boss, you order the music, just keep the green leafs coming” but I don’t mind cooking up something hacky pro-bono for you. It’s more of a question of how deep into the rabbit whole do you want to go with such a project.
-
Without further ado, Option 1, MIDI. There is already an existing midi module, abiet not integrated. It can probably let you automate just about anything. Well, it will not be integrated in this release, but you can see, the previous discussions, I have been rather vocal about various Quelea related features.
In short, I have been saying let’s go the beelind edge (the arch way) because users have desires for features, but it’s Berry’s responsibility to keep us on the stable (Debian path) of course because we can’t have weird things happening in production. Other than that the module is fully functional. But, are you rally interested in connecting a midi controller or a steam deck !? Well, I have a feeling maybe not in your use case.
-
Option 2. Just custom simple class module loading somewhere at the end of the init sequence and we make a few callbacks that can be registered and triggered with shortcuts.
That will be your own custom thing.
The great part here is that, when there is a new release we just rebase and merge your module into the code, build, create installer and you update just like everyone else, but with a bit tweak to your version.
-
Option 3. Go the Reaper way! If you have ever used it or heard about it, it has 2 very fascinating features.
In the Reaper DAW, every action, is in a searchable list. You can do peripheral mapping for each mapping. And if that’s not enough you can do LUA scripting and more.
Now, I think integration of LUA into Quelea, would be a bit too much. But how about this.
Let’s say, I define for you a list of actions and maybe 1 or 2 conditionals. Simple small list like: toggle black screen, send to live , if state ON do A else B.
Let’s say I put 10 to 20 of those in a file which yiu can edit wirh a text editor. You can define a custom action by placing those action labels in a row. Let’s say it’s some kind of init or yaml script. Easy to read, and you just put your desired key binding to that sequence.
After the init sequence, I just put a hacky interpreter which checks this script that you just edited and and at runtime creates a call sequence. So all of your call sequences i.e. macros, can be triggered via a shortcut. We could maybe even put a toolbar ther if we have to be really fancy!
I just have to somehow find the key binding module event handler, then just register your macro handler which will get a copy of any keyboard input. It will ignore non matches but run a sequence if there is a match.
This way, you are not limited to a single custom action and have flexibility to modify without having to have to ask me to edit code every time you want to change something. If you have ever seen scratch (the Lego like “programming language”) it could be a bit like that.
This design would be fairly self contained and will not have to affect other code much.
Berry recently, gave me some instructions on how to package, which worked. Then stopped working because of JavaFX. Then I got annoyed and put a clean Intelij install on manajaro and that happily built again. So apparently somtimes that can be finicky (at least until I figure it out).
I think option 2 can definitely be done in a few hours but I am kind of tempted but a fuller macro interpreter design.
With the midi control, you can do quite a lot of automations and connect a control serfice for real buttons, although here it’s just a fully working prototype in MIDI reception.
In all honesty, I have actually been quite interested in presenter lately. Specifically what feature make it functional for the users. The MIDi module I did here was actually partially inspired by Propresenter, and even did a fully featured and much more advanced one for openlp where you have Midi device profiles and bidirectional control. Including some outlandish ideas for deferred control, where the presentation software can act as a slave to another controller software.
