[MEI-L] Encoding ligature and coloration brackets

[Micah Walter]

This makes complete sense! Thanks for the specific recommendations.

I would, of course, like to encode the mensural notation as well, but unfortunately that is beyond the scope of our resources at the moment.

-Micah


On 19 June 2013, at 16:15, Johannes Kepper <kepper at edirom.de> wrote:

> 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
> 
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l