Scripting

Dorico
1

I’m well aware that this has been discussed quite a bit in previous threads, and that this is a busy time with the release of 4.0 yesterday. I’d just like to write some thoughts about scripting here, with the hope that they’ll be received as intended: constructive dialog. (Some of this is copied from the Facebook group discussion.)

I understand the philosophy behind limiting scripting at present, which Daniel and others have shared here before. I recognize the desire to focus on proper implementation. And in a perfect world, plug-ins wouldn’t be needed. We’d all like to have our specialized features built directly into Dorico and properly implemented, with all the burden of maintaining the code placed on someone else!

But even a mature program like Acrobat has plug-ins. I used one the other day to automatically add the file name as a watermark to the top right corner of some 2,000 PDFs. I searched for this functionality, found it on an obscure forum somewhere, downloaded it, and voila: it took me literally 60 seconds to set up, then I walked away and let it work for the next hour or so. Any guesses as to how long that would have taken me without a plug-in? I can’t even imagine it…

Of course this sort of specialized task would never become part of Acrobat itself. And for good reason: it would make the program incredibly bloated and unusable.

I’m sure we could easily come up with a list of dozens of such tasks that would suit a very small number of users, would be a massive lifesaver to those users, but would be too specialized to ever be considered for inclusion in Dorico.

That’s why I think the continued limitation of scripting is a missed opportunity. There’s a very enthusiastic community of users here, some with a great deal of expertise in coding. Opening up scripting could really turn them loose on all sorts of helpful plug-ins.

I know development is quite active at present. I don’t think anyone would mind working on scripts with the understanding that the next update could break their script, or render it obsolete by the proper addition of some particular functionality. Anyways, I imagine many of the scripts users would create would be niche enough that their proper implementation would be years down the road, if ever.

LEGO faced a decision about 15 (?) years ago. The company was in crisis (so, a bit different of a scenario than here, I think). They had to decide whether to circle the wagons, or to open up to the user community and involve them. They decided on the latter, and the result was the massive growth of an enthusiastic user base… not just kids, but adults too. Of course I know this isn’t an exact comparison to software, but it’s a fascinating story that I think is pertinent.

Think of the excitement this sort of thing could generate in the Dorico community. I don’t see plug-ins as an implication that a software has stalled in its progress, but rather an invitation to broader usage. I would even try learning it.

I’m just giving one user’s perspective, I’m not presuming I know all the factors at play here. But I do hope there can be serious consideration given to opening this up soon.

8 Likes
2

You forumites really do pick the best times to start waxing lyrical, don’t you? Just as a hint for the future: even though it might naturally seem like the best time for you to express your big ideas about the future, right in the white heat of a release where thousands of users are all using new software for the first time at the same time… might not be the best time if you are looking for a considered response from the team?

Designing a scripting API that will be fit for purpose and provides the correct levels of access to the data models and functionality of an application like Dorico is a huge job, and one that has to be given a lot of time and attention in order to be done properly. We are committed to adding scripting to Dorico in the future, but it has to fight for its place among everything else that we are working on, and the reality is that we have enough large-scale projects on the go that this isn’t something we are likely to be working on in a big way this year. Sorry, but that’s just the way it is.

8 Likes
3

Fair enough, Daniel. As you say, I was merely thinking out loud, and certainly not demanding a response.

2 Likes
4

It is. I’ve done this several times in my working life as an engineer, an insidious issue too is that an API like this is something you get stuck with. Dorico being still a relatively young application, with an evolving architecture, means for the health of the system it’s much better to delay a scripting interface as much as possible. Once the mainline features are in, the architecture has settled - that’s a good time to open up scripting for real. And in the meantime we do have a usable system if we wish, with the caveat that there’s no guarantee it’ll be stable (it probably won’t).

So as much as I can imagine all the scripts I’d write, personally I think they should wait until all the big features have been added (Dorico still doesn’t do Roman notation for example).

1 Like
5

Hi Dan,

given your obvious experience I assume that you have a clear understanding already what scripting can and can not do at current; and I realise that your post is purposefully concerned with the bigger picture. But just in case: as I have stated occasionally, there actually is a lot more possible with scripting already than one would think. So, if there are certain things on your mind that you would like to do, but think they are probably not solvable via scripting, feel free to send me a pm. (But again, given your experience, the most probable outcome is that I answer with my agreement about a certain task’s impossibility.)

6

Since writing sometimes doesn’t convey tone, I’m going to take your response as genuine. But that fact is, I really don’t know what I’m doing regarding scripting in the slightest, and I wouldn’t want to convey otherwise. I’ve recorded a macro here and there, but that’s it. No experience in coding other than messing around with fonts. Perhaps that renders my post a bit less useful!

7

One thought is that some enterprising person could apply for access to the new Remote API, and write a ‘front end’ application. Steinberg may/may not approve such a request, but I applied for access to the Nuendo API and received it for a custom plugin we’re going to release (we had to sign disclaimer forms).

Anyhow then this new application could provide say, it’s own python, lua, or visual scripting interface (that would probably be best). Maybe the Dorico team would recoil in horror at this idea.

Anyhow, it’s not trivial either, but could be a business opportunity for somebody (not me don’t ask! Music is my one chance to get away from programming! :grin:)

8

It is certainly genuine. Dorico is so complex that there is not one of us so-called power users here who could claim to have real expertise over even half of its features, I would guess. And that goes for any other sub-topics in our wide field.

If, for example, I were to present you with my occasional font butchery, it would probably constitute culpable negligence if I did so without a trigger warning.

3 Likes
9

This apple-like philosophy of controlling the implementation for every single feature (so that it’s made “the right way”) make for a very sleek and powerful program, but the lack of professional power-user control over it make it so I’m losing faith of ever switching over completely. I still use Dorico for my commercial tight-deadline projects, with simpler music and it probably gives me the most joy over all the other software, but I don’t think I’ll ever abandon the other alternatives as far as flexibility and true niche poweruser uses go.

1 Like
10

Clearly it’s in the plans, as evidence by the existance of the present scripting, the addition of the new Remote API, and Daniels comments above. I think we need to appreciate how small the team is, how busy they are, and how demanding we are! :grin:

4 Likes
11

I realise that! I’m sure the development team is made of great people and they are amazing developers. No doubt about that!

I do however have three points:

  1. This may seem harsh, but i don’t intend it to be: I’m not their friend. nor I’m actively “rooting” for the success of the software. Of course I wish them all the best, and I would love for Dorico to continue flourishing (I love to use the software!) but ultimately I’m a consumer on a market with other alternatives, and I’m weighing in on what I see as the biggest disadvantage Dorico has.

  2. Yes, they disclosed plans to eventually have a more robust scripting system, but they have so for a couple of years already. This isn’t a specific issue, nor a feature vs. time question, it’s a philosophy one. Countless times on the facebook group or in this forum the team has said that “the feature will come eventually, but we want to implement it ‘right’”. That’s all well and good, but for people who use this type of software everyday with deadlines and projects we have no alternative than to keep relying on the other software since there is not much space of infrastructure for community driven plugins or contributions.

  3. Dorico is a young software, as has been said countless times whenever anyone raises an issue. But it’s not that young anymore, and it promises to blow the competitors out of the water (and credit where credit is due, it has so on TONS of implementations that are amazing and fresh and that I have huge gratitude for the team), but for contemporary classical music and big projects I still find it lacking on flexibility. The music is just too diverse to “correctly implement” everything, and creating ways to workaround it is essential.

I understand that Dorico values consistency and implementation over flexibility, and it clearly has its payoffs. It has a much better implementation than either Sibelius or Finale in a great number of uses, and it’s clear a lot of thought goes into each aspect of it. But it’s no coincidence that most heavylifter software in most fields looks unpolished and ugly, etc. For maximum power and flexibility for heavy users you have to sacrifice a bit of sleekness and polish, and I’m saying that maybe Dorico’s power and usefulness lies elsewhere.

2 Likes
12

I think the major changes implemented in Dorico 4 (rewriting the Play mode, for example) show how much the program can change as the Development Team follows their road map, responds to user observations, and sees new possibilities in the program model.

While scripting (planned down the road) can be a great asset, were it to inhibit the Team from making major changes they deem important, as @DanMcL has suggested, we would all be the poorer for it. I trust the Development Team to know when the time is right to make the API public.

4 Likes
14

100% my sentiments, word for word!

15

I can hardly wait. My other geek joy is Reaper with action scripts, cycle actions, scripting in EEL2, Lua, Python, and JSFX or full-blown extensions in c/c++. (Even scripts with GUIs). Good job I’m retired and music is a hobby as I spend more time creating miraculous workflow than production.

2 Likes
16

I fully understand Dan’s viewpoint here, especially for software that will be used by many people with vastly different levels of coding skill and a few zillion variables that could be controlled. It would be great to have a well thought out interface and set of tutorials (etc…) for scripting Dorico, however long it take to get there.

I want to post a humble reminder though that sometimes “the perfect is the enemy of the good” or put another way, anyhing truly worth doing is worth doing badly, at least at first.

Users are already trying to figure out and use Lua scripting. So anything that can be done that’s not too labor-intensive on the part of the development team that could be helpful to all the users already jumping the gun on scripting Dorico would be appreciated. For example releasing documentation with the caveat that it is subject to change would be helpful.

Another thing that would be really helpful, for example, would be the ability to simply load scripts with different file names instead of only the default name. Then we can use any external editor. (Or maybe that’s been done. I shamefully haven’t upgraded in awhile. ) External editors already have all the file handling (etc.) functionality in them already.

In other words, maybe there can be some interim levels of release for Dorico Lua scripting.

I am sure that Dorico users who are also coders will happily help out in whatever ways we can.

But I do understand that users wanting to do scripting is still a relatively small subset of the user community and that the needs of the larger project have to take precedence.

1 Like
17

ahhh yes. So they can all complain about how the functionality is currently too limiting to be truly useful, and then cry ‘foul’ once they get themselves in really deep and things change. I look forward to those theads. :zipper_mouth_face:

4 Likes
18

When I rename a script file it immediately shows as I named it in the Script menu, even while Dorico is running.

1 Like
19

You can save or rename any scripts into the Scripts folder, and they will show up in the Scripts menu. I have a bunch of scripts that I’ve saved there. It’s been like that since v2 at least.

(Ninja’d by Mark!)

20

I just upgraded to the current rev, and so they do, scrips I save or modify from BBEdit show right up on the menu. But after opening the console window I got a most curious result, multiple transport panels and an alert for an unspecified error.

Probably just something wrong with the script I tried running.

Thank you for the nudge to get current. Been meaning to.

Dorico_script_error?
Dorico_script_error?1071×572 145 KB

21

When you do incorporate scripting, Please, please, please just use the core standard javascript as Adobe does with After Effects. No need to learn a whole new syntax. Sibelius Manuscript is useful but a useful mess. Don’t do anything like that again with Dorico. Please.