[trunk] Section break and long instrument names

• Apr 13, 2011 - 11:38

Hi,

Context: trunk rev. 4179 (both under Win XP and Ubuntu 9.10).

As trunk is regularly improving, both in features and in reliability, I am starting to move (with care and many backup!) some of my 'real' scores to it.

I noticed that, when a section break is added, full instrument names are repeated at the beginning of the next system. This is sometime what I am after, for instance, when joining in a single score several short works not strictly related.

But sometime I just need the score to go on, after the section break, with short instrument names (which I usually set to empty strings). For instance, instruments names are not usually repeated at the beginning of each movement of a sonata (but section break can be very useful there!).

Is it possible to have this choice (after a section break use long instrument names or short instrument names)? I looked for it in some obvious places (section break properties, staff properties), but I did not find it.

Of course, there are workarounds; for instance, set both long and short instrument names to empty string and add staff texts at the very beginning of the score (or wherever instrument names are needed) to be positioned as instrument names. But:

1) positions of staff texts may change when layout changes (even slightly)
2) I have learned that 'tricks' may quickly (sometime) achieve the intended visual result on the spot, but one 'pays' for them in the long run in terms of side effects, backward compatibility with new versions and so on.

Thanks,

M.

Comments

• Apr 13, 2011 - 19:20

Not specifically related, but I'm wondering what people who have been using the nightly builds regularly think about its stability overall. I get the impression from the issues I see reported that it's probably *less* stable now than it was a few weeks ago, but maybe it's really just that more people are using it.

Unfortunately, there have been a few what to me are showstopper bugs that have been around for months (eg, create score from template always crashes immediately, instrument transposition is completely broken with respect to both key signatures and accidentals) that prevent me from being able to do anything but occasional playing around with the nightly builds. I actually don't mind living on the "bleeding edge" occasionally, and I really would love to be taking advantage of the new features, but I'd need these few bugs fixed before I could get started. Would it help if I "bumped" the older issues that are preventing me from using the nightly builds?

Reply

• Apr 13, 2011 - 20:52

Werner: Just asked and in a few hours it is there!

Would you mind to add to next revision a tap pouring espresso, possibly with preferences for temperature and sugar quantity? Seriously, many thanks!

Marc: It is difficult to quantify current stability of trunk; to my experience, most of the tasks I usually do are stable enough to attempt doing some 'serious' work with it, of course keeping in mind that the programme is still under heavy development, so I do save every minute or so and always before I do anything I have not done before.

It DOES crash, of course, not so rarely, and I occasionally loose some work; I would say a few weeks ago it was worse, as crashes occurred for operations fairly frequent or important to me, which now work correctly (most of the times...). So, I know I am taking some risks (including risks with file format changes), but so far I could go quite on with some jobs, taking advantage of the new features, so the balance is globally positive for me.

I also know that the kind(s) of scores I do are rather simple, they maybe include some strange things (strange compared to 'mainstream' modern scores), but the overall structure is simple; for instance, I never need transposition, I rarely use multi-staff instruments (and almost never with complex features like cross-staff beaming and so on); I also do not use templates, as scores are in my case different enough to make simpler and quicker using saved styles. In addition, if some (small!) detail is blocking me, I sometime go into the code and I add some change, which I later propose as patch.

So my experience may or may not be transferred to other. On the other side, as long as the programme is not actually used for some 'real' work, assessing its status will be difficult.

About bumping old issues, taking into account that it is easy to look unfair to the developers, really blocking issues which lag since a while may probably need some new assessment.

Thanks again to the MuseScore community!

M.

Reply

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