There seems to be way more 3rd party plugins. Reaper has quite an extensive API while Ardour is open source. There was quite a long discussion about this on the Ardour forum. It seems that the Reaper API and general extensibility gained more traction than Ardour being open source, as counter intuitive as that seems. Having used both pieces of software a reasonable amount, Reaper has a slight edge in terms of usability and customisation of the layout and look and feel. In particular the midi editing is smoother. That said, Ardour is a fantastic piece of software and a great open source success.
Ardour can run VST plugins, so I don't think it's limited in this way at all, as VST is the most common plugin format in the world and there are literally thousands of VST plugins that one can use.
Ardour can also run LV2 plugins, which is another plugin format. It's not as popular as the VST format but gives Ardour users even more options.
So, yeah, I wouldn't say that plugin availability is a limiting factor for Ardour, any more than it is for any other DAW.
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'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
Are you looking for a proof of Girsanov's theorem or an explanation of how it is used to price? A good reference is Oksendal [0], but it's still quite tough going. As for how it's used, a good reference is Shreve's second volume [1], which also contains a proof of Girsanov's theorem. Joshi's book [2] is a little bit lighter on the mathematical rigour.
A quick explanation of how it's used:
Taking the stochastic differential equation for geometric Brownian motion, apply Girsanov's theorem to change measure via a drift change such that we now have a discounted stock price that is a martingale. The discounted stock price is the stock price divided by a short term bond or cash account asset. In this new measure the discounted short term bond/cash account asset is also trivially a martingale since it's being divided by itself. So we have that our two key assets (discounted) are martingales. We then define the time zero price of the option (divided by the time zero price of the bond/cash asset) to be the discounted expected value of its value at maturity in this newly constructed measure. By construction this discounted option price is a martingale and we now have three assets that are all martingales which implies there is no arbitrage possible. With this option price, called the "risk neutral" price, no arbitrage is possible under our newly constructed measure, but, because the original measure is an equivalent measure no arbitrage is possible here in the "real world" either and so this is our actual price.
I appreciate there are a few steps here that seem like a bit of a leap. It took me a while to appreciate them. The key things to appreciate are:
How everything being a martingale implies a lack of arbitrage. Girsanov allows you to make your (discounted) underlying a martingale.
How you can then just make the option price a martingale by construction. And then how lack of arbitrage under one measure means lack of arbitrage in any equivalent measure.
The discounting can also be a little confusing, but it's really just incorporating the time value of money into the calculations.
[0] Oksendal B . Stochastic Differential Equations.
[1] Shreve S E. Stochastic Calculus for Finance II.
[2] Joshi M S. The Concepts and Practice of Mathematical Finance
From my (a very layman) understanding, the price of the security is stochastic can be assumed only during a very short period, which does not include major moves. If this is correct, does it mean all these models are useful only for market makers earning money from the spread, or they can be useful for retail traders?
There are other models that take into account jumps in the prices/market. As for retail traders using these models, I think it is not recommended and not practical.
