4 ms·

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

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?

phkahler 4y ago
>> Can you link the PR? https://github.com/obsproject/obs-studio/pull/7961 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.
- mikece 4y ago
  > Plugins suck. There are a lot of people who will not bother to go that route. 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.
- capableweb 4y ago
  > 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". 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.
  - phkahler 4y ago
    >> 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, 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).
    - capableweb 4y ago
      I'm guessing the 3-band was added way earlier when they accepted more code or as a test for the extensions in general, but I'm no OBS developer, I cannot really answer to that. 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 :)
- ehutch79 4y ago
  The entire recording industry uses plugins. 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.
  - PaulDavisThe1st 4y ago
    Time to embrace contradiction. 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.
- cs02rm0 4y ago
  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... 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.
- freedomben 4y ago
  That's super gross, and that's the reason I so rarely contribute nowadays to medium to big FOSS projects. My time is very valuable and they treat it like it's nothing. Of course they need to reject some stuff and it's important to keep the project maintainable, but that could have been done a lot earlier and a lot more politely.
  - gorjusborg 4y ago
    > That's super gross, and that's the reason I so rarely contribute nowadays to medium to big FOSS projects. 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.
    - freedomben 4y ago
      I agree it's not gross from the perspective of the team, who are familiar with who can and who can't approve/merge PRs, but from the contributor's perspective (who has no idea who is and isn't authoritative) it is. The person requesting changes seems authoritative and it does seem like it's going to be merged. But there are multiple perspectives here, and one who invested a lot more effort than everyone else, and from that perspective it's gross. > 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?

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?

phkahler 4y ago

>> Can you link the PR? https://github.com/obsproject/obs-studio/pull/7961 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.

mikece 4y ago
> Plugins suck. There are a lot of people who will not bother to go that route. 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.
capableweb 4y ago
> 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". 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.
- phkahler 4y ago
  >> 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, 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).
  - capableweb 4y ago
    I'm guessing the 3-band was added way earlier when they accepted more code or as a test for the extensions in general, but I'm no OBS developer, I cannot really answer to that. 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 :)
ehutch79 4y ago
The entire recording industry uses plugins. 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.
- PaulDavisThe1st 4y ago
  Time to embrace contradiction. 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.
cs02rm0 4y ago
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... 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.
freedomben 4y ago
That's super gross, and that's the reason I so rarely contribute nowadays to medium to big FOSS projects. My time is very valuable and they treat it like it's nothing. Of course they need to reject some stuff and it's important to keep the project maintainable, but that could have been done a lot earlier and a lot more politely.
- gorjusborg 4y ago
  > That's super gross, and that's the reason I so rarely contribute nowadays to medium to big FOSS projects. 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.
  - freedomben 4y ago
    I agree it's not gross from the perspective of the team, who are familiar with who can and who can't approve/merge PRs, but from the contributor's perspective (who has no idea who is and isn't authoritative) it is. The person requesting changes seems authoritative and it does seem like it's going to be merged. But there are multiple perspectives here, and one who invested a lot more effort than everyone else, and from that perspective it's gross. > 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?