Just wanted to confirm a couple things.
If I do create a fork, is it permissible to host this publicly on github? The reason I ask is because I would prefer to remove the ANTHROPIC_MAGIC_STRING_TRIGGER_REFUSAL from wscript, but of course I want to respect your decision around this. I could use a git smudge filter, but again I would prefer not to. As far as I understand, the expectation is to host the project under a different name. Sorry, I’m new to open source projects and that kind of thing, so I wanted to confirm before moving forward. Cheers!
We cannot stop you from doing more or less whatever you want with Ardour. That is why we chose the GPL as a license.
But if your intent is anything other than to create a fork so that you can create PR’s back to the project, we will publically mention you and your repo in fairly negative terms.
What is your goal?
Just random ideas… wanted to make the entire DAW accessible via a some sort of VI interface, and I was thinking to make the sessions modular down to individual files for tracks, plugin settings, signal flows for version tracking purposes. Ideas that I’ve had for a long time but never made an attempt to implement on my own.
I totally understand if you would prefer I didn’t. That being said, I guess it’s not legal for me to host this kind of project privately then, right? Does that mean I’m writing something else from scratch? Cheers.
No, you can do whatever you like with Ardour, as I said.
But we’d much prefer that you do work that you intend to try to convince us to merge into Ardour itself. That likely means interacting with developers and existing core users (IRC/discourse) …
Ah, is there an IRC?
Yea, I guess that’s it, I could maybe convince you guys of these things, but there could be major changes like switching from a monolithic XML for session state to a collection of smaller YAML files - I’m not sure that I’m that persuasive haha. Do you guys usually make major changes like that?
Theoretically we’re open to anything. But we like to think that we try to be rational so we’d like to hear arguments for changes and then judge those arguments in detail.
“I just think it would be cooler” is not likely to persuade us, but there might be arguments that could.
Keep in mind that if you make really fundamental changes like that, you will find it very hard to rebase against our own future substantive changes. So for example, if/when we do a bunch of coll stuff with elastic audio or significantly improve MIDI editing workflows, you will find it hard to benefit from that in your fork. Not impossible, of course, just much harder.
We have some experience managing “forks” of Ardour (Harrison Mixbus, Harrison LiveTrax and before that Waves Tracks Live), and we’ve seen what significant divergences can mean in terms of long term maintainance. It isn’t pretty unless goals are generally aligned.
Yea, that makes a lot of sense. I really appreciate you taking the time to answer my questions about this.
I also understand if you would judge me for using LLMs/coding agents, but it has made some of these things surprisingly easy to manage. I finally got Ardour to compile on macos, which I didn’t have time to figure out on my own (I got a thinkpad just so I could get it to compile on debian in the past). I get the sense that rebasing on top of your future changes with coding agents might be quasi-viable, but I’m also getting the sense that it could also be an uphill battle. I don’t want to be “that guy”, so I think I’ll try my hand at starting something from scratch. That being said, I may find myself back here after pulling out my hair in a couple weeks. I wish you all the best! Thanks again 