Finale says three ain't three

General notation questions, including advanced notation, formatting, etc., go here.

Moderators: Peter Thomsen, miker

Post Reply
User avatar
Jay Emmes
Posts: 227
Joined: Thu Dec 08, 2016 4:29 pm
Finale Version: 25.4.1.164
Operating System: Mac

Post by Jay Emmes » Mon Apr 26, 2021 5:24 pm

So, this is how Finale thinks a tuplet should be spaced:
screenshot_135.png
Note how the third eighth note (down bow) of the tuplet in the second, third and fourth staff are spaced even after the last sixteenth in the upper staff and thus way further than the same third eighth of the same tuplet in the lower three staves. And no, there is no manual displacement of notes or any other user's wrong doing — this is all Finale on its own, [Deity of your choice] knows why.
Running Finale 25.4.1.163 in OS X 10.11.6


User avatar
motet
Posts: 8229
Joined: Tue Dec 06, 2016 8:33 pm
Finale Version: 2014.5,2011,2005,27
Operating System: Windows

Post by motet » Mon Apr 26, 2021 6:10 pm

And you've selected the entire measure stack before applying spacing? If so, can you post a one-measure Finale file exhibiting the problem?

User avatar
Jay Emmes
Posts: 227
Joined: Thu Dec 08, 2016 4:29 pm
Finale Version: 25.4.1.164
Operating System: Mac

Post by Jay Emmes » Mon Apr 26, 2021 8:04 pm

Find attached the culprit measure.
I had checked and double checked everything, loaded different spacing libraries, respaced, removed possible accidental manual repositioning, you name it — all to no avail.

On triple check, I found the problem: the eighth rest inside the tuplet is in fact not an eighth rest, although it displays as one and should have been one, certainly was entered as one. In the 'Edit Frame' dialog, Finale shows that the eighth rest has a duration of 683 (?), which should be 512. Oddly enough, Finale doesn't consider the measure to have too many notes in it, as it should since the measure is 171 too long. But okay, it is known that Finale has a number of problems with tuplets. Apparently, this yet another one.

Problem found, but not solved. How can a tuplet of straight eighths have different durations for the eighths? I enter a tuplet in Speedy Entry by option-3, 4, 4, 4 (4 on the keypad bringing fourth an eighth).

So, in hindsight, the subject should read: "Finale says four ain't four". My bad.
Attachments
V copy.musx
(125.89 KiB) Downloaded 72 times
Running Finale 25.4.1.163 in OS X 10.11.6

User avatar
zuill
Posts: 4418
Joined: Sat Dec 10, 2016 9:35 pm
Finale Version: Finale 2011-v26.3.1
Operating System: Windows

Post by zuill » Mon Apr 26, 2021 10:23 pm

I followed your entry instructions and I get 3 8ths (512). So, I can't say how you got the odd number for the rest. I am using v26 in Windows, so maybe there's a bug in v25, or maybe in Mac but not Windows.

Zuill
Windows 10, Finale 2011-v26.3.1
"When all is said and done, more is said than done."

User avatar
Jay Emmes
Posts: 227
Joined: Thu Dec 08, 2016 4:29 pm
Finale Version: 25.4.1.164
Operating System: Mac

Post by Jay Emmes » Mon Apr 26, 2021 11:14 pm

In the document I attached, try this: add any note or rest at the end of the measure with the offending tuplet (either staff). When you stop editing that measure, Finale will tell you that there are too many notes in that measure. Tell Finale to delete the extra notes. Finale will turn the last note (tuplet eighth) into a sixteenth, but that is also wrong, because 512+683+256 doesn't add up to 1536, which it should be to have the measure have enough beats. A computer application that doesn't know how to compute; go figure.

I have encountered frequently that, when copying and pasting a measure with a tuplet at the end of the measure, Finale will screw up the copied tuplet by cutting the last note short. I now suspect that that was because Finale wrote incorrect lengths of notes in those tuplets to start with, which gave the incorrect note values when copied and pasted. Unfortunately, I do not remember exactly when and where this occurred; otherwise I would be able to verify my suspicion.

Yes, it may be a bug in only version 25 or the Mac version of Finale, but it's a nasty and sneaky one — not visible at first glance, but leading to all kinds of unwanted results.
Running Finale 25.4.1.163 in OS X 10.11.6

User avatar
zuill
Posts: 4418
Joined: Sat Dec 10, 2016 9:35 pm
Finale Version: Finale 2011-v26.3.1
Operating System: Windows

Post by zuill » Mon Apr 26, 2021 11:28 pm

Maybe a Mac user will have to test this. I can't seem to reproduce the bug. With Simple Entry, there is a similar bug that does changes with note values to unusual numbers, but I can't get that with Speedy.

Zuill
Windows 10, Finale 2011-v26.3.1
"When all is said and done, more is said than done."

User avatar
motet
Posts: 8229
Joined: Tue Dec 06, 2016 8:33 pm
Finale Version: 2014.5,2011,2005,27
Operating System: Windows

Post by motet » Tue Apr 27, 2021 1:14 am

You can't add those EDU (duration) numbers and get a meaningful number where they're in tuplets. Whether you have 3 eighth notes in the space of one quarter or 7, they will show up as 512 in the frame. The tuplet information is evidently elsewhere. Your eighth note of 683 is of course still wrong.

Are you sure you didn't enter these in Simple Entry, Jay? What you describe sure sounds like the Simple Entry bug that Zuill alludes to.

User avatar
zuill
Posts: 4418
Joined: Sat Dec 10, 2016 9:35 pm
Finale Version: Finale 2011-v26.3.1
Operating System: Windows

Post by zuill » Tue Apr 27, 2021 4:15 am

The warning of too many notes in the measure is only in Speedy Entry, so it's not Simple Entry.

Zuill
Windows 10, Finale 2011-v26.3.1
"When all is said and done, more is said than done."

User avatar
motet
Posts: 8229
Joined: Tue Dec 06, 2016 8:33 pm
Finale Version: 2014.5,2011,2005,27
Operating System: Windows

Post by motet » Tue Apr 27, 2021 4:34 am

Ah, right.

The rest in the middle of the triplet is wrong. It's a mystery how it got that way. I don't think there's anything to be learned from what Finale does after you tell it to delete the extra. In any case it's easy to fix: in Speedy entry, turn off "Insert notes or rests," put the cursor over the offending eighth rest, and press 4.
Last edited by motet on Tue Apr 27, 2021 4:40 am, edited 1 time in total.

User avatar
zuill
Posts: 4418
Joined: Sat Dec 10, 2016 9:35 pm
Finale Version: Finale 2011-v26.3.1
Operating System: Windows

Post by zuill » Tue Apr 27, 2021 4:39 am

I think we need much more information about how the corruption got there. As other staves were entered properly, I'm guessing there may be more to the picture than we are seeing. I even went to the original file, and can't get improper entry in Speedy. There's got to be more that we are not privy to.

Zuill

P.S.: If Quantization settings isn't set to minimize rests, then retranscribe will fix the rest.
Windows 10, Finale 2011-v26.3.1
"When all is said and done, more is said than done."

User avatar
zuill
Posts: 4418
Joined: Sat Dec 10, 2016 9:35 pm
Finale Version: Finale 2011-v26.3.1
Operating System: Windows

Post by zuill » Tue Apr 27, 2021 5:01 am

Another way to fix the 8th rest with the wrong value: In Speedy, when the cursor is on the rest, press the numberpad 4. That will reset it to an 8th rest with the proper value.

Zuill
Windows 10, Finale 2011-v26.3.1
"When all is said and done, more is said than done."

User avatar
Jay Emmes
Posts: 227
Joined: Thu Dec 08, 2016 4:29 pm
Finale Version: 25.4.1.164
Operating System: Mac

Post by Jay Emmes » Tue Apr 27, 2021 9:36 am

Actually, yes, the number of EVPU's in a tuplet like this should be 1536 (a total duration of three eighths), regardless of the subdivision of note values in that tuplet. A quarter and two 16ths, e.g., is 1024+256+256=1536. A dotted 16th followed by a 32nd, an 8th, a 64th, a dotted 32nd and a 16th is 384+128+512+64+192+256=1536. Since the tuplet consists of a total value of three eighths, it should always equal 3x512=1536; in fact, that the notes are in a tuplet has no impact on the EVPU value — an eighth remains an eighth, after all.

I never use Simple Entry, only Speedy.

I corrected the value of the eighth rest in the 'Edit Frame' dialog (in Speedy Entry option-click the measure).
I'm not a mathematician, but how does one even get a value of 683? There is no note of whatever value that equals 683 EVPU.

Yes, the 4-key of the number pad gives an eighth note/rest in Speedy Entry — that's how I entered the tuplet (option-3, 4, 4, 4), but somehow Finale understood the second four I struck as some undefinable other value (683 instead of 512) than the other two fours.

I know this problem can be corrected and I did. My issue is that Finale cannot be trusted. I enter a value of 512 and Finale notates 683. Suppose the 683 value is somehow caused by th user, even then Finale should find any measure that has too many beats in it (Plug-ins>Note, Beam and Rest Editing>Check Region for Durations…), but it doesn't.
I'm not happy with an application is not capable of adding up numbers correctly, or that collides elements when you tell it no to.
Running Finale 25.4.1.163 in OS X 10.11.6

bkshepard
Posts: 118
Joined: Tue Dec 27, 2016 6:48 pm
Finale Version: Finale 25.5, 26.2
Operating System: Mac

Post by bkshepard » Tue Apr 27, 2021 4:07 pm

Doesn't a quarter triplet equal 683 (actually 682.66667)? It's durational amount is 2/3 of a regular quarter note.

User avatar
motet
Posts: 8229
Joined: Tue Dec 06, 2016 8:33 pm
Finale Version: 2014.5,2011,2005,27
Operating System: Windows

Post by motet » Tue Apr 27, 2021 4:52 pm

Yes, but I don't think Finale ever intentionally stores such a value in the frame. But maybe that's a hint where the problem came from!

User avatar
zuill
Posts: 4418
Joined: Sat Dec 10, 2016 9:35 pm
Finale Version: Finale 2011-v26.3.1
Operating System: Windows

Post by zuill » Tue Apr 27, 2021 5:28 pm

Regarding values, you can change the value of that middle rest of the triplet all the way up to 1023 without Finale considering the measure overfilled. Once you hit 1024 (quarter), it is now officially overfilled. Odd what the values really do, or how they affect the measure overall.

The 683 value does give some insight into Finale's math calculations. There must be a connection with how the code is put together, but might be beyond the scope of the programmers. However, giving this information to the programmers might give them a clue that maybe they haven't considered before. One never knows. Maybe someone should report this?

Zuill
Windows 10, Finale 2011-v26.3.1
"When all is said and done, more is said than done."

User avatar
zuill
Posts: 4418
Joined: Sat Dec 10, 2016 9:35 pm
Finale Version: Finale 2011-v26.3.1
Operating System: Windows

Post by zuill » Tue Apr 27, 2021 7:21 pm

I've not seen this kind of bad behavior in Speedy, but I suppose we should try to find out how to duplicate the bad result so we can test things further.

Question: was this with MIDI keyboard input?

Zuill

P.S.: Maybe, as I speculated earlier, that this misbehavior is Mac only, so I am probably not going to see it on Windows.
Windows 10, Finale 2011-v26.3.1
"When all is said and done, more is said than done."

User avatar
Jay Emmes
Posts: 227
Joined: Thu Dec 08, 2016 4:29 pm
Finale Version: 25.4.1.164
Operating System: Mac

Post by Jay Emmes » Tue Apr 27, 2021 7:36 pm

My input is with Speedy Entry, using the number pad of my computer keyboard for note duration and a MIDI keyboard for pitch. Same procedure for the 1st violin parts as for the 2nd violin and violoncello parts, different results in Finale.
Running Finale 25.4.1.163 in OS X 10.11.6

User avatar
zuill
Posts: 4418
Joined: Sat Dec 10, 2016 9:35 pm
Finale Version: Finale 2011-v26.3.1
Operating System: Windows

Post by zuill » Tue Apr 27, 2021 7:44 pm

Observation: the three misbehaving staves all have a dotted half note tied to an 8th note that starts the triplet. The staves without the misbehavior are triplets starting with an 8th rest. Possibly a connection. Maybe not. [Edit: the cellos were from a tied note, so somehow those staves ended up okay.]

Also, I'm using v26. Maybe this is a behavior that was fixed in v26, but with MakeMusic's track record, I doubt it.

Zuill
Windows 10, Finale 2011-v26.3.1
"When all is said and done, more is said than done."

User avatar
motet
Posts: 8229
Joined: Tue Dec 06, 2016 8:33 pm
Finale Version: 2014.5,2011,2005,27
Operating System: Windows

Post by motet » Tue Apr 27, 2021 10:19 pm

I'm on 2014.5, Speedy with a MIDI keyboard, and have never had a problem. So if it were a general problem, it would have to be V25 only.

User avatar
motet
Posts: 8229
Joined: Tue Dec 06, 2016 8:33 pm
Finale Version: 2014.5,2011,2005,27
Operating System: Windows

Post by motet » Wed Apr 28, 2021 6:04 am

zuill wrote:
Tue Apr 27, 2021 5:01 am
Another way to fix the 8th rest with the wrong value: In Speedy, when the cursor is on the rest, press the numberpad 4. That will reset it to an 8th rest with the proper value.

Zuill
"Insert Notes or Rests" unchecked (toggled with the Windows Insert key), right? The 4 on the top row of the keyboard works as well.

User avatar
zuill
Posts: 4418
Joined: Sat Dec 10, 2016 9:35 pm
Finale Version: Finale 2011-v26.3.1
Operating System: Windows

Post by zuill » Wed Apr 28, 2021 2:45 pm

Correct. With Simple Entry, Alt+Numpad or Alt+QWERTY numbers will also change the errant 8th rest to a correct 8th rest.

Zuill
Windows 10, Finale 2011-v26.3.1
"When all is said and done, more is said than done."

Post Reply