Scripting example

I notice there is a script menu and some example Lua scripts in the app bundle. It would be great if one of the beta testers who is familiar with plugin scripts (you know who I’m talking to here) could write up a blog post on how to create and use a plugin script. Get approval from Steingberg of course since I’m sure there is a non-disclosure issue on beta testing.

The scripting support is incredibly rudimentary at the moment. We’ve got the Lua engine embedded in Dorico, but there’s still a lot to do on getting the right form of the Api. There is a thread somewhere else on the forum where I talk about our plans in a bit more detail. At the moment though we do use the scripting engine to implement the Macro function in the script menu, but not all functions can be supported because many of them require extra parameters.

In short, scripting is something that we will come back to and we’ll solicit feedback from the community on the kind of things they need in an API

That’s great to know! I’ll try to find the thread you mention. I’d love to hear what the plans for Macro actions are.

If Dorico has an extensive and complex object model it should be easy to implement scripting and using all object properties in scripting.

See my posts on this thread from earlier in the year:

Peter - on the contrary. We certainly don’t want to expose Dorico’s internal APIs because they are incredibly complex and likely to change at any time (which would mean all plugins would need to be rewritten). The challenge for us is to design a scripting API that best matches the requirements of Plugin writers whilst being decoupled from our internal models. That said, Lua offers us some very exciting opportunities for putting hooks into various parts of the application.
Please note however that we don’t have any timescale for this yet,or whether it will be part of Dorico 1.x

The other side of this coin is that most of the plugins in two other notation programs shouldn’t be plugins anyway IMO - they are just a clunky way of putting sticking plaster over the core program’s lack of functionality.

Of course there are some good reasons to write plugins (like the examples shown in PaulWalmsley’s thread) but doing the core software developers’ job for them isn’t a good reason!

If you take that position to its logical conclusion, you could argue that the only data that should be exposed to the plugin is exactly the same data that is exposed via the “human-accessible” user interface, apart from the essential extra features for communication between the application and the plugin, etc.