A new file format to install extensions in MuseScore ?

• Jun 4, 2018 - 10:55

MuseScore can currently be extended in many ways:

  • Soundfont SF2 and SF3
  • SFZ (a whole set of files already)
  • Templates
  • Instrument list
  • Workspaces
  • Palettes
  • Plugins
  • Style files (*.mss)
  • Drumset files (*.drm)
  • (Images for background and foreground)

For each category, the user needs to know where to install the files, how to configure MuseScore to use them and needs to upgrade each of them separately. Some of these resources would be better suited if delivered together. For example, a harp package could contain a plugin and a palette for harp pedaling, a sfz for better sound, a template for solo harp ready made for the sfz.

If we imagine that we group all these resources in a single zip file, for example, using the msext (or muxt or whatever) extension, MuseScore could be associated with this extension, open such a file and do the required steps to install and configure the resources.

These files could be hosted and versioned on a file server and integrated into the resource manager in order to deliver upgrades. We could then choose to support opening “msext” files with MuseScore or limit it to the resource manager.

Such an extension would contain several types of resources. We have two ways to deal with this new file :

  1. unzip the extension, store all resources in one place and teach MuseScore to go and look in these extensions

or

  1. Unzip the extension and teach MuseScore to copy each type of resources in the right existing directory (soundfont, templates etc…)

After talking in through with Anatoly, Jojo and jeetee, it seems the first one is the prefered way.

We can add a new directory that the user can change in “Preferences > General” to store extensions. When opening a msext file, MuseScore should copy the files to the user extension directory as defined in preferences. Before doing so, MuseScore should check if there is enough room left on device and warn the user otherwise. Each extension is stored in its own subdirectory in the extension directory and it becomes easy to uninstall them.

Description of msext

metadata.json

The file is required

It contains :

  • The name of the extension
  • The description of the extension
  • The version of the extension
  • A number of tags separated by a comma
  • A unique id to deal with uninstall

soundfonts directory

This directory can contain sf2 or sf3 files. MuseScore should look for soundfonts in this directory. When installing the extension, MuseScore should ask  the user if he wants to add the soundfont to the synthesizer (as default ? for the current score? What to do with the existing soundfonts already loaded ?)

sfzs directory

This directory can only contain subdirectories ! These directories can contain one or more sfz files and associated audio files, potentially in a subdirectory. MuseScore should look for sfz in this directory. When installing the extension, MuseScore should also ask  the user if he wants to add the soundfont to the synthesizer (as default ? for the current score ? What to do with the existing soundfonts already loaded ?)

templates directory

This directory can contain templates or directories containing templates. The subdirectories will be used as categories and templates will be listed alphabetically just like the embedded templates.

instruments directory

MuseScore 2.2 allows only two instrument lists….
For percussion, we see that we might need more. For other instruments, maybe even more because of MidiAction but that’s it for now.
We could add the ability to look for instruments.xml files (or we might need another extension?) in the extension directory. If we do that we need to be careful with global articulations, they can currently override the existing articulations. Same for groups and instruments, the second instruments.xml currently override existing instrument and group with the same id. Do we want that for instruments.xml  provided by extension ?

workspaces directory

Should be ok. Just ask “are you sure”, and load the workspace, potentially select it by default

plugins directory

I would postpone this one. Not needed for percussion and plugins could become a security hazard if plugins are easier to install… If we limit the installation of plugin via extension in the resource manager then we could eventually do some quality checks...


Comments

Just a note to say I like this idea. Could Style files be added to this list? Ultimately it would be good to include plugins too, but I get reaosns to not do so at first.

Another thing that would be good to include would be shortcut lists (for whatever release that feature might be good for).

In reply to by Marc Sabatella

I added styles and drumset definition. The main difference with the other files (in particular instruments.xml, templates and soundfont), and probably why I didn't include them, is that styles and drumsets are currently not "loaded" by MuseScore and presented in the UI. The user has to load styles and drumsets manually and so it wouldn't make any sense right now to install more of these files, since the user would not be able to discover them.

In reply to by lasconic

True. I guess I was less thinking of loading these automatically, more just the delivery of them. Still, a style file can be specified as default in Edit / Preferences / Score, I suppose that could be considered in this context.

Regarding workspaces, somehow this seems to touch on GSoC work by Joshua Bonn (current focus is on expanding the workspace concept). So I've directed him here to ponder this.

In reply to by Daniel

I like that too, although a complication is that we actually dont deal with installing fonts at all currently - they are compiled in (well, I guess not on macOS, but on Windows and I think most Linux packages). I gather this is because we didn't want to deal with the technical issues involved with installing fonts, but I wonder if maybe we shouldn't revisit that.

FWIW, I still have a notion that it would be nice to have a dedicated Roman numeral font. I see it working like the "Sicilian numerals" font that has been floating around, where you use Shift with characters to superscript them, and clever use of zero-width characters allows things to line up. Or, maybe better, using ligatures for 64 etc. It's not that hard to take an existing font and tweak these things, someone could probably pull it off in a day if they knew what they were doing. Someone who only half-knows (eg, me) would take longer and not do as good a job)...

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