Bar Properties / Other / Bar number / post-increment feature?

• May 20, 2015 - 09:51
Type
Graphical (UI)
Severity
S5 - Suggestion
Status
closed
Project

For generating multi-measure-rests, i use the bar properties in a bar with a whole rest. For example, with bar duration (Nominal) = 4/4 and bar Duration 4/1 (Actual) i get a 4-measure-rest. So far so good, but for get a correct bar numbers in the following bars, i wish to post-increment the bar number by 3 steps (I know the workaraound to increase the following bar by 3 steps, but i think is it not so clever, because of follow error copying this bar to another location for example).

Sorry for my bad english

Greatings, Felix Schuster


Comments

This doesn't seem to be multi measure rests, but 4 whole rests in one measure.
Why don't you just add 3 more empty measures and switch on multi-measure rests?

I find the concept (only global switch on or off multi-measure rests) too rigid. When i switch off or on multi-measure rests, my layout breaks. I miss an easy way to bundle individual rest-measures to one multi-rest-measure when entering notes.

My above described way (s. my last comment) was my alternative to achieve this goal (with a small optical defect in the rest-representation and the small problem with the bar-numbers)

What do you mean "my layout breaks"? If you are seeing some sort of layout issue with multimeasure rests, you should report it - with sample score and steps to reproduce the problem.

In general, the multimeasure rest feature is should work fine; your aren't supposed to need to create them manually.

I mean , that move the line breaks when you switch the multimeasure rest function on or off, so that changed the entire presentation, because the space required by a multimeasure rest is less than the space of several rest bars.

Well, sure that's to be expected. You can't expect 20 individual measures of rest to takes a little room as a single multimeasure rest, and that wouldn't be true whether you were forced to create the multimeasure rests manually or continued to have them creeated automatically. It dosn't make sense to have the same layout with or without multimeasure rests. So you shouldn't be dealing with layout until you are essentially done entering music and have enabled multimeasure rests. If for some reason you need to temprarily disable them again, sure the layout changes, but so what? It changes back as soon as you re-enable multimeasure rests.

I find, the current multi bar rests concept is not so user-friendly and and wishes

either an function to "freeze" already existing multimeasure rests (between notes) in its presentation, so that the layout will not change by switching the multimeasure-rests-function on or off

or alternatively a possibility to deaktivate the multimeasure-rests-function only for (empty) bars at the end of the score, so you can continue to edit the score while to see the current layout.

Hier nochmal das gleiche in meiner Muttersprache, da mein Englisch nicht so gut ist.

Ich finde das aktuelle Mehrtaktpausen-Konzept Stelle nicht anwenderfreundlich und wünsche mir

entweder eine Option, mit der man bereits vorhandene Mehrtaktpausen (zwischen Noten) in ihrer Darstellung "einfrieren" kann, so dass das Layout nicht wechselt, wenn man die Mehrtaktpausenfunktion an- oder ausschaltet,

oder alternativ die Möglichkeit, die Mehrtaktfunktion gezielt für leere Takte am Ende der Notenzeilen auszuschalten,

so dass man an einer Notenzeile weiterschreiben kann und gleichzeitig ein aktuelles Layout sieht.

Eine Belehrung in der Art, dass ich mich um das Layout erst kümmern soll, wenn ich alle Noten eingegeben habe, finde ich nicht besonders nett.

The ability to freeze multimeasure rests is not bad, but I still don't understand why you are turning on multmeasure rests before you are done entering notes. The normal order of operations would be to enter your notes first, *then* turn on multimeasure rests, *then* worry about layout details. Is there something specific about what you are doing that requires you to deviate from this? Understanding your use model would help in understanding what improvements would be possible. But I would suggest you do this in a new forum post, not here in the issue tracker.