Plugins?

Dorico
1

Again HUGE CONGRATS to you Daniel and team and Steinberg:)

Will plugins-comparable to what we know from Sibelius, be used in Dorico, and if so, will they come from users, and/or Steinberg ?

Thanks so much.

Bob Morabito

2

We do have the beginnings of a scripting API already built into Dorico, using the Lua scripting language. At the moment, script plug-ins are limited to the sorts of things you can do in a macro recorder, i.e. triggering commands that are in the user interface. This can be useful for batch processing operations, but as yet it doesn’t really provide much access to the internals of the application or the music you write.

Over time we hope to broaden and deepen the API so that the kinds of extraordinary plug-ins written for Sibelius by legends like Bob Zawalich and for Finale by people like Jari Williamson can be written for Dorico as well, but like many other aspects of our development, it will take a little while for the application’s capabilities to match up with our aspirations!

3

Thanks so much Daniel–very exciting and so many wonderful things to look forward to:)

4

LUA sounds great especially when using the script-feature of Logitech - when calling the correct libraries both can interact in a pretty cool way

5

Bob, It is great to see people from Sibelius forum here. Welcome!

6

Thanks so much Makumbaria–very kind of you:) Its great to be here, and so very excited about Dorico–thank you again! Bob

7

We chose Lua for our plugin language because it’s simple and lightweight, and you can do a lot with it. You can even create lua bindings for C/C++ libraries, so it’s entirely possible that you may be able to use the plugins to link Dorico with other libraries or applications. We’ll be looking at the sort of things that users want to achieve from a plugin interface and designing our API accordingly. The Lightroom API is a big influence on our design, as that has a great variety of community-provided plugins, and has stabilised over several major versions.

8

Thanks so much Paul–do you mean like which plugins users want/need? For example-- invert, Retrograde, Rotate pitches, Apply Series, Draw free Rhythm Barline etc–as found in Sibelius?

Thanks Bob

9

I’m thinking more generically than that - we want to ask the question: which classes of plugin do users want? For example:

    • Batch processing and macro recording plugins (which need access to the command system - some of this is working already)
  • Import/Export plugins (which need access to the low level object models and layout model, and I/O)
  • Proof-reading plugins (ditto)
  • Content generation plugins, eg for creating scales, worksheets (needs object and score creation ability)
  • Score editing plugins, eg for invert, retrograde (needs access to higher level objects)
  • Playback plugins, eg for adding/changing controller messages, note duration/velocity (needs access to playback mode and object model)
  • Style plugins, eg for adjusting score for ‘House style’ (needs access to the score library and object model)
  • Extensibility plugins, eg for plugging in third party Dlls or applications (needs lua’s C/C++ bindings)
  • Remote control, for writing controller apps from tablets
  • …

Each class of plugin needs a different type of API. Rather than have a ‘kitchen sink’ API where the Score object has 400 methods, we’ll design the API to reflect the requirements of each of these cases, in a similar way to how the major modes of the application are focussed on that part of your workflow.

In the fullness of time there is the possibility for us to hook Lua scripts into other parts of the app, eg so that you could have your own custom pre-flight checks that happen before printing, playback, etc.

10

Thanks for the quick and informative reply Paul–for myself, these would head my list:

  • Proof-reading plugins
  • Score editing plugins, eg for invert, retrograde (needs access to higher level objects)
  • Playback plugins, eg for adding/changing controller messages, note duration/velocity (needs access to playback mode and object model)

Thanks Bob

1 Like
11

Dorico programming:
it would be marvellous to be able to write 20% code with Lua and 80% code with Visual Studio
VS allows designing Advanced Forms and so on
thanks to the team
(i buy Dorico the first day of its release)

12

In theory that should be possible, because Lua can call into any C or C++ code, so you should be able to produce a dll with a lua script that calls it. Obviously it would only run on one platform.

13

thanks for your quick answer
we wish you a tremendous success with Dorico !

14

I’m personally most interested in plugins for “adding/changing controller messages, note duration/velocity (needs access to playback mode and object model)”, and possibly for plugins that could provide alternative visualizations of playback (think music theory visualizations of chord structures, etc.).

That being said, my most-used Sib plug-in is the counterpoint checker (parallel 8ve/5th detector).

15

One request I have with respect to the object model for Dorico: it would be very nice to have a dedicated field that could be used by plug-ins to “tag” objects they add, be they dynamics, slurs, accidentals, text, playback notes/CC/program changes. The idea is that, for example, the parallel 5th detector plug-in would tag any text objects it adds so that they could all be trivially located and deleted. Or CCs added by a play-back plug-in could trivially be deleted (by the plugin) before it re-computes and adds new CCs.

This would help solve an annoying issue encounter in Sib where I’ve almost given a score to a conductor with “Parallel 5th” text still in it! Or running a CC-generating script will delete all CC messages, even those it didn’t add and weren’t supposed to be removed.

16

I totally agree with Chris. Invisible properties which are attached to the objects themselves and not to their representation in the plugin would be really useful. In Sibelius you can assign a property to a variable that represents an object, but if it is duplicated or pasted elsewhere, then the link between the variable and the object is broken, hence the property is lost. I’ve sometimes used colour or redraw info to paint such objects but this is a far from satisfactory solution.

17

This should be possible, as every object in the score has a property table, and this should be accessible for plugins to add in custom data, which will then be preserved in the file. I hope that this will open up many opportunities for editorial or analysis type plugins.

18

Paul,

I do live playback (of organ scores) with Sibelius. I most frequently use a custom tweak of the stock Scale Numbers plug-in to modify metronome marks in System Text. In the brave new world of Dorico, I’d expect that to be exposed by the object model.

I’m also very interested in the concept of property tables, with an eye to developing tools for score librarians. In my case, I work with hymns–where I might have as many as four or five hymns in the hymnal with the same tune, but (obv) different length, lyrics, and even different key. (“For a lower setting of this hymn, see #512.”)

I want to be able to review a range of scores (perhaps recursing into child folders) to create a list–then iterate over the list to identify scores with particular custom fields (in my case, tune, date of last performance, season of church year). A marching band director might want something similar–to be able to review band arrangements; a symphony librarian might want to do something similar as well.

19

I envisage that this is the sort of thing you will be able to accomplish. We’ve done the gruntwork to make it possible to modify the score with Lua scripts, but as I’ve noted above, we’ve yet to decide on the exact look of the API. I expect that it will be possible to have raw access to the property tables (and the value of a tempo event is one such property) so that you could both query and change these values. Functions to traverse directory structures can be found in some of the Lua addons (we are thinking of bundling Penlight to give some Standard Library support: Penlight Documentation ). So I think it should be quite possible to achieve what you need.

20

I would like it if I could access Dorico through a network and send it commands…for example…I want to create an Android, IOS or Windows App that “connects” to Dorico. Then I start the process by firstly selecting a bar on my Dorico software and the app shows THAT bar (zoomable). Then I can enter elements (notes, rests, dynamics, lyrics) on my iPad, and the “finished” bar in my mobile device updates Dorico when I leave that bar. Then, from my mobile app, I move to other bars.

Just imagine the usability of using my Samsung Note 4’s stylus and write notes etc on my cell phone screen and it updates in the Dorico software. THAT will contribute saving time entering music elements into a score!

All I need is a scripting language support (like VBScript…or whatever) that can access Dorico’s API’s from outside the software…like a command line functionality.