Bar property: do not hide
As far as I know, if a part is marked as "Hide empty staves", then the only way to stop this happening in a particular case is to add a note, make it invisible (and "do not play" if you care about that). So you have something for flute, clarinet and piano (I do), want the flute and clarinet parts hidden during an extensive piano solo, but do not want either flute or clarinet hidden separately, then the hidden note messes up the Fl and Cl parts because multi-bar rests do not show properly.
I suggest a property of a bar (everyone knows what that is, don't they? Americans must understand it, because Gardner Read spends a paragraph ranting about how it's "wrong")... "Do not hide". This is an extra property and an extra checkbox, but can be implemented very simply: when checking a line for whether each bar is empty, you check the "Don't hide" flag, and count it as non-empty.
Easy to implement, but low priority, I think.
Comments
Easy to implement
Maybe not so easy. Most options in the measure (bar) properties affects every staff, not just one instrument. The programmer would likely need to create a new property that affects only one staff in measure properties. This will likely break previous version 3 compatibility so would then need to be delayed to version 4.
In reply to Easy to implement Maybe not… by mike320
There is the staff list used for the "visible" property, so it could be added there. But I personally think it would be easier (both for the implementation and the use) to have this be an ordinary palette element. Could be like the "staff type change" where it's just an element added to the measure, then we check for one in that measure / staff in the place we decide if a staff is empty.
As for compatibility, the only break would be that scores using this new feature would display differently in previous versions. In that respect it's no different from any number of other features added since 3.0 - sticking, fret diagrams with attached chord symbols, Roman numeral analysis, autoplace "min distance" for individual elements, etc. I don't think there has been any "official statement" on this, but the general feeling seems to be, we just don't worry so much about that. I think we'd only bump to a version 4 if something caused scores to not open at all in older versions, as was the case with the more fundamental changes between 2 & 3. And right now there really aren't any plans to ever do that.
In reply to There is the staff list used… by Marc Sabatella
To clarify, adding a new measure properties that only affects a single staff would probably cause previous versions to crash. Your new palette item idea could be implemented so it didn't cause a crash in previous versions.
In reply to To clarify, adding a new… by mike320
I suspect there would not be a crash either way. But indeed, everything I said is contingent on the implementation actually working such that older versions can handle new properties/elements gracefully - not crashing when they encounter a tab (representing a property or element) they don't recognize. This was a big problem during 2.x development to be sure, but we did do a fairly thorough job of making the score-reading functions more robust. So you can actually throw in quite a lot of new stuff and older versions will generally be able to handle (e.g., silently ignore ) it. Sometimes you have to be a bit clever in how you decide to write the information to the file to make sure older versions will be OK with it, and we do generally test this when adding new feature. I know I did this recently with RNA, symbols on barlines, the "min distance" changes, etc.
No doubt there will come a time when some new feature gets added that just cannot be made to work this way, though, and then we'll have to face the question of making change to the file format version number in order to prevent older versions from even attempting to load the file, and then will presumably mean a move to 4.0.