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
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
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!
Thanks so much Danielâvery exciting and so many wonderful things to look forward to:)
LUA sounds great especially when using the script-feature of Logitech - when calling the correct libraries both can interact in a pretty cool way
Bob, It is great to see people from Sibelius forum here. Welcome!
Thanks so much Makumbariaâvery kind of you:) Its great to be here, and so very excited about Doricoâthank you again! Bob
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.
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
Iâm thinking more generically than that - we want to ask the question: which classes of plugin do users want? For example:
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:
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: Penlight Documentation ). 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.