Plugins?

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.

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

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)

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.

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

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).

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.

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.

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.

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.

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: http://stevedonovan.github.io/Penlight/api/libraries/pl.dir.html ). So I think it should be quite possible to achieve what you need.

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.

The scripting will be in Lua and so you should be able to use any networking library that can work with lua (eg see http://w3.impa.br/~diego/software/luasocket/). I expect that you will be able to send commands to Dorico via the scripting interface. However, if you want to build a full-featured remote control mobile app then this would need a far more detailed API than just the ability to send commands. This is a very interesting request though, so I’ll add ‘Remote Control API’ to the list of plugin feature areas we’ll look at (see the top of this thread).

Paul, Hans and all,

A couple of years ago, based on an implementation by LA orchestrator Tim Davies using the TouchOSC iPad app, a colleague and I built an expanded control surface for Finale using the LEMUR app on iPad:

The LEMUR control surface can communicate via either MIDI or the OSC (OpenSoundControl) protocol.
http://opensoundcontrol.org/introduction-osc

Neither Finale or Sibelius support direct handling of menu selection or other application control in this way, so the control surface works through the third party macro program Keyboard Maestro to run sequences of events “live” in Finale (formerly via Quickeys).

In the DAW world, some applications which support software control surfaces have implemented OSC for direct access while others are using their own proprietary i/o technology. (e.g. software based control surfaces vs hardware remotes).

A brief internet search for “OSC+LUA” turns up what appears to be a number of OpenSoundControl bindings for Lua. I’m not sure how useful the existing open source bindings would be, but the OpenSoundControl protocol seems to offer high resolution and a rich parameter space for anyone who might be interested in digging more into this.

Thanks Robert, that’s very interesting. If there’s an OSC-Lua binding then that may be the sort of thing that will be very simple to accomplish in Dorico. Dorico has a simple URL-like mechanism for all its internal commands, so that they can be represented as a string and provide a means to pass parameters - eg “Window.SwitchMode?WindowMode=kPlayMode”

The fun starts when we think of how we can send useful status info back to the controller. I will certainly give the remote control part of the API some thought when we come to investigate this.

This also interests me greatly. Here’s a video discussing the application of Lemur control in Cubase using Project Logical Editor macros. This is a good example of what can be accomplished with good bidirectional communication between the controller and the app. In this case everything is Midi based, but Osc would obviously also work well.

https://www.youtube.com/watch?v=hvvx7KWTakM

I’m a latecomer to this discussion, but if anyone is keeping a tally, I would REALLY NEED 3 plug-ins from Sibelius. In this order, Rhythm Section Assistant, Make Pitches Constant, and then Number Bars. Not so much to ask, right?

I’m really looking forward to what Dorico can become and hope to move my publishing company to it one day.

Also coming late; may I request Inversions and Retrogrades, please; and Check for Multiple Stops etc?

Thanks; good luck!

I need a system that lets me create my own plugins with a sophisticated API. A one-note macro recorder isn’t enough. Something on the order of ManuScript (versus something I have to compile and would have platform compatibility issues) should be available and documented. Proofreading and Chord recognition would be high on my list of things “in-the-box” I’d like to see with Dorico.

The trick is surely to have a system that can be made to work both for those with the time and expertise to build their own; and the professionals (like Bob Zawalich) who can respond to others’ needs as well.