Do rests within beams get a <beam>?

[adrianholovaty]

Considering this music —

Should that rest get a <beam>continue</beam> or is <beam> only meant to be used on non-rest <note> elements?

Whatever the answer is, I think we should update the beam element docs to state the correct encoding.

[mscuthbert]

Both Finale and MuseScore's interpretation is no: rests do not get the beam information. (For comparison, this is also consistent with the music21 data model where rests do not store beam information, but might need to for stemlet length)

[cecilios]

Perhaps should be allowed in rests to deal with cases such as the bottom figure in E.Gould, p.165

[mdgood]

I agree. I think we could clarify this to say that beams are not included on rests unless a stem element is also included for use with stemlets. I suspect that's how most apps are doing this, but if @adrianholovaty or others have seen beams on non-stemlet rests, that would be good to know.

[adrianholovaty]

Here's the relevant image from Behind Bars, p. 165, so we're all on the same page:

[adrianholovaty]

@mdgood For what it's worth, I haven't seen beams on non-stemlet rests. I don't have a strong opinion either way; mainly my concern is documenting the "correct" behavior. :)

[Jojo-Schmitz]

But what about beams over rests, without stemlets? Certainly possible in MuseScore (see https://musescore.org/en/node/11370), not sure though whether it is also in MusicXML ex- and import

[mscuthbert]

@mdgood For what it's worth, I haven't seen beams on non-stemlet rests. I don't have a strong opinion either way; mainly my concern is documenting the "correct" behavior. :)

I think I remember seeing some in some 1960s band parts, where there were sometimes beams over entire beat groups even if they began with a rest. In any case, it seems like because of stemlet rests, <beam> is a fully legal tag on rests. Yet, usage in the wild shows that <beam type="continue"> is not being generated by all (any?) systems when beaming over a rest. (But it is not optional for notes). I think we should specify that best practice is to use <beam type="continue"> for all note objects under a beam, regardless of note or rest (unless it is a <chord/> note) but that importing systems should expect to encounter rests within beam groups that do not have beam information and if there are any "open" beams interpret the rest as having one <beam type="continue"> for each open beam.

[mdgood]

@Jojo-Schmitz This works fine in MusicXML from the information supplied by the beam elements associated with notes.

@mscuthbert The alternative would be to specify best practice as encoding <beam type="continue"> elements on rests only if there is a <stem> element as well, but other <beam> types should always be encoded on rests if needed. That would require less changes from systems from current behavior, which might be an advantage even if the rule is more complex. I have no strong feeling about this, aside from a reluctance to make the simpler and frequently used encoding "wrong" because of more unusual cases.