Has anyone actually tried this? Most of the comments seem to be about the licensing or the ui, i'm just curious how this holds up to ardour. This actually looks pretty awesome.
I've tried using it but it crashes too often and is generally too buggy to use. It seems to be in an early stage of development so this is to be expected. The UI and general workflow look very promising though, in particular the piano roll. It has a long way to go to match the maturity and features of Ardour, but the UI design that it's aiming for will make it more suitable for people making EDM.
It's using some notable chunks of Ardour's code, which might help it along.
OTOH, Reaper's lead developer was thinking of doing that at the beginning of Reaper's life, decided against it, and we can see how (well) that worked out! :)
Please elaborate, not sure if you mean in a positive or negative way.
For what it's worth, I find Reaper to be a lot better than Ardour in general. It just feels 100% professional and slick. The Ardour interface comes across like your typical GTK app, sluggish and glitchy with that constant feeling that something ain't right. You should have moved to QT a long time ago.
I don't bother to listen (much) to critiques of Ardour's GUI. Every week I get an email that tells me it is totally pile of crap and I should feel embarrassed to even consider it usable, and another telling me how smooth and intuitive it is, much better than any other DAW.
When people say things like "Ardour's workflow for doing <X> is a bit clunky - it takes 6 mouse clicks, but if you did it like <this> it would only take 3" ... I try to listen to that and incorporate these kinds of ideas.
Reaper does a bunch of things that Ardour doesn't. Ardour does a bunch of things that Reaper doesn't. Reaper does some things that we both do better than Ardour, and vice versa.
"300k+ LOC application should have moved to <other GUI toolkit a long time ago" suggests that you have never moved 175k lines of GUI code between toolkits, regardless of which application and which toolkit you're discussing.
I actually like Ardour's GUI a lot (and am grateful that it uses Gtk: KDE never ran stably on a machine I owned, and I found that in Gtk-based environments, it is actually always the Qt applications that are inexplicably unstable). The main problem that prevents me from using it is that I keep running into show-stopping bugs in the backend: for instance, MIDI recording (including even "loopback" where I just recorded the output of another MIDI automation channel playing in Ardour itself) in 5.12 kept dropping note-on/-off events, and more critically, there is some persistent issue that results in ZynAddSubFX plugin settings getting corrupted through save-load cycles. I have confirmed that the latter is still around in 6.0, and the furthest I have gotten in pinning it down is the observation that the correct state seems to get saved in a plugins/<id>/state<n> folder, but this is not what gets loaded and loading and then saving again without doing anything else results in it creating a state<n+1> subfolder with the garbled state without state<n> being touched.
I haven't had any luck getting responses to bug reports, and anyhow it seems that ZynAddSubFX should be a sufficiently common plugin that if this bug were easy to reproduce, someone else would have stumbled upon it by now (and so it probably arises due to a weird interaction with something else that's particular to my setup).
The lead dev of current zyn says: " I heard about the corruption issue quite a while ago, though I had thought it was traced back to a now resolved DPF issue. I might be wrong about that though"
My half-remembered experience of Ardour from some years back was that it felt very fleshed out in replicating traditional recording, but had little in terms of sequencing. As such it was "wonderful product, just not for me". And I'm happy to hear that you are sticking with it.
I have basically stuck with OpenMPT after all this time, since most of the time I want to really sequence something on the grid, and only deviate from that if really necessary(and then usually turn to Mixcraft which has a decent set of defaults and built-in plugins and presets for most things).
Yeah, Ardour definitely started life as linear/timeline recording tool, along the lines of (then) ProTools/Samplitude/Pyramix/Sequoia.
Ableton Live changed everything, even for the sequencer-originated DAWs like Cubase, and it's true that in Ardour we haven't (yet) attempted to tackle that sort of thing.
Personally I prefer the lack of a sequencer in ardour. I use muse or rosegarden for most midi tracks and hydrogen for drums. I feel like this fits more with the modular linux philosophy, though I do realize ardour is cross platform. I appreciate that ardour has pretty much one paradigm and does it well.
not just code, even the price model and some bits here and there from Ardour's website and other ideas. I'm really thankful for Ardour for paving the way, and Robin Gareus has been key to getting this far with his advice and help
FWIW, the original versions of Ardour were "extensible in Guile" too. The entire program (well, the GUI) ran inside the interpreter's REPL. We ripped that our before v2 came out. These days, we use Lua.
LV2 plugins aren't supported in Reaper but are in Ardour, this makes quite a difference in Linux. In my opinion the anywhere to anywhere routing is better in Ardour. That said, I moved from Ardour to Reaper and prefer Reaper.
I believe Ardour has an open license and Reaper has a proprietary licence. In terms of functionality and ease of use however, I think Reaper is hard to beat.
Whenever I see something like this, my first question is, wow what a beautiful cross-platform UI -- I wonder what they are using?
It's amazing how challenging it is in 2020 to have a simple path for creating a cross-platform UI that actually looks good and is not aimed at developers as users, but rather competes with the polish of established applications. Unless you go with Electron or pay thousands per year for a Qt license, options are quite limited.
Why does everyone keep repeating the "pay for a Qt license" meme every time that someone presents a Qt software? You do not need to pay for a Qt license, it is under lgpl, just like a lot of other libraries that you can use in both foss and non-foss applications. Even GTK which some replies suggested uses the LGPL! Same goes for glibc which you link all of your programs to.
IBM / Redhat reputation managers want you on systemd + gnome + wayland. Their natterings reach all corners of the Internet. It's concerted, shameless, and it's really starting to get irritating.
The sheer pervasiveness across all platforms with unified messaging indicates faux grassroots shillops. Super easy to spot these days. Over-shilling broke the reputation management industry.
The license for QT has been evolving quite a lot over the last year or two, which makes many developers very nervous to use it without a paid license. Have you seen what they’re doing?
The terms of their commercial license may have been evolving, but the terms of the open source has not. GPL is GPL and LGPL is LGPL. The terms of those licenses prohibit additional restrictions (notably, you are not allowed to add a noncommercial clause to the GPL/LGPL) and the Qt company cannot make their own open source license that is noncommercial otherwise they'd violate the KDE Free Qt Agreement. The most they seem to have been thinking about doing was witholding the open source releases for 12 mo. which is unfortunate, but they are required to keep an open source version around because of the KDE Free Qt Agreement[1], otherwise they are required to release the framework under the BSD license.
Autodesk Maya notably does not use a commercial Qt license, they use it under the LGPL. You can find the source code for their patches of Qt on their website. [2]
Maybe they simply see no value in keeping their modifications to qt to themselves and value in up streaming it ensuring they no longer have to maintain the code. This makes a lot of sense they are in the business of providing world class software not gui frameworks.
I am not sure if it's still this way, but I think at least some versions of the Qt Commercial License disallowed you from having user scripting in your application - or at least, exposing Qt APIs to user scripting. So no bindings like PySide or PyQt and the like could be used.
> In case The Qt Company would ever attempt to close down Open Source Qt, the foundation is entitled to publish Qt under the BSD license. This notable legal guarantee strengthens Qt. It creates trust among developers, contributors and customers.
Content production tools have fairly unique UI needs compared to the average desktop application, e.g. they often have very complex timeline controls that offer dozens if not hundreds of different interactions specific to the tool at hand. Generic UI libraries would only be a hindrance there. They almost never have enough screen space, so the widget/interaction density is far greater than what’d be ergonomic for standard apps. Since people spend considerable time learning these tools they generally have their own UI paradigms independent of the host OS, which is the opposite of what you‘d want in a crossplatform toolkit.
I have argued in the past that any app worth a damn will not use some generic off-the-shelf widget kit. This includes even apps such as Excel or Word.
The reasons for this are that GUI widget kits are generalized to the least common denominator. They are written with a specific, narrow usage in mind and will never fit your application to the degree you need. And in some cases the author of a certain widget tries to do this, and the widget succumbs to the weight of complexity required to be all things to all people. Not even GIMP uses only GTK+.
The second reason that staying in one widget kit is bad is because it's a competitive world out there. You need to differentiate. That's not easy when every app looks and feels the same because they all use the same tool kit.
In addition to all of this, different OSes have different UX. A Qt app on Mac is not going to be identical to a Qt app on Linux. Assuming the Qt app is written to the guidelines of the OS and not just doing whatever it wants. Internally, the app will do what is best (e.g. photoshop canvas), but will play nice with the external window manager, accessibility, etc.
Word/Office is such a good example because they use their own window decorations, ribbon, scroll bars etc., which no other program (even from MS) has, and no second source implementation with exactly the same features exists.
the question is not really whether they use Qt. It's how much of Qt they use. Ardour, for example, uses GTK, but hardly uses any of GTK for the majority of the GUI.
Same with modern ZynAddSubFX. I personally have no issues with this model, I'd rather pay for libre software then equivalent proprietary. That being said, if I were to try using this I would probably build it.
They just have a very (over)zealous locale detection system that tries to show you a language localized page based on your browser's language priority.
Addendum: since this is getting downvoted, probably because I didn't explain why this matters beyond philosophical arguments, read my reply down the thread for why the license means in practice I can't use this DAW as a live plug-in host (without a huge hassle). There's a practical concern for you. One that doesn't apply to most proprietary applications, it's very unique to the AGPL.
This looks good, I've been making music with Ardour lately and this has a few features I wish Ardour did.
But - too bad it's not free software. It's unfortunately licensed under an EULA, the GNU AGPLv3 - which, as much as the FSF would like you to believe otherwise, is not a Free Software license, as it violates Freedom 0, your right to use/run the software however you wish without conditions. The AGPL imposes requirements not only on people who distribute the software (like a simple copyright license, e.g. the GPLs, BSD, Apache, etc), but also on people who merely use it (it requires you to make the source code available to anyone who even uses the software indirectly, e.g. as a service).
So I might use if it's good, but I won't be contributing patches to it, as I would with other software like Ardour, and I won't use it in a live setting. I can't in good conscience spend my free time contributing to software behind a EULA.
(I haven't the foggiest clue why they picked this license either; its main purpose is to extend the GPL's virality to network services to the detriment of user freedom, but this isn't a network service.)
This reads more like a general diatribe against AGPLv3 than a critique of the program.
I don't like GPL licenses myself, I prefer BSD/MIT/etc.
But that aside, this has very little to do with this program, and it very little (if any) impediment to using this kind of program.
It might prevent a company from building a commercial closed source version (which is fine, we have plenty of commercial DAWs already), and it might prevent a company from somehow turning this into SaaS. Both of those seem like very remote and unlike possibilities, even if this was non GPLv3.
"I don't like GPL licenses myself, I prefer BSD/MIT/etc."
The GPL may deserve some criticism from a business point of view, but how many of the businesses that criticize it openly, or attempt to dodge it covertly, were brought to success thanks to developers who could become what they are by studying and modifying code that without the GPL would have never been published?
It's actually a common misconception: that companies publish code because GPL forces them to. In practice, it works the other way around: first you make the decision whether to publish the code or not, only then you choose software with appropriate license.
How does it limit what code you are allowed to integrate with? Do you think that running someone else's code on your machine obliges you to somehow acquire the code to the module that you loaded and share it somehow?
It does when the license says so. Of course, such a document cannot override the local law, and it might be hard to enforce.
For the AGPL, you cannot link against something that isn't also (A)GPL. That means that if you integrate it any tighter than 'running it standalone on an OS' you're probably linking it.
It's certainly a critique of the AGPL. I was just rather shocked to see the AGPL here, of all places. It doesn't make any sense, and it puts me off of considering it as a general free software DAW, and more in the same category as the proprietary plug-ins that I use (because there's no FOSS alternative). I'll use them, but not consider them a community project I can contribute to.
It may not be obvious how the AGPL would impact your ability to use a DAW, but it does. Just two days ago I was at band practice with a band I play in, and we decided that for one song the guitarist, who didn't have a part on it, would play a synth running on my computer, via a MIDI keyboard. That's a computer network by most definitions. That means the guitarist is now a user of the software on my computer. I was using Carla (LGPLed) as a plug-in host, but had I been using this instead, I would've been obligated to inform him of the fact and offer the source code.
In other words, this means I would never consider using this DAW in a live environment with any external interaction at all (no inputs other than my own, that includes no microphones or analog inputs that might pick up third party signals), lest I become legally obligated to start explaining what I'm running and where to get the source to everyone around me.
Now I bet the authors of this software didn't think of such use cases and don't care about them - and this is why the AGPL is evil, because it encroaches on users' rights well beyond you might think at first glance.
I think you are wrong. If you don't modify the software then GPL compliance is not your job. If you modified the software AND you distribute it you need to have the modifications available somewhere so the users of the software can get them.
I mean I seen proprietary and open source software prompting a license popup or message so you are informed that this program offers no warranty etc , when you use a proprietary tool and lend your device to your friend do you also make the argument that your friend did not clicked the proprietary EULA or he did not read the MIT/BSD disclaimers and you first make them read those licenses/EULAs?
Open source software prompting a license popup is actually an anti-pattern, a common mistake. Open source software under a license like the GPL or MIT/BSD should never throw it in a click-through EULA in the installer, because those licenses are copyright licenses, and the disclaimers aren't legal requirements to use the software (you don't need to agree to them to use it, they are just legal boilerplate).
However, the AGPL is an EULA, so in fact it should be included in click-through screens in insallers, unlike every other open source license.
The AGPL doesn't require you to distribute modifications only if you distribute the software (that would be a copyright-based requirement and it's what the GPL does). It requires you to distribute modifications if you offer access to the software. That's a huge difference. And as I wrote in the other comment below, the interpretation of "making medications" is horrendously ambiguous, and can be interpreted in two way: in one way, the AGPL doesn't offer any protections over the GPL (so it's useless), and in the other way, every user of the software is using a "modified version" and thus required to offer it to any downstream users they provide access to the app to.
If you offer me access to the software doesn't this mean that I am a user of the software and I should be entitled to see the source code ?
My understanding is that AGPL solves a real problem, people modifying GPL software and using loopholes to not give the modifications back to the community, is there a better license that fixes same problem and offers the maximum rights to the users (not maximum power to the developers)
Locally running the software doesn't force any obligation upon you. Running a modified version of it that other end users interact with does. Before you engage in modifying the source code it behooves you to read the license to discover what you are allowed to do with it thus it needs to click through license at first run.
You only have to make the source code available if you run a modified version of an AGPL app. And you have to make the source code available to the user of the app, not give a medium with the source code to any user that communicate with the modified software each time they do.
This is a broken argument when you consider how the AGPL interacts transitively.
If this argument is based on users not modifying the code themselves, then you could use this loophole:
* I make changes to an AGPL app and distribute it to you
* You take my version verbatim and run it as a SaaS. You do not have to provide the source, as you yourself didn't modify it.
If this is the case, then the AGPL is meaningless, and equivalent to the GPL.
Alternatively, the "modified version" property persists across distribution. In this case, any time a third party contributes code upstream (without copyright assignment), they would be making upstream itself become a "modified version" in perpetuity. There is no concept of "upstream" in the license itself to provide an out here.
If this is the case, all users of the software are required to disclose that fact to their network users and provide source.
So pick your poison. Either the AGPL is broken and equivalent to the GPL, or it actually requires all users to follow the requirements of that section, regardless of whether they themselves have modified the code.
The real answer here is that the AGPL is a horribly vague license, the SaaS viral provision is extremely poorly written, nobody knows what it'll mean when interpreted by a judge, and you just should never use it. It's a bad license. A bad EULA.
I think the obligation would attach to the user running the service regardless of whether they were the person who made the modification. Looking at the actual text I see
>License explicitly affirms your unlimited permission to run the unmodified Program.
Logically you would be liable for providing a copy of the software running to your users and he or she would be liable to provide source to you. Merely placing more links in the chain wouldn't abrogate someone either you or they from sharing their modifications.
I think you should read more about the licence before criticizing it so harshely. AGPL was created as an answer of this exact loophole that existed in the original GPL.
Not saying that those licences are perfect an there is definitely grey areas, but what you are stating is not true.
Please read my comment more carefully before claiming what I said isn't true.
The "loophole" in the GPL is that you can modify the software, then only provide access to it, not a copy of it, and the users do not need to receive the modified software, because the GPL is a copyright license and has no bearing on what you can and cannot do as long as you don't copy the software itself.
(Whether this is a "loophole" or a desirable property is very much open to individual opinion)
What the AGPL does is say "Aha! If you modify the software and make it remotely available to users, then you must share your changes with them anyway!". And thus the loophole now becomes: modify the software, give it to someone (but nobody else), and then they can provide access to it as a service, without distributing the software itself, because they didn't modify it so the clause doesn't apply to them.
But maybe your interpretation (of the very vague clause 13 of the AGPL) is that the fact that the software was modified "sticks" even after you give it to someone else. In that case, as soon as anyone contributes changes upstream, then upstream becomes a "modified" version and all users of the software are now required to offer source code to anyone they provide access to it to, regardless of whether they themselves have modified it.
So you get to decide: either the AGPL can be trivially bypassed, or it actually requires all users of the software (in normal open source contribution models) to prominently advertise that to anyone they offer remote access to, modified or not. What's your interpretation? What will a judge's be? Neither of the two are what was intended, anyway.
Logically what you actually do is you ask a lawyer to tell you what a judge would probably say in order to spend merely hundreds to low thousands instead of 10s of hundreds of thousands embroiled in lawsuits.
You could also spend nothing and adhere to the strictest letter and spirit of the law instead of trying to get away with something.
Let's be real, nobody is going to SWAT you for not telling your guitarist friend about software licenses. It's really a non-issue; if you want to get particular about such things that is certainly your prerogative. But if that's not your cup of tea, then just don't worry about it.
"It's a non-issue" is not really a good approach to take to software licenses. The point of licenses is that they should be followed, and they should be written so that following them does not unduly burden your users. It doesn't make much sense to pick a license expecting your users to break it in ways you don't care about.
I'm not the one who licensed this software this way, so your complaints are misdirected. I'm just pointing out the practical reality of the situation, that if you were to violate the license in the way you describe, nothing bad would happen to you.
If it's the principle of the matter that concerns you, then fine. But if you're concerned by the possibility of actual consequences, then your concern is misplaced.
If its a non-issue, then the license would not include these clauses.
You could argue the exact same way about the exact thing the AGPL was created against: "Let's be real, nobody is going to SWAT you for not telling your SaaS users about software licenses for things you use on your server..." I mean, who'll know, right?
To me free usage of the software means I can use a piece of software in any fashion I use for any purpose I use it. I cannot understand how the requirement to share your modifications prevents any lawful or reasonable use.
Most end users don't modify their software after all.
The sole and only wrinkle is that a requirement to share your code may in some instances keep you from adding some secret sauce to the software, using it to derive profit, and not sharing it with the party that created 99% of the value by providing you the software in the first place. Which seems to be literally complaining that it works as intended.
If we accept the premise of copyright and licensing software in the first place I'm not sure where you derive the justification for complaining that they are merely interested in giving you some rights to their efforts and not others. After all they could give you none. Regarding existing free software you already can't take GPL software and make it part of your AGPL software. The kind of software that can be incorporated in AGPL software is software that is allowed by license to be incorporated with software that adds additional restrictions like BSD licensed software.
Many would term that "more free" but would somehow manage to differentiate between taking "more free" software and using it to build proprietary software that gives downstream no privileges and taking "more free" software and using it to build software with restrictions that gives some privileges and somehow find the latter wanting.
