Change Mixer Patch mid-song
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
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!
In reply to Change Instrument to the… by jeetee
This is clearly a bug (that there is no way to return to a previously-defined instrument on this staff, especially the "initial" one). If the staff alternates between two instruments, you shouldn't have to reproduce the mixer settings for each unwanted new instance.
In reply to This is clearly a bug (that… by [DELETED] 1831606
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 yourinstruments.xml
file contains the channel items for the different patches you need. For a pipe organ, you could customize yourinstruments.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 customisedinstruments.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.In reply to Not sure I'd call it a bug… by Lofo
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.
In reply to One needn't go that far. If… by [DELETED] 1831606
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.
In reply to Again, it is not a bug,… by Marc Sabatella
I offered an improved design right there. Clicking on "Change instrument" should first offer a list of instrument/patches already used on that staff as well as "new one". Is that so obscure or discordant?
In reply to I offered an improved design… by [DELETED] 1831606
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...
In reply to No, that's a good start… by Marc Sabatella
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.
In reply to One needn't go that far. If… by [DELETED] 1831606
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 insertingStave Text
items at each change patch point. You then edit theStave 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 - withinstrument
XML tags for each keyboard manual andchannel
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 achannel
XML tag entry within itsInstrument
XML tag to represent the manual (or pedal). This.xml
file is then loaded in MuseScore Settings so you can use theStave 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 theInstrument 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 thechannel
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 andStave 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 customizedinstruments.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 customizedinstruments.xml
file....)Lofo
In reply to I like that idea BSG -… by Lofo
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'.
In reply to Change Instrument to the… by jeetee
Well, it's not a bug - it's working the way it was designed to. But I think everyone agrees the design could stand improvement. A way to re-select an existing instrument would be appreciated by many, and probably wouldn't be all that hard to implement.
In reply to Well, it's not a bug - it's… by Marc Sabatella
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.
In reply to Really? What exactly is the… by [DELETED] 1831606
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?
In reply to I agree there is no… by Marc Sabatella
Yeah. The dialog should include a little list-box of previously-created instruments on this staff, if any (would be none for the first such change). Choose one or "new" with instrument choice as now.
In reply to I agree there is no… by Marc Sabatella
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?
In reply to I think a staff text option… by Christian Litster
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.
In reply to Christian, the concept you… by Lofo
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.
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).
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.
In reply to Really? What exactly is the… by [DELETED] 1831606
The value to me is allowing to change soundfonts for the same instrument during playback without the need to first create a custom instruments.xml to allow for additional channels.
But yes, being able to change back to an already created channel/instrument change is an outstanding feature request: #42301: Instrument Changes: add ability to change back to a previous instrument
In reply to The value to me is allowing… by jeetee
No, I guess I can see that now, esp if switching between "exprs" or "slows" of, say, violin, is needed, although shouldn't that be done with patches on the same channel, not channel switching? But I guess you're talking about different sound fonts on different channels ...
In reply to OK, 1 out of 200 :) . by [DELETED] 1831606
Or an AI program that determines what patch to use if, say, a composer writes "agitato" or "teneramente" or some such subjective thingamabobber like that. It could switch to the appropriate soundfont and patch when it sees musical directions like that.
In reply to Or an AI program that… by [DELETED] 29378932
Would you really want a pencil that completes the screenplay you are writing with its own ideas? Think how many people can hardly stand autoplace (I love it FWIW), let alone autocompose.
In reply to Would you really want a… by [DELETED] 1831606
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.
In reply to Or an AI program that… by [DELETED] 29378932
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 separatechannel
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).
In reply to Or an AI program that… by [DELETED] 29378932
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.
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.
In reply to Not only patch changes in… by [DELETED] 29378932
Learning about bass guitar notation, I found that a T under the note means to slap it. A symbol in the pallet would be great. A text or symbol option that can be defined to change the patch would be splendid.
In reply to Learning about bass guitar… by Christian Litster
T is available in the fingering palette
In reply to T is available in the… by Jojo-Schmitz
Thought it might be. I probably haven’t utilized a lot of instrument capabilities due to my inexperience with those instruments haha
In reply to Learning about bass guitar… by Christian Litster
Fingering text can't be configured to change playback channel, though. So better to create one such staff text yourself (eg, Ctrl+T to create the text, type T, then right-click for Staff Text Properties to change the channel), then Ctrl+Shift+drag it to your palette for future re-use.
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)
In reply to Create a custom xml and put… by ramblinj
Slight correction here ramblinj: as part of adjusting the
channel
XML element, you should choose both thecontroller
XML tag to choose the bank, and theprogram
value within theChannel
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 abank
andprogram
at all times to ensure you get exactly the patch that you want.