Please note that what you described is a feature of copyleft, not of all open source software (which also includes permissive licenses like MIT).
But your understanding is correct, since Ardour is copylefted (GPLv2+) and indeed, Mixbus has to comply with the requirement of releasing their source code under the same license.
The build script for Ardour includes the option to build as Mixbus instead of Ardour.
I don’t believe you could distribute any build with “Mixbus” in the name because of trademark issues, but if you just want to build you can do that.
My understanding is that there are really two parts to making Mixbus different from standard Ardour, and building Mixbus from the Ardour source only gets you the workflow and UI differences. The other half is the proprietary Harrison plugins, and you will not have those. Since plugins are loaded as independent modules Harrison is free to distribute close source plugins, just as you are free to load closed source plugins into Ardour.
One small clarification. Although it is true that you can find #ifdef MIXBUS in the ardour source code, that is because we share in development efforts. The ardour source code is NOT the same as the Mixbus source code - you cannot build Mixbus from the ardour source, nor ardour from the Mixbus source.
I was not sure how to google what I was looking for but I did find some results after the fact.
Thank you for clarifying, sorry I did not do my homework a little better before posting.
The vast majority of Harrison’s changes to the Ardour source code actually become part of Ardour itself; the remaining changes (including the channelstrip knobs and such) are publicly accessible at git://git.ardour.org/harrison/mixbus (hosted on ardour’s server)
Other elements in the Mixbus package (channelstrip plugins, XT plugins, and the proprietary ‘ACE’ control panels, etc) do not use any GPL libraries or software, and we don’t publish the source code. Harrison’s build and code-signing systems, commercial-quality support services and custom documentation are also value-additions that are not subject to the GPL.
We contribute heavily to the ardour workstation with both $ and code (I’m currently the fifth-largest contributor but I’ll probably become 3rd place within a month or so!) … so we’ve had a very good relationship with the ardour team for over 12 years now.
Let me know if you have any other questions!
-Ben at Harrison
Thanks for clearing this up. Not sure if this is possible but since the layout code for the mixer is there, would of been cool to have the stock ardour and compressor working in the layout of the mixer instead of 32c proprietary lol but maybe that’s just wishful thinking
Hi Ben, I apologise in advance for any lack of Google research but … does your response imply that there is a Harrison API to the various (lib) modules that us, the proletariat, can access and integrate into our own UI for Harrison Mixbus(32c)?
Full disclosure: I own all the MB plugins and 32c but fiddle at a hobbyist level with Lua albeit a I’m a fully fledged C++ (&c.) software dev.
yes, there is an API (source code is available!) but (a) there are much easier entry-points if you want to do something cool with ardour and (b) what’s the point? replacing the eq plugin with an eq that matches the knobs won’t provide anything new and won’t be the harrison sound.
I might not have understood your comment … “can access and integrate into our own UI…” can you tell me what you want to achieve?
I have to chime in here, as for the reason for replacing the 32c EQ and not having the Harrison sound, I’ve seen countless videos and testing that the 32c doesn’t have any sort of colour or tone, in fact the 32c eq seems to be very clean, along with the compressor modes, only thing is the LP/HP filters that don’t NULL. So I don’t know about Harrison sound. I don’t hear any sort of vibe with 32c. And to be honest if the eq was switched with ardour’s stock eq with same curves I probably wouldn’t tell a difference.
In regards to the 32c tape sat, well it’s definitely not clean as it does add vibe and colour and tone depending on how hard you push it.
I would still love ardour to have its own eq mixer layout like mixbus and reason DAW etc, but not similar to mixbus but different. Ardour seems to have lots of screen space, I know there’s an option to have plugin controls there, but sliders are not ideal for me so I would prefer knobs. Maybe a feature request is needed.
There’s a major philosophy difference between Mixbus and Ardour.
Mixbus sets out to deliberately constrain your workflow in the same sort of way that a traditional console would, out of a sincere belief that this is better for you, most of the time.
Ardour sets out to deliberately release you from constraints, out of a somewhat naive belief that this is liberating.
If you want a set up in Ardour that roughly parallels the Mixbus one, you can set up a session template and track templates and you’ll be fairly close. But we’re not going to help you get closer - you can use Mixbus for that.
I guess the best of both worlds world be nice but maybe mixbus would be more preferable for that. In reality I do think it would be nice to see ardour’s stock eq and compressor etc have its own in-line gui, not for the sake of a mixbus workflow but just flexibility considering ardour has in-line plugin vu already. But maybe the in-line is more the plugin info such as level meters, vu meters and not actual plugin usage. Does sound kinda cool but sometimes are just cool thoughts but not feasible in reality.
@Ben, that’s very good to hear! Thx. With regards to the “access and integrate into our own UI” it’s simply a case of removing the elements of MB32c that I still find a nuisance. All these niggles have been addressed in the forums and I completely accept the answers - basically my mods would break the ethos.
I will say though that I do think I achieve better sounding mixes with MB32c than I do with the equivalent tools in Reaper - for whatever reason that may be. And maybe more to the point, I really try not to overthink this aspect.
For the record, as to the few niggles;
There are a few even more miniscule things I keep getting tripped up by but as I get used to Lua I’m slowly knocking them off.
Re 4: everything in the menu bar is an action, and can be invoked from Lua.
Re 3: pre- and post- fader colors are a part of the theme (look for gtk_processor_{pre,post}fader)
per-region ‘polarity’ is not currently supported, but it has been on my wish list for years now. I bring it up regularly at our dev meetings but it has not yet made it to the top of the priority list.
-Ben at Harrison
What is the use case for that? I don’t think it would have occurred to me to switch polarity in the middle of a track.
@Chris: the reason this is on my personal list is because the region could be drawn inverted so you can see it match its ‘sibling’ tracks.
I’ve never had this problem, but it is conceivable that the polarity changes during a recording. Perhaps a long session spanning several songs, and on some of the songs someone bumped the mic-preamp phase button instead of a pad, or somesuch.
Another argument for doing it on a region basis is that you could cut/copy/paste the region to another track (to apply different processing to that part) and you wouldn’t have to remember to invert that track’s polarity to match.
-Ben
Harrison is a company, why not hire some contractors to implement desired features in GPL Ardour, if Paul or Robin don’t have time to work on them? And then, if Paul or Robin don’t accept to merge those features, just keep them in GPL Mixbus.
It’s not worth fixing something that isn’t broken. I understand that both programs are being developed together. And Harrison has a team of people involved in the project.
I think that the work of skilled coders is welcomed, so it’s worth applying if you have that kind of skill and passion. Aren’t open source projects like that?
I would agree normally but here we’re talking about adding a feature (per-region polarity). I do not understand how having per-region polarity could impact negatively Ardour, keeping aside possible refactoring issues (which could actually benefit Ardour, in the long-run).
From a programming perspective, I can understand that it is desirable to avoid merge conflicts, as they waste precious time. But on the other hand, Harrison could ask the Ardour devs if it’s OK to implement that feature and if they get the OK, Harrison could hire a contractor to implement it (else, nobody does anything).
Actually, I think a bounty system would help Ardour grow but I understand that preparing the infrastructure for it can waste Paul’s time (even if there are existing sites like BountySource and now Ardour uses Gitea, which could replace BugZilla for both feature requests and merge requests, IMHO). I’ve contributed code to FLOSS projects in the past and IMHO one big obstacle to becoming a contributor is the size and complexity of a given codebase. Getting to the level needed to be able to contribute to Ardour without breaking anything requires a time investment and without funding, only people paid to work on Ardour by third parties and (the really small subset of) committed hobbyists/musicians with solid C++ skills can realistically afford to do it, everyone in between is probably better off working on smaller projects.