[MEI-L] Encoding ligature and coloration brackets

[Johannes Kepper]

Hi Micah,

In an ideal world, I would recommend to encode both the mensural notation and its transcription to cmn, and connect the two of them as closely as possible / reasonable. However, I suspect that your world is equally non-ideal as mine, so you may not have the resources to do that. Under these circumstances, Perry's first suggestion seems most appropriate to me – the bracket is a sort of graphical annotation to the musical text. It has a very specific meaning, and a very specific rendering. What I would do now is to define a schema for this kind of annotation, based on the <annot> element. This would (probably) result in a set of schematron files, that make sure that all <annot type="bracket"> have a @subtype, which is either "solid" or "broken". They must appear only where other control events are allowed, that is inside a <measure>, but nowhere else (let's put editorial markup aside for a moment). These <annot>s should also be forced to indicate their range by @startid and @endid (or @tstamp and @tstamp2, if you prefer). Other markup inside <annot> should be suppressed. This would give you a very specific element, that may not appear in other places in your markup and interfere with other kinds of <annot>s. Based on the experience you have with it, and if other people request the same kind of element, it could serve as incubator for a new specific element (in contrast to a specific profile for a generic element like <annot>). In the end, this kind of bracket is not super-unusual…

What this doesn't solve is the way of drawing the bracket with Vexflow. However, if you use <annot> in this specific way, it should be possible to include some rules in the translation that generate your lines from the <annot>. The concept is not that different from a hairpin, for instance, where one element is converted into a set of lines that relate to some specified notes. I wouldn't recommend to include additional <line> elements in the encoding itself. I suspect more problems than it solves (changes on one element would have to be reflected to the other etc.). 

Hope this helps,
jo








Am 19.06.2013 um 20:32 schrieb Micah Walter:

> To me, it always makes more sense to use semantically meaningful markup. You are right about our goals in encoding as accurate (and abstract) a form of the CMN as we can. We're rendering on the fly from MEI using VexFlow <http://www.vexflow.com>. I'll see if I can try using <annot> to describe the content of the music, but as you suggested, we might reach a point where we just need the brackets printed, by hook or by crook…we'll see.
> 
> I suppose it would also be possible to *both* draw brackets explicitly *and* encode content using <annot>—this might be an eventual compromise.
> 
> Thanks for the suggestions,
> Micah
> 
> 
> On 19 June 2013, at 13:50, TW <zupftom at googlemail.com> wrote:
> 
>> In my eyes, the choice between <ligature>, <annot> and <line> or
>> <symbol> depends on two things:  Whether and how you generate the
>> graphics from the encoded MEI and what is the "philosophy" of your
>> encoding.
>> 
>> I understand that your encoding process is also a transcription
>> process of mensural notation into CMN.  It appears that you therefore
>> need the CMN structures and can not use the mensural module.  Given
>> that, I see that you can move between two encoding "extremes":  Either
>> making an encoding that aims at describing the graphical elements
>> which should be put on the page when visualizing, or an encoding that
>> does not yet focus too much on presentation but is meant to capture
>> what the original notation "means in modern terms", capturing
>> additional information that is worth carrying over--but can not be
>> represented in CMN--in abstract, meaningful structures.
>> 
>> In my eyes, the latter approach makes more sense.  It is, so to say,
>> more flexible, as the first approach already decides rather precisely
>> how to visualize the music, while the latter is more content-oriented
>> and leaves open how to visualize non-CMN features.  Who knows, there
>> might be other wishes for visualization in the future.
>> 
>> But from a pragmatic point of view, the best solution might be the one
>> that that makes your life easiest when producing the brackets while
>> generating the graphics--if you do this from the MEI data.  Are you
>> using the data for rendering, and if so, what does the process look
>> like?
>> 
>> Thomas
>> 
>> _______________________________________________
>> mei-l mailing list
>> mei-l at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
> 
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l