Can you link the PR?
But also, what's the problem with having this as a plugin? Isn't it better to keep the core OBS small, and provide extra functionality via plugins?
But also, what's the problem with having this as a plugin? Isn't it better to keep the core OBS small, and provide extra functionality via plugins?
https://github.com/obsproject/obs-studio/pull/7961
I guess most frustrating to me was the request to format the code and fix the commit message as if it was on track, only to be rejected for "we don't want this in the first place".
Plugins suck. There are a lot of people who will not bother to go that route. It immediately raises questions about what OS do they work on, do they cost money, how do I install them?
They include compression and noise gate among others. Enough to clean up my microphone input. But not much in the way of tone control.
Serious people WILL explore the plugins route, but one has to go from "What is this thing I just downloaded and how do I use it?" to "Okay, I've got the hang of this, I'm pretty good at it, but the stock tools are holing me back from making something better." I would venture to say that the majority using OBS will never make it to that second phase. For those who do, have a well SEOed blog post and YouTube/TikTok video ready to show them how to take it to 11.
Usually, those things are easy to check, almost a part of just triage where you try to cover lots of ground but just the surface. Takes small amount of time for the maintainer unless there is a lot of ground to cover obviously.
But unless they explicitly signal the change is wanted, I wouldn't (in the future) take that as a signal that the change in general is wanted.
As a tip, before trying to contribute any larger patches to FOSS, create a issue to ask if this is something they'd actually be willing to merge, if you chose to build it. Then you know for sure up front if it's worth spending time on.
> Plugins suck. There are a lot of people who will not bother to go that route. It immediately raises questions about what OS do they work on, do they cost money, how do I install them?
Personally, I appreciate the architecture of "small core - allow extensions" so I'm happy they don't expand OBS in that way.
As well, I'd appreciate it a lot if you made what you did into a plugin, better audio control is wanted by a large set of OBS and I know many do the piping outside of OBS to get a proper equalizer. So if you spend time on making it into an extension, I'm sure you'd find lots of people grateful for that.
Oh I completely agree. This was scratching an itch on my part, plus I had been under the impression they didn't want it. But it wasn't clear, did they not want to develop it themselves? Why the 3-band? So I finally sat down and did something and fit the submission guidelines to find out.
Now I kinda have the bug. It might be best to make some kind of pipewire effects that can be used in anything (on linux).
Pipewire effects for equalizer and so much more already exists (personally I use Easy Effects for that), and the people I know using OBS are kind of stuck with Windows because of other reasons. Also, it's nice to have everything you need in one package.
But, you're the author after all, you decide what you want to do :)
The majority of the time a DAW ships with things like EQs, compressors, etc, they are actually some kind of plugin.
Plugins don't suck, your opinion is not everyone else's fact.
Plugins do suck. But the entire recording industry uses plugins.
Both are true. Loading arbitrary blobs of 3rd party code into your plugin host is a nightmare; adding arbitrary blobs of amazing new functionality into your plugin host is amazing.
That does suck, from multiple people too. Code review processes that put off developers from contributing and don't value their time, rather than helping them to contribute are a pet hate of mine.
Reading that PR discussion, I don't see any sort of 'gross'-ness.
The submitter submits a (presumably unrequested) PR. One project maintainer adds comments to bring it up to project standards. Later, another dev clarifies that after discussion, they agree that it doesn't belong in the core project.
For anyone else out there who doesn't like 'their time wasted', discuss your idea with project maintainers before submitting a PR. Just because you think it is a good idea doesn't mean it fits within their vision for the project.
> For anyone else out there who doesn't like 'their time wasted', discuss your idea with project maintainers before submitting a PR. Just because you think it is a good idea doesn't mean it fits within their vision for the project.
Of course. I give the same advice. But that's not a valid excuse for treating would-be contributors like this. You can reject PRs but in a more respectful and polite manner, without the misleading additional time-wasting requests. Rejection and professionalism/politeness are not mutually exclusive.
clarification request: with scare qutoes around "their time wasted," does that imply that you do like your time wasted? or that you don't think all the effort spent making the PR was wasted?
You know the answer, so forgive me for not responding to your not-in-good-faith question.
To clarify my point: If you think about this from the project maintainer's standpoint, the submitter is the one doing something wrong if they are getting angry at this outcome. They are speculatively doing work assuming that it is going to eventually get integrated, without seeking any information about its value beforehand.
No I don't, otherwise I wouldn't have asked. And if you're going to assume bad faith on my end then there's probably not much more to discuss.
Curious, what if the maintainer had just replied with a "finger" emoji instead? Would that change your opinion on whether this was gross, or is the manner of the reply completely irrelevant to you? (Since you seem to be presuming bad faith on my part, I feel I have to add this disclaimer to my thought experiment. Don't assume I'm implying there is some sort of equivalency here with the response that was given and a hypothetical "finger" response. I am not. This is a thought experiment, not an implication that the maintainer acted in such a way).
If so, then I would suggest that our disagreement here is just about what is polite and what's not, and what a person's social responsibility is regarding being polite. In my opinion there's a responsiblity on the maintainer to be polite in this case. If you disagree with that, that's just an "agree to disagree" sort of thing.
If your opinion wouldn't change if the response had been a "finger" emoji, then I would suggest that our disagreement here is about whether politeness is something that matters.
The person who submitted this code went out on a limb and implemented something without talking to the maintainers first. That's completely fine. I'm sure they learned quite a bit by implementing it. That's a win by itself.
It's the getting upset that it didn't get integrated that I think is unreasonable. The maintainers donate their time to write and curate code to make progress on their vision of the software.
Submitting code like this (not talking beforehand) is like giving a friend who likes photography a camera without asking what they want. There's a chance they love it, but there's a good chance they wont. If you care about getting one outcome over another, you need to communicate beforehand.