Change Mixer Patch mid-song

• Jan 2, 2020 - 06:33

It would be nice to be able to change the patch of the instrument mid-measure/song, so that only a few notes are played in a certain style.
It is possible with some instruments (bass to slap bass, for example), but doesn’t seem possible with other instruments (electric guitar to guitar harmonics; acoustic drum set to electronic kit; etc.). Or maybe it is, and I don’t know how to do it. It doesn’t work with the Change Instrument tool when I change it to the same instrument and use a different patch on the Mixer.
Please consider making this a bit more user-friendly! Thanks!

Comments

• Jan 2, 2020 - 09:31

Change Instrument to the same instrument definitely seems to work for me, it adds an extra entry into the mixer for that instrument. Make sure to press the arrow on the topleft of the slider of the instrument to be able to see all its subchannels!

Reply

• Apr 20, 2020 - 13:05

Not sure I'd call it a bug either, but it would be nice to 'flip' between, say, organ registrations (stop combinations), rather than create a new mixer patch choice each time (which quickly gets unwieldy). You often only need to swap between two or three patches in a particular score, but do this many times in a single score.

As to how it could be implemented, I guess there are a few options, but they seem to me to be a fairly significant change (or at least the addition of quite new functionality) into the app. For organ music, design-wise you'd be implementing something similar to pre-programmed thumb pistons - and in fact replicating this functionality could be a good design guide into future versions. I've previously downloaded the code base for MuseScore, and might have a look around to see if there are any clues as to how to implement this kind of functionality - initially though I suspect it's likely to be a fairly significant technical change, as well-coded as MuseScore is within its Qt framework (which I've always thought tries to force good design principles).

I've also been exploring the Edit - Stave Text to choose patches for voices, however this requires that your instruments.xml file contains the channel items for the different patches you need. For a pipe organ, you could customize your instruments.xml file, adding different channel patches for a 'main' patch, then use Stave Text edits to select the patch you want. Seems a bit easier than full-on instrument changes, but might be a better solution, albeit at the expense of having customised instruments.xml files - which is not ultimately ideal. It does allow you to switch between patches, possibly more logically than using Instrument changes, although I suspect the complexity issue is not much different ie. multiple Mixer patches throughout you score.

Reply

• Apr 20, 2020 - 14:59

One needn't go that far. If the "Change instruments" menu simply offered you a list of all the patches you had used previously on this staff, including the initial one, you could get whatever you want (although not the ability to use multiple instruments, including organ stops, at once -that's colla parte, which is another needed feature). It is unquestionably a bug that I can't go back to what I had.

Reply

• Apr 20, 2020 - 20:18

Again, it is not a bug, simply a feature that doesn’t yet exist. The word “bug” already has a meaning - several, in fact; you don’t get to invent new ones. No more than I get to say D-F-A is a major triad. A major triad has a major third above the root, not a minor third. And a bug is something that doesn’t work as designed, not something that you wish had been designed differently.

Using the wrong terminology does nothing to further the discussion - on the contrary, it takes time and energy away from the real work of proposing and implementing an improved design.

Reply

• Apr 20, 2020 - 21:07

No, that's a good start indeed. But, it is worth further discussion to be sure it solves everyone's use case. There are alternate designs I could imagine that might be more generally useful. And still, that's only a high-level description of the design, we'd still need to talk about how that list should be offered (dropdown within same dialog? any buttons or checkboxes involved? and so on). And then we can also talk about the design from a code perspective - what's actually feasible given the current architecture (which is actually changing somewhat for 3.5 as a GSoC project from last summer was recently merged). I haven't really looked at these changes - which also include UI changes, so we'd want to make sure what is proposed makes sense within the 3.5 UI.

So yes, absolutely let's discuss these issues here...

Reply

• Apr 20, 2020 - 21:16

I think a straight item-list menu, interposed between "Change Instrument properties" and the (present) instrument dialog-- you can, and must, select only one (including "new instrument", which brings you to the (present) Instrument dialog). No buttons or checkboxes involved. The first time you use Change Instrument on a staff, you don't see it. The second time, you get a choice of the old instrument or "New instrument". The third time, you get both old instruments or "new instrument". If you really do create 2 mixer panels of violin on purpose, then they get subscripted [1] [2] or whatever.

Reply

• Apr 29, 2020 - 09:53

I like that idea BSG - anything that minimizes the number of instruments in the mixer is an important goal, particularly as we know for pipe organ scores where you're usually just flipping around a few registrations.

AFAIK there are two ways to change patches mid-score in MuseScore. The most common technique is to insert a Change Instrument text item at the point you want your patch change, then edit the Mixer instruments to choose the patch you want.
The second method is to create a customized instruments.xml file, reflecting the SoundFont you want to use, and then inserting Stave Text items at each change patch point. You then edit the Stave Text properties to select a patch from the list (for the particular manual/stave) and assign it to a voice.

I've been doing some research into this second method to compare it to the first.

In my case, I've made a customised instruments.xml file that reflects the PiteaMHS2.0 SoundFont - with instrument XML tags for each keyboard manual and channel XML tags for each patch (pipe rank) within the manual. For the Pitea organ there are 35 patches spread across 3 manuals and pedal, and each patch requires a channel XML tag entry within its Instrument XML tag to represent the manual (or pedal). This .xml file is then loaded in MuseScore Settings so you can use the Stave Text method of changing patches.

Testing against a pipe organ score, I found that the Stave Text method of changing instruments has an advantage in that you don't end up with an inordinate number of Mixer Instruments everytime you change registration. In short, as you flick between different registations, MuseScore doesn't add anymore Mixer instruments - all patches (ranks) are already in the Mixer list. An additional benefit is that you can assign different voices to different patches, within the one stave. Contrast this approach with the Instrument Change method: every time you change instrument, you get a new Mixer instrument item. It can also be hard to keep track of which Mixer instrument your changing, in relation to your score.

The downsides to the Stave Text method however are:
- you need a SoundFont-customized .xml file. This is slightly unpleasant, in that this file is changed in the app's settings, not the score, so needs to be done each time you want to use it - on a per-score basis. Of course you also have to create this .xml file, well-formed and matched to the SoundFont patches (I used PolyPhone to help with this - namely, identifying the bank/patch numbers to insert into the channel XML tags.
- when you create your score using this .xml file, you see the entire set of patches in your Mixer window (e.g. 35 in total for the Pitea organ) - regardless of whether you intend to change patches mid-score or not. This happens before you've even written a note (although they are grouped by manual at least). You can reduce this number further if you're not using all 3 manuals + pedal in your score.

A question: Could the process above (custom .xml file and Stave Text entries) be made easier with a QML Plugin? It would need to be able to:
a) run the plugin on opening the score;
b) load the SoundFont file stored in the score; and
c) change the Setting's instruments.xml file to the customised one.
(I'm not familiar enough with the Plugin architecture/design to know whether these actions are possible).

In summary, I'm not convinced either method of changing patches mid-score is better than the other, although I found that once set up, the Stave text in combination with a customized instruments.xml file was easier to use and keep track of within a score. Neither method is perfect, so a design change to allow flicking between a limited number of patches, without creating a tonne of Mixer instruments would be beneficial. For a pipe-organ enthusiast, nirvana would be the ability to combine patches together to replicate the organ concept of a 'stop' - but I realise this is getting outside the requirements of score-writing software, and I don't know if SoundFonts are even set up to allow this to happen.

(I can post the Stave Text patch change method instructions, and the custom Pitea .xml file as a tutorial if anyone's interested. It's all self-documented in the one customized instruments.xml file....)

Lofo

Reply

• Jan 14, 2021 - 17:10

Stave-text method is the best method. Plugins are not intuitive and its just too much work to have to input ranges and parameters and this and that. You should be able to use symbols in the palette or words (musical directions), and those symbols or words should be tied to a specific soundfont patch. That way, the way it's written is the way it sounds. Soundfont patch changes should be automated so we won't have to think about such things when we're trying to make music. They've already made a good start with "pizz" and "arco". Now they just have to increase their own soundfonts to include all possible instrument effects and apply the rest of the symbols to them. For example, in the soundfont that comes with Musescore, there is no col legno patch. There should be. Get crackin'.

Reply

• Jan 2, 2020 - 20:23

Really? What exactly is the value in what it does now? I suppose you could have "Oboe, oboe, oboe" meaning three different "mixer configurations" of oboe, but that might be fruitful one out of a hundred times when the other 99 are "I wanted to return to the instrument originally there". It is a design bug, as far as I am concerned.

Reply

• Jan 2, 2020 - 20:26

I agree there is no advantage to not having this feature. But still, the word "bug" has a pretty specific meaning that simply doesn't apply here, and misusing the term doesn't help solve the problem, it just serves to create noise and distract from actually improving the design. Any thoughts on what the UI should look like for this proposed new feature?

Reply

• Jan 3, 2020 - 06:48

I think a staff text option defined to change patches for an instrument would be great. Or perhaps a symbol you can place on a note that requires a new patch selection to operate.
How I picture it: a text/symbol box in the pallet that you drag onto a note/chord. It will prompt you to put in a character. You put in an appropriate character to indicate a difference in style for the note/chord, and then it gives you a drop-down menu to change patches. That patch change will apply to the note/chord alone. Copy/paste the symbol onto other notes that require playing with that same style.
What do you think?

Reply

• Apr 29, 2020 - 11:14

Christian, the concept you've described is similar to what you see in pipe-organ scores. The different registrations (stop selections) are often written at the top of the score with an associated (Roman) numeral. Then, the required registration is identified at the note/rest using that symbol (e.g. I, II, III, IV etc.)

Thinking about the code-base, I'd envisage you could solve the problem by adding an editable 'registration' table (or technically, a v-table) to the application where you identify the patch, and the matching number as part of the process of setting up your score. Then, you'd insert the symbol (Roman numeral) at each point you want to change patches. It's not dissimilar to what MuseScore does now with Instrument Changes, however rather than adding a new Mixer instrument selected from the entire SoundFont every time you change patch, MuseScore would go back to the v-table instead, pick up the patch required from its pre-defined list, then apply it (via MIDI) to the score as it plays - without adding new Mixer instruments.

From that perspective (choose from a v-table, not the entire SoundFont), it might best be technically solved with a new text-item type ('Change registration? The term is probably too pipe-organy!). The number would not represent an 'instrument change' as such, but rather a patch change checked against the pre-defined v-table, not the entire SoundFont as is the case now.

From an object perspective, there would be two new objects, stored within the score:
- a patch table of SoundFont patches to use within the score (containing bank and patch number), matched to a specific, identifying symbol/number
- a new text item type (e.g. 'patch or registration change text'), inserted at the required note/rest and that looks up the registration/patch table, and then applies the MIDI bank/channel change at that point.

From a UX perspective It would require:
- a new window to create/edit a limited set of patches chosen from the SoundFont, assigned to a symbol/number, and set up before adding notes to the score.#
- a new text item type to add at a note/rest, where you could edit this text item to choose from the list of patches in the new table you just created (and not the entire SoundFont list of patches).

#An advantage of using this patch table would be that you could change the patch in this table, and see the patch choice chosen against the entire score, wherever its matching symbol/number occurs on a note/rest. Currently with 'Change Instrument' you need to edit the mixer list for every patch item you want to change, individually.

This is just thinking aloud (well rather, by a keyboard), but the discussion has helped me think further about some of the suggestions.

Reply

• May 28, 2020 - 10:54

I've had a look through the MuseScore code base, and found a few design decisions that should be useful in the design of any new MuseScore functionality re SoundFont patch choices. I also think the change we're talking about here is not quite as difficult to implement as I'd first thought.

  1. MuseScore song files and SoundFonts are quite strictly decoupled. MuseScore's interface to the SoundFont via a score file extends only to choosing a bank and patch (via numbers), defined in the instruments.xml file. There's one exception though: you can save a reference to a SoundFont in the score. But...it won't actually load unless you open the Synthesiser window and tell MuseScore to "Load from Score" (see Feature Request #81591 to change this behaviour, to allow for automatic loading of score-defined SoundFonts).

  2. instruments.xml files can customize a single instrument with 'sub' instruments (or playing styles) - for example, violins plucked versus bowed. These playing style variations must be pre-defined in the instruments.xml file, and allows you to modify different voices using 'Stave Text' - 'Stave Text Properties' . The net effect from MuseScore is that this feature lets you select a different bank/patch number for a voice, as long as the instruments.xml file has defined the different bank/patches under a single instrument. MuseScore score files still don't know anything else about SoundFonts, except for which bank and patch number to play notes on.

I think, design-wise, the decoupling of scores and SoundFont files is entirely appropriate for many reasons and is considered good design practice anyway. (Coupling different objects/files together resulted in 'DLL Hell' for those that can remember early Microsoft o/s's!) Consequently, the implementation of a future 'patch table' or 'patch set' (may need a new term here) which can be referred to at any point in the score using a new 'Change Instrument Set' text type, and relieving the score of having to continually add Mixer instruments at every change would be best implemented via a new class object.

Reply

• Jan 4, 2020 - 03:47

If by "pencil" you mean a "conductor", and if by "you" you mean the "composer", then I'd say that it happens all the time when there's a concert. The conductor "interprets" the score that the composer wrote. A composer who's probably dead and can't defend him or herself. By allowing a third party to interpret what a composer meant, it opened the door to AI as conductor and orchestra, IMHO.

Reply

• Apr 30, 2020 - 11:59

Your suggestion wouldn't require AI, and in fact I'd guess if you impemented it via AI it would probably add a huge level of complexity to the MuseScore application that it doesn't need, or was never designed for. I hate to say it, but people often say 'Use AI' when they're not sure how to procedurally define a requirement within the architectural design of the existing code.

MuseScore really only gets to select bank/patch changes - not temperaments or dynamics within a bank/patch. It's based on sampled sounds after all - and has no recognition of how these sounds relate to a particular physical instrument (even if humans think they're only slightly different e.g. "But it's still just a saxophone"!).

You could possibly achieve what you want though if MuseScore was designed to recognise your SoundFont's modulation (dynamics) settings as well (e.g. when to use Vibrato LFO frequency/amplitude within a single sample) and this can be achieved through MIDI messaging, but AFAIK, this is not something MuseScore recognises - it just uses your bank/patch selection to decide what to play - and you need to use your own MuseScore score to utilise the different dynamics. (Having said this, perhaps it's possible to use new channel XML subparts to influence this i.e. controller messages to choose SoundFont vibrato via a separate channel with the correct MIDI messages applied via the XML settings. You'd still have to choose an instrument change to select the required bank/patch/dynamic in your score).

Of course MuseScore will let you have some of your own independent articulations - but remember that these happen in your score, (e.g. trills articulations) not via the SoundFont bank/patch you have selected.

I realise this dicussion is getting somewhat arcane, but it does demonstrate how an intimate understanding of the design architecture of SoundFonts vs. MuseScore is important when trying to solve problems or opportunities in the design of the MuseScore application, and the discussion is absolutely worthwhile in the continuing develepment of MuseScore (especially given the design of SoundFont files is probably more rigidly fixed, and less subject to modification).

Reply

• Aug 27, 2022 - 20:34

You don't need an AI program to do this. All you need are user defined presets. Agitato could simply mean elevating the tempo a little bit while making all the notes staccato. Teneramente could be achieved by just making all the notes legato and slower. All musical directions are parameters that can be preset by the user to suit their tastes.

Reply

• Jan 3, 2020 - 04:06

Not only patch changes in the middle of a score within the same soundfont, but patch changes using different soundfonts as well. The ability to program musical directions for players, for example, like "harmonics" or "harm." or "o" over a note, to equate to a patch in one of your soundfonts would be a big step toward user friendliness. Then all those symbols in the symbol palette would actually do something instead of just looking really purty.

Reply

• Apr 29, 2020 - 16:44

Create a custom xml and put it in the secondary menu of the instruments folder under preferences-->score. You need an xml editor. There is Msc documentation on this. (google search) make sure you don't fold changes under a larger group like "percussion" when you only want "drums." Copy the channel line as many times as you like. You can add "channel name" to "channel" so you see it in the mixer. But don't change anything else but the program values (patches). Regular drumsets run from "0" on up. "Electronic" is "24."
Pull the secondary xml out of the folder when you don't want it. (BTW, drumset changes are not timestamped and midi exportable the way melody bank instruments are)

Reply

• Apr 30, 2020 - 11:02
  • But don't change anything else but the program values (patches) *
    Slight correction here ramblinj: as part of adjusting the channel XML element, you should choose both the controller XML tag to choose the bank, and the program value within the Channel to get the patch you need within the bank. While this is unneccessary in single-bank SoundFonts (though advisable for completeness), it is important when it comes to any multi-bank SoundFonts (like Jeux14.sf2 for instance). You can do without the XML editor if you're careful, but text editors like Sublime Text (on OSX) help with this process. All patch changes are arguably done with both a bank and program at all times to ensure you get exactly the patch that you want.

Reply

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