A new file format to install extensions in MuseScore ?

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

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