Question regarding negative <offset> values

[lemzwerg]

Are there restrictions how negative <offset> values are applied? For example, assume that we have the following (in pseudo-MusicXML).

<measure>
  <direction>
    <offset>-10</offset>
    ...

Is this valid? Does the offset cross the measure boundary, shifting the affected object to the previous bar?

I know that you would normally write

  <direction>
    <offset>-10</offset>
    ...
  </direction>
</measure>

at the end of the bar before, but...

Similarly, I wonder how large values for <offset> can be. Irrespective of making sense, would it be possible to shift an object, say, three measures forward or backward? AFAICS, the documentation doesn't cover this (I would actually expect that <offset> is restricted to the current measure).

Please advise.

[mscuthbert]

As far as I know there are no restrictions on the size of the number. It would be unusual for a spec to put such a restriction on (just like a text spec wouldn't put a limit on max font size even though 1,000,000,000pt is probably not a good idea).

Consumers of course can put limits on the values they will support (my music21 definitely does so with divisions though not with offset)

[lemzwerg]

OK, thanks. As mentioned above, a 'natural' limitation would be to restrict <offset> values to not exceed the current bar. However, if this assumption doesn't hold – as you've just said – I agree that a limit doesn't make sense in the specification.

[mscuthbert]

I have definitely seen cases in "the wild" where people have specified offsets as moving into the next measure (to attach something to a particular note but move its display elsewhere to avoid collisions) -- if we had a relative-x that was measured in divisions then that would possibly make more sense, but all our relative-x/absolute-x, are measured in page-size not musical-time dimensions.

One thing that the docs could do is give some guidance about how an offset value that pushes an element into the margins could be conceived -- that is, taking the (positive) last or (negative) first pixels-per-offset computation for the system and applying it into the system/page margins.

[mscuthbert]

MNX has comments such as about dots something like "The number of dots is not constrained, but processing systems should not be expected to support more than five." I think giving developers cover from Bug Reports about absurd values could be a good thing. So here MusicXML docs could add something like, "The offset value may exceed the dimensions of the measure (forward or backward) and even that of the system or piece. In these situations, rather than rendering the direction outside the measure, consuming applications may choose to ignore the <offset> or ignore the direction completely."

[lemzwerg]

Sounds good! In addition to that I think it would be helpful to emphasize the difference between <offset> and relative-x (at least this is how I see the functionality of those entities). I consider using <offset> to avoid collisions with other objects as incorrect usage. Instead, <offset> should be used to align objects musically to other moments, like making a wedge or a 'rit.' start mid-bar on the third beat, say, if there is only a whole note in the bar. If collision avoidance is necessary, use the relative-x attribute (probably in addition to <offset>). Doing so would make a (more or less) clean separation between musical content and layout, allowing MusicXML interpreters to ignore relative-x while still retaining the musical meaning.

In other words, doing

...
<f/>
...
<wedge/>
<offset>1</offset>

to slightly move the starting point of a wedge to the right is not good (I know that this kind of coding style is done everywhere, unfortunately). Instead, there should be only relative-x.