GSoC 2016 - Week 12 - Rhythmic durations

Posted 8 years ago

This was my 12th week working on note entry with MuseScore for Google Summer of Code. This week I improved the ability to simplify tied notes to indicate rhythms.

This week’s summary:

  • Rhythmic durations
  • Menu command to re-tie notes (e.g. after a time signature change)

Still to do:

  • Voice extraction
  • Test user feedback

Rhythmic durations

Standard practise in music notation is split notes when they cross over a stressed beat, in much the same way as beams are split to indicate beats. Currently MuseScore can split beams automatically, but notes and rests must be broken manually. This week I added the ability for MuseScore to do this automatically.

Comments

• Aug 15, 2016 - 02:54

Hurray! I can hardly wait.

Regarding the "Test user feedback" agenda, how are you planning on going about that? I actually have a couple of things I've thought of already, but I don't know if I should open new forum discussions or issues or leave comments here or what.

Reply

• Aug 15, 2016 - 13:34

I guess I'll pass on the "option to remain anonymous."

The first thing I came on is that the preselected note duration of a quarter note (same as in step-time entry) is not much use in automatic real-time mode. The whole point is to start with smaller subdivisions and then automatically combine them to longer ones; if the smallest subdivision is a quarter note, there's no way to subdivide after the fact.

So it seems like the default duration selected in the toolbar should be something much smaller—perhaps a 32nd note subdivision—when entering real-time automatic note input mode.

Going along with that, then, the metronome would want to be eight times faster, and maybe only tick on the "big beats" at quarter notes.

Reply

• Aug 31, 2016 - 03:17

I agree that in auto real-time mode, entering smaller durations is much easier than quarter notes, but I hesitate to make it the default because this would probably involve all sorts of checks to see how the user entered auto real-time mode and whether anything is selected.

As for the metronome sound, I deliberately made the full beats much louder than the sub-beats---hopefully that will help to avoid confusion. I think you are suggesting that my "semi-realtime" style of note entry should be more like the "real-time" input in other notation editors where the user plays in time to the full beats and then the program adjusts for changes in tempo, etc. In those programs nothing is displayed on the screen until the end of the bar, whereas with my semi-realtime method notes are added immediately. This means that there can be no adjustment later on, so the user should hear a click for every note, not just every beat.

However, if you read the "future work" section of my GSoC Work Product you will see that I envision semi-realtime as becoming a kind of optional "preview" for a future fully real-time mode. The behaviour you describe is what would happen if the user were to disable the preview: nothing is displayed until the end of the bar, like in other programs.

Reply