Note and rest presentation

• Mar 22, 2011 - 20:14

Could we implement a function that tidies/re-maps rest and note values to automatically display correctly?

You would select the bar (or entire score) and apply it (via right click, or in the menu perhaps).

This maybe useful for those who aren't familiar, or don't have time with notation rules/etiquette.

In 'Presentation of notes', bars 1-4 (as opposed to 5-8) seem to represent the proper way?
In 'Presentation of rests', bar 1 (as opposed to 2) seems to be correct?

Perhaps correct isn't the right word - just the recommendations from professionals for better comprehension?


Comments

In reply to by chen lung

This strikes me as something that would be a great application for a plug-in!

Regarding the plug-in architecture, I'm still a bit unclear on how things are supposed to supposed to work as far as adding notes and rests to an existing measure. Some things I've tried work, some mysteriously don't, and some crash MuseScore. At some point I do plan to sit down and really try to find my way around this stuff. But it looks to me like everything that would be needed to implement this as a plug-in is already in place, assuming it actually works. So if no one else does anything with this idea, I may try my hand at it later.

In reply to by chen lung

Hi,

In the rest examples, measure 1 seems to me a more correct way of notating than measure 2: measure 2 hides the fact that 3rd C is 'off-beat' (sorry, I don't the English name for that).

The note example is probably ambiguous: measures 6 and 8 are 'better' than the corresponding meas. 2 and 4 (but still some cases could possibly be made for them in certain conditions); but measure 7 is wrong: measure 3 is the correct way.

That said, the function you ask for wold be very useful, but I doubt we could reach an agreement on what it should and should not do.

M.

In reply to by Miwarre

The fact that there is room for disagreement about the "best" way to do this is part of why I was thinking this would be something more naturally handled as a plug-in.

But I also have in mind the notion that the main application itself should be kept relativly streamlined, focusing on features "necessary" in order to produce some particular result efficiently. If you already know how to produce good rhythmic notation, a feature like the one we are discussing wouldn't be necessary - you'd just enter the notes that way in the first place. So I think of it more as a "compositional aid", along the lines of taking a melody and re-writing it backwards or upside down for the purpose creating twelve-tone serial pieces, or automatically figuring out appropriate harmonies to use for a melody, or automatically improvising a melody to fit a specified chord progression. Such features might be described as allowing to use Musescore as "scratch pad" to put down not-yet-fully-formed ideas, and having the program help you turn them into "real music".

And I don't mean to denigrate the value of such features. I'm just saying, I see that as one way of looking at the question of what might belong in the program and what might belong in a separate plug-in. Not that it's my place to be saying what goes in and what doesn't. I am just saying, it seems pretty likely that the folks doing the actual development would not consider a feature like this high enough priority to implement, but that doesn't mean it isn't worth doing. Hence the thought that a plug-in could be the way to go.

As for the actual feasibility of doing it that way, I don't doubt that the current framework would present obstacles, but I'm still unclear on what really can and cannot be done. I mean, while you might not be able to "replace" notes, you *can* delete notes, and you *can* add notes. There are methods for that, and at least sometimes, they work. I've played around with things like having a plug-in delete some notes currently in a measure and then insert new ones, with mixed results. As I said, some things I try work, others don't, and other crash MuseScore. I haven't yet spent the time to really get to the point of understanding what is possible and what is not, or how much of what is not possible is that way by design, versus because of bugs in the Cursor.add() method (which is my suspicion). But given that deleting and adding notes works *sometimes*, it still seems within the realm of possibility that it could be made to work here, with at most maybe needing some minor (?) bugs or limitations in the framework addressed first. Unless there really is something I'm missing here regarding what the add(0 and delete() methods are and are not supposed to be able to do.

Even if it worked, there would be limitations in such an approach, no doubt. The new notes would not be able to inherit many of the properties or items attached to the old ones (eg, staccato markings might disappear). That's one reason I mentioned wanting the ability to access more note properties and other elements in my thread from a few weeks ago on possible extensions to the framework. But even without those extensions, I could still see this being a useful utility - you'd just have to be in the habit of using it early in the compositional process, before adding much in the way of other markings..

The "correct" presentation depends a lot on style. In some styles of music where off-beats are common place, the ties are less needed. The current MuseScore behavior allows any style and assumes the note setter knows what they are doing. Whether this is the best for everyone is up for debate. Currently every scorewriter I've used behaves like this (does not enforce a particular style).

Do you still have an unanswered question? Please log in first to post your question.