MakeMusic
SmartMusic Finale Garritan MusicXML

Additions to Clef Support?

Moderator: Michael Good

Additions to Clef Support?

Postby Urs Liska » Fri May 29, 2015 5:29 am

While improving MusicXML export from LilyPond I realized that some items from LilyPond's reference can't be properly exported because MusicXML doesn't have specifications for their sings. Would it be possible to add them to the standard?
Concretely I'm talking about the signs for the clefs
Code: Select all
GG
tenorG
varC
altovarC
tenorvarC
baritonevarC

for which three clef signs are missing: The double G, the "varC" and the combination of G with varC.

In addition to that I'd like to know if it would be possible (or already is) to add labels to the clef. AFAICS there are numerous instances of multiple clef names mapping to the same shape/line combination, and I think these multiple names may well have a semantic meaning (well, sometimes they may just be conventions on the users' side, but surely not always).
Urs Liska
 
Posts: 2
Joined: May, 2015
Reputation: 0

Re: Additions to Clef Support?

Postby Michael Good » Fri May 29, 2015 11:56 am

Hello Urs,

Thank you for this suggestion. I think adding more clefs is a great idea for MusicXML 4.0 and goes together nicely with increasing our SMuFL support. Most if not all of this might be handled by adding a "shape" attribute to the sign element that distinguishes between different SMuFL clef names.

For some of these SMuFL clefs there will be in interaction with the octave-change element. If we represent LilyPond's GG and tenorG clefs (SMuFL gClef8vbOld and gClef8vbCClef, respectively) as G signs, those shapes should only be used if the clef-octave-change element is set to -1.

I am not sure when your varC clef symbol resides in SMuFL. It seems like it my be a variation of the cClefCombining glpyh, but perhaps not quite. It would be good to clarify the SMuFL standing for that clef, as we would like most of MusicXML 4.0's symbol expansion to be referencing SMuFL names.

I am not quite sure what you mean about the labels. Is that something like the shape attribute I am proposing here, or something else?
Michael Good
VP of MusicXML Technologies
MakeMusic, Inc.
User avatar
Michael Good
 
Posts: 2197
Joined: March, 2014
Reputation: 0

Re: Additions to Clef Support?

Postby Urs Liska » Mon Jun 01, 2015 2:23 am

Hello Michael,

I think incorporating the extension through SMuFL is the correct way to go. If there should be still things missing after that then it would be an issue between LilyPond and SMuFL, IMO.

Supporting such additional glyphs as "shapes" of "signs", with the "sign" referencing the anchor pitch sounds correct to me too, also the suggestion about the clef-octave-change element.

Regarding the varC shape I have asked both on the lilypond and the SMuFL lists because I can't tell that either.

No, the labels would be different from shapes. There are several cases where identical clefs can be referenced differently in LilyPond (e.g. "treble", "violin", "G"). Maybe this is mainly intended to accomodate different coding styles, but it can also transport semantic value. I'm not sure if it's worth an addition, but I could see a "name" or "label" attribute to add a descriptive/semantic layer to the clef's definition in MusicXML. Probably I'd vote for not enforcing any values for that attribute, but I admit I can't judge such decisions through to the end.
Urs Liska
 
Posts: 2
Joined: May, 2015
Reputation: 0

Re: Additions to Clef Support?

Postby Michael Good » Mon Jun 01, 2015 10:51 am

Hello Urs,

Thank you for clarifying the label request. I think these distinctions in LilyPond are there just for ease of use during score entry. I wouldn't think that anything changes in LilyPond output if you move between treble, violin, and G clefs. A LilyPond developer would be able to look at the code and let us know if that is correct or if there is indeed a semantic distinction.

If these are syntax synonyms as they appear, this is a type of application-specific distinction that we have generally tried to keep out of the MusicXML format to reduce complexity. If there is a semantic distinction, that would be a different situation. Please let me know if you think I am misunderstanding something.
Michael Good
VP of MusicXML Technologies
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