Open craigsapp opened 4 years ago
See this https://github.com/rism-ch/verovio/issues/445#issuecomment-274008419 and this https://github.com/rism-ch/verovio/issues/1151#issuecomment-539965672
Maybe we can change the default priority order to:
Any objections?
(There was a while ago a discussion about being able to provide the order explicitly in the encoding when a particular sequence is desired, but I cannot find anything about it.)
That looks good, but the octave line should have lower priority than in the above list since usually only dir, tempo and endings are further (but it is not common to have dynamics above the staff, so an actual music example containing both would be good to find).
articulation (staccato / accent / tenuto / stacattissimo) (closest)
ornament (mordent / turn / trill)
brackets (not sure about this one: might depend on its purpose and may be just above octave in the list)
breath
fermata
dynam / hairpin
octave
dir
tempo
pedal
[verse] (especially when above the staff)
harm
(ending) (furthest)
For now I would prefer to keep dynam / hairpin
and dir
next to each other. That would (I think) solve the issue when some dynams and dirs are grouped together. Now it is a problem when there is something in-between, which makes no sense - basically saying that a group of elements needs to be aligned together, but some placed above other ones, and others below.
More fundamentally, the problem is related to the fact the dir
covers a very broad range of cases. Once we have a way to qualify them in a more refined way (see https://github.com/music-encoding/music-encoding/issues/712) we can do something like:
@func
)We can have other dir@func
in the list, e.g. dir@func="lv"
, which should probably be closer to the note than generic dir
elements and be at the same level as lv
.
As it stands, artic and verse are treated differently since they are not control events. I don't think we support verse to be above the staff, do we? In any case, they would appear after (further away) than harm. I think this is fine.
OK
We can have other dir@func in the list, e.g. dir@func="lv", which should probably be closer to the note than generic dir elements and be at the same level as lv.
Yes, l.v.
should have higher stacking priority than regular dirs.
A thought: tempo-like dirs should be given lower priority than regular durs (such as "ritard"), since they should be equivalent to <tempo>
in their stacking order (or should these just be called <tempo>
?).
dir@func="dynam" (if we agree for this value to be added to the list in
@func
)
That is good. I have been calling these <dynam>
.
I don't think we support verse to be above the staff, do we?
Not yet, but eventually: https://github.com/humdrum-tools/verovio-humdrum-viewer/issues/292
[lyrics] would appear after (further away) than harm.
I have never seen such a case where verse and harm are on the same side of the staff, but I would think that verse has higher priority than harm since it is more important musically. But that can be dealt with if a real musical example is found demonstrating the priority of the two.
Have you thought about implementing the aboveorder
/ beloworder
attributes on scoreDef
? Maybe the list of values should be expanded, but these attributes may serve the purpose we are looking for. (It would be an addition, of course, to a default stacking order.)
I am still not sure how to properly stack some control events, in particular dir
. For example, I assume something like this would be encoded with two dir
elements, one for con sordino and one for Thema, and a tempo indication.
However, I would expect to be able to encode that one of the dir
is below the tempo
the other above. I don't think above / beloworder
allows us to do that, does it? Any though how to handle this?
In this particular case, the <dir>
/<tempo>
elements each have a well-defined function, so maybe @type
can be used to refine the stacking order: Regular <dir>
should always be below a <tempo>
. And maybe Thema
could be encoded using dir@type="title"
which would stack above <tempo>
(and above anything else, including endings). Or there could otherwise be a certain type, such as top
or furthest
, that is always placed above <tempo>
while other <dir>
would be placed below <tempo>
.
Yes, that would work. However, it would break the rule of thumb that Verovio should not rely on @type
attribute values - these are not pre-defined in MEI and are meant to be application specific. It would be much better if we can rely on something that is part of MEI in order to maximise interoperability. Hence the proposal to have @func
on dir
(see here) but that did not seem to lead to a consensus.
Instead of using dir@type
I would prefer to have a Verovio customization with dir@func
, but that would be a very last resort solution I would prefer not to go for. @kepper, do you see any other options we have with MEI?
One possibility is to promote the <div>
container for Thema
to its own element, as is done with <tempo>
. This would simplify stacking, since that new element would always be given the highest stacking order.
This sort of case is common in particular genres (especially Theme and Variations), so some sort of solution would be very useful. Here is an example where it is common in Minuet and Trios:
Notice that there is no tempo under the Trio label in this case:
Of course, here is an exception where the tempo is above the section title:
But more common is section title first and then tempo below:
Yes, that would work too. Something like <title>
?
Of course, here is an exception where the tempo is above the section title:
I think this type of exception could then be handled with @aboveorder
.
I think that title
is an element for semantic tagging, not for display.
The current structure of MEI doesn't seem to allow multiple pieces with different titles on on page at all with pgHead
. It would be good to have something more versatile here.
Here is an example of a fermata and a dynamic that are stacked in the wrong order:
The "sf" should go above the fermata rather than the other way around. If the
<dynam>
is converted into a<dir>
, the stacking order is correct:MEI test data: