Extending default instruments.xml

• Feb 29, 2020 - 11:43

Hi all,

I'm trying to understand how I can customize the behaviour of existing instruments. The main rationale is being able to have MuseScore send MIDI CC events when some things happen, which apparently can be done either using Channel (which can issue a CC along a program change) or a custom MIDI action. Looking around in other posts and the documentation, it looks like the way to do that is with a custom instruments.xml file (which is why I suggested a feature request to use the UI somehow, https://musescore.org/en/node/301586 ).

That said, what's not clear to me is how I can extend an existing instrument by providing a secondary XML file. Adding an instrument is apparently easy enough, and well understood: you create a well formed object, add a new with its own id and musicXMLid, and it should appear in the list. I want to add CC options to existing instruments, though: how should the secondary object be formatted in that case? If the I add in the secondary file has a known "id", will the properties I set extend/replace the existing one, while keeping the non-mentioned one as they are? Or would the object completely replace the one in the original file?

If the former is true, does this mean I could do something like this, for instance:

            [..]
            <Instrument id="violins">
                   <Channel name="arco">
                        <controller ctrl="14" value="1"/> <!--My custom CC-->
                  <Channel>
            </Instrument>
            [..]

and that would only add what I specified to what violins are already configured to do in MuseScore (e.g., including the pre-existing CC32=21 delivery and the 48 program change for the "arco" channel)?

If not, does this mean that to provide any customization to existing instruments, I must clone the instruments.xml file, add what I want there, and tell MuseScore to only use that one?

Thanks for the clarification!


Comments

In reply to by [DELETED] 33854647

Yes.
The current full xml for violins is

            <Instrument id="violins">
                  <longName>Violins</longName>
                  <shortName>Vlns.</shortName>
                  <description>Violins</description>
                  <musicXMLid>strings.group</musicXMLid>
                  <clef>G</clef>
                  <barlineSpan>1</barlineSpan>
                  <aPitchRange>55-88</aPitchRange>
                  <pPitchRange>55-103</pPitchRange>
                  <Channel name="arco">
                        <controller ctrl="32" value="21"/> <!--Violins Fast Expr.-->.
                        <program value="48"/> <!--String Ensemble 1-->
                  </Channel>
                  <Channel name="pizzicato">
                        <controller ctrl="32" value="20"/> <!--Violins Pizzicato-->.
                        <program value="45"/> <!--Pizzicato Strings-->
                  </Channel>
                  <Channel name="tremolo">
                        <controller ctrl="32" value="21"/> <!--Violins Tremolo Expr.-->.
                        <program value="44"/> <!--Tremolo Strings-->
                  </Channel>
                  <genre>orchestra</genre>
            </Instrument>

In reply to by Jojo-Schmitz

Wouldn't this create a new instrument that inherits from the default instrument, though? And without redefining a new name, possibly confusion in the UI when it comes to picking an instrument among the two? I was trying to avoid adding a new instrument in the first place, but maybe the only way is to indeed manually edit the default instruments.xml file and use that one as the default instead (which isn't the optimal solution as it will create a fork, meaning I'd lose new instruments or fixes after MuseScore updates).

In reply to by Jojo-Schmitz

I think I found an alternative solution. I found out that I can take an existing .mscz file, extract the .mscx (since .mscz files are basically zip files), manually add actions to a part, save the modified .mscx file and update it in the original archive, and the next time I open it in MuseScore the actions appear on the related staff, and they work as expected.

I've already started scripting a way to do this automatically (in node.js because I'm lazy :-) ), so as soon as that's ready I'll publish it somewhere (github probably) and share it with the community. My main aim here is preparing some new .sfz files from Virtual Playing Orchestra that use a custom CC instead of KS as a switch: this way, for instance, I'll be able to use, e.g., a single .sfz for sustain/tremolo/staccato/accent/pizzicato for a string section, and drive the samples to play using stave text with the related MIDI action ("send CC14=4 for staccato"), which would be especially helpful once I import the MIDI generated by MuseScore in a DAW like Ardour (even though I verified this works nicely in Zerberus too). As such, ideally these new repository will have both the script to update an existing score, and the new .sfz files to use with it (and maybe an Ardour template based on https://github.com/michaelwillis/virtual-playing-orchestra-ardour-templ… but using CC instead of -PERF).

In reply to by [DELETED] 33854647

FYI, I've started working on it here:
https://github.com/lminiero/musescore-vpo-midi-actions

It already kinda works, even though there are some issues. The main problem I experienced with MuseScore is that, apparently, while MuseScore adds the MIDI CC 14 messages just fine when I use my pre-configured MIDI actions, it looks like they're sent after the note they're tied to (not sure if always, or just some times). The result is that of course the wrong sample is often used for that note when you're trying to play it (the previous articulation still applies). A partial workaround I found is to put the stave text with the MIDI action on the note/rest before the one you want to affect (assuming this behaviour is consistent, that is), but that has other issues when exporting to other tools.

I guess I'll probably have to open another post in the discussion group to get feedback on CC vs. notes. Not sure if I should do this in the Bug reports, though?

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