Channels for instruments other than in the Strings category
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?
Comments
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 That's not a bad idea, but I 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 I had doubts myself, but the 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 That's not a bad idea, but I by Marc Sabatella
It wasn't working properly last time I checked.
But in fact an instrument change is effected by a very similar means to a channel change.
In reply to It wasn't working properly by ChurchOrganist
If you mean 'Change Instrument' isn't working, then yes.
In reply to If you mean 'Change by chen lung
No I meant channel switching....
#23011: Change channel is broken stafftext properties.
In reply to No I meant channel 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 Last I checked, channel by Marc Sabatella
I was referring to this: #23999: Instrument change produces incorrect Mixer details
In reply to I was referring to this: by chen lung
That's an extremely minor display glitch that only shows up if you don't use the feature correctly in the first place. That's hardly the same as not working, which has been the case with channel changes.
In reply to That's an extremely minor by Marc Sabatella
One part probably is extremely minor, but the rest I would say is definitely not as it may go deeper - and I do think I'm using it is valid and proper, just perhaps different to how some may do.
In reply to One part probably is 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 I don't understand what part by Marc Sabatella
Let's discuss it over there :).
In reply to One part probably is 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 A further thought on use by Marc Sabatella
See my comments in #23999: Instrument change produces incorrect Mixer details
In reply to A further thought on use 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 Last I checked, channel 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 Sure change instrument works 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 First - yes, I think I by Marc Sabatella
You're obviously a level up from me Marc :)
I still haven't figured out how to get debugging messages :(
In reply to You're obviously a level up 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.
I just thought about one for Voice:
Synth Voice
Ahh Choir
Ooh Choir
Whistle
Any others?
In reply to I just thought about one for 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 That isn't really about by Marc Sabatella
Three transcriptions of the same song:
It might be harder, or not possible to produce a case for the other three. At the time, my thinking was that they just all come under voice. It probably needs more discussion.
In reply to Three transcriptions of the 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 Whistle makes sense, I agree. by Marc Sabatella
Handclap and kazoo are entities in their own right (not projected solely using the mouth). Not sure if I've seen hum in General MIDI.
In reply to Handclap and kazoo are by chen lung
It's not there, nor is handclap except as one element of a drumset, which makes it useless for this purpose as far as I can tell. Anyhow, my point was, those are things a singer might actually be asked to do. Turning oneself into a choir is not :-)
In reply to It's not there, nor is by Marc Sabatella
"Anyhow, my point was, those are things a singer might actually be asked to do. Turning oneself into a choir is not :-)"
If it is intended for a passage to be sung by a choir (or choir-like), the sound would reflect this.
In reply to "Anyhow, my point was, those 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.
It was done for bass (link ).
In reply to It was done for bass (link). 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
In reply to I did experiment with similar 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,
mkj
In reply to My compliments on your in my by mkjnovak
I manually fiddled with the instruments definition inside the file to add all these channels. There is no instrument change.
In reply to I manually fiddled with the by Jojo-Schmitz
neat
thanks for the reply