[MEI-L] Invisible staves and content

[Gulewycz, Paul]

I can’t really decide if I find one solution better than the other. I think putting extra layout information into <scoreDef> and/or <staffDef> e.g. after a <sb> is a very elegant way to choose which staves should be displayed, as it keeps the encoding slim and easy to work with. In our problem especially, it is definitely smarter to choose what is visible than what is invisible. In situations like the ones that Eleanor described, it could work out as well that way, I believe.
But I might be mistaken entirely, because maybe I’m missing something.

In the case of the study book, we would like to keep this exercise as one single unit and not separate the different parts into many smaller units. Which means, that we would still have 32 staffDefs in the <scoreDef> at the beginning of <score>. Every time there is change in instrumentation, the names of the instruments should be displayed in the beginning to correctly label the staves as soon as they occur. Currently, instrument labels only shown in the first system of the first page. When two staves are visible, the other 30 staves without content have to be hidden in our encoding, as the rendered score should look just like the page in the facsimile.

Von: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] Im Auftrag von Andrew Hankinson
Gesendet: Dienstag, 10. Juli 2018 19:27
An: Music Encoding Initiative <mei-l at lists.uni-paderborn.de>
Betreff: Re: [MEI-L] Invisible staves and content

It looks like it really is a measure-by-measure showing and hiding of particular staves, so I might agree with your first instincts of adding @visible to individual staves. I would be interested in hearing more about why this is not a good option, though.

What will you expect the rendered score to look like? That may inform what the best option is for encoding it.

On 10 Jul 2018, at 17:32, Gulewycz, Paul <Paul.Gulewycz at oeaw.ac.at<mailto:Paul.Gulewycz at oeaw.ac.at>> wrote:
Dear MEI community,

many of you might currently be on vacation or enjoying the sunny weather, but we have to ask you for a short interruption, because we need your opinion and advice on an issue concerning the encoding of invisible content and staves.

In our project on the digital edition of the study book of Anton Bruckner, we came across many pages, in which multiple staves need to be made invisible. In particular, there is one exercise across five pages, where the instrumentation changes every two lines, sometimes even after each line. That’s why the header in this file contains 32 different staffDefs. We were trying to hide unnecessary staves by inserting @visible=”false” into the staff elements in the measures in question, but, of course, that only makes the content invisible, staves and barlines remain unhidden.

We talked to Laurent about this issue and he would be happy to implement a function in Verovio to change the layout in such a way, except not via making content invisible on the staff-level, but by using scoreDef.

Now, the questions are: should @visible be made usable for changing the layout? If not, then scoreDef would be probably most suitable, which leads to the question: how should this information be included in scoreDef?
In our special case, we would like to use the @label-information of the staffDef in not only the first system, but also each time the instrumentation changes. So we could cheat, delete every invisible staff and use <dir> to label the staves, when new instruments occur, but this is not pretty at all and we would not be happy with this solution.

Thank you very much in advance!

Best regards,
Agnes Seipelt, Peter Provaznik and Paul Gulewycz


Paul Gulewycz, BA
Österreichische Akademie der Wissenschaften
Institut für kunst- und musikhistorische Forschungen
AG Digital Musicology
Dr. Ignaz Seipel-Platz 2
A-1010 Wien
+43/650/646 94 32

<A-WnMus.Hs.44706-231.jpg>
<105.png>
_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
https://lists.uni-paderborn.de/mailman/listinfo/mei-l
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20180711/42cc5908/attachment.html>