Suggestions/requests for the plugin API

• Feb 10, 2010 - 17:20

Hi,

Some additions to the plugin API I believe useful:

1) MuseScore version: as the plugin API is going to evolve, it is important a plugin knows which version of MuseScore it is running in.

This may take at least three forms (in desired order):
* 1 global variable returning the major, minor and update version in a combined form; for instance the global variable musescoreVersion could return 905 for version 0.9.5, 906 for version 0.9.6 and, in the future, 10213 for version 1.2.13;
* 3 separate global variables, returning the major version, the minor version and the update version: for instance musescoreMajor could return 0, musescoreMinor 9 and musescoreUpdate 6;
* 1 global variable returning the revision (then 2012 for the stable 0.9.5 version); this would be the most precise, but less understandable than the previous.

I think a string return value, like "0.9.6" would be the least useful, as numbers in strings are difficult to compare.

2) invisible status: an item may be irrelevant (or maybe not) if it is invisible (for instance an invisible rest in multi-voice staves); it is better to report the visibility status and let the plugin to decide.

3) The Note object could take advantage of several additions:

* the datum contained in the <tpc> tag of the .mscx format, for easy enharmonic recognition;
* the datum contained in the <userAccidental> tag of the .mscx format, for quarter-tone info;
* the tied status, possibly differentiating between tie beginning, tie continuation, tie end, so a plugin can distinguish between notes inherently separate or only graphically divided;
* the slur status (similar to tie status);
* the invisible status, as per point 2)
* 'small' notes (appoggiaturas and acciaccaturas) are currently hidden to plugins: they should be reported and qualified as such.

4) Selection info: I know this is under discussion, but I though it useful to repeat it here.

5) curCursor: I have never been able to use the value returned by this global variable; either it is my fault or an issue with the program...

I would like to help with these issues, but all my attempts to replicate a development setup of MuseScore have miserably failed so far (probably I'm too spoiled by VisualStudio...), so I can only beg at the moment.

Thanks,
M.

Comments

• Feb 12, 2010 - 22:02

I'm amazed! I thought interest for plugins was, hmmm..., marginal?, but all my suggestions are already implemented! This is fast! I cannot wait to try them!

Thanks,

M.

Reply

• Feb 12, 2010 - 12:55

Regarding point 1 and versions, giving access to the core version in the plugin looks like a suboptimal solution. Each plugin will need to have is own version handling and decide what to do. It could be better to have a file per plugin describing the plugin. For example:

name= Abc importer
description=An abc importer for MuseScore relying on a webservice
url=http://musescore.org/project/abc
version=0.2
coreVersion=0.9.5
author=Lasconic
authorEmail= ...
menu=Plugin.Abc Importer
init=init
run=run

See amarok plugin interface and script.spec file

We could then define a plugin as a .js file and a .spec file. On startup, there will be no need to parse all JS file but only the spec one to get the Menu item, the run and init hook, and then parse the script when necessary, depending on the hooks. The coreVersion property should be checked to decide upon plugin activation.

Having more metadata we could add a kind of "Plugin Manager" to list the installed plugins, their version, authors etc ...

Reply

• Feb 12, 2010 - 22:16

Definitely a good idea. Particularly the Plugin Manager idea and the possibility to skip most of plugin parsing (I think plugin parsing takes a good part of MuseScore startup time) look promising.

Still, I believe this does not supersedes the usefulness of a version variable: a plugin may support more features if a greater version is detected, but still do something useful if not.

I do not know how fast the core developers plan to release new versions and how fast users usually align to the latest version (and among stable release(s), pre-release(s) and nightly build(s), it is not always clear which the "latest" release is...), but allowing a plugin for some 'latitude' in supporting several versions may be worth. Anyway, I noticed that several global variables dealing with version are already implemented in the latest SVN.

The coreVersion in the plugin spec would then mean the minimal required version under which the plugin cannot run at all (and can be ignored by the plugin framework).

M.

Reply

• Feb 13, 2010 - 07:57

The fact that extensions in Firefox have to be updated for every release of Firefox is actually a serious problem. It discourages users from upgrading (because they want to continue using their extensions) and frustrates developers (because they have to update, test, etc for every release, prerelease, etc.) In fact Firefox is looking for ways to move away from this model as much as possible with experiments such as Jetpack.

I haven't got into plugins yet but I assume the principles of object detection that are recommend for web development would also work with MuseScore plugins. See Javascript - Object detection .

Any thoughts?

Reply

• Feb 13, 2010 - 12:47

Oh well, so I've been using a technology called "object detection" without knowing it...! Without much a formal framework, this is what I've done in the few plugins I tried to write so far.

It is useful, but 1) it is lacks some answers and 2) provides answers to questions we do not have. Examples:

1) Checking if the Note.name property is implemented tells little about 'how well' it is: this property so far returns a string which ignores enharmony; assuming one day it will returns a more precise name, version will still needed to know how much the name is reliable.

2) We only have one MuseScore! All the web development problems arising from the variety of browsers (each with non-overlapping support) do not apply to our case, luckily! We still have the unknown of future releases, but this may be greatly reduced by never dropping existing scripting features (backward compatibility), or dropping them only at some major turning point(s) of the programme life time (which may be annoying but affordable if rare enough).

So, object detection is a useful 'trick of the trade' but a flexible scripting support may probably need all the elements discussed: global variables with info about the core programme, metadata about the scripts, a built-in plugin manager clever enough (but not too clever either!).

Ciao,

M.

Reply

Do you still have an unanswered question? Please log in first to post your question.