Channels for instruments other than in the Strings category

• Jan 24, 2014 - 20:55

I don't know if it's been discussed, but after discovering 'Channels' in 'Stave Text Properties…' for instruments in the Strings category (having the options: 'normal', 'pizzicato' and 'tremolo'), I wondered if we could have similar for other instruments.

I'm not an expert, but here are potential examples (not sure if some maybe inappropriate):

Electric Guitar: Distorted, overdrive, harmonics, jazz, clean, palm mute.
Electric Bass: Picked, fingered, slap, pop.

What do others think?


That's not a bad idea, but I wonder, with the new Instrument Change facility, is it really needed any more? The basic semantics are, after all, pretty similar - add a text, set properties that have the ultimate result of changing playback. To the point where I might actually wonder if we shouldn't consider *removing* the channels for strings & brass (normal / muted) and having people use Instrument Change instead. I suppose there might be some philosophical reason for the distinction but it is by no means obvious to me.

In reply to by Marc Sabatella

I had doubts myself, but the distinction is being able to produce different sounds by using the same instrument.

I would use 'Change Instrument' if an instrument completely changed, or for some other instances (e.g. a synthesiser entry changing Mixer sounds from marimba to strings).

In reply to by chen lung

Just because one *can* make that distinction doesn't mean it provides anyone any advantage. Yes, I see that putting a mute in a trumpet doesn't turn it into a different instrument - but it *is* a different instrument from the MIDI perspective. And your other example - changing the patch on a synthesizer - also shows how grey that distinction is, because this clearly is *not* a different instrument in exactly the same sense that a trumpet is not a different instrument than a muted trumept.

And also speaking of trumpets, what about changing from trumpet to flugelhorn? That's truly a different instrument in the sense that neither of these other changes are. But I would bet not 1 user in 1000 would think they should need a different mechanism for "create marking that tells human player and musescore to insert mute" versus "create marking that tells human player and musescore to switch to flugelhorn". Nor would 1 in 1000 want or expect these two markings to be controlled by different text styles and hence potentially displayed with different fonts and relative positions.

Really, unless I'm missing something, it's going to be to people's advantage to stop using the old Channel mechanism and start using the new Instrument Change mechanism in all cases. One mechanism to achieve one result.

Of course we need to keep supporting the old mechanism for existing files, and there's no harm in keeping it around for new scores as well for people who are comfortable with it. But if it *works* to just tell people to use the same mechanism for both kinds of changes from now on, this simplifies everything: usability, documentation, support, and maintenance.

Now, the one potential complication I see is if someday the Instrument Change facility actually starts affect staff properties like staff style, playable range, or transposition. Channel changes do not. But I'm struggling to think of a case where you wouldn't *want* those attributes changed - except the case of a synth changing its patch, which is the one case we are already acknowledging can't be done with a channel change even though it "should". And actually, I'm guessing any eventual mechanism for changing the staff properties will be separate from the Instrument Change - a la the Finale "Staff Style" you can apply to a range of measures.

In reply to by ChurchOrganist

Last I checked, channel switching was working for some scores, others still showed everything piling up at the beginning. I'm not aware of any issues with Change Instrument - it always works fine for me.

Another reason to prefer Change Instrument, BTW - the UI is simpler. The staff text mechanism has become more complex and can be appropriate when you need the extra power (eg, setting different sounds for different voices).

In reply to by chen lung

I don't understand what part you think is not minor. Certainly, the steps you list describe a corner case situation no normal user would ever encounter (stopping to look at the mixer in between adding the instrument change text and actually completing the operation) If there is some sort of *other* bug that is only visible by following a *different* sep of steps, you should submit a separate report for it, with clear sterps to reproduce.

In reply to by chen lung

A further thought on use model:

With both Staff Text and Instrument Change, there is a two-step process: first you add the text, then you define the playback behavior. For Staff Text, that is as it should be, since *most* staff text won't need playback semantics. But for Instrument Change, we know that each and every such element is going to require the user to define an instrument to change to. Right now, you have to do it in two steps (first place the text then select the instrument), and as noted in the aforementioned issue, if for some reason you decide to look at the Mixer after the first step but before the second, you see a minor visual glitch. I say, why not fix both the glitch *and* the use model by making it a one-step operation in the first place? The act of adding an Instrument Change text could automatically pop up the Select Instrument dialog. Then you wouldn't be tempted to interrupt the process and do something else unrelated in between the two steps. And more importantly, you wouldn't have to fumble around trying to figure out what that second step actually *is*. The act of selecting an instrument in the dialog could even pre-populate the the text with the instrument name. That saves you the additional third step of needing to edit the text.

All this said, there is still no harm in adding channel definitions for guitar as originally suggested, and I think it's a good idea. But the user experience can be simplified considerably by directing people to use Instrument Change for all changes of this type and having it work the way I describe above. Unless maybe there is some sort of architectural reason placing an element cannot automatically pop up a dialog.

In reply to by Marc Sabatella

Another observation: one issue with adding channel definitions for all those different guitar patches is that the Mixer becomes more cluttered. It's bad enough that every time you add a violin, you get three entries whether or not you actually use pizz or tremolo. Now we'd have half a dozen mixer entries forg uitar whether you used those sounds or not. Not that this a reason not to do it, but I rather prefer the Instrument Change model where the additional Mixer entries are created on demand.

Anyhow, it's pretty clear from this discussion that there are different use models that need to be supported, and right now the proper steps are hard to discover. So definitely a lot of room for improvement here. Somehow, I doubt any significant changes are in store for 2.0, though. Wouldn't hurt to brainstorm for the future though. We'll hopefully have changes in store at some point to support transposition changes as well.

In reply to by Marc Sabatella

Sure change instrument works fine provided you don't want to mute the instrument.

The muted instrument patches are not in the instrument list as they were presumed to be controlled by staff text.

The fact that this is still not working after being reported 3 months ago is a cause for concern as it is part of the 2.0 Milestones list.

I have had a look at it, but nothing appears to be wrong in the stafftext code itself (stafftextproperties.cpp).

I have no idea where to start looking other than there - we could do with some proper systematic documentation for the code, so that it is possible to track what is calling which routine from where.

In reply to by ChurchOrganist

First - yes, I think I already acknowledge I now get why Instrument Change in its current form cannot replace Staff Text. And I think I was the only one not getting it before :-) I do think the instrument list and sound list *need* to remain separate, since they really represent different abstractions with different requirements. Still room for improvement in the UI here, but it should start with fixing the bugs to be sure.

While more code documentation is always welcome, running under the debugger does a good job of letting you know who is calling whom during execution. Also, even without the debugger, QtCreator (and presumably other similar tunes) does a remarkably good job of showing who potentially calls whom - even to the point of disamguating virtual function calls. Really useful tool; I highly recommend it.

Anyhow, I'm doing an investigation, and will update the issue thread if I learn anything interesting. I can say that so far, I'm thinking the code happens during playback, not when the elements are created, and that the relevant function is Score::updateChannel() in libmscore/rendermidi.cpp.

In reply to by ChurchOrganist

:-> I learned a ton over the summer when I worked on chord symbols, and am still learning. On Windows, debug output normally goes to the console window that opens when you start a nightly build. Couldn't say for Linux.

Anyhow, you'll be happy to hear I've got this fixed - just working out the details of how to address the tests that fail because of the change.

In reply to by chen lung

That isn't really about "Voice" at all - you would never put instructions like that on an actual score for actual vocalists. That's really about "patches for synthesizer players". And sure, you need full flexibility to change sounds to *any* supported sound for a synth part; we've already established that, and provided a mechanism for it (Instrument Change).

I think the electric guitar variations mentioned previously make sense, although it's kind of a drag that they take up so much space in the mixer so I think we should consider this carefully.

In reply to by chen lung

Whistle makes sense, I agree. In the same vein, so might hum, handclap, and maybe kazoo (where available as General MIDI patches). On the other hand, it's not like the standard vocal patch is going to sound that much like an actual person singing (esp. lyrics of course), so the "need" for an easy way to change patches mid-stream is considerably less than for brass open / mute or strings arco / pizzicato.

In reply to by chen lung

Yes, but you don't normally write music for a singe vocalists and then mid-way through the score ask therm to suddenly become a choir. Solo voice and choir would normally go on separate staves. Just like you don't ask a single clarinet player to suddenly become an orchestra. That just doesn't make sense. Again, if you are not writing for an actual vocalist but for a synthesizer player, then sure, they might be asked to change patcvhes from voice to choir to clarinet to orchestra to car horn to anything else. But that's about synthesizers, not about vocalists. Individual trumpet players can be asked to insert a mute. Individual violinists can be asked to play pizzicato. Inidividual guitar players can be asked to play harmonics. But individual vocalists cannot be asked to turn themselves into choirs. It's just not something one should ever expect to place as a direction on a a staff that is actully meant for a vocalist.

In reply to by chen lung

I did experiment with similar changes for guitar, see attached, I'm not really happy with the sound though, esp. with the harmonics, doesn't sound like harmonics at all to me (which is the same as flageolet, isn't it?), this is bascially why I haven't submitted a PR for this yet.
Might be a defect in FluidR2Mono_GM, not sure

Attachment Size
Guitars.mscx 85.58 KB

In reply to by Jojo-Schmitz

My compliments on your in my opinion excellent file -
but let me ask a question, please.

Did you change staff properties at each instrument change?

I stared at it for a while to figure out how you got those separate parts with multi measure rests in them. I found it very unusual and will mentally file that away if I ever need such a layout. Usually if I write everything on one staff in score I want it all on one part as well.

Take care,

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