I wonder, what are Dorico’s designers’ and developers’ stances on support for third party plug-ins? I’ve always wanted to write C++ or .NET add-ons to notation packages, to really get in there are trick out some of the features of the application. Sibelius offers something like this with its proprietary scripting language, and Finale has FinaleScript, but neither offers an actual API supporting a major programming language.
This has always seemed like an oversight, to me. Comprehensive applications like professional notation software really tend to have their doors blown off (in a good way) when their functionality is opened up for expansion by us outside developers. I can’t imagine that this is a feature that hasn’t been considered by developers of notation software, so why hasn’t anyone introduced a C++, .NET, or even Python API into any notation package after all these years of Finale, Sibelius, Dorico, and all of the other lesser music composition applications?
Is it insufficient demand? Is it insufficient time/resources? Is designing architecture that supports a C++/.NET/Python/whatever API too problematic? Is it wanting to maintain control over the evolution of the software? What?
There already is one. The good news is that it’s based on lua, not some proprietary language. The bad news is that it doesn’t do much as yet, there is no guarantee the API will stay the same as it currently is, and there is no documentation. Given the number of other things that are “not implemented yet,” it may take a while to change that situation!
The short answer is: ‘time’. (or the lack thereof)
We had originally hoped to have full-featured scripting within the first release of Dorico, but it became clear that there were a huge number of other demands on the team’s time (some people just insist on having chords, drums, etc…). We did put a bit of the infrastructure in place, which you can still see in the Script menu, though the functionality is currently limited to macros. However, Dorico’s command system is still accessible through it, and some people have done some quite amazing things with the limited API. Search the forum for ‘Lua’ or ‘Scripts’ and you might find some of them. We know how valuable they are to users, and how they help to smooth over some of the gaps of missing functionality.
We do really want to revisit scripting in a future version, but one of the big things we need to do is work out how the API will look, and that is far from trivial. Another annoyance is that the Lua binding library we initially chose seems to have ceased development, so we’ll need to port to a new one. As Rob mentioned, the final API will probably look very different to how it is today, though I imagine that converting existing scripts to work in the new way will be simple. The great thing about Lua is that you can link against all kinds of 3rd party libraries, so you can work in C++ or .Net if you wish.
For some more context, here’s an old thread that shows some of our thinking: