I appreciate the engagement and commitment. I know it’s not easy to even read all the threads.
And thank you everyone for your help. I will continue to work with the software and hopefully have some better feedback.
I do think there still is something buggy with the ties. I have reproduced this “error” several times with the following procedure:
-create new doc. start note entry and lock in a duration.
-enter the following keypresses: C, D, T, E, D, C
This produces this output:
Now, I tied the D “in error” and nothing happened when the program “saw” the next D. If I control-Z back, I can see the tie icon is still lighted from the second note, so it’s looking the connection (?) but no output.
Now, do the same thing with the following keypresses:
-C, D, T, C
Which produces this output:
Now, the C is tied back to the previous C. Furthermore, it cannot be untied with “U”. Instead, I have to scroll back to the D and untie that note, which is not involved in the tie in any way I can see from the user’s perspective. BUT… If I step out of note entry and into edit mode, I now most go back to the first C to Undo the tie. I cannot undo the tie from the second C, nor can I undo it from the D.
It seems to me that there is an inconsistency here. If this is intended behavior, I am having trouble understanding it from the user’s perspective. I think this is what created my frustration.
If the user doesn’t make a mistake in entry, then there’s no problem. But if the user incorrectly specifies a tie, maybe the program doesn’t handle that very well yet?
Also, I do understand what you’re driving at when you say I shouldn’t even have to think about ties, but I don’t think this is realistic. As a composer, I work on paper first. When I carry to notation software, don’t ask me to convert the half note tied to a whole note to a dotted whole note, knowing the software will take care of the bar line. That’s cool, but it’s not practical. 9 times out of 10, I’m going to enter a whole note and tie. (And what about other possibilities… a whole note tied to an eighth, for instance?)
I’m just reinforcing the point that I believe your user is going to be thinking in terms of ties, even if you are correctly parsing rhythmic values in the background independent of barlines.
And I’m sure there will be times I’ll be grateful for that… I bet Dorico can handle rebarring and shifting time signatures beautifully… but if you are stuck on trying to get me to think of sounding duration rather than written you are creating a significant barrier to adoption. (And that’s a battle the devs are going to lose with users down the road lol…)