Score transcription/copy is a big part of what I do for work, particularly in the context of musical theatre and songs for TV; and I’ve done big projects in all the major score-writers including Dorico, but Sibelius is currently my main. I believe in Dorico for the future of score-writing, but there’s one major problem that keeps me from using it on a more regular basis: as I often need to handle a lot of material in a short time frame, having custom scripts to handle some of my engraving has proven essential to give me space to focus on the content of the scores. I have a number of recurring issues with Dorico engraving, but none that I couldn’t fix on my own end if Dorico added robust Lua support. I have a large number of Dorico automation macros but they only cover a tiny fraction of the ground for my Sibelius scripts. I understand this is a very large feature, but my understanding is it’s been in the works for a long time and it’s really the one thing that’s keeping me from recommending Dorico for other users such as myself or using it on projects outside where it’s specifically requested. Is there any update on timeframe for rolling that out?
From what I understand this is not a goal of Dorico. Many, if not most, do not need scripting. Perhaps its simply the wrong tool for your use case. Sorry. It can’t be all things to all people. @dspreadbury will comment.
Actually, I believe it is in their plans, as it was reported about a year ago that they had hired Robert Piéchaud, the designer of Finale’s scripting language. I could be misremembering, however.
Where was that reported?
Maybe this?
Daniel has said many times that improving the scripting capabilities is on the roadmap.
However, he has also cautioned against the ‘vicious cycle’ in which deficiencies in the app are fixed with third-party plug-ins, which then negates the need to improve the app.
That was obviously an issue with Finale. But for me (and I imagine for others as well) the need for scripting is less about improving the app in a general sense, and more about automating my own conventions, which are contextual and require logical tests
There are certainly still gaps in Dorico’s feature set, but could you give us some examples of these issues? (Also, given the differences between the two apps, I wouldn’t expect that you would necessarily need the same set of scripts as Sibelius.)
So yes, there are some case-specific things-- such as I have my conventions for courtesy accidentals and bar numbers automated in Sibelius, and those things can be handled automatically enough by Dorico that I can do the case exceptions by hand. There are likewise case-specific things I’d add to my copy of Dorico if I could. The biggest one would be any and all page overrides in engraving mode (particularly headers and intentionally blank pages), as the number of pages in a musical theatre score changes all the time during development and this can completely throw Dorico engraving for a loop. Also I’d definitely add an automated script for flow first-page sub-headers of instruments used in a given flow (for MT orch books this is standard) and characters in a song with name abbreviations if present. Then there’s general workflow stuff. I have some transposition stuff automated in Sibelius, which Dorico is a bit better about but I’d still probably automate if I could, things like the lead-in bars to key changes within transpositions. And then really it gets to a lot of stuff having to do with MT-style Piano/Vocal and Vocal Books, and their equivalents in TV. It’s standard to have a wide variation in part distribution from system to system and even in the same system; and there are a wide variety of repetitive tasks relating to this. Sibelius has a convenient “split bar” button, and while it’s totally possible to accomplish the same thing in Dorico, digging into the settings and turning on and off the mid-measure system breaks safeguard gets quite tedious, especially if you’re engraving multiple layouts (PV & VB) with the same required mid-bar system breaks. And even many of the subtleties of character labeling can be automated.
But to be frank, I wouldn’t really know until I got the feature. I’ve had to make more compromises with my engraving in Dorico than in Sibelius because I don’t have the ability to automate things. If I gained that ability, I’d probably make my engraving conventions better and more specific, but in ways that required the automation. And it’d influence my whole workflow. I haven’t been able to make use of Dorico’s automatic reduction features, because I’m looking for more specific details than it can provide; and so I net lose time with the extra steps it requires to make things work… but with scripting I could plausibly build a workflow around Dorico’s built-in features such as that one and handle the processing with a key command.
I don’t have some crazy amount of time to develop these things but I’ve been adding little things to Sibelius for years with a day here and there every few months; I’d love to be doing the same with Dorico. And of course what I did with scripting would depend on what features and capabilities were offered.
Would a token for the list of instruments in a flow fix this?
I’m thinking out loud, but if a token were available if would have to accommodate instruments that are played live and those that are present only for playback purposes and feature in a Keys part.
Benwiggy beat me to it… 
Only for the orchestral instruments, and only for that one problem, but yes that would certainly be nice!
I understand the argument, but very few use native TeX today. There is great value in the large number of skilled people who have developed LaTeX into what it is today. A team of 10(?) people at Dorico (and 1 person for TeX, D. Knuth) can never compete in terms of general skills or time with 1000s of people. Leland Smith refused all the help offered, and we know the outcome. With a Script API, more “odd areas” can be covered. It does not mean that core development will be made redundant.
It seems like the arguments against expanded scripting capability is more about preventing open source development of Dorico (which I find unlikely at this juncture) and less about individual users creating scripts and complex macros that actually assist them in their approach to using Dorico. I think the latter is an important way to extend the reach of Dorico to the “masses” while retaining the core philosophy and structure of the application.
For my part, there are quite a few actions I have to perform all the time that are far too niche or quirky to ever warrant development time. A custom script to accomplish them would potentially save me hundreds of hours.
I agree with Andro: scripting should not be a priority for Dorico. It is notation software first, and scripting is a relatively niche feature.
In my opinion, the team should focus on the issues that affect the majority of non-technical users—just look at how many such topics appear on this forum every day. More technical users can usually find a suitable workaround anyway.
Implementing scripting would almost be like creating and maintaining an additional product, with its own support and compatibility requirements. I would rather not see the Dorico team split its efforts instead of concentrating on making the proper notation software.
Just my two cents.
I hear you, but it hasn’t been a priority. Dorico is the last of the major score-writers to not have scripting. Finale had it probably to a fault, Sibelius has it, MuseScore has it. Even if only 5% of Dorico users would use the feature, I wager this feature could save Dorico users a net of more time than just about any other addition. If the team wants Dorico wants to be industry standard (which I’d be perfectly happy to see happen given the direction Sibelius has been heading of late) it has to embrace the technical needs of people working quickly and with lots of material.
Yes, I understand your point, and I work with scripts and I would benefit from advanced scripting as well. But wouldn’t it be fairer to request that functionality from the Dorico team so that everyone could benefit from such a time-saving feature, rather than having only advanced users gain those benefits through scripting?
And why does that (necessarily) require scripting?
I’m curious what tasks scripting really would speed up in your Dorico workflow.