Please do give it a try and let us know of any issues!
Do you have any plans to integrate the midi plugin?
Definitely not with this release I’m afraid - the video side of things definitely takes priority as it’s completely broken on some platforms at the moment. It is on my radar though.
Do you have a list of what’s new / what you’re working on?
Consider doing it as a hidden testing feature.
It is disabled by default and can be enabled manually from the config file by flipping the enabled toggle. It’s for the tech savvy users to try it out. It’s fully operational but doesn’t have a GUI anyway.
The whole thing is 1 file and inserts itself into the Remote Handler into a few handler classes.
Unless this is satisfied “if (isMidiActive() && isMidiOutDevReady())”, it’s a ghost. Doesn’t do anything and it’s just skipped.
The rest of the commit is some new settings added to the default properties.
That is literally all it is!!!
The video has been broken on and off for years. What’s the latest bug? The half or 1/3 monitor display ? Happened to me too.
It definitely won’t brake anything! The users do need a change to test out beta features anyway.
NOTE: I am currently writing the same type of thing for OpenLP. The plugin there is 10 times more complex to write. Granted it has a GUI, but the code overall is more convoluted as well.
In short, mainly the video work, plus a few other minor things for this release.
Appreciate that the majority of the code is in a single class, but there’s others that are modified too - and I’ve heard the “definitely won’t break anything” line too often to believe it over the years 
It’s also about being able to thoroughly vet & review the code before merge, rather than merging and then trying to sort things out later - and I just haven’t had the time to do that yet.
There’s no “latest bug” with the video, but the VLC integration has had a number of issues for years, some of which have become more prevalent over time (such as the scaling issues on Windows, and the fact loading the native libraries usually doesn’t work at all on Ubuntu.)
Hope your work on OpenLP goes well too! There may be a greater number of active devs over there who are able to review your code more quickly.
I am fully aware you would have heard it, everybody has. Which is why, if you just look at the modified files, you will go “Oh, it really can’t break anything when it’s off by default”.
I made sure of that.
I submitted the pull request ~2 years ago… (emotionally got over it 
)
I know that everyone is using VLC, but then something brakes their reaction is not, oh it’s VLC integration. They say “your software’s not working” and that’s the nature of relying on 3rd party lib.
A sidenote! I never managed to package a production ready installer/executable it in windows. 
I even talked to some of the other contributors, apparently it’s not trivial. Maybe it would be good to at least release some kind of packaging script, docker env packaging env or at the very least repeatable instructions.
I am fully aware you would have heard it, everybody has. Which is why, if you just look at the modified files, you will go “Oh, it really can’t break anything when it’s off by default”.
I made sure of that.
That definitely wasn’t my reaction when looking at the code (which isn’t to say your code is particularly bad, but I don’t think any seasoned developer ever has that reaction to anything but the most trivial of changes - and even then with some trepidation!)
As said already though, this isn’t just about functional correctness - it’s about ensuring the code is as good as it can be before it’s merged. At the moment it’s also incomplete as it doesn’t have any UI options behind it (which isn’t to say it’d be merged if it was complete - but it’s another barrier to it being merged to master.)
I submitted the pull request ~2 years ago… (emotionally got over it
The date on Initial MIDI module implementation by JessyJP · Pull Request #596 · quelea-projection/Quelea · GitHub is Nov 2022, so just over a year ago - and bear in mind that’s the year I’ve been mostly inactive, hence the absence of a 2023 release.
Please note that the contributors guide clearly says:
We’re usually a little more cagey about accepting pull requests for new features out of the blue - they’re great to have, but we have to make sure that they’re implemented well, not rushed, and the core team agrees on any UX implications they may have. If you’re thinking of a new feature, then talk to us first (feel free to create an issue for it if one doesn’t exist already.)
This definitely counts as a new feature, and so the above caginess applies. I’ve now updated the contributors guide to make this even clearer. The issue is that while you’re authoring this code, the core team is going to inherit it and be responsible for maintaining it - so we need to be sure that a) this additional maintenance burden is worth it for the number of users that would use it and b) that the code is reasonably maintainable for the functionality it offers.
I know that everyone is using VLC, but then something brakes their reaction is not, oh it’s VLC integration. They say “your software’s not working” and that’s the nature of relying on 3rd party lib.
Agreed, which is the exact reason why we’re replacing it. This is on us to sort out, we can’t blame another product that we chose to integrate with. Relying on a 3rd party library of some description is necessary for this though - reimplementing every codec we want to support from scratch would be completely infeasible!
A sidenote! I never managed to package a production ready installer/executable it in windows.
It shouldn’t be too hard - you just need Gradle, Java 11 (with JavaFX, the Azul builds are the easiest to use these days) and Innosetup installed, then run the “dist” Gradle target and you’ll get your installers in dist/standalone. Dockerising this build process would be a nice thing to have in future - just not high on the priority list.
Happy, Christ-birthday!
With all due respect, I have been talking about it since about 2 years ago. Made an external version before integrating it. It’s definitely not out of the blue.
There were issue posts/ suggestions/ tutorials/ complaints and all the relevant jazz. I did my due diligence!
Tests, unit tests, end to end sim on VMs, compile run, enjoy! We can’t be trepidant over every single line … although I kind of do too … sometimes … but wouldn’t want to admit it!
As for maintenance … well the midi protocol has been around since 1980s, (feel free to change slides with the old electrical organ in your church, or use midi pedals while you play the guitar).
Hance the code implementing the protocol, is unlikely to change (much if at all), unlike VLC implementations, even HTTPs implementations etc.
When I was saying 3rd party, I was actually referring to non-standard libraries. I didn’t check, nor do I want to, how the video was implemented, but I am pretty sure it’s not part of the standard java libraries. Especially since VLC always requires to be installed on the system, so that the wrappers can find the binaries. Or people use bundles. Unlike this the MIDI uses native java library. I think I just googled/used the most popular/standard one out there.
Therefore that should be ~0 maintenance, once done right.
Still that’s up to you! You are right, you will be the one maintaining it. And, of course I wouldn’t do a GUI. 1st, I don’t really like or want to learn it (yet another UI lib). (I did make an attempt).
2nd, hance you will do it faster and better than me.
3rd, I think you would have rejected it most likely anyway. I mean if you are even suspicious of 700 line core which implements a standard library, so that would have been wasted effort on my part.
4th, aside from code pretty print, there is the matter style and consistency. I wouldn’t know in advance what style of UI might be suitable or how you might want to arrange it to keep it consistent. I just put an example UI mashed up in 30min in MATLAB for reference.
For reference, here is what I have so far for OpenLP. It supports profiles and dynamic assignment.
Feel free to steal ideas if you ever actually want to implement it.
As for code quality, pretty print is up you, that’s a matter of preference. Initially when I was readying your code I was kind of stunned you didn’t put a single comment.
Funnily, as I read on I just get it because the names, logs and errors are descriptive, so I guess that also works. If you don’t like my code, change it as you like, I have no complaints.
In terms of design I went with it as simple as possible, hance the word “Initial” in the commit.
We can’t always predict in advance how the users will adopt a new feature.
I still maintain the idea that a beta feature disabled by default is not a bad idea, but you are the captain and if you have decided it’s not ready, then it’s not.
I will have no more objections anymore.
Despite, what I said and how it may sound like, I agree with your philosophy and protocol for validation, merging and release, and I understand and agree with priorities. Not that my opinion matters too much, but I understand that.
What really frustrated me was that we could have had that discussion 1 year ago and maybe had something more complete by this time.
The ship will not stop sailing, you will be be busy with other things too, so you could have assigned some responsibilities to someone else (“your first officer” to keep the analogy). At least a point of contact could have been better than nothing.
I also think this negatively impacted the userbase and maybe lost some users.
People rave about ProPresenter and even recommend google slides (tch tch tch), but I couldn’t even find Quelea being mentioned in Youtube reviews for 2023.
One more thing, for this release. Please, please, please, make the password authentication optional.
Empty, password means ignore, authentications.
Don’t ask! Don’t pop up! Just connect as soon as it’s on!