Mixer colours
I just noticed a score with some quite striking mixer colours. Not sure if these are all going to be revamped for MS4, but I also noticed a few quirks.
It would be useful if the RGB or hex values for each colour in the panels could be given, and also if a RGB or hex value (or indeed any of the standard number style colour forms) could be used for input of colours.
Also, although it seems possible to change the colour of each channel/instrument strip, it does not seem possible to alter the Master channel colour.
These aren't really great concerns, but if MS4 is being built with new and extended features, these might be issues to bear in mind.
A few final points - it might be useful to be able to rearrange the order of the channel strips. This can be done by rearranging the staves in the scores, but it might be helpful to do the channel strips independently.
Also the channel strips could be grouped, and perhaps also their visibility could be toggled on and off.
I suppose also subgroup "sub-master" channels could be created - for example Brass, Winds - so that groups of instruments could be balanced against other groups. However I wouldn't restrict the instruments in each group. If someone wanted to have a Brass group containing Accordion, Horn, Trumpet, Timpani and Dizi, Bandura and Organ I wouldn't object. Normally though I would expect a "standard" configuration of Brass to contain Trumpets, Horns, Trombones and Tubas, but having a sub-group feature could help some people.
Comments
In current MuseScore 4 builds, it does not appear user-assignable colors are thing anyhow. It does seem a useful feature, so if you'd like to see it considered for future re-inclusion, I recommend submitting a Suggestion to the issue tracker.
The idea of grouping strips by section is definitely one I think many people would like to see and I would assume is on the roadmap.
I kind of doubt an arrangement where the mixer channels are not in sync with the score itself would be something considered - seems a recipe for confusion - but feel free to discuss that idea further here with a real world use case (sample score, etc).
Hmmm. I'm not sure I see any value to different colors in the mixer. Unless the score is like-wise.
I agree with Marc that the order in the score and in the mixer need to match.
As for subgroups, I'm not sure that works well in notation software. Sure we have them in live sound mixing, but that's not to compare anything. It's to, say, bring the vocals up for a bit then bring them down later. Score writing is not like that. In orchestral writing you would need so many subgroups. What happens when you have the brass subgroup pulled way down but then you need the trumpet solo louder than the subgroup volume allows? Personally, I don't mess with the sliders, and do almost all volume control in the score.
In reply to Hmmm. I'm not sure I see any… by bobjp
Sorry - almost as usual - I don't have to agree. My suggestion about the order of the strips not being tightly linked to that of the ordering in the score was simply to allow users to decide. I expect that many would want to have the same ordering, but what I was deliberately trying to avoid is the notion that the MS developers impose a constraint which many people would not need, as they would probably naturally put things in the order of the score. It wouldn't, in any case be that difficult to implement both options, but jumping to the conclusion that something has to be constrained in a certain way - perhaps because that is how things are done now - is not always a good thing.
Re colours in the mixer - I think for a large score the mixer colours could be very helpful. On the other hand I would almost certainly not want to see a coloured score.
In reply to Sorry - almost as usual - I… by dave2020X
As always, if you want others to understand your specific use case so they can consider and prioritize your request for a particular feature, the best way is to attach a real score and describe the real world situation that led you to suggest this. If you are able to show it’s something many users would value, that’s the first step toward getting it included.
For colors, the use case is obvious - to color different sections in an orchestra, etc. But for allowing the channel strips to have no relationship to the order of the staves - that’s just a head scratcher to me and I have to imagine to anyone else as well.
So again, if you want others to understand and consider the idea, common sense dictates that it is in your best interest to provide specific real world examples. I have no power to make decisions here, it’s just free friendly advice. The best way to convince people to implement a feature is to make the strongest possible case for why it would be valuable to others.
In reply to Sorry - almost as usual - I… by dave2020X
I don't think the MS developers are imposing anything on anyone. What you suggest would be more like having an index not be in alphabetical order.
In reply to I don't think the MS… by bobjp
Not quite. I was simply suggest that no order would be imposed on the end user at all. If he/she wanted the standard layout arrangement that would be possible. For convenience many users might like to have a standard order - but there might be several choices - which I think is already the case in MS.
For example I believe (I'd have to check) that there might be different "standard" layouts for full orchestra, jazz combo and brass band. So a composer who wanted to have all three elements within one work - perfectly possible - might want to see different strip groupings within the mixer depending on which section of his or her work was being considered.
If one wanted to have instruments shown in alphabetical order by instrument name - why not?!!!
Not sure whether that would be so useful, and would change if the language used changed, but the implementation could have free ordering as the default, and then whatever ordering is desired put in as an extra bit of code.
Doing things the other way round could be limiting.
In reply to Not quite. I was simply… by dave2020X
Sure, MS users can put instruments in any order they want. I don't use the score templets. But that's because I don't need all of them. I don't feel limited at all. But I still adhere to a standard order. Why? Because the purpose of notation software is to produce...notation....for live players. A conductor expects to see the trumpet part somewhere in the middle of the page. Not at the top or bottom. It's just the way it is. Truth be told, I use MS for playback, and not for producing a score. I can do that because I know what I'm doing. Many users are new to the process, and need help. MS does that by doing many things for them. Not to limit them. But to show them some of the norms. Learning notation is not easy. Neither is notation software. It's a mistake to just let everyone do what they want at the outset. Later, sure.
I know people who know nothing about notation and produce great music with a DAW. All they want is playback and a DAW does that better.
In reply to Not quite. I was simply… by dave2020X
If a feature is truly useful to a lot of people, I want to see it implemented. So if someone suggests a feature, and others are having trouble understanding the need for, my goal is to guide them to take the steps to help increase the likelihood of getting support for it. And as I've explained, those steps include first showing real world use cases - an actual score and a precise description of how the proposed feature would help with it - to help others understand how it could be useful to them as well. That remains the first step to take here.
Once there is general agreement among a large number of users that a suggested feature would be useful, and
a consensus develops through the conversation as to how it would need to work in order to suit everyone's needs, then the process of actually creating the design can begin. And once that design is approved by the core team, then someone can consider implementing it.
Again, my goal is to help shepherd people through the process. That is why I am a broken record on this topic: step one is showing a clear and relatable real world use case to help others understand how it could be useful to them.