Changing Key signature
Hello again.
Approx year ago I ask question how to change Key signatures in all staves at once. In that time it was buggy and program crashes a lot (the feature was in nightly build). Now I was trying same procedure but doesn't work.
So if I drag key signature in multistave part the only one was changed, but (in that time) if I drag it with ctrl key the all staves changed key.
In this new version that doesn't work. Is it deleted or what?
And another thing...
I just retype some bad score. But I start with single stave and write down the instrument. After completion I add next stave. The clefs, Barlines, and time signature are copyed in new one stave but not the Key signature. As that part use as lot of key changes is it possible to make that "automatic"?
Thanks.
Comments
The feature where you can change key for all staves at once is in the eventually-upcoming 2.0 release, for which it has been possible to install experiment nightly builds for some time now. So that must be where you saw the feature. it's still there, just hasn't been released yet. Actually, the *default* in 2.0 is to change all staves at once; ctrl allows you to override this for an individual staff. That's one of many improvements I am eagerly awaiting - probably several months away at least, though.
As far as I can tell, there is no way in 1.2 *or* 2.0 to have newly added staves get the new key automatically. I agree it should. There is an existing issue in the tracker requesting this: #5961: Wrong key signature for new instruments
In reply to The feature where you can by Marc Sabatella
This feature is probably dissabled as someone has working on that year ago. Nightly build from December 2011 has that feature (well the build was unstable and crash a lot) and as I remember that was version 0.96 or 1.1. Now in version 1.2 there is no trace on that. And above bug(#5961) is from 2010! So in two year should be some progress.
In reply to This feature is probably by eslavko
No, the nightly builds from December 2011 (or December 2010) were not for 1.x - they have been for "the trunk" (latest and greatest sources) for at least that long. I am not sure when the big split between 1.x and 2.x was made, but the feature you refer you was never part of any 1.x build as far as I know. It was in the nightly builds for the teunk only - which is to say, what will eventually become 2.0.
As I said above, the feature is still there in 2.0 nightly builds, and you can see this for yourself if you install ne. It was never disabled, nor is any additional work necessary - it's been working for quite a long time. It's just that this feature was never backported into the 1.x branch, so it isn't in 1.2. That's true of most new features developed in the past year or two. The 1.x series was more or less frozen in terms of new features because so muchwas changing for 2.0 tht any new feature would likely have to be implemented twice in order to appear in both 1.x and 2.x.
So again, the was implemented and remains implemented - for 2.0.
In reply to No, the nightly builds from by Marc Sabatella
I was thinking that nightly was just one release ahead. I don't really understand "the trunk".
So is there some timeline when 2.0 should be released? I tryed nightly but got two crashes in short time but can't reproduce it. the 1.2 doesn't crash for now.
One crash happen when redirecting (assigning) MIDI keys (in setup). (in nightly)
In reply to I was thinking that nightly by eslavko
Hopefully it's not out of line for me to try to summarize the situation:
Think of the release history of any software project as being like a tree, where the trunk represents the code that is added that is intended to be forever part of all subsequent release *once there is a release that incorporates that code at all*, and branches representing improvements made to earlier releases that do not include the code that was added to the trunk after that earlier release. Often, major new features are added to the trunk but then it is decided to have "minor" releases based on previous stable releases just for bug fixes and what not before any release based on the trunk ever happens.
This was, as far as I know, the story with MuseScore. At some point around the 0.96 release (not being part of the development team, and also a relative newcomer to the project, I'm somewhat fuzzy on details), it was realized that so much new and largely untested code had been added to the trunk, changing so many fundamental things about how things were structured, that it would be a long time before it would ever stabilize again to the point where there could be another release based on the trunk that would be as stable as 0.96. And yet 0.96 itself was already "almost" good enough to promote as the first "official" MuseScore release. So it was decided to create 1.0 as a branch from 0.96, not directly including any of the code that had been made to the trunk since the release of 0.96, but instead just fixing bugs that were in 0.96 and maybe reimplementing a few features here and there (taking the code from the trunk, duplicating it on the branch, and tweaking it as necessary to work without all the rest of the new code on the trunk).
In hindsight, that seems to have been exactly the right choice, because indeed, two years later, the trunk is *still* nowhwere near stable enough for release. So the 1.X branch - 1.0, 1.1, and the current release 1.2 - has served very well to provide an increasingly stable platform for real world use while still allowing the development team to throw new code onto the trunk without worrying too much about stability yet. So while 1.0 was an only incremental improvement over 0.96, and 1.1 only an increment improvement over 1.0, and 1.2 over 1.1, 2.0 will be a *huge* advance, as it is where most of the development for the past two years has been focused.
As for timeline, what we keep hearing is that they are aiming for an alpha and/or beta around the end of the year, with the actual release presumably coming a few months after that. Over the past couple of months, I have noticed the nightlies become more and more stable/usable.
In reply to Hopefully it's not out of by Marc Sabatella
Thanks for that explanation.
I tryed nightly but it's unstable for me as user.
In reply to Thanks for that by eslavko
Have you tried a recent nightly?
I find them stable enough to produce music for our church hymnsheet every week, and I recently entered the Buxtehude Ciacona in E minor as a means of testing its capablities.
Sure there are still bugs, but you get to know what will make it crash, and avoid those actions, having first submitted and error report.
In reply to Have you tried a recent by ChurchOrganist
The latest nightly had problem with that.
I try it right now but doesn't work as I expect. And as I see there is more issues opened on that subject.
For example what I do and what I expect.
I create new part with C flute and Bb trumpet.
In concert pitch I drag one (b) to flute (F major)
The trumpet got one (b) too (F major)
So far so god.
Now I uncheck concert pitch and trumpet got one (#) G-major
So far so god.
Now If I change Key in trumpet to F major (one b) the flute got F major too and that's wrong. It should be tree (b) Eb major!
seems that work correctly only when is in Concert pitch.
In reply to The latest nightly had by eslavko
That's worth submitting as an issue, or at least starting a new thread on.
In reply to That's worth submitting as an by Marc Sabatella
Submitted as issue.