plug ins and extension language
Can someone comment on (explain) the current system for writing plugins in Musescore 2.x? I.e.,
- What is the use mode for using an existing plugin?
- How does a person write a new plugin?
- How does a person figure out the API?
- What kinds of things are possible and impossible?
- Which kinds of things are impossible simply because no one has written the binding, vs which things are really impossible given the current musescore framework?
- What kind of users are using it? and how many?
- Are there lots of enhancement requests to improve it?
- How are plugins distributed, downloaded, etc?
Comments
These notes refer specifically to 2.0.x.
*) What you mean by "use mode"? To run an existing, but non-installed, plug-in, load it into the "Plugins | Plugin Creator" and run it; if the plug-in has been installed as described in the handbook , it appears in the "Plugins" menu.
*) To write a new plug-in, the simple way is to start by some of the exiting plug-ins and modify it as needed, with any kind of text editor. Of course, they can also be written from scratch.
*) Plug-in API has its own manual; for self-built 2.0.x installations, the manual is in the <build-folder>/share/manual/plugins folder. For released 2.0.x installation, I have no idea, probably it is in different locations, depending on the OS.
To all the following question, I have no idea. For 1.x there has been quite a number of plug-ins and a page where developers could post and maintain their own plug-ins, but I cannot find it any more: possibly, it has been considered obsolete and unlinked.
The plug-in forum is also a source of information on this topic.
In reply to These notes refer by Miwarre
By use-model I mean for example. Can I write a bunch of plugins to do common tasks, and put them somewhere and expect them to be loaded and installed into the menus automatically every time I restart musescore?
Once a plugin has been loaded, does it provide a programmatic API which I can call from other plugins?
I downloaded one plugin (in response to your post) to see a .js file downloaded even though the link was a .zip file. I was under the impression that the musescore 1.3 javascript plugin mechanism is obsoleted, and now there is a new scripting language? Is this true? Do the js plugins still load and presumably work? Or are they really obsolete?
In reply to By use-model I mean for by jim.newton.562
First read https://musescore.org/en/handbook/plugins-0
MuseScore 2.0 doesn't use Javascript files anymore. It uses QML file. So if you got js file, it's not a MuseScore 2.0 plugin and it will not load, it is obsolete.
If you wonder why it changes from QML to JS http://dev-list.musescore.org/New-QML-based-plugin-system-td7577435.html
Once a plugin has been loaded, does it provide a programmatic API which I can call from other plugins?
I don't think so. My understanding is that they are independent.
Can I write a bunch of plugins to do common tasks, and put them somewhere and expect them to be loaded and installed into the menus automatically every time I restart musescore?
Yes, sort of. Once a plugin is installed and activated in the plugin manager, it will show up in the menu everytime you start MuseScore.
How does a person write a new plugin?
Open Plugins > Plugin creator. Write the plugin, read the doc (press the ? in the toolbar).
How does a person figure out the API?
Reading other plugins and the documentation (press the ? in the toolbar in plugin Manager)
What kinds of things are possible and impossible?
If you read the doc, you will be a better idea of what is possible.
What is known to work well, save/load score in different format. Get note properties (pitch, accidental, color etc...). Change color of elements, add text to chord.
A nice thing that is possible is to call a webservice. I used it for the ABC import plugin and I would anyone who wants to write a format converter or a tool taking MusicXML in and spitting out MusicXML to make a webservice and a plugin instead of trying to write a complete plugin for it.
What is not possible, or doesn't work well. Creating note, new staves, "complex" rythms (tuplets, dots).
Which kinds of things are impossible simply because no one has written the binding, vs which things are really impossible given the current MuseScore framework?
If a complete binding was provided, the plugin framework could do exactly what MuseScore core can do. I believe it's not the goal of the plugin framework. To me, it should give a simple API and not necessarily be complete.
A plugin cannot be run "dynamically", or for every change, or when playing back the score etc... It can only be triggered by a user from the menu. It does something and then it exits. (it can also be triggered from the command line).
There is know issue with the "ownership" of objects created by the plugin framework. Who should delete these elements etc... Also, we would ideally don't want to think too much about the plugin framework when working in the core. We got several problems (some unsolved) with that. In particular, exposing enums has been a major headache.
What kind of users are using it? and how many?
It depends for every plugin I guess. A plugin for harmonica tablature doesn't have the same user base than a plugin for tuning notes according to non standard accidentals.
As plugins are giving a specific feature that are not implemented in MuseScore, once a user used a plugin, he is on it greatly. That's often true for "instrument" related plugins.
Are there lots of enhancement requests to improve it?
I guess you mean the framework. I wouldn't say a lot but there are a dozen of pending pull requests that I didn't merge yet for several reasons. 1/ I don't consider plugin framework a priority. 2/ Often the change to the plugin framework needs to be tested so we don't break compatibility with existing plugins, and no tests are written.
How are plugins distributed, downloaded, etc?
In 1.3 there were downloaded as zip file and we instructed user to install them. The installation was done in a system location (C:/ProgramFiles/MuseScore on windows). Pretty bad... but it worked.
For 2.0, the master plan was big. But we didn't do much on this topic.
1/ Provide a way to install plugins in the user space (done)
2/ Provide a standard packaging format with an extension (for example, *.mplugin). (Not done)
3/ Ability to double click *.mplugin to install (not done)
4/ Provide a centralized plugin repository with an API (not done, plugins for 2.0 are currently in the same repo than 1.3 ones and need to be installed manually)
5/ Provide access to the repository, possible in Help > Resource Manager (not done)