Orange stems?

[gogreen]

I've recently edited a part in a brass quintet, and that measure's note stems turned orange in both the score and part. All I did in the measure was add a courtesy accidental. Nothing else is affected--neither printing nor playback. Why the orange stems? Is that telling me that something in the measure is unlinked? Does it have anything to do with stem length? And how do I change the stems back to black?

[johnmouse]

You might want to post it so we can see it. Without seeing it, I'm guessing "out of range notes."

[motet]

A note will turn orange for instance if you make an enharmonic change in the part but not the score, and I'm guessing the orange stems likewise reflect a difference between score and part, but I couldn't say why adding a courtesy accidental would cause that. If the stems got flipped somehow, that would do it.

[michelp]

I also noticed those numerous orange stems (noteheads, beams and flags are still black), even on notes which were not touched at first sight. I am certain I didn't do anything to the stems. On screen, it is very unpleasant.
The notes are definitely not "out of range".
I also would like to see them in black again...
Here is a screenshot :

orange_stems.png (21.44 KiB) Viewed 17383 times

[motet]

What does the part look like in that measure?

[michelp]

Identical.

[motet]

If I go to a part, flip the stems and flip back, they turn orange and stay orange. Could you have possibly done that? Doesn't HP sometimes temporarily flip stems when it puts stuff in other layers?

[michelp]

I had no reason to flip the stems, they were correct, all of them.
I almost never use HP, and 1 layer is used.
I just made a test in a part. Speedy entry. I click on the measure (cursor appears on beat 1, and I don't touch anything), and immediately all the stems on beat 4 change to orange, part and score.

ex.png (5.7 KiB) Viewed 17335 times

It seems that just clicking in Speedy causes the problem, but it is not systematically the case, which is strange !

[Peter Thomsen]

Stem alterations can be different between score and linked parts.
You can e. g. flip the stem direction in a linked part, and the stem direction will stay the same in the score.
Finale will show this difference between score and part, by coloring the stem.

However, the coloring does not always happen immediately, as you have found out.
Activating the Speedy Entry rectangle can make Finale update the stem coloring.

[michelp]

Thank you, Peter, but I still don't get it because I have not flipped any of those stems, as there was no reason to do it, they were ok and Finale's default stem direction.
P.S.: I have submitted the problem to MM support.

[gogreen]

Here's the measure in question. Only the stems are affected, in both the score and part, and playback is OK. Activating the Speedy Entry rectangle on the measure doesn't change the stem color.

[Peter Thomsen]

Seeing a graphic (screen shot) does not help much in finding the culprit.

Could someone attach a (small) Finale sample document with the problem?

[michelp]

Here is an example (excerpt) :
Ten sax 1 and 2 : in their parts, Speedy, simply click on the third measure (don't make any edits), and all the stems turn to orange.

test_stems.musx

(216.31 KiB) Downloaded 216 times

(Finale 25.3)

[N Grossingink]

Here is an example (excerpt)

I see the behavior you describe. It does not happen with Finale 2014.5, so I guess this is something new and a bug.

By the way, I work with the unlinked highlighting turned off in Preferences. Don't see the need to use it as part of my workflow.

N.

[motet]

As Peter says, the altered stems are already there, and it's yet another Finale bug that's delaying their display until you trigger it with Speedy.

Michel, do you work in concert pitch, perchance? Switching back and forth could result in stem-flipping. Just a thought.

[motet]

I certainly want to see the unlinked highlighting. If this is a new bug in V25, that's yet another reason not to upgrade.

[michelp]

Michel, do you work in concert pitch, perchance? Switching back and forth could result in stem-flipping. Just a thought.

Yes, but I don't change much (enharmonies, not stems) and no back and forth switching, just working on the transposed parts at the end.
It is hard to imagine that the transposed parts would create broken links each time Finale simply applies the conventions in terms of stem direction ! Broken links are not automatic, they seem to require some user action, AFAIK.
I have submitted a case to MM support, I'll report back.

P.S. : I also confirm what you have found out. The same file behaves differently in 2014.5. The stems which were orange remain orange, but I cannot "create" new ones with the Speedy click on measure 3 of the ten sax parts.

[motet]

Unless you can reproduce it, I don't expect them to do anything.

You'll notice that the stems which are orange are those and only those which change direction between transposed and concert view, so I'm sticking to my theory that it's related to that. I re-entered some of your alto sax music in concert pitch in subsequent measures, though, and it didn't immediately happen, so something else must need to go along with it to trigger it. But I don't have V25, so it might be a new bug, or perhaps something they consider a feature.

Let us know what they say.

[michelp]

I have sent them my test file (.musx) so they can reproduce the problem.
In measure 2, the alto sax 2 changes stem direction going from concert to transposed without getting orange stems.
In measure 3, the orange stem is back. So there is something else at play here.

[motet]

As Peter pointed out, in your test file, the problem has already occurred. It's just that a bug prevents the stems from showing orange until Speedy makes them redisplay.

So there is something else at play here.

Not all stems which flip as the result of transposition turn orange, but all those that are orange have flipped as the result of transposition. So something in addition needs to uccur, but I think it's related to this.

[michelp]

I have received a reply from MM. They could reproduce the problem in my file. In short, the cause would be that my document is derived from a template created in an older version of Finale. That's a familiar answer, I have heard it before. They suggest exporting/reimporting via MusicXML...etc...

"Over time documents can experience some degradation that can cause unexpected behavior like this. When this happens, the document needs to go through the XML process which does sort of a digital cleaning of it and restores it.
...in the newly created file, you may find that you need to make some changes and remake some edits. Two things you normally have to do is regenerate parts, and reassign playback sounds."

Once more, the theoretical compatibility of older files is not a 100 % reality; they acknowledge "some degradation" !
Would you imagine something like this with text documents ?
Besides, having to recreate my numerous templates and libraries for each new version is a time-consuming task. IMHO, we are touching here a weakness of our beloved program.

[BuonTempi]

You should never assume that any old complex document format from years ago will be displayed without error. There are plenty of professional apps that cannot open documents from their considerably older forebears without some "conversion" process to the current document model and the possibility of elements moving about or going wrong. This is true of Illustrator, Quark XPress, InDesign, and many others.

I doubt there is any bit-rot -- the data is not rusting away on the disk; but rather every time a new version of Finale opened an older .mus file, it had to convert it to the new document model. This is of course why the .musx format was created: to address the shortcomings of the .mus format. If problems are still occurring in files created since .musx was implemented, then that's more worrying.

And indeed, if other people can replicate the same problem, then that pretty much rules out document corruption.

[motet]

I am skeptical that it has to do with older versions, but I guess we'll see.

[michelp]

Sharing my experience : a remark concerning the suggestion by MM to export the problematic file to MusicXML et importing it :

The imported file lacks many things which were included in the original :
• My own libraries are absent (chord suffixes, expressions, staff styles etc...).
• Staves with zero line now have 5
• Some text blocks are missing, such as titles, some text inserts (Date, Hour...)
• Default rests are now selected. Not what I had in the original.
• All the metatools have to be recreated for each library (not a surprise)
• Page sizes are lost in Page Format
• Parts have to be redone
• Sounds have to be redefined in the ScoreManager
• etc...(probably more to be discovered)
Conclusion : the MusciXML procedure requires a huge amount of work to get a file identical to the original file.

Creating a new template from scratch probably takes just a bit more time, but that's what I eventually did.

[gogreen]

I am skeptical that it has to do with older versions, but I guess we'll see.

I sent my file to MM, and they told me the same thing--export to XML and import. The also blamed the problem on having created the document in an older version of Finale. In my case, I had originally created the file in Finale 2007, and through upgrades to Finale 2011 and 2014, the file arrived in Finale 25.3.

That said, as michelp explained, xml leaves a lot out of the import. I can live with orange stems in one measure (so far) of this file--a pretty large file, actually.

I went through my most-used templates, which I had doctored from previous versions, and did the xml export-import, and I'll make other adjustments from there. Those templates are at least now up to date. It's a bit easier this way to work with an empty template. I had saved my loaded Aria banks, so I reloaded them into the templates. At least that part was easy.

MM needs to make conversion from older files easier.