Michael9Merged the upstream 1.1.0 version of Ambience into my fork and released it today.
https://github.com/michaelquigley/ambience/releases/tag/v1.1.0
Should be ready to go!
#linux #audio #linuxaudio #studio #vst #vst3 #foss #software
DRMR@fortifieduniverse If you're going to maintain a fork maybe rename the project?
@dreamer Why? The GitHub URL disambiguates it? I'm not trying to give the plugin a separate identity.
🐈⬛David Sommerseth@fortifieduniverse, it's about the user experience once a user has installed it. If the user has both the origin and the fork installed - it can get very confusing.
What is fairly common, is to add some extra word(s) to the origin project name. Some do change the name entirely, but not necessarily unless there is a trademark violation.
As an open source developer for over 20 years, I would really recommend you to do add a variation to you fork name, unless your goal is to get your modifications accepted into the origin project. If your goal is to go your own route, independently of the origin project, having a name differentiating your work from the origin project is going to be more helpful for both your project's visibility as well as being less confusing for your users.
Just play with the idea at least ...I'll throw in a few suggestions to seed some ideas ... "Ambience Novus", "Ambience Alius", "Ambience Reborn".
I honestly believe you'll get more traction around your work this way. And I'm pretty sure the origin project will appreciate it as well.
If you truly want to just provide this plugin for Linux users, I would strongly recommend you to do a pull request from your fork to get that support upstream. Work with the upstream project closely to find the right approach together.
It's seldom an upstream project rejects such help. But if they do reject it completely and there is no possibility to get your work merged, then a modified project name would be needed.
And sometimes an upstream project will accept only some of the changes. Work with them on that, as that will make your fork easier to maintain as well - the gap between the projects ends up smaller.
@dazo Appreciate the lecture... but I already understand the problem and the proposed solution.
This is just a personal fork that I've made available in case someone else would like to play with it. Best I'll do is consider changing the metadata. Maybe.
I'm not trying to "get traction" or go through a big effort to merge my changes.. the original author does not seem interested, if you read their website.
Not every little "hey... here's a plugin build to play with" needs this treatment.
@fortifieduniverse Often projects might not show interest publicly because of lack of a maintainer for the needed changes. Projects are veary to take on more code to maintain if they are scarce on resources and already have more than enough tasks to tackle.
Reach out to them, commit yourself to help out on the Linux part and they might change their stance.
@dazo And again, the only way a Linux user is going to have the original installed right now, today, is if they go to the trouble of not just building from source, but hand-patching the JUCE framework location.
The number of users who are going to install my build, and also hand-hack the upstream? I bet that number is zero.
@dreamer If I planned to revamp the plugin in a major way, then I would rename it. But this is just a "fork" in the sense that I've added Linux build support, and a couple of quality-of-life improvements.
@fortifieduniverse Releasing someone elses work under the same name is imo a bit disrespectful.
If you're going to fork and continue development on your end then it's best to rename the project.
@dreamer and quite honestly I think it's more disrespectful to change the name and call it something else.
@fortifieduniverse did you change the slug at all? because if a user loads both plugins they will have a bad time.
Morten Mosgaard@fortifieduniverse @dreamer Interesting discussion.
To me as a non-programmer (and not knowing any written/unwritten rules in the open source community), keeping the same name seems quite obvious, especially when the Linux-port-purpose is so clear on the Github: https://github.com/michaelquigley/ambience
Isn't it the same with these DISTRHO ports: https://distrho.sourceforge.io/ports.php
@mosgaard @fortifieduniverse Not really. The distrho ports do not conflict with the original JUCE versions, in this case there is a clear conflict if one installs both.
So I will concede on the name (unless the OG dev complains of course), but you really should change the slug by changing the manufacturer and plugin codes: https://github.com/michaelquigley/ambience/blob/master/CMakeLists.txt#L48-L49
You can also try to clean all of this up (it's kind of a mess imo) and open a PR upstream of course.
I already opened a PR for easy Linux builds.
@dreamer @mosgaard "You can also try to clean all of this up (it's kind of a mess imo)" ... this whole thing is an example of the attitude that keeps people away from the Linux community.
It's not "a mess". It's a choice you can freely choose not to make. I'm not trying to take credit for anyone's (AI generated) work. I literally built the thing because I wanted to use it, made a few tweaks I liked, and shared it. Everyone is free to use it or not.
Markus@fortifieduniverse Thank you!!
Alexander Tuchaček@fortifieduniverse
thank you!!!
thank you!!!