More transparent project goals outside of Discord

[michaelgregorius]

The following comment/interaction and also some personal experiences motivated me to start this discussion: #7538 (comment).

Project directions and goals are not transparent

The direction(s) that the project team wants to take and the goals are not really transparent for users that are not on Discord. Because development is taking place here on GitHub it would be logical to me to also make the goals of the project transparent on GitHub so that people can contribute in a meaningful way even if they are not on the Discord. This might be done in various ways:

• Add sub projects to the "Projects" page. Break them down into clear individual tasks that in sum will lead to the implementation of a feature/goal. Doing so has several advantages:
  • Progress can be measured.
  • Participants can take a shot at different task without running into the risk of creating big pull requests that go into the completely wrong direction and/or that are not reviewed and do not move forward. Put differently: breaking down the tasks reduced the risk of a lot of wasted time.
• List the current goals in the projects README and link to the projects.
• Discuss goals on the "Discussions" page.

It might also be helpful to make team members responsible for certain topics and areas and to make them more prominent. If I create pull requests it's not really clear to me whom I should add for reviews, e.g. who is still active and might be interested in the pull request. Also most reviews are only style reviews but not really reviews of the actual feature and its direction.

Project leadership

My personal impression is that the project is lacking leadership, e.g. someone like Ton Roosendaal for Blender or Guido van Rossum for Python. However, it might only be my impression because I am not on Discord and therefore things are not transparent to me.

The people that I have mentioned are sometimes called BDFL (Benevolent Dictator for Life) in tongue-in-cheek. In my opinion what's important for such a role is that the person that takes it is knowledgeable in the field so that they can take the "right" decisions.

In the context of LMMS that would mean that such a person would ideally have experience with several different other DAWs and be curious how things work under the hood.

The role of such a person would also be to steer people that are not as knowledgeable in the field into the right direction. If I remember correctly I have once read that there are developers on the project who have never seen a DAW other than LMMS. It's not hard to imagine that this can result in very strange solutions that are unorthodox and potentially off-putting for users that have experience with other DAWs.

My personal goal

My personal goal is to help push LMMS more towards a "professional" direction and to make it more on par with other DAWs (see for example my PR for faders with a dB scale). If you compare LMMS to other DAWs you will find that it is lacking quite a lot and has a number of the aforementioned weird solutions.

However, my time is sparse so unfortunately I cannot help with the real big tasks that would be necessary to do so: real-time safety, audio graph with latency compensation, more sophisticated features for audio drivers, e.g. multiple inputs and outputs, etc. That's also the reason why I cannot or do not want to get too involved, e.g. via Discord.

I would greatly appreciate if someone who is active on Discord and who reads this would point the other team members to this discussion. 😉 Thanks!

[Rossmaxx]

I can agree to the point you mentioned here, as we do still discuss about development on discord. I have created a thread on discord for 1.3 development, which honestly should be here.

Regarding the "Project Manager", most of the candidates come online at random times, then there's people like me, who are online almost every single time but not qualified enough to step into that role.

Maybe I'll try chunking some key points and post them right here, in the next message or a seperate discussion.

[Rossmaxx]

So the general movement seems to be like this:

1.3 development

I'm ready to do the work towards making a release, but there seems to be some critical performance regressions related to the threading mechanism (hopefully #7568 fixes it) and the horrible vst performance, which @DomClark has taken up on but it's left on hold because of his tight schedule.

not adequate testing

We have a lack of devs, yes. But more than that, we have a lack of testers. I could test, if I wasn't on my phone 24/7 and on PC. But college stuff already kills the little focus I have.

Lack of coordination

Even with discord, coordination is sparse. Different people move in different directions. But can't really complain about that because it's the nature of community driven FOSS projects. The point regarding a lack of a project manager might be in effect here.

[michaelgregorius]

We have a lack of devs, yes. But more than that, we have a lack of testers. I could test, if I wasn't on my phone 24/7 and on PC. But college stuff already kills the little focus I have.

Some testing could also be made part of the review process. In an agile context one might say that testing would be part of the "Definition of Done". Although the bigger problem is that most of the time it's not really clear what should be done in the first place.

As I have mentioned above, the reviews currently seem to be mostly style reviews. I assume that's because style reviews are easy because there are rules that can be checked.

It seems though that only very few people in the team feel to have the competence or authority to say: "Yes, this new feature goes in like this. This is the direction into which we want to go." To improve this one would have to "bestow" some team members with that authority and also make that transparent. Hence the proposal that I have made above with regards to responsibilities.

Lack of coordination

Even with discord, coordination is sparse. Different people move in different directions. But can't really complain about that because it's the nature of community driven FOSS projects. The point regarding a lack of a project manager might be in effect here.

The examples that I gave for Blender and Python were also meant to show that FOSS projects can be managed differently and that it is not a natural law that each FOSS project is just a bunch of people who move in different directions and just "scratch their own itch".

Many successful open source projects have a leader and I assume that this is a big factor in their success in the first place. The Linux kernel has Linus Torvalds, Ardour has Paul Davis, etc.

I am aware though that these people cannot be conjured from thin air. However, even if LMMS would not have such a person then it would still be nice if the group could manage to at least make it feel more like as if that person existed through a more defined process and more transparency.

Disclaimer

I'd also like to make very clear that I am not striving to become this person for LMMS. This thread is not intended as an attack on people who might have that role in some sort of way or as a "power grab".

I'd just like to get a discussion going how things can be improved because I have spent quite some hours on LMMS' code in my spare time and have created lots of pull requests in the last ~10 years but it still feels rather frustrating. Almost every pull requests feels like: "These hours of work might potentially be wasted even if the changes already bring some form of objective improvement."

[tresf]

LMMS is a fairly straightforward project to manage and there's even potential for the management of the project to be a paid endeavor.

The reason Discord is used so heavily is because the leaders that we do have helping are stretched too thin, so we can focus -- as a team -- to collectively merge something that might have been better off with a sign-off by someone that may not be available for weeks or months. It's also nice to be in direct communication with the users on a daily basis as the regulars on Discord will ping us for something urgent.

The major downside to Discord is that it's not public, at least not in the conservative sense, so it leaves a lot of knowledge behind a proprietary tool. In many ways it's replaced our forums, but it does so in a non-Google searchable fashion, so a lot of knowledge that's gained there also stays there to rot for eternity and I'm not particularly happy about that. I consider this mostly to be a cultural shift as even our own developer mailing list became abandoned slowly after the switch from sourceforge to GitHub, so it's here to stay.

My personal goal

My personal goal is to help push LMMS more towards a "professional" direction
[...] my time is sparse so unfortunately I cannot help with the real big tasks

This pretty much summarizes the project. Those that can, don't (or more accurately, can't commit full time to any particular effort). I think it's true for most of our skilled help.

With regards to "more professional", I used to agree with this, that everything could be organized and anyone could pick up where a project left off, but I'm not sure I still feel this way. As a person who's actually tried to consolidate issues and track milestones, I can say with 100% certainty that the milestones mean nothing when the team completing them is volunteers that work on whatever they can or whatever they want or whenever they want.

WIth regards to "like other DAWS", I personally have a hard time taking these claims seriously. I do believe that there's a collective subconscious of what LMMS can become, but I also know first-hand how hard it is to worry about upstream changes all the time and the maintenance of these items can bog down any attempts for improvement. It's also an uphill battle fighting the community against bugs that have become features or odd workflow steps that have become second nature. I have several tracks from 10 years ago that won't work on modern LMMS versions because they rely on a broken plugin playing broken sounds and once this was fixed, I don't know how to reproduce.

Add sub projects to the "Projects" page. Break them down into clear individual tasks that in sum will lead to the implementation of a feature/goal.

But who does this? And what are these tasks?

My issue with statements like this is it implies that someone takes the time to simplify a problem down to a description of a task that's easily completable. If that's the case, it's often quicker to just fix the problem rather than documenting how easy it is for someone else, but even when tasks are identified and put simply, people still jump in with ways to do it better and this won't stop happening until the codebase has been made coherent. I think #4067 is a classic example where a quick fix was ready for merge, but the "better" fix is pushed, which starts quickly grows in scope of how to fix it correctly.

This is NOT the exception for this project, this the standard. I don't think we can "wish" it into being more organized, I think we need good, active developers working together and around the clock to get this done and until we have those, we'll still get there, just much, much slower.

There's also a fair chance that LMMS will be forked into a complete rewrite as a result of this bottleneck. I think the project is a good candidate for this, especially considering how dated the MDI interface is, how coupled the UI + Core are and how inconsistently most UI features behave.

As I have mentioned above, the reviews currently seem to be mostly style reviews. I assume that's because style reviews are easy because there are rules that can be checked.

I would agree.

It seems though that only very few people in the team feel to have the competence or authority to say: "Yes, this new feature goes in like this. This is the direction into which we want to go." To improve this one would have to "bestow" some team members with that authority and also make that transparent. Hence the proposal that I have made above with regards to responsibilities.

I think you're combining unrelated things... Competence, authority and knowledge. For example, some people have authority but just aren't skilled in a particular area of code. "Competence" is a bit of an ambiguous term because one can be technically competent to approve a feature from a UI/UX perspective and from a testing perspective and also have the authority to approve it, but not be competent to approve the code.

Today @bratpeki asked for access to testing and we created a new GitHub groups for testers so that they can help triage issues with us (whether assignment, review, etc). I think this is a step in the right direction. The #testing channel on Discord is pretty active and is a great place to ping people for help with at least the UI/UX and testing stuff. Discord is also a fair place to gain consensus (whether totalitarian by the few lead developers at a given time or democratic by the community it impacts).

My personal impression is that the project is lacking leadership, e.g. someone like Ton Roosendaal for Blender or Guido van Rossum for Python. However, it might only be my impression because I am not on Discord and therefore things are not transparent to me.

I think this is an accurate statement, but with regards to having a sole leader to take on the project, everyone that steps up gets burned out and getting good leadership (for free) is very hard to come by. We have some up and coming developers that might step up to this plate, but I fear that they'll quickly get discouraged. I've watched so many technical arguments sour developer's involvements that "needs leadership" is an obvious side-effect of these projects, not an insightful prescription that fixes anything.

I hope my replies aren't too negative.

@michaelgregorius As an aside, I would like to personally invite you to Discord. You can mute the non-technical channels and it's a pretty pleasant place to be. We might eventually add an IRC relay bot to interact with it for those that would rather use conservative comms, but that effort lacks volunteer effort as well.

[tresf]

Unfortunately, the first messages did not come across as disagreement to me but rather as some "tribal" "Hey, look! This guy is trying to discredit the community, our developers, users and projects". When in fact I intended to give some insight about perceived problems and proposals on how to improve things. Most of the proposals were not addressed at the time which I would expect from a rational discussion.

I think this is where I took issue with the original post because tasks like:

• Subprojects
• Adding goals to the readme
• Move discussions here

... feel, at least to me, like someone saying "please change the project to be more convenient for me", whist taking no responsibility to act on these.

Subprojects

This one confused me as I don't think there's anyone preventing this from happening?

Goals in readme

There was a day when Toby had his TODO list in the readme, but those days were also the days of tarballs and slow internet connections. I personally don't like this idea because it uses a source file for task tracking and I find it to be a bit "1990s" of a way to do things. Some projects I contribute to still use the README as a form of milestone/changelog though and I do comply, but I don't particularly care for it.

Move discussions here

In some ways I agree with this as it can make project involvement more transparent, but I'm just afraid it is fighting human nature. I offered an example of how Discord is actually better than IRC... I'll expand on that...

This is why I called the decision cultural. As much as I dislike the cultural shift to Discord, so many projects I've tried contributing to use IRC which when I try, I lose any replies that occur when my laptop goes to sleep.

To elaborate a bit on my personal examples:

• I offered to help the Gimp project with macOS builds, but hit a snag that I was hoping for help with.... I was sent to three different IRC channels, none of which I could remain online unless I changed my PC sleep settings and all of which directed me elsewhere. I got about 80% of the way on my own but never a successful build and never ended up helping with the macOS builds. Note that Gimp uses a special "jhbuild" tool for building dependencies, so debugging build failures was pretty hard for me.
• I wanted to discuss a regression from linuxdeployqt to linuxdeploy to fix our AppImages, but the IRC channel didn't even say "Hello" when I chimed in. Not one reply despite dozens in the room. This is holding up the cpack PR. We'll probably change our project downstream to accommodate, but having a discussion with upstream first would be preferred.

I should have learned from that other thread that rational discussions are not possible. In the end of that thread you apologized to me after a long back and forth and lots of wasted energy. I do not want to repeat this here because I am already getting agitated by this thread again and it already feels like wasted time.

Yes, I did, but so far, you haven't. I understand that I can come off as harsh and I also acknowledge my own mistakes, I make them often, but the OP still reads as a prescriptive rant, not a conversation. Stuff like "the project lacks leadership" is for all intents an purposes a well-worded complaint, not an actionable item whereas "Add goals to README" is an actionable item but one that's easily buried because this thread was largely started as a manifesto rather than an actual discussion, which can be observed by how hard it is to actually track each point.

[tresf]

I should have learned from that other thread that rational discussions are not possible. In the end of that thread you apologized to me after a long back and forth and lots of wasted energy.

I think this is misrepresentative of our interactions. Here's a conversation where I believe you were in the wrong: #3086 (comment)

If this is the apology you're referring to, it was meant as an olive branch, not necessarily admission of wrongdoing or guilt as arguments often have a way of getting in the way of themsevels. Apology here: #3086 (comment)

Note that even then, I asked for a way to PM you. If you offered one back then and I missed, it, sorry! I can still add you, although your most recent post to Discussions says you're leaving so if we stay in direct communication it may be just to say hi.

Due to the escalation, I considered reaching out in PM to clarify any motives or lack of appreciation -- but I don't have a way to do this (please consider this an open invite, as well as a partial apology for any bad feeling I've caused - Discord, Telegram, Google Chat, Email).

[michaelgregorius]

I think this is where I took issue with the original post because tasks like:

* Subprojects

* Adding goals to the readme

* Move discussions here

... feel, at least to me, like someone saying "please change the project to be more convenient for me", whist taking no responsibility to act on these.

Please refer to this reply. It will explain why I understand that it might come across as such. But it also explains why I believe that doing these things would not only have benefited me but might bring benefit to the project by attracting more developers. It's somewhat ironic that an open source project uses a closed communications platform and then complains that it does not have enough developers.

And giving feedback to someone does not imply that the one giving the feedback must be the one taking actions.

Subprojects

This one confused me as I don't think there's anyone preventing this from happening?

Great, perhaps it can be tried in the future then. IMO it would communicate commitment and would also be another indicator that the project is alive and worth investing time into (see also the reply to bratpeki linked above).

Goals in readme

There was a day when Toby had his TODO list in the readme, but those days were also the days of tarballs and slow internet connections. I personally don't like this idea because it uses a source file for task tracking and I find it to be a bit "1990s" of a way to do things. Some projects I contribute to still use the README as a form of milestone/changelog though and I do comply, but I don't particularly care for it.

Ok, I can understand that. It's not that important of a point anyway as it would only be links to the projects which I find more important due to the reasons listed above. They'd also be outside of the source code, findable by search engines, persistent and completely transparent and in the open.

Move discussions here

In some ways I agree with this as it can make project involvement more transparent, but I'm just afraid it is fighting human nature. I offered an example of how Discord is actually better than IRC... I'll expand on that...

I cannot follow the jump from discussion (and projects) on GitHub to Discord and then suddenly IRC which I have never brought up. I therefore hope you understand if I do not reply to your examples below why IRC is bad. Otherwise we might end up in a discussion why using smoke signals is bad. 😉

Yes, I did, but so far, you haven't.

In the aforementioned thread I did in this comment: #3086 (comment)

With regards to your apology in this thread, you have apologized for the comment about "bureaucracy". However, you did not apologize for trying to bring up everyone against me by going on a comment spree misinterpreting my comments wherever it suited you in that goal and giving all others a heart upvote trying to pull them onto your side. You even quoted my Unfortunately, the first messages did not come across as disagreement to me but rather as some "tribal" 'Hey, look! This guy is trying to discredit the community, our developers, users and projects". above but then talked about something else below that.

When I accepted your apology in my reply my first knee-jerk reaction was to offer an apology as well to "balance things out". But then I reread my OP and your aforementioned discrediting replies. You also called me "unprofessional" which tells me that you have no idea about my work here and definitively do not have an idea of my work in my day job (which is to be expected). You apologized for nothing of that. So why should I be the one offering an apology? What do you expect an apology for?

I have also discussed this situation with a friend and they agreed that it was the right thing to do.

I understand that I can come off as harsh and I also acknowledge my own mistakes, I make them often, but the OP still reads as a prescriptive rant, not a conversation. Stuff like "the project lacks leadership" is for all intents an purposes a well-worded complaint, not an actionable item

Well, it can still be used as something to start a discussion. It is not expected to bring perfect solutions in the first post of a discussion thread, is it? It could have lead to a discussion about how to deal with the situation where there is no leader/BDFL which could have brought some results and actionable items. That's why this is a discussion thread.

whereas "Add goals to README" is an actionable item but one that's easily buried because this thread was largely started as a manifesto rather than an actual discussion, which can be observed by how hard it is to actually track each point.

So a valid item should not be discussed due to the form? Why not just start another discussion then if it is perceived as a separate topic?

I also do not understand why you call it a "manifesto". It's some personal observations with some proposals.

[tresf]

Discord is actually better than IRC... I'll expand on that...

I cannot follow the jump from discussion (and projects) on GitHub to Discord and then suddenly IRC which I have never brought up. I therefore hope you understand if I do not reply to your examples below why IRC is bad. Otherwise we might end up in a discussion why using smoke signals is bad. 😉

The OP criticizes (among many other things) the project's (lack of) communication outside of Discord. The example describes how atrocious this is elsewhere for projects which are -- outwardly perceivably -- much more successful than LMMS, so this statement is in defense of using Discord, as it has merits. Regardless, this was mostly meant to humanize the experience of working with other projects and share my experience. This point does not directly support or criticize the notion of moving conversations here, although I did share some thoughts of this on Discord to the team. (Not in spite, but because it's more likely to be found and read there by the team that such a change would affect).

You also called me "unprofessional"

It was mentioned that "blind abandonment" is unprofessional. The discussion threatening abandonment was already linked. It's not the first time in this thread that "professional" is tossed around as a conditional subjunctive so I did not find it to be particularly acustatory. It was meant to be a pragmatic notion, aimed at an action. The action's intent was questioned (and defended, sort of), and I did link where I observed this intent, but diving further into this is likely a waste of time, since you know what you meant and I know how I interpreted it.

You apologized for nothing of that. So why should I be the one offering an apology? What do you expect an apology for?

Hope != expectation, but I understand your sentiments and for sake of both our our sanity, I won't dive too much more into these comments as I feel it's hard to avoid the pejorative when doing so.

I have also discussed this situation with a friend and they agreed that it was the right thing to do.

I too discuss my conflicts with peers and regardless of my opinion on the points in this conversation, when conflict comes to this point that peers need to be involved to help with judgement, I tend to apologize because the cortisol levels just aren't worth it.

giving all others a heart upvote trying to pull them onto your side.

With regards of "rallying" upvotes, I hope you understand that there's no hidden intent here of that. The OP has the most upvotes of any comment here, and developers on Discord are actively discussing this. My replies are meant to be objective criticisms, not personal attacks. I understand that my communication style has room for improvement and I'm trying to take that into careful consideration to prevent this thread from even further off topic as I still believe there are objective truths/tasks to discuss.

[michaelgregorius]

You also called me "unprofessional"

It was mentioned that "blind abandonment" is unprofessional. The discussion threatening abandonment was already linked. It's not the first time in this thread that "professional" is tossed around as a conditional subjunctive so I did not find it to be particularly acustatory. It was meant to be a pragmatic notion, aimed at an action. The action's intent was questioned (and defended, sort of), and I did link where I observed this intent, but diving further into this is likely a waste of time, since you know what you meant and I know how I interpreted it.

IMO you are not discussing this objectively and you unnecessarily load the topic and discussion with emotional and negative terms ("blind", "threatening", "unprofessional").

I want to stress here that I did not blindly advocate for getting rid of the third party plugins but have presented some strategies on how to deal with the consequences of doing so:

1. I have presented a strategy on how to deal with old projects that use the plugins. They can be opened with old versions which have the plugins, i.e. they can still be worked on and rendered/archived with old versions. It's not like the users suddenly lose all their work.
2. The plugins are not lost. They can be installed separately from other sources if users need them. This is the basic idea of plugins.
3. I have advocated to extend and strengthen LMMS' own, internal plugins so that development of core functionality can be focused on these instead of having to maintain a large set of third party plugins with duplicate functionality. This set of plugins would work on every platform (a requirement that came up later in the discussion) and would be up to the quality standards of the team.

Some downsides:

1. The chances of projects not being able on all platform increases. It's a problem that already exists anyway though because users already have the option to use plugins which are exclusive to some platforms in a project. This can be alleviated with good plugins that are internal to LMMS so that users prefer to choose them over plugins which are exclusive to some platforms.
   This is also the strategy followed by most other DAWs. If LMMS decides to not treat plugins as plugins then this will bind resources which will then not be available in other areas of the software and the project.
2. There's some extra work if people wanted to continue to work on old projects with a new version. They might have to find replacements for the removed plugins or install them onto their system by hand.

So, I have objectively discussed some options on how to deal with complexity in a project that is already scarce of developers.

Doing the above is the opposite of being unprofessional, a term that I strongly want to distance myself from. Especially since the parent commenter built a straw-man argument with the straw-man being the "blind abandonment" accusation which was taken out of thin air: proposal by me is made (including the aforementioned strategies, open for discussion) -> parent portrays this proposal as "blind abandonment" (which it is not, see above) -> parent states that "blind abandonment is unprofessional" -> suddenly I am portrayed as being unprofessional.

@tresf, if you feel "threatened" by the thoughts presented here then I guess that it's your own perception and "problem". It would really help if you focused on the things being discussed in the future instead of attaching attributes like "blind" and "threatening" to them or discussing hypotheticals and straw-men and going off into meta discussions. Loading discussions with emotions does not really help the discussion or the project.

[bratpeki]

Today @bratpeki asked for access to testing and we created a new GitHub groups for testers so that they can help triage issues with us (whether assignment, review, etc).

Thanks for the invite! ❤️

I've had a number of technical complications which have made development halt for me, and thus, I've reverted to testing, only to find out testers are, funnily enough, more needed than developers, in some aspects.

I'm all for pushing towards 1.3, but I'm afraid this approach will drive certain developers away. Szeil and Regulus come to mind. Cool PRs, but not at all 1.3(+) related. So it's a difficult position. Their efforts in 1.3 would do wonders, but I don't know how to convey this to them without making their currently open PRs sound unimportant to us for the time being.

I'll test whatever and am currently bound to Windows 10. Building is not at all an issue, in great part due to Fuyir's, Krejstal's and @tresf's help with generating the MSYS2 build rules!

I'd suggest reviving the 1.3 development thread or opening a separate Discord chat where a small handful of us can work on that, or working from here. These "developer views" are uncharted territory for me, but I'm hopeful Tres and Ross would help me adjust by answering whatever questions I might have!

Anyhow, yeah, maybe pack up the Caps plugins PR first and go from there? Sounds like a sound approach to speeding up the trip to 1.3.

[regulus79]

Szeil and Regulus come to mind. Cool PRs, but not at all 1.3(+) related

I totally understand. My PRs are mostly new features, when I probably should be focusing on fixing regressions lol. I would love to help out with the core stuff like LV2 support to speed up 1.3, but I'm not yet knowledgeable enough in those areas to do much. And from what I've gathered, LV2 seems to be blocked by the Plugin Pin Connector PR, which isn't ready for testing yet. So in the meantime, I've just been kinda making frontend improvements, since that's what I know how to do.

If there are any 1.3 issues which my elementary c++ experience may be of assistance to, please feel free to ping me. For now, I can try to focus on things like #7454 which does at least fix a regression on the 1.3 milestone.

[szeli1]

Szeil and Regulus come to mind. Cool PRs, but not at all 1.3(+) related

I wanted to do bigger things for lmms for the past year, but I feel there were not enough guidance from others to achieve this. I asked a few times on Discord (i think), and I can't remember any suggested tasks other than fixing bugs (or maybe the oscilloscope plugin, but that has other issues like I can't use my graph widget to display things, but I will have to write a new one because there is no graph widget that can display vaweforms). The lack of guidance lead me to make PRs that went nowhere (about 7000 lines wrote, 160 merged). I'm one of those contributors that have never used other DAWs so I don't usually know the most ideal solutions to problems. I'm also unsure where to learn the necessary skills for audio development. I would certainly appreciate if there were future plans with detailed requirements that I know are right and will be merged.

I should focus on bugs in the future, but I'm currently not actively developing this project.

[firewall1110]

My impression from aside:
(1) I agree with all in "Project directions and goals are not transparent"

(2)

I am not on Discord and therefore things are not transparent to me

I hope Discord information cardinally change situation, but my impression is: LMMS project have problems with term "Project directions and goals" (at least no agreement about this).

But , comparing 1.2.2 , 1.3 alpha and master , I see that LMMS is in right direction.

(3)

solutions that are unorthodox and potentially off-putting for users that have experience with other DAWs

Different DAWs has different "using logic",so even changing one top 10 DAW to another top 10 DAW is " potentially off-putting".
My opinion as "Cubase user" is : LMMS has completely different logic but it is not a problem.
But there are a lot of simply uncompleted things ... And it seems that nothing happens one year, second year , ... Even issue is not opened ...
(in 10 days I will open discussion about such "little" uncompleted things)

PR for faders with a dB scale

It is one good example, that is now done, but not so critical ...

real-time safety, audio graph with latency compensation, more sophisticated features for audio drivers, e.g. multiple inputs and outputs, etc.

For me LMMS is good enough without this ... This things should be done but with lower priority ...

(4)

project is lacking leadership

Leadership can be good solution, but it is near not real for new person to be able for such leadership, and LMMS team now has no candidate (how I understand situation) ..

[michaelgregorius]

I hope Discord information cardinally change situation, but my impression is: LMMS project have problems with term "Project directions and goals" (at least no agreement about this).

But , comparing 1.2.2 , 1.3 alpha and master , I see that LMMS is in right direction.

Yes, it is moving but it feels like it is moving glacially slow. Which is no surprise if it takes ages to get a pull request through.

solutions that are unorthodox and potentially off-putting for users that have experience with other DAWs

Different DAWs has different "using logic",so even changing one top 10 DAW to another top 10 DAW is " potentially off-putting". My opinion as "Cubase user" is : LMMS has completely different logic but it is not a problem. But there are a lot of simply uncompleted things ... And it seems that nothing happens one year, second year , ... Even issue is not opened ... (in 10 days I will open discussion about such "little" uncompleted things)

Of course different DAWs will also feel slightly different. You will find though that there is a set of similarities that most DAWs share. However, LMMS does not even always share these. Having linear faders instead of logarithmic ones is the perfect example.

PR for faders with a dB scale

It is one good example, that is now done, but not so critical ...

All DAWs have logarithmic faders because that is how human hearing works. LMMS not having them makes it look like a toy which provides users with a subpar experience.

So in my opinion this is critical.

real-time safety, audio graph with latency compensation, more sophisticated features for audio drivers, e.g. multiple inputs and outputs, etc.

For me LMMS is good enough without this ... This things should be done but with lower priority ...

These are basic and important features of any serious audio software so I find it quite surprising that you do not find them to be important. What things do you consider of higher priority?

[tresf]

All DAWs have logarithmic faders because that is how human hearing works. LMMS not having them makes it look like a toy which provides users with a subpar experience.

So in my opinion this is critical.

It's not critical. Critical is installing and working. Critical is (mostly) opening old projects. Critical is making sure AppImages ACTUALLY OPEN, making sure VSTs don't crash, performance, regressions.

That said, If the team - or even one highly involved contributor - wants it for 1.3, just add it.

However, if it's a blocker for too long, whoever's spearhead the release might pull it. If there's conflict over this, said developer can offer to help spearhead the release so that it's included but doesn't punish those tracking the milestone.

[michaelgregorius]

All DAWs have logarithmic faders because that is how human hearing works. LMMS not having them makes it look like a toy which provides users with a subpar experience.
So in my opinion this is critical.

It's not critical. Critical is installing and working. Critical is (mostly) opening old projects. Critical is making sure AppImages ACTUALLY OPEN, making sure VSTs don't crash, performance, regressions.

I guess we then simply have different opinions about what is critical and what not.

I consider the basic functionality of the application as critical (perhaps even the most critical) because providing a meaningful use to users is the primary purpose of the software. Some of the things that you have listed are non-functional requirements which are also important but do not have a purpose on their own.

I guess to fix some of the other problems refactorings and redesigns might be needed. However, with the current state of how things go it's far too risky to start these without knowing if they are really wanted (if they are committed to) and that they are in the direction that the project wants to go.

I think you mentioned the effort by jsmtux to separate the core and the GUI which seems to be abandoned? If you in fact meant that project then it might be a good example. Imagine how much time and work they have put into it only for it to potentially go nowhere although it would definitively put the project in the right direction.

But I think we are turning in circles because preventing these things was one of the reasons for the creation of this discussion. Having project goals that a distributed team can commit to so that the risk is minimized that efforts are wasted.

[tresf]

with the current state of how things go it's far too risky to start these without knowing if they are really wanted (if they are committed to) and that they are in the direction that the project wants to go.

Agreed. I think this is a big risk for the project, large contributions never get merged. I truly believe it's due to lack of resources, but we need to find a way to take on these things faster. Or in your case, help set priority for these things. Priority is sadly a lobbying effort and GitHub may be a bad platform for this, so it likely causes disdain for something that was never intended to.

[tresf]

pack up the Caps plugins PR first and go from there?

This is one of the examples I was referring to when I made this statement:

I also know first-hand how hard it is to worry about upstream changes all the time and the maintenance of these items can bog down any attempts for improvement.

The maintainer of this plugin changed so much code that it's a huge task to upgrade. #4027. To NOT break projects, we need someone that can help provide an upgrade routine (for starters, they don't need to be in code, just the recommendations need to be documented) so we know which ports and which values to map for each missing or renamed plugin. That PR's been open for 7 years.

[tresf]

I guess the better statistics would be to find out how many users really use or need the LADSPA plugins.

I don't think we can get a fair representation of these numbers. I agree that #7103 is a good start, thanks for linking. A poll may help. We do these on discord and github on occasion for similar purposes.

[bratpeki]

Puts Linux at an generous 8% usage.

Gotta be more. I'd believe Windows users move onto other DAWs significantly more often, because of the choice pool.

[tresf]

Puts Linux at an generous 8% usage.

Gotta be more. I'd believe Windows users move onto other DAWs significantly more often, because of the choice pool.

The percentages are based on download statistics that we have. We can't measure that which we don't have, but it's meant less to represent our overall percentage of OS distribution, and more as an illustration that a solution to this problem (e.g. get plugins from the OS distribution) mustn't be aimed at the overwhelming minority of users when there's no equivalent for the majority -- whether that's 92% or 82% or 72%.

Nearly all Linux distributions offer some form of disto-specific version of LMMS, however these versions lag behind and often distributions strip out components or get the components elsewhere, fragmenting the users and affecting the experience, which is why the numbers that we're most concerned with are those that are within the project's control, which delivers the most consistent experience across all platforms. We may be able to add flathub numbers to these if the version and featureset are identical (and if the stats are made available).

If OS distribution accuracy is more important to the project, telemetry is likely needed to get "accurate" numbers. (Steam does something similar, but in the form of an annual survey). As a project we try not to speculate what one OSs users favors over another or make any "architype-specific" decisions except those that are technically bound.

For example, notions like: "The average mac user..." or "The average Linux user..." is fun for conversation, but to be used for project goals, should be either measurable or at least be bound/represent a technical fact prior to making project decisions based on it. For example, many people on Discord will say things like "Mac users typically can afford commercial software", however projects like Homebrew exist due to the hard work and dedication of a dedicated FOSS community, so it's not accurate nor fair to a particular user base to categorize them in this fashion without data to support this. On the other hand saying things like "Mac users cannot run Windows VSTs in LMMS and therefore won't' be affected" is a historical fact and can be used for decisions.

[bratpeki]

Why waste time to maintain third-party plugins which the users can also get elsewhere

I'd always be in favor of keeping them if we don't have stock alternatives. Also, we really couldn't remove them until 2.0, since we'd break backwards compatibility.

[tresf]

It took me some time to locate these discussions, here they are:

#96 (comment)

Quoting: (2014)

There were and are good reasons to include and ship with all these plugins. By far not all distributions ship all LADSPA packages and even if, they're partly outdated. Furthermore most of the plugins are not available for Windows so that's why we include them in our build so the end user always gets a huge collection of nice plugins, on whatever platform or distribution he is and we don't have lots of work to build them for every platform manually. It's party of the all-in-one-concept - installing all kind of dependencies manually sucks.

Distributions are free in shipping LMMS without particular LADSPA plugins (by setting CMake flag WANT_SWH etc. or not including according *.so files) and depend on the external package.

Anyways feel free to implement proper LV2 support ;-) -Toby

#3979 (comment)
(I cannot find the original source of this message. I had preserved it for the issue but I can no longer find it in mailing archives).

Quoting: (Date unknown)

"[...] We have been shipping CAPS 0.4.x for years now and the available plugins and their behaviour remained stable for the users all the time. If you would depend on https://packages.debian.org/jessie/caps instead, lots of effects would be missing when loading a project as the available plugins inside CAPS have changed significantly between 0.4.x and 0.9.x. If you'd simply rename caps.so to caps-lmms.so no plugins would be loaded at all as the library base name (caps) is saved in the project file (internally we load caps.so, caps.dll or caps.dylib depending on the platform). If we (LMMS developers) decide to switch to 0.9.x we will implement an according upgrade mechanism internally (and probably even still provide CAPS 0.4.x in a separate library) so things don't break for the user. -Toby"

[firewall1110]

What things do you consider of higher priority?

(1) Substitute current lmms-1.3.0-alpha.1.102 with new one:

• fix release critical bugs (critical);
• make new record button working , or hide it in build (high priority);

And I treat thing critical only if it is something, that prevent new release happen.
You, @michaelgregorius, treat word "critical" in different way, than I.

(2) More transparent project goals (high priority)

P.S
"For me LMMS is good enough without this ..." I mean without this improvement.
"DAW good enough without real-time safety"- is absurd.

But a lot of video like this, shows, that LMMS (even before 1.2.2) is good enough in practice (and I made like this testing videos on 10 years old garbage computers - no lags, no sound dropouts). So real question is: "What real-time safety problems are in LMMS master now?"

But if has, than this is high normal priority task.

audio graph with latency compensation

another high normal priority task.

more sophisticated features for audio drivers, e.g. multiple inputs and outputs

But this now even not actual - SDL driver has configurable input right now in master, but how LMMS user can use this?
(And this bring Audio Recording PR priority to high level - real-time safety, audio graph with latency compensation can wait)

[michaelgregorius]

P.S "For me LMMS is good enough without this ..." I mean without this improvement. "DAW good enough without real-time safety"- is absurd.

But a lot of video like this, shows, that LMMS (even before 1.2.2) is good enough in practice (and I made like this testing videos on 10 years old garbage computers - no lags, no sound dropouts). So real question is: "What real-time safety problems are in LMMS master now?"

Bugs like #7461 or #7638. They are likely caused by doing long running tasks on the audio thread which then leads to drop-outs.

If someone used LMMS in a live session and something like this happened then it would just be embarrassing IMO. Because it would indicate that the developers are either not aware of text like "Real-time audio programming 101: time waits for nothing" or that they do not really care about it.

It's more or less the equivalent of writing a graphics editor that sometimes randomly inserts black rectangles into the images. Would you like to use something like that?

audio graph with latency compensation

another high normal priority task.

It's the basis of any serious DAW.

more sophisticated features for audio drivers, e.g. multiple inputs and outputs

But this now even not actual - SDL driver has configurable input right now in master, but how LMMS user can use this? (And this bring Audio Recording PR priority to high level - real-time safety, audio graph with latency compensation can wait)

Yes, the SDL driver lets you select an input but it only allows you to select one input and that's deeply buried in the settings. Therefore you likely cannot even switch the input during a session because changing the settings requires a restart.

[firewall1110]

Bugs like #7461 or #7638. They are likely caused by doing long running tasks on the audio thread which then leads to drop-outs.

It is release critical bug - regression : SID became broken after code refactoring. This long running task is memory allocation for simulator.
( lmms-1.3.0-alpha.1.102 has no such problem. )

Because it would indicate that the developers are either not aware of text like ...

And this developer is who made this LMMS code refactoring - not the SID author !..

And regression in SID is not the reason, that LMMS have problems with real-time safety - just one refactor code author have this problem.

Sorry for some "sharp words" ...

P.S.
I have started to work with this bug , and hope to fix it ...
But now I am "paralyzed" with my semi professional musician work ...

[michaelgregorius]

Hi everyone. If you want to continue discussing in this thread this is obviously fine. For me personally it is not needed anymore.

I tried to get some discussions going on how to improve things but quickly learned (again) that rational discussion seems not to be possible with some people.

It is now clear to me that things will not change and that I will therefore need to make a change myself and stop contributing to the project because it is not working for me in this form. I was already short of doing so after the "ADSR conundrum" thread that was alluded to here and this thread shows me that it might have been the right decision to do so earlier.

Because I am not on the Discord and also do not plan to join it after I have just left the project I'd like to write a farewell message in a new discussion so that I can say goodbye to the other developers. I hope that is okay. It has been around 11 years after all.

I will also be available with regards to my open PRs if they are intended to be merged at one point so that this work is not wasted. However, I won't implement any new features or do reviews anymore.

[tresf]

I believe discussions are quite rational and I believe that no one here actually disagrees with the OP's (your) high-level observations, but there are some low-level specifics that (I feel) are plainly wrong and I'm hoping to talk though these.

My personality focuses most on the points that are wrong (versus confirming those points that are right) and for that, I'm sorry if it discourages progress. It's something I struggle with as an individual and I'm not sure will change.

That said, I think the OP's (your) declaration/decision to NOT participate in Discord discussions puts parties at a disadvantage when it comes to inflection and intent. I also think it's partially insulting (Edit: disappointing is probably a better word) to those so eager to work with you, as you're mentioned fairly often over there, almost always in recognition of good features, good points, or for need of peer review.

I hope for the sake of the project that you reconsider this decision.

[regulus79]

I feel so bad for this discussion 😭

I love all the work you have done for LMMS. If you feel like you need to step away from the project, I completely respect that. I really wish I could help make the project goals more transparent outside of discord, but to be honest, I'm not sure I even know the project goals.

I also respect you for not using discord. I apologize that I do most of my dev discussion there instead of on github where everyone can see it. Maybe I should try to shift more of it to these discussion boards, and post links in the discord to try to move people here?

[tresf]

Maybe I should try to shift more of it to these discussion boards, and post links in the discord to try to move people here?

This is why I called the decision cultural. As much as I dislike the cultural shift to Discord, so many projects I've tried contributing to use IRC which when I try, I lose any replies that occur when my laptop goes to sleep.

I think DIscord is fine for devs when they learn to mute the nonsense. I personally like it better than professional tools like Slack and Teams.

[tresf]

With regards to preventing more work down the road that's were the "trust" part would come in. People that have proven to provide good and stable features could be trusted to have more freedom (and therefore less bureaucracy).

@michaelgregorius I think as a project we need to focus on this here. For starters, we do discuss trust fairly often on Discord because this conversation tends to benefit by being behind doors (not closed doors, just not internet searchable). For example, when people want to update our wikis, gain access to triage or developer we're pretty quick to grant such trust and we discuss this fairly openly there.

Sadly, this can cause alienation to those only exposed to "trust" through the bug tracker. Adjacent to this, LostRobot expressed some concerns as well about PRs lasting too long in limbo. This is fairly well-known and something we need to fix. I think we're all happy to hear suggestions to improve this.

My personal belief is:

• Nightly is unstable, drive fast and take chances
• Don't screw up too much code that it forces us to hard-reset the main branch
• Small fixes should just be fixed
• Larger changes should receive code quality review and testing

I'm fine with devs testing their own stuff, but even if they don't they need to take onus of any regressions that they caused. This is usually the case, so if the project feels hesitant to accept PRs -- especially by previous, "trusted' developers -- we should be able to collectively make that process easier.

[szeli1]

Nightly is unstable, drive fast and take chances

This would be great, currently I feel like nightly is treated like it's an unofficial stable release for those who don't want to wait for an official release

[tresf]

Yeah I think it sort of is... There's always scope to a regression. I'd love to see us move away from "stable" releases and just add tags for points in time when we think it's "good enough". Stable assumes we provide backport patches and stuff but the branch duplication is hell. It's not really something we have resources or justification for.

[regulus79]

Nightly is unstable, drive fast and take chances

That sounds like a good idea. If we get a bit more "risky" with merging PRs without as much testing, things would go much faster. We would probably have to make more bugfixes, but that's to be expected for a nightly build.

[bratpeki]

Nightly is unstable, drive fast and take chances

I feel like we would then have to provide downloads for at least three nightlies back lol

[regulus79]

Once we get an alpha out that will give us freedom to wreak the nightly. But if we want to fix all the known regressions before doing that... that might take a while lol

[bratpeki]

IF communication issues arise in PRs not being looked at, I've recenlty take a bigger role in LMMS regarding testing (7477 is actually nearing finalization, 7444 is in progress, and some more) and would be willing to look at those.

Regarding communication issues, if @michaelgregorius still has it in his heart for me to try and make amends, I would like to know if the problem with Discord is it being proprietary and whatnot? Rocket.Chat is a possibility, say, and we could keep it team-exclusive. That way, us Discord folk can do PR (public relations, since I know that's not what comes to your minds when you see those two letter 😂) and can report back and use that feedback to work on the project.

In essence, a more Discord-like chatting system (pinged messages, message replies, etc) without being directly Discord (Rocket.Chat running on the same server the website is running on) would allow for neat communication.

In any case, project goals could be more clear, I agree, but now the project is in a position of senior devs doing the heavy-lifting and junior devs investigating the codebase and adding QOL features. I don't think this is a bad approach, even if it is a slow one.

If @michaelgregorius has a list of PRs that are important and should be tested first, I would be happy to look at those as soon as I can!

[michaelgregorius]

Thanks for reaching out, @bratpeki! There are several aspects regarding the communication and one of it is of my own making. 😅

Things of my own making

Let's start with the one of my own making so we have this out of the way. It's not because of the commercial aspect of Discord and it would have been easy to sign up to yet another site (Discord) and to join the discussions there. However, as I have already noted I did not want to get too involved in the project because software development is already my day job. So I wanted to keep it at a recreational coding level and providing code and features without getting too involved with all the nitty gritty details. Not joining Discord was something of a barrier that I have set up for myself to keep it like that. This is the "of my own making" part and I could perfectly understand if someone said: "Well, that's your own problem then."

General aspects

Now to the more general aspects. Discord is completely separate and "hidden" from GitHub where the "actual" development takes place. Obviously, I am not asking to close down the Discord channels as it is a valid communications medium. However, due to its closed nature IMO it would be good to communicate the "big decision" and directions the project wants to take using the already existing and open GitHub infrastructure.

Open and persistent information

First of all this would help people stumbling over the project and coming here to get an understanding of what's going on, what's planned and where they could potentially help. It would be a low barrier entry as the information would be available in an effortless and persistent way whereas Discord is a somewhat higher barrier.

Commitment and lowering risk

I also believe that having the goals here in the open would help with aspects of commitment from both the project and potential developers. Lets say some things have been discussed and decided in Discord. And let's say one of these decisions was: "We want to separate the core from the GUI because it brings more structure to the project and helps with implementing alternative GUIs, e.g. the one designed by Budislav." If the team decided to also document and organize this decision here then this might be interpreted as some form of commitment because it takes time to flesh things out, to perhaps create projects and organize the goals.

Seeing this commitment in turn might give developers and potential collaborators more certainty that the work and effort that they might be about to invest is not lost and for nothing.

A good example might be the actual separation of the core from GUI that was discussed here: #6712. I'm not sure if that discussion and the effort is dead but in case it is then that was lots of commitment by a potential new and motivated contributor that has gone nowhere. Looking at the thread one might then come to the conclusion that the project does not really want such efforts and that providing such efforts in advance and good hopes has a high risk of being wasted. Having this separation would have brought tons of improvements. If these are not wanted then why should people invest time to also redesign other components that LMMS might be in need of.

I have heard lots of time that the project needs more developers. In #6712 there was a developer who was motivated, provided lots of effort and work and yet it did not go anywhere. They had to start out of pure hope that it might lead to something which it seems it did not. I also remember another developer joining and working on the file conversion code. They came across as very motivated, talked positively about the project and yet weeks later they were gone as well.

All I proposed was to try to change some things to increase the chances of these things not happen anymore (or at least as often). And most of what I hear is that this is not possible. To me it looks like the project is in an almost complete stasis and unable to change which is also one of the reasons why I decided to leave. Due to the reasons given above it does not make sense for me to try to implement some bigger changes, especially since even smaller changes take an eternity to get in. Although there seems to be some movement now with regards to the latter issue which I appreciate.

PRs

@bratpeki , regarding the PRs I would greatly appreciate if the following PRs could be tested and moved forward:

• Faders with a dB scale (instead of linear/percentage) #7636 Brings actual value to the users and make LMMS feel like all other DAWs with regards to fader behavior.
• Individual knob labels rendered using the widget font #7525 This is rather technical but makes the knobs more flexible with regards to their labels. With the current implementation you can only change the label size of all knobs in the application and with the fix their sizes can be set individually. It was also quite a lot of time spent which would be sad if it was wasted.
• Vectorscope render fix #7652 Fixes a fundamental problem with rendering under Wayland and improves performance while looking nicer because it scales better even without the bug under Wayland.

Edit: Crossed out the last PR as it is now merged.

[bratpeki]

Thanks for reaching out, @bratpeki!

My pleasure!

So I wanted to keep it at a recreational coding level and providing code and features without getting too involved with all the nitty gritty details.

I get that, I would still say, you can mute everything, and when a PR of yours or related to you is mentioned, we ping you, you read that little bit of text and go back into hiding! 😆

@bratpeki , regarding the PRs I would greatly appreciate if the following PRs could be tested and moved forward

Sure! That being said, my queue now is:

• Add splitting (and resizing) to all types of clips #7477 (Near completion; minor tweaks, final testing and reviewing inbound)
• Refactor PortAudio backend #7444 (WIP)
• Improve waveform rendering performance #7366
• Faders with a dB scale (instead of linear/percentage) #7636
• Individual knob labels rendered using the widget font #7525

so please be patient, as I often take multiple PRs at a time, so I can work on one inbetween breaks from the first one! This is, of course, if you are willing to assist me with them and follow through with merging them!

@LMMS/developers, please drop more PRs, and I'll sort them in some way. I can use this discussion as a way to keep track, then! :)

[tresf]

@LMMS/developers, please drop more PRs, and I'll sort them in some way. I can use this discussion as a way to keep track, then! :)

@messmerd has recommended publishing some type of monthly goal list status report, quoting Discord:

If we wanted to start doing status reports, someone could take on the responsibility of drafting the status report at the end of each month and posting it on GitHub discussions (and maybe mirrored on lmms.io). The drafting could be done in a Discord thread with input from others + incorporating comments from the previous month's status report on GitHub.

Status reports could inform both users and devs about the project's current direction (whether on or off Discord), provide a sense of structure that helps keep us focused, and also allow people to give feedback on recent features and what they hope to see.
Individual devs could provide a few sentences summarizing recent work that they've been doing and what they hope to do. Only if they want to of course.

Thoughts?
👍 (4) 👎 (0) 😕 (0) (options to "vote" were placed in the Discord #dev-only channel).

[Rossmaxx]

Sorry Michael on behalf of the project, for making you feel like leaving is the only option. I respect your decision to leave but at the same time, I would appreciate if we can take care of the pending work before your exit, the unmerged stuff.

Note: I said something else in the message before i edited this in, because peki said the old message lacked humanity, and i felt it too. Didn't mean to hurt anyone.

[michaelgregorius]

Thanks for the kind words, @Rossmaxx! It was nice to work with you, e.g. on the Qt6 migration. I wish you good luck with the remaining work as it is an important step to make sure that LMMS will still build on all distributions in the future.

I would greatly appreciate if the unmerged stuff would not go wasted. At the end of my reply to @bratpeki there's a list of the PRs that I see as valuable. Most of the other ones that are still open are either small or stalled ones anyway.

By the way, the old comment is still available in the drop down box and you made me curious about what you meant. 😉 It did not hurt me and I just interpreted the "RIP" as a translation or language barrier thing. The rest of that sentence I interpreted as a simple observation as I am not the first one to leave (see also the comment to bratpeki).

[firewall1110]

I wrote before: (in 10 days I will open discussion about such "little" uncompleted things)

Instead I participate in discussion #7653 : Thank You, @regulus79 !

[messmerd]

I just started a monthly progress report for the benefit of both users and devs. It will be a kind of newsletter where we talk openly and transparently about goals for each month, in-progress work, and recent changes in Nightly, while also being a place for discussion and feedback. It will be posted here, on Discord, and on the lmms.io forums.

#7676