MakeMusic
SmartMusic Finale Garritan MusicXML

default-x and opposed noteheads in chords

Moderator: Michael Good

default-x and opposed noteheads in chords

Postby Carl de Marcken » Mon Feb 04, 2013 4:33 am

Michael,

I notice in a MusicXML score generated by Finale the following phenomenon:

In a single chord the default-x of notes varies - in this case because the notehead is opposed on the stem.

Using default-x to handle opposed noteheads seems like a mistake, since any reasonable interpretation would imply the stem moves and of course in a chord it doesn't. (So far as I can tell MusicXML doesn't provide a direct way to specify that a notehead is opposed, so I can understand why Finale does this.)

It seems like the MusicXML documentation could be clearer about the interpretation of default-x in this case. In my opinion interpretation and implementation would be simplified if the spec said that either all notes in a chord receive the same default-x, or the first in the file applies to all. Adding a special attribute to allow specification of an opposed notehead in a chord would help in this case.

Speaking more generally, the lack of specification of where chord-common information appears is quite problematic from an implementation standpoint. Good examples of this are stem sizes and beam and slur specifications - the fact that there is little consistency among score editors about the note on which they place this information forces many interpretation questions upon implementers.

Just a reflection. Thank you,

Carl de Marcken
Carl de Marcken
 
Posts: 12
Joined: March, 2014
Reputation: 0

Re: default-x and opposed noteheads in chords

Postby Michael Good » Wed Feb 13, 2013 10:32 pm

Hi Carl,

Thank you for your suggestions. This MusicXML behavior for default-x is deeply ingrained into a lot of software at present, so I am afraid we will not be able to change it. Note that the stem element can also have a default-x element, so the note/stem relationship can be represented more specifically.

What we might be able to do is to add an element or attribute that directly indicates placement on the opposite side of a stem (right side if stem is up, left side if stem is down). This would be similar to the way that the placement attribute provides an above/below distinction vs. the exact positioning of the default-y element.

I agree that we should see how we can make the specification more precise about the treatment of chord-common information. It is on our list of things we hope to address in the future.

Best regards,

Michael Good
MakeMusic, Inc.

Carl de Marcken wrote:Michael,

I notice in a MusicXML score generated by Finale the following phenomenon: In a single chord the default-x of notes varies - in this case because the notehead is opposed on the stem.

Using default-x to handle opposed noteheads seems like a mistake, since any reasonable interpretation would imply the stem moves and of course in a chord it doesn't. (So far as I can tell MusicXML doesn't provide a direct way to specify that a notehead is opposed, so I can understand why Finale does this.)

It seems like the MusicXML documentation could be clearer about the interpretation of default-x in this case. In my opinion interpretation and implementation would be simplified if the spec said that either all notes in a chord receive the same default-x, or the first in the file applies to all. Adding a special attribute to allow specification of an opposed notehead in a chord would help in this case.

Speaking more generally, the lack of specification of where chord-common information appears is quite problematic from an implementation standpoint. Good examples of this are stem sizes and beam and slur specifications - the fact that there is little consistency among score editors about the note on which they place this information forces many interpretation questions upon implementers.

Just a reflection. Thank you,

Carl de Marcken
User avatar
Michael Good
 
Posts: 2197
Joined: March, 2014
Reputation: 0

Re: default-x and opposed noteheads in chords

Postby Carl de Marcken » Thu Feb 14, 2013 2:52 am

Michael Good wrote:Hi Carl,

Thank you for your suggestions. This MusicXML behavior for default-x is deeply ingrained into a lot of software at present, so I am afraid we will not be able to change it. Note that the stem element can also have a default-x element, so the note/stem relationship can be represented more specifically.

Michael,

A basic problem with indicating opposed noteheads by jointly specifying default-x on both the notehead and the stem is that the width of a notehead in tenths isn't a constant but depends on the rendering of noteheads and stems. I'm not sure what a rendering program should reasonably do when presented with several different default-x's for different noteheads in a chord and no way to ascertain the the width of the noteheads in the original layout. (And specifying the stem default-x in chords seems like a bad practice - what on earth would it mean for multiple notes in a chord to have differing stem x's?)

Using default-x on exactly one note in a chord where the default-x always indicates the left of the notehead works fine: a rendering program can draw the stem and other notes in the proper relative position given its own rendered noteheads. Ditto for specifying default-x on the stem exactly once in a chord, but not the noteheads. But specifying default-x on both the notehead and stem is over-constraining and layout programs can't render directly from such information but must attempt a reverse- engineering of intent.

In general I think MusicXML gets the problem of specifying horizontal and vertical placement _right_, by specifying note position relative to top of staff and left of measure (though it would really help to better define what the measure reference point is supposed to be when bars are of significant width or there is a staff signature), and by specifying the position of most ornamentation relative to the note. Your solution makes it relatively easy to change the horizontal and vertical scaling and positioning of notes and staffs but retain stylistic rendering hints in the source. All great! But this breaks down when there are multiple specifications of positions that can only be consistently interpreted with respect to very specific rendering assumptions - and providing multiple x positions or y positions for different parts of a note or chord is the main place I've seen such problems.

I completely sympathise with your statement that too many programs have been written to change everything now. But perhaps you could specify in documentation a best practice for indicating the x position of chord noteheads and their stems?

(In my own programs I haven't found a better solution than to scan chords for situations where multiple default-x have been provided and assume the leftmost is the one to use for ordinary noteheads and to determine stem placement, and then to ignore other default-x and use reasonable rules for opposing noteheads in chords. Similar logic is needed to determine how beams and slurs should be interpreted in chords. Any such code is extremely brittle because it's deducing intent from idiosyncratic details in score-generating programs.)

Carl
Carl de Marcken
 
Posts: 12
Joined: March, 2014
Reputation: 0

Re: default-x and opposed noteheads in chords

Postby David Webber » Thu Feb 14, 2013 3:57 am

Carl de Marcken wrote:A basic problem with indicating opposed noteheads by jointly specifying default-x on both the notehead and the stem is that the width of a notehead in tenths isn't a constant but depends on the rendering of noteheads and stems.

Just a comment as this is a problem I'm very well familiar with, and I'm not sure that there can ever be a general solution.

My own software, Mozart (http://www.mozart.co.uk), works with vertical dimensions as multiples of the spacing of staff lines (exactly like MusicXML), but horizontal dimensions are multiples of the width of a black note-head. So, for example, if you change music font, to one where the note heads have a different aspect ratio, then the width to height ratio of the staff can change, so that exactly the same number of notes with the same relative spacing fit on it :-)

I chose this method in about 1986 and have lived with it ever since, very often wishing fervently that I had chosen identical horizontal and vertical units (as MusicXML does). But the truth is that (despite my method perhaps sounding bizarre) either method will do some things easily and other things with difficulty. In exporting MusicXML, the first thing Mozart has to do is convert its horizontal distances into MusicXML's 10ths. It can only do this based on the aspect ratio of notes in its own music font, and the results when importing the MusicXML into other software can only be identical if the other software happens to have the same aspect ratio of the note-head.

For this reason I am currently considering very carefully how much spacing information it is worth including in a MusicXML export, and how much to leave to the discretion of the importing program. [Some things should definitely work though like (vis-a-vis my recent post) system spacing!]

Anyway, this probably doesn't help, except to point out that some things are probably impossible :-( Maybe I'm just agreeing with you.

Dave

David Webber
Mozart Music Software
http://www.mozart.co.uk/
David Webber
 
Posts: 148
Joined: March, 2014
Reputation: 0

Re: default-x and opposed noteheads in chords

Postby Carl de Marcken » Thu Feb 14, 2013 4:38 am

David Webber wrote:
Carl de Marcken wrote:A basic problem with indicating opposed noteheads by jointly specifying default-x on both the notehead and the stem is that the width of a notehead in tenths isn't a constant but depends on the rendering of noteheads and stems.

Just a comment as this is a problem I'm very well familiar with, and I'm not sure that there can ever be a general solution.

My own software, Mozart (http://www.mozart.co.uk), works with vertical dimensions as multiples of the spacing of staff lines (exactly like MusicXML), but horizontal dimensions are multiples of the width of a black note-head. So, for example, if you change music font, to one where the note heads have a different aspect ratio, then the width to height ratio of the staff can change, so that exactly the same number of notes with the same relative spacing fit on it :-)

If the goal is to mimic the page layout of a score editing program, then of course matching units exactly is necessary and for MusicXML to support this it would need to provide quite a bit of additional information - especially size of glyphs like noteheads and accidentals.

But for many situations exact matching is neither necessary nor desirable and I think MusicXML comes very close to supporting uses where the rendering program makes its own decisions wrt page layout and font. There are still several blockers though, IMO.

MusicXML makes a very good decision to use a common unit for x and y (tenths) but specify placement using a very clear hierarchy of relative values that is independent in x and y (for y, system -> staff -> notehead and for x, system-> measure-left -> note -> ornament). If one wants to move systems or staffs around vertically one can still retain the staff- local default-y information and similarly for various x motions. A nice example is how well slur bezier information survives substantial layout changes because it's interpreted relative to notes.

The two areas I think need work in the spec to properly support renderers that make some of their own decisions:

1. When there can be multiple "paths" that can't be consistent unless one EXACTLY matches the source, such the chord or notehead & stem issue.

2. When the provided layout information is missing crucial details.

A good example of this is the lack of width & height information on words: font families and sizes are given, but since many score-editing programs either don't specify fonts or specify proprietary fonts, and MusicXML doesn't provide rendered width and height, rendering programs have no knowledge with which to match fonts or scale appropriately and hence it's very difficult to keep words from drifting into each other or off the page.

Another example is the unclear relationship between measure widths, bar widths, staff signatures, and note default-x: unless one reverse engineers the width decisions and reference point assumptions of the score editing program it can be very hard to match the original intent and prevent notes from running into staff signatures or bars. I think this could be fixed if the documentation were more clear about exactly what the reference point for note default-x and measure-width are in
"interesting" situations.
Carl de Marcken
 
Posts: 12
Joined: March, 2014
Reputation: 0

Re: default-x and opposed noteheads in chords

Postby Michael Good » Thu Feb 21, 2013 7:59 pm

Hi Carl and Dave,

Thanks for the great discussion. Regarding some of Carl's points:

I think the font issues and the notehead/stem issues are similar. MusicXML gives you enough information to reproduce the music exactly, but this does depend on having the original fonts available. Otherwise you have to approximate the positioning as best you can. I think this is reasonable for MusicXML's major use cases. Better supporting the intermediate case where fonts are not available can get quite tricky, and can add quite a bit of complexity to the format for comparatively little benefit. At least that is the way this tradeoff has appeared in the past.

I'm not sure what is unclear about measure widths and note default-x. As documented, the default-x origin is "from the start of the entire measure, at either the left barline or the start of the system." We have had requests for more closely specifying the left / right / center of the barline, especially for thick double / repeat barlines. Aside from that, what else could be clarified?

Best regards,

Michael Good
MakeMusic, Inc.
User avatar
Michael Good
 
Posts: 2197
Joined: March, 2014
Reputation: 0

Re: default-x and opposed noteheads in chords

Postby David Webber » Fri Feb 22, 2013 5:32 am

Michael Good wrote:MusicXML gives you enough information to reproduce the music exactly, but this does depend on having the original fonts available....

I'm hoping that any effects dependent on this will be 'small'.

If MusicXML is to be used as an exchange format between different notation programs, there can't be any expectation that they will use the same music fonts, or even have access to them. I produced my own fonts for Mozart (a) in the belief that those of other programs were proprietary and under copyright, and (b) because I needed absolute control of the position of the origin of the symbols, which (as far as I'm aware) not even the Unicode music symbol subset specifies. (If I'm right about (b), this makes it particularly awkward for notation software just to use any old font with Unicode music symbols.)

The above reasons are general enough that I would expect other notation programs to have their own fonts. And of course if scanners (music OCR programs) are used, the font in the image may not be the same as that of any modern software.

For these and similar reasons, I am not importing/exporting detailed horizontal positioning information to/from Mozart from/to MusicXML. As I develop my import/export modules I am hoping to be able to get away with this indefinitely! I haven't found any problems (at least in principle) with the vertical distances specified in 10ths, which concept seems to work very well.

Dave

David Webber
Mozart Music Software
http://www.mozart.co.uk/
David Webber
 
Posts: 148
Joined: March, 2014
Reputation: 0

Re: default-x and opposed noteheads in chords

Postby Carl de Marcken » Fri Feb 22, 2013 9:04 pm

Michael Good wrote:I think the font issues and the notehead/stem issues are similar. MusicXML gives you enough information to reproduce the music exactly, but this does depend on having the original fonts available. Otherwise you have to approximate the positioning as best you can. I think this is reasonable for MusicXML's major use cases. Better supporting the intermediate case where fonts are not available can get quite tricky, and can add quite a bit of complexity to the format for comparatively little benefit. At least that is the way this tradeoff has appeared in the past.

Michael,

Thank you for this perspective. I understand completely. However echoing David Webber, I think many fonts used in editing programs are either proprietary or not available on many devices, and this decision does make it difficult to faithfully replicate a score's look.

Michael Good wrote:I'm not sure what is unclear about measure widths and note default-x. As documented, the default-x origin is "from the start of the entire measure, at either the left barline or the start of the system." We have had requests for more closely specifying the left / right / center of the barline, especially for thick double / repeat barlines. Aside from that, what else could be clarified?

There are 3 issues I think need clarification.

1. As you say, what constitutes the reference point for a barline when it has thickness or involves extra glyphs like repeat signs?

2. How is measure-width interpreted with respect to barlines: what exactly constitutes the start and stop point that measure-width is calculated from? Similarly, what are the system width and margins measuring? (It is possible this has been defined but I haven't found a precise statement in the DTD.)

3. Where are staff signatures placed in x?

Perhaps I've missed something, but I don't see any positioning attributes on the staff signature sub-elements of Attributes that would let one deduce where clefs, key and time signatures should be placed. Obviously rendering programs must be capable of laying out staff signatures without such help, but when notes include positioning attributes then it can become problematic to mix a rendering program's default staff signature placement with an editing program's note placement. This is especially true when the key signature may involve many accidentals that could have wildly different widths depending on the fonts used, and when signature changes take place mid-measure.
Carl de Marcken
 
Posts: 12
Joined: March, 2014
Reputation: 0

Re: default-x and opposed noteheads in chords

Postby Joe Berkovitz » Sat Feb 23, 2013 11:12 am

My perspective on this issue, which some might understandably disagree, is that default-x amounts to a sophisticated set of hints as to the engraving and layout decisions made in the original document. That is what they are: hints, not exact positional specifications. In the end, one usually will need to render MusicXML with a notation layout engine that can make at least some of its own decisions, if not all of them, in which case default-x values will not be taken as truly prescriptive.

I don't see this as a bad thing. To perfectly capture the graphical rendition of a document in a "dumb" semantics-free way, we already have the PDF format. I think MusicXML is most useful today in its capture of notational semantics, rather than notational layout. Just as you said, it is difficult to use default-x values literally without an understanding of the original font metrics and layout logic. Not that these values are useless, but they require interpretation, and they can't be taken as-is if one wants any flexibility in the resulting layout.

. . . . . ...Joe

Joe Berkovitz
President
Noteflight, LLC
www.noteflight.com
"Your music, everywhere."


Carl de Marcken wrote:
Michael Good wrote:I think the font issues and the notehead/stem issues are similar. MusicXML gives you enough information to reproduce the music exactly, but this does depend on having the original fonts available. Otherwise you have to approximate the positioning as best you can. I think this is reasonable for MusicXML's major use cases. Better supporting the intermediate case where fonts are not available can get quite tricky, and can add quite a bit of complexity to the format for comparatively little benefit. At least that is the way this tradeoff has appeared in the past.

Michael,

Thank you for this perspective. I understand completely. However echoing David Webber, I think many fonts used in editing programs are either proprietary or not available on many devices, and this decision does make it difficult to faithfully replicate a score's look.
Michael Good wrote:I'm not sure what is unclear about measure widths and note default-x. As documented, the default-x origin is "from the start of the entire measure, at either the left barline or the start of the system." We have had requests for more closely specifying the left / right / center of the barline, especially for thick double / repeat barlines. Aside from that, what else could be clarified?

There are 3 issues I think need clarification.

1. As you say, what constitutes the reference point for a barline when it has thickness or involves extra glyphs like repeat signs? 2. How is measure-width interpreted with respect to barlines: what exactly constitutes the start and stop point that measure-width is calculated from? Similarly, what are the system width and margins measuring? (It is possible this has been defined but I haven't found a precise statement in the DTD.) 3. Where are staff signatures placed in x? Perhaps I've missed something, but I don't see any positioning attributes on the staff signature sub-elements of Attributes that would let one deduce where clefs, key and time signatures should be placed. Obviously rendering programs must be capable of laying out staff signatures without such help, but when notes include positioning attributes then it can become problematic to mix a rendering program's default staff signature placement with an editing program's note placement. This is especially true when the key signature may involve many accidentals that could have wildly different widths depending on the fonts used, and when signature changes take place mid-measure.
Joe Berkovitz
 
Posts: 79
Joined: March, 2014
Reputation: 0

Re: default-x and opposed noteheads in chords

Postby Michael Good » Mon Feb 25, 2013 10:11 pm

Hi Joe, Carl, and David,

I think Joe captures the use of default-x and other formatting attributes quite well. In MuseData these were referred to as print suggestions. You can indeed get very high precision out of MusicXML output, but you must have the same fonts, not merely fonts that have similar metrics. Music notation is highly interrelated, and one change rapidly effects others. The shapes of the sharp and flat accidental characters, for instance, can effect whether accidental spacing looks nice and tight, or overlapping and sloppy.

There are some common business scenarios where the exact fonts are indeed available, so this design works well for high fidelity in that situation. But as Joe mentions, once you need to make the score editable or interactive, you need to move beyond slavish fidelity to the MusicXML formatting, and apply some interpretation regarding how MusicXML's formatting maps to your application's layout features.

Carl, key signatures, time signatures, and clefs all have default-x attributes available. However, I don't think there are many programs that output this formatting data, though you have musical positioning available for mid-measure clefs. In Finale this information isn't available via the plug-in interface, so that has limited Finale's MusicXML export in this area.

David, you're quite right about the issues regarding the reference positions of different musical characters. Trying to make sense of this in a standardized way is on our list of possible future features, but it's a complex problem.

Best regards,

Michael Good
MakeMusic, Inc.
User avatar
Michael Good
 
Posts: 2197
Joined: March, 2014
Reputation: 0

Who is online

Users browsing this forum: No registered users and 2 guests

cron