Finale says three ain't three
Moderators: Peter Thomsen, miker
- Jay Emmes
- Posts: 227
- Joined: Thu Dec 08, 2016 4:29 pm
- Finale Version: 25.4.1.164
- Operating System: Mac
So, this is how Finale thinks a tuplet should be spaced:
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.
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
- Jay Emmes
- Posts: 227
- Joined: Thu Dec 08, 2016 4:29 pm
- Finale Version: 25.4.1.164
- Operating System: Mac
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.
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
- zuill
- Posts: 4418
- Joined: Sat Dec 10, 2016 9:35 pm
- Finale Version: Finale 2011-v26.3.1
- Operating System: Windows
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
Zuill
Windows 10, Finale 2011-v26.3.1
"When all is said and done, more is said than done."
"When all is said and done, more is said than done."
- Jay Emmes
- Posts: 227
- Joined: Thu Dec 08, 2016 4:29 pm
- Finale Version: 25.4.1.164
- Operating System: Mac
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.
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
- zuill
- Posts: 4418
- Joined: Sat Dec 10, 2016 9:35 pm
- Finale Version: Finale 2011-v26.3.1
- Operating System: Windows
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
Zuill
Windows 10, Finale 2011-v26.3.1
"When all is said and done, more is said than done."
"When all is said and done, more is said than done."
- motet
- Posts: 8229
- Joined: Tue Dec 06, 2016 8:33 pm
- Finale Version: 2014.5,2011,2005,27
- Operating System: Windows
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.
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.
- motet
- Posts: 8229
- Joined: Tue Dec 06, 2016 8:33 pm
- Finale Version: 2014.5,2011,2005,27
- Operating System: Windows
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.
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.
- zuill
- Posts: 4418
- Joined: Sat Dec 10, 2016 9:35 pm
- Finale Version: Finale 2011-v26.3.1
- Operating System: Windows
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.
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."
"When all is said and done, more is said than done."
- zuill
- Posts: 4418
- Joined: Sat Dec 10, 2016 9:35 pm
- Finale Version: Finale 2011-v26.3.1
- Operating System: Windows
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
Zuill
Windows 10, Finale 2011-v26.3.1
"When all is said and done, more is said than done."
"When all is said and done, more is said than done."
- Jay Emmes
- Posts: 227
- Joined: Thu Dec 08, 2016 4:29 pm
- Finale Version: 25.4.1.164
- Operating System: Mac
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.
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
- zuill
- Posts: 4418
- Joined: Sat Dec 10, 2016 9:35 pm
- Finale Version: Finale 2011-v26.3.1
- Operating System: Windows
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
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."
"When all is said and done, more is said than done."
- zuill
- Posts: 4418
- Joined: Sat Dec 10, 2016 9:35 pm
- Finale Version: Finale 2011-v26.3.1
- Operating System: Windows
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.
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."
"When all is said and done, more is said than done."
- Jay Emmes
- Posts: 227
- Joined: Thu Dec 08, 2016 4:29 pm
- Finale Version: 25.4.1.164
- Operating System: Mac
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
- zuill
- Posts: 4418
- Joined: Sat Dec 10, 2016 9:35 pm
- Finale Version: Finale 2011-v26.3.1
- Operating System: Windows
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
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."
"When all is said and done, more is said than done."
- zuill
- Posts: 4418
- Joined: Sat Dec 10, 2016 9:35 pm
- Finale Version: Finale 2011-v26.3.1
- Operating System: Windows
Correct. With Simple Entry, Alt+Numpad or Alt+QWERTY numbers will also change the errant 8th rest to a correct 8th rest.
Zuill
Zuill
Windows 10, Finale 2011-v26.3.1
"When all is said and done, more is said than done."
"When all is said and done, more is said than done."