Re: MusicXML representation of "additional" staff

Hello Evan, hello group,

sorry for waiting a month to reply to this, but it just kept working in my mind all the time. I agree with the fundamental problem you sketched between semantics and optics. (Apologies if somebody else wrote about this earlier already, but I couldn’t find anything.)

If we think it is not possible to enhance the additional clef property with this is in a way that also semantically clarifies which notes belong to it, then we ought to look for a way to do so.

So, what actually happens syntactically when we see an additional staff within a measure? We mentally associate all subsequent notes in proximity to that staff as if it were an additional instrument/hand - and this is also the way an interpreter should render it visually (and on playback). Therefore, my suggestion would an element like an <AdditionalStaffMeasure> within an existing measure that has an associated position within its parent measure and can contain notes/pauses/expression symbols. While it is semantically a measure with a fixed point, visually it is shown just as additional staff within the parent measure. Would that seem like a feasible plan?

Kind regards, Christian.

> On 22 Mar 2016, at 21:00, Evan Brooks <scanmaniam@gmail.com> wrote:
> 
> There are numerous cases in the usage of music engraving software, such as Finale, where music symbols are graphically placed in order to generate a particular semantic meaning, but the engraving software and/or the MusicXML export from it do not or cannot represent it.
> 
> A case in point is the example of the “additional” clef used below (from "Written vs. Sounding Pitch” by Donald Byrd). In order to create a more compact visual notation, a single F Clef is used within a larger G Clef context.  Most importantly, it is meant to semantically apply only to one particular note, and not any other notes that are played at that same time on that clef, or afterwards.  It is this restriction that causes problems with MusicXML, in that clef symbols apply at a particular time in a measure, and all notes played at that time on that staff would be affected by it.
> 
> In Finale, for example, one would have to essentially “paste-up” this extra clef in order to make it appear correctly from a visual perspective, but it would take some fooling around with the note itself to get the proper note value to sound, I would imagine.  In such a case, there is a disconnect between the visual and structural or semantic representation.  It seems likely that there are other such cases.
> 
> The problem is exacerbated with MusicXML export from Finale, because if Finale itself does not make the connection between the visual and semantic representations, it is unlikely to be able to express it in MusicXML properly.
> 
> And lastly, I don’t believe that there is a good way to express this scenario in MusicXML, and thus the core of this posting. While MusicXML allows for a clef with an “additional” property to be placed at a specified location, all this does is propagate the “visual” component of this clef, and not the semantic one.  Given the lack of ability to have a clef in MusicXML apply to one of many notes sounding at one time on a staff, we should at least have a recommended “best-practice” for how to represent this use case in MusicXML.  Engraving applications could then generate the appropriate MusicXML source when they recognize this situation graphically.
> 
> Best regards,
> 
> Evan Brooks
> 
> 
> 
> <Screen Shot 2016-03-22 at 12.24.43 PM.jpg>

Received on Tuesday, 19 April 2016 15:39:55 UTC