-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PSA: New PRs may be affected by refactor #5836
Comments
Clarification... open as many PRs as you like, but expect to have to refactor them before they're merged. This means large, sweeping changes may be a mess to refactor. |
Is there any estimate on when the refactor will be finished? |
I must say I am quite disappointed in how LMMS is managed. A while back I opened an issue where I offered my help to add recurring patterns for note sequences. This is a very basic and essential feature that any DAW has had way back since the 80s. When you make a melody for example, you want to have one pattern let's say "melody1" that you reference in the Song-Editor and that you can modify later on and it will reflect throughout the entire song. The same is true for almost any notes you put down. You do not want to delete, then copy&paste the same notes all over again if you make changes, deleting half the song in the process. As if what you are doing is to carve the notes into stone. That is just insane. I was willing to code the entire feature, and I was merely in need to discuss this briefly with a developer. I never got any replies. All I see is PRs stocking up, now they are even frozen entirely. If you try to get in touch with the devs, it just one disappointment after the other. Like being purposefully lead into a customer support maze. All endpoints to contact the team are shut off for good, and if you can write mails or issues you get no replies. I am sorry to say, but this really just looks like the kind of open source project to stay away from. And that will eventually kill itself. With LMMS being the only DAW for creating music on Linux, that is kind of sad. |
@ballerburg9005 Devs are relatively active on Discord: https://lmms.io/chat. But I see you're already in there; give another try at talking to them when you have a chance in the #dev-only channel. If you want to add recurring patterns, submit a PR. The core developers are focused on other things right now, particularly refactoring the code to be cleaner and easier to edit. Thus helping outside developers like yourself contribute. I myself have had good experiences with the devs; I found an issue one day, posted on Discord, and it was fixed within a few days. I fixed an issue myself once with a PR and it got merged fairly quickly, despite being in the middle of the freeze. Also, there are IMO more important things than getting note patterns to work as, surprise, the "patterns" created in the "pattern editor" (the main note editor) can in fact be copy/pasted around the song, and there are nice and efficient ways to do that. Also, you can select notes inside patterns and copy/paste them. You may say that this isn't helpful for someone who didn't write the music in separate patterns to begin with, and I'd agree with you on that, but that's a solvable problem on the user side, not the program side. More important right now is making plugin integration better and giving base support for features like sample editing, which is necessary for many genres and current either has to be done with a 3rd-party program or by abusing AFP. Which nobody likes doing. Also, more synths and effects that would be expected from a modern DAW are being added. TL;DR: If you truly want to help, reach out, and someone will answer. Or, if they don't, they're busy, either with their lives or with some other feature or function. |
This kind of features you describe is specific to FL Studio workflow. From what I get using other DAWs (Cakewalk, Ableton) those programs doesn't have this function either. I think you had quite specific issues with patterns workflow in 1.2 which is current 'stable' version. In 1.3 it is vastly improved in terms of copy-paste operations on large scale. |
Thanks for the replies. I don't want to derail this thread, but let's just say there is quite some disagreement. Maybe I was a bit quick to pass judgement, I am sorry. And either I overlooked things or they weren't there back then. How long is this "refactoring" going to take? It has been over 3 month? Does it make sense for outside devs to get into it to speed it up? I briefly looked through the issue, it seems to be somewhat ... nebulous. |
@ballerburg9005 It looks like the refactor was, for a while, waiting on the other PRs to close. We're down to 2 I think that just need reviews, then the refactor will really kick off. |
It's not actually the refactoring that has been taking long, but the preparations for it. It's hard to give an estimate on the refactoring itself but it's definitely going to be much quicker than all the tasks we've been handling in order to make it happen.
Every extra hand is welcome. What has been a bottleneck is the reviewing of PRs. We made a list on Discord of the PRs that were going to be merged before the refactor (and have been tagging the new ones with
Just a correction, we have currently 8 (soon to be 7) PRs left for reviewing before the refactor:
|
Gotcha, must have misread something somewhere. Excited for progress! |
Just to clarify on some of this, @ballerburg9005, the refactoring (which is a clang-format run and file reorganization) is going to be breaking the merge-ability of all currently open PRs. We selected a few PRs that were close to finishing up that we wanted to get merged first before we kick off the refactoring process which is going to touch every file in the source tree causing conflicts on all PRs. While waiting, some of us devs are still doing some refactoring things, or fixing bugs and whatnot. We aren't completely frozen, but we're not going to be reviewing large enhancements or new features until after the refactor. The codebase is something that is in dire need of cleaning and becoming much more maintainable, which is why we're at this point. Since we're all on volunteer time, our estimates to get things done unfortunately get extended a lot more than we'd like. With more developers and reviewers/testers, this would really help move things along. |
I think the best for the refactor to progress faster would be to have a clear document that describes what needs to be refactored and what is being refactored, it's harder to get refactoring help when people don't know what is being refactored and what needs to be |
The OP links #5592 which describes the process and what's left. |
As outlined in #5592, the codebase is undergoing a major refactor. New PRs are likely to be affected by merge conflicts, so please be prepared to fix these if you open a PR before the refactor ends.
Credit for the idea goes to H:S on Discord:
But if you take issue with it, blame me for implementing it and not H:S for having it :)
The body of this post has been updated, Tresf's clarification adn the complaints below made a lot of sense in the context of the previous version
The text was updated successfully, but these errors were encountered: