Bug with Concert key and transposing instruments in Version 1.3 on Mac?

• Mar 27, 2013 - 17:22

I think I've run into a bug that's been talked about in other places on the forums and was thought to be fixed.

I've attached a score that demonstrates the problem. I'll try and summarize it here.

I'm using the Jazz Combo template with the Trombone and Guitar removed, a Baritone Saxophone added, and the clef of the Tenor Sax and Baritone Sax changed to bass clef. See screen shot #1. I set the key signature of the piece to be Bb concert (as reflected in the screen shot). In measure 4, I have a key change to F concert (also in the screen shot). Everything looks OK now.

However, now I click the "Concert Pitch" button to turn off "Concert Pitch", and I get the results seen in shot #2. I believe that the Trumpet and Tenor keys should be C in the first measure, but they are in D. The Alto and Bari should be in G but are in A. Bar 4 is correct with Trumpet and Tenor in G, and Alto and Bari in D.

Now, if I toggle the "Concert Pitch" button again, things go back to the way they should be, but then when I toggle it again to non-concert pitch, NOW all key signatures are correct.

But, then one more time to toggle the "Concert Pitch" back on, and I see what's in shot #3... The key for the Trumpet and Tenor has changed to Ab Concert, and Alto and Bari have changed to Db concert!!!

I've included the score that's showing this behavior. It only seems to happen if there's a key change some time during the tune, which as it happens is the case in a score that I'm working on right now... it's very frustrating.

Other than this issue, my time with MuseScore has been fantastic. Keep up the great work!

Please let me know if I can provide any more information.

- Mike.

Attachment Size
Bad_Transposition.mscz 3.77 KB
Capture01.png 35.63 KB
Capture02.png 33.54 KB
Capture03.png 34.64 KB

Comments

• Mar 27, 2013 - 17:28

3 things:

1) The bug shows itself on extracted parts from the above score
2) It shows up with a score with the Jazz Combo template and no modifications made to the instrument list.
3) it also shows up if I make a new single instrument part with a transposing instrument like the Tenor Saxophone.

Am I just making some sort of fundamental mistake in my settings? Or is this really a bug?

Again, please let me know if there's anything else I can do to help solve this. I'm a software developer myself, so I have an idea of how hard it can be to track things down when you don't have enough data :-)

- Mike.

Reply

• Mar 27, 2013 - 17:57

Do you still see the problem if you download the score you posted and open that? I don't. I can toggle Concert Pitch on your score all day long and it keeps going back and forth correctly (trumpet & tenor with concert pitch off goes from C to G, alto & bari go from G to D; all staves with concert pitch on go Bb to F)

I have temporary glitches with transposition and key signatures if you try changing key signatures while concert pitch is off, and they always go upon reloading the score. So perhaps that is what you are seeing? Could list the exact steps you follow, starting from the very beginning when you create the score (what key signature you give it)? And does the problem persist after saving and reloading?

Reply

• Mar 27, 2013 - 20:38

Hi Marc.

Thanks for getting back to me so quickly.

Yes, i still see the problem when I download the score I posted.

I ran across this problem when I was working on a score in concert pitch. I didn't change the key when not in concert pitch. I worked in concert pitch... saved the score several times... when I was finally done, I did a part extraction and then switched to non-concert pitch to print out the parts. That's when I noticed the bad behavior.

In this case, the steps in the simplest case are:

1) Create a new score
2) Give it a title, click Next
3) Choose "From Scratch", click Next
4) Add a Tenor Sax, click Next
5) Choose the key of Bb (2 flats), click Next
6) Enter number of Measures as 8, click Finish
7) Click into Concert Pitch
8) Open the Key Sigatures palette and drag the one flat (key of F) to the 4th measure
9) Toggle back and forth out of Concert Pitch, and back into Concert Pitch a few times and see that the key signatures (either in Concert Pitch, or not) get really messed up. After several toggles back and forth, and finally landing in Concert Pitch, my keys are now Gb (incorrect) in measure one, and F (correct) in measure 4, and then clicking out of Concert Pitch, measure one is in Bb (correct), and measure 4 is in G (correct)

Does that help at all?

Thanks again.

- Mike.

Reply

• Mar 27, 2013 - 21:45

Your description is clear as a bell. I just can't reproduce. Followed your instructions to the lette,r but even after 100 toggles of the concert pitch button, the key signatures never misbehaved. This is 1.3 on Windows. So I am think it's either something that has gone wrong on your particular system (like maybe you somehow replaced instruments.xml with something thatdefines a strange transposition for tenor sax, unlikely as I realize that sounds) or the bug is Mac specific.

Any other Mac users able to reproduce this?

Also - have you tried it with a nightly build? Does it work there?

Reply

• Mar 28, 2013 - 12:34

I just tried the nightly build and it won't even launch. It comes up with the splash screen and then crashes. I've attached the crash report to this comment.

Here's some more info from some more playing around with the 1.3 release.

First the good news... if I don't have a key change in the middle of the tune, everything works exactly as expected. I can toggle "Concert Pitch" as many times as I want without any issues.

Now the bad news...

I made the same tenor sax part with 8 measures... the first 4 in Bb and the last 4 in F while in Concert Pitch.

I then transposed the whole thing from the Notes:Transpose menu up a whole step (leaving the "Concert Pitch" on). Everything looked fine (the first 4 bars in C, the last 4 in G). Then I did the same thing in reverse, transposing down a whole step expecting the first 4 bars to be in Bb and the last 4 in F. No such luck. I get the first 4 in Ab, and the last 4 in F. Very strange.

Now, I go back to the Transpose dialog box, and it shows the current key of my piece to be in Ab (at least this matches what I see on the screen)! If I transpose down a whole step to try and get the piece back to its original key of Bb, I end up with the first 4 bars correct at Bb, but now the last 4 are in G!

This all makes sense to me as a software developer myself. Since I imagine that the "Concert Pitch" toggle is implemented with the same code as the Transpose dialog, I'd expect the same behavior whether I'm toggling, or going through the dialog. Actually, thinking about it, maybe this is all good news because it does help isolate the problem to a specific piece of code?? Maybe??? And maybe there's a #ifdef MAC_OSX or something in that code??? Maybe?? Please?? :-)

- Mike.

Attachment Size
musescore_crash.txt 54.13 KB

Reply

• Mar 28, 2013 - 14:39

The same thing happens with non-transposing instruments when transposing by hand. That is:

1) Create a new score
2) Choose piano
3) set the key signature to Bb
4) Choose 8 bars for the length

At this point if I transpose up or down and back again, everything is fine. If, however:

5) Change the key signature of the 4th bar to F

Now, if I transpose up or down, the key signatures get completely hosed.

So, it seems to be specific to transpositions of scores with changes of key, and has nothing to do in particular with transposing instruments like the tenor sax.

I hope that helps.

I've download the source code and am having a look. I'm hoping to spot something obvious, but I doubt it :-/

- Mike.

Reply

• Mar 28, 2013 - 18:15

I downloaded the sources to my mac and tried to build musescore so I could try and debug this problem. The build failed with:

CMake Error at /opt/local/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:97 (message):
Could NOT find Qt4 (missing: QT_QMAKE_EXECUTABLE QT_MOC_EXECUTABLE
QT_RCC_EXECUTABLE QT_INCLUDE_DIR QT_LIBRARY_DIR QT_QTCORE_INCLUDE_DIR
QT_QTCORE_LIBRARY QT_QTGUI_INCLUDE_DIR QT_QTGUI_LIBRARY
QT_QTXML_INCLUDE_DIR QT_QTXML_LIBRARY QT_QTSVG_INCLUDE_DIR QT_QTSVG_LIBRARY
QT_QTNETWORK_INCLUDE_DIR QT_QTNETWORK_LIBRARY QT_QTWEBKIT_INCLUDE_DIR
QT_QTWEBKIT_LIBRARY QT_QTDECLARATIVE_INCLUDE_DIR QT_QTDECLARATIVE_LIBRARY
QT_UIC_EXECUTABLE) (Required is at least version "4.8")
Call Stack (most recent call first):
/opt/local/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:291 (_FPHSA_FAILURE_MESSAGE)
/opt/local/share/cmake-2.8/Modules/FindQt4.cmake:1225 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:142 (find_package)

I guess my machine isn't set up properly.

Should the build process use some sort of dependency management to go out and grab everything it needs to build? Kind of like Maven (for Java)? I don't know if such a beast is available.

Also, the musescore.xcodeproj doesn't seem to be in the git source tree.

I'll keep digging to see if I can find something in the code.

Is it possible that it's some sort of code optimization setting on the Mac?

- Mike

Reply

• Mar 28, 2013 - 18:38

Sure would be nice to hear from someone else with a Mac to confirm this really is something that affects all Mac users and not something more unique to your system. It seems odd that this wouldn't have been seen and reported by many others by now if it were that pervasive, so I'm still a little skeptical. But if it it's mot a somple matter of PC versus Mac, then it would also be nice to hear from other Windows & Linux users to see if it happens for anyone else at all. Did you ever try this with 1.2? Desn't really seem like anything on the list of things fixed for 1.3 should have affected this.

Reply

• Apr 3, 2013 - 00:14

I am using a mac, and I was able to reproduce the bug, with slight variations.
The first toggle of Concert pitch shows the trumpet and tenor in D and the other Saxes in E.
Going back to concert pitch is fine.
Toggling concert pitch again produces the correct transposition.
Toggle it again, the trumpet and tenor are in A flat, and the Alto and bari are in D flat.
Toggle it again, all the instruments are in b flat, despite concert pitch being off.
Toggle it again, Trumpet and tenor are in G flat, and alto and bari are in E.
Toggle it again, all the instruments are in b flat, despite concert pitch being off.
Toggle it again, the trumpet and tenor are in A flat, and the Alto and bari are in D flat.
Toggle it again, and the transpositions are correct.
This continues changing keys, eventually looping.
Suffice to say, this bug does happen.

Reply

• Apr 3, 2013 - 17:46

Thanks for giving this a try. That sounds just like what I was experiencing.

FWIW: As a developer, this has the feel of something like a global state variable (static member variable?) retaining its value at the end of the transposition and not getting reset to the initial state before the next transposition is run.

- Mike.

Reply

• Apr 5, 2013 - 16:11

Hello.

So, I think we've established that on at least 3 macs (2 of mine, and another from Rocketman44) that this is indeed a bug on the Mac version.

Is anyone taking a look at fixing this and providing a point release in the 1.3 branch? Or am I going to have to wait until 2.0? Should I file a bug report?

What can I do to help debug the problem? I'm still trying to build it on my desktop to see if I can figure out exactly what's going on.

Anyway... what are the next steps and how can I help?

Thanks.

- Mike.

Reply

• Apr 5, 2013 - 16:27

I can build the app and get it running, but the display is all wonky. It looks as though it's missing some display fonts. Also, I think this is source for the 2.0 release, and it appears as though (from what I can tell from the wonky display) the problem does not present itself.

For what it's worth...

- Mike.

Reply

• Apr 5, 2013 - 16:30

How dow I get the source code for v1.3? I've looked at github and there doesn't appear to be a branch or tag that I can pull from. Was the source stored someplace else before v2.0?

Thanks.

Reply

• Apr 5, 2013 - 17:18

Still baffles me that this has apparently existed since 1.2 at least and not been reported until now, at least not as such a simple reproducible case. Doesn't bode well for chances of an official fix before 2.0, I'd say. But the idea of you building and fixing it yourself - that's the beauty of open source. And who knows, if you provide the fix, maybe you'd be able to convince someone to offer a 1.3.1 despite the oft-repeated statememt that there will be no more release on that branch.

I don't know much about the development process, but I do know that sources *did* live elsewhere in the past - on sourceforge, managed with SVN. I'm sure someone else willl be able to confirm or correct me, but I believe this is what you want:

http://sourceforge.net/p/mscore/code/5708/tree/tags/mscore-1-3/

I have no idea how feasible it is to construct the necessary build environment for this, but I suspect there are others here who have one set up and might be able to walk you through it.

Good luck!

Reply

• Apr 10, 2013 - 15:02

Just following up...

I have been unsuccessful getting version 1.3 to build and run such that I can debug it. I'm running into problems getting QtGui to be found (I've checked and rechecked the version that I have installed to ensure compatibility with 1.3).

I'm wondering if there's anything else I can contribute to getting this solved? I'd really like to be able to put key changes in scores and have them extract the parts correctly and/or transpose parts correctly.

I'd also like to ensure that whatever this bug is doesn't make it into v2.0, but the latest nightlies of 2.0 won't start on my machine so I'm unable to validate them.

Lasconic... is there anything I can do to help out here?

- Mike

Reply

• Apr 10, 2013 - 15:32

Trying to help where I can...

I verified that ALL released versions of MuseScore for the mac (from 0.9.5 through 1.3) exhibit the same behavior. This is nothing that was introduced recently.

So... is there a temporary "global" (either globally scoped or statically scoped within a file or class) that is used for intermediate results whose value is not reset at the end of a transpose operation (the behavior of memory initialization could be different on different platforms)?

OR... is MuseScore a multi threaded application with a race condition updating such a variable? (different threads win the race on different platforms)? (EDIT: nevermind... I see pthreads all over the place... duh. So this is definitely a possibility?).

I know... I know... grasping at straws... just trying to help :-)

- Mike.

Reply

• Apr 10, 2013 - 18:30

Hello Lasconic, and thanks for getting back to me.

I've seen this behavior on 10.7.5, and on older versions of MuseScore (1.2) on OSX 10.6.8, and event 10.5 on 3 different Macs.

The simplest way to reproduce this error is by opening the score on a Mac that I've attached to this comment. The score is VERY simple: 1 instrument (violin), 2 bars. The key signature of the tune is "Bb", with a key change in the second bar to "F".

Make sure that nothing is selected and then:

- choose Notes:Transpose
- Answer "Yes" to "Transpose the whole score?"
- Choose Transpose by Interval
- Choose "Up" and "Major Second"

Now, after this is done, the key of the tune should be "C", with the key in the second bar "G". What I get is the key in the first bar is "D", and the second is "G".

If I reverse the process (transposing down a major second), I get the original keys restored (Bb and F).
If I transpose up a major 2nd again, I get the correct new key signatures of C and G.
If I transpose down a major 2nd again, I don't get the original keys of Bb and F like I should, but rather Ab and F.
If I transpose up a major 2nd again, I get C and G
Down a major 2nd, I get Bb and F
... etc.

From what Marc said above, this only seems to be an issue on the Mac.

- It is only an issue on scores that have a key change... if the whole score is in one key, all of those transpositions above behave as expected, toggling between Bb and C (for instance).
- I first notice this when I had a score with a key change and transposing instruments (for instance Tenor sax) and toggling "Concert Pitch". As I've shown with the attached score, transposing instruments are irrelevant... the problem is somewhere in the core transposition code which is used both by the Transpose dialogue and the "Concert Pitch" toggle.

I believe that these symptoms indicate some sort of state not being re-initialized at the start of a transposition operation.

Would you like me to try anything and report back results? I wish I could get it to compile so I could debug it for you, but I haven't been successful with that effort yet.

I just tried something that I thought might be a workaround, but it actually made things worse. See the "test02" score attached to this comment. It is 3 bars, 1 non-tansposing instrument (violin), with the first bar in Bb, the second in F, and the third back to Bb (restoring the original key). Transposing up a major second gives me C, A, D!

Let me know if there's anything I can try.

Thanks again for getting back to me.

- Mike

Attachment Size
test01.mscz 1.55 KB
test02.mscz 1.57 KB

Reply

• Apr 10, 2013 - 19:19

test01.mscz
On Windows, using MuseScore 1.3

  • choose Notes:Transpose
  • Answer "Yes" to "Transpose the whole score?"
  • Choose Transpose by Interval - make sure that "transpose key sigature is checked"
  • Choose "Up" and "Major Second"

I have "D" and "G". So I can reproduce the bug. It's not Mac related. Maybe Marc didn't follow the same steps. They are now more precise. What happens next is then of no interest... unfortunatly.. since it goes wrong from there.

More interesting, exactly the same steps, with current development version of MuseScore
4f5befc37d

I obtain C and G. So good.
Then I transpose a major second down. And I got Bb and F again. So good too.
Up again, C and G.
This bug seems to be fixed!

test02.mscz
MuseScore 1.3, Windows. I also obtain C,A,D. It confirms it's not only a Mac issue.
MuseScore 4f5befc37d I obtain C, G, C. Good again.

test03.mscz
You probably attached the wrong file. This file is C,A,E,A.

MuseScore nighlies for Mac only run on 10.7+. You shoud be able to run the last one available, if not, open a new discussion and attach your log file.
If you want to build and debug the current development version, you need Mac 10.7+ too and instructions are here : http://musescore.org/en/developers-handbook/compilation/compile-instruc…

Reply

• Apr 10, 2013 - 19:32

Well... from a developer point of view... that it's a repeatable bug on Windows too, and not some weird edge case on the Mac. I'll take a look at the diff between the 1.3 code base and the 2.0 code base and see if I can spot something obvious (doubtful, but I'll give it a go).

I followed the directions to build both the latest code and rel 1.3 on my mac and it fails on both. I'll try again though, and let you know exactly what the errors are.

I will open a new discussion for not being able to run the latest development release on my intel Mac with 10.7.5 installed. I just downloaded it and tried again. What log are you talking about? I'll attach it when I post the topic.

Is there any chance that we can get a point release out with a fix for this problem (assuming it's not a major issue)?

Thanks.

- Mike

Reply

• Apr 10, 2013 - 19:50

When MuseScore crashes, your mac should ask you if you want to see details of the crash and there is a log. You can also check a directory where the past crashlog are stored. See http://serato.com/scratchlive/support/6600/how-to-get-a-crash-log-in-ma…

We are really racing to release 2.0. Releasing 1.3 took more than 2 weeks of work. It's not just about fixing the bugs, build and upload the result on sourceforge. We need to write release notes, blog post, update social networks, pad files etc... So, no I wouldn't do a release on the 1.X branch for this bug. I would prefer to hunt bugs in the 2.0 branch.

Reply

• Apr 10, 2013 - 19:58

Fair enough. I look forward to the 2.0 release :-)

As far as the nightlies not launching correctly, it turns out that's not the problem... it's a particular score that I'm trying to load that's causing the problem. I'll see if I can simplify it down to the essence of what's causing the problem before I post the score. But the log is attached here.

Attachment Size
log.txt 67.52 KB

Reply

• Apr 10, 2013 - 19:52

I've done a quick diff between the branches and I notice that the code in libmscore/transpose.cpp for Score::transpose() (around line 224 in the rel1.3 branch) has been substantially modified. The code looks like it should not be too tough (from an admittedly non-informed viewpoint) to back port from the 2.0 branch, and I bet that one update would fix the problem. If I can get the 1.3 branch to compile, I'll give it a go myself. The changes that look to be incompatible seem to be around some constants that have been scoped by Element:: (such as Element::HARMONY and Element::NOTE) that weren't scoped before, and some features that weren't supported back in 1.3 such as FRET_DIAGRAM.

I'll let you know if I make any progress by posting here. If you make progress, perhaps you can do the same?

Reply

• Apr 10, 2013 - 19:48

You are correct that I didn't follow the same steps. I followed the steps in this earlier post, which involves the Concert Pitch button: http://musescore.org/en/node/20613#comment-76848.

However - and I don't know if this is good news or bad - I just tried it using the new file and new steps - transposition by major second - and I still don't see a problem on my system (stock MuseScore 1.3, Windows 7). I transposed up a major second, down major second, up, down, up, down, up, down, up, down - always with the transpose key signature option selected. At no time did the key signature do anything unexpected. Up changed them to C & G, down changed them back to Bb and F, every time.

I tried repeating this test with Concert Pitch on as well as with it off, no difference. i just couldn't get it to fail.

So it might not be Mac versus Windows, but it does seem to be dependent on *something*.

I'd be curious if anyone else can get the version to fail that I tested orginally, whee all one had to do was toggle Concert Pitch.

Marc

Reply

• Jun 7, 2014 - 16:02

I am also suffering from the same bug. Running MuseScore 1.3 on Mac OS 10.8.5
Any update or suggested work around ?

-SK

Reply

• Jul 11, 2014 - 14:02

I hesitate to call it a workaround because it doesn't avoid this problem at all, it just lets you get your score and parts printed correctly.

Remember, this *ONLY* happens when doing some sort of transposition of a piece of music that has a key change in it either by toggling the "Concert Pitch" button (which effectively transposes non-concert instruments), or actually transposing a score to a different key.

For what it's worth:

1) In your score, ONLY work in concert pitch mode if using transposing instruments (e.g. Tenor Sax), and make sure to start your work in the right key. While working, do NOT toggle the "Concert Pitch" setting.
2) When you are satisfied that everything is as you want it, create your individual parts
3) Open the individual parts, and if it's for a transposing instrument, click on the "Concert Pitch" toggle button EXACTLY ONCE and your part will be in the correct key for that instrument (if you click it more than once, you'll experience this problem and you may or may not get back to a stable key).
4) Print out the part.

- Mike (anxiously awaiting MuseScore 2.0 :-)

Reply

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