[MEI-L] Invisible staves and content

[Andrew Hankinson]

I think there needs to be a clear separation here between what you're "encoding" (that is, the change of instrumentation) and what you're "displaying" (that is, how it is being rendered). I would favour an encoding-first approach, recognising that display in a digital context will be very different than how it is physically represented on the page.

In a dynamic rendering environment (like Verovio), it would be very hard to maintain the appearance of the original study book while still doing all the things that Verovio does really well, like fitting as much music on the screen as it can depending on screen size and zoom level. Faithfully reproducing the layout, and dynamically rendering the notation, are two very different tasks.

You said "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."

This will be problematic with Verovio. "in the beginning" may be halfway across the screen, depending on screen size and zoom level. Similarly "as soon as they occur" may necessitate rendering a big blank gap. Or do you want Verovio to automatically condense the staves into a single system so that the Viola starts on the same system as the oboe? (for example). Doing these things well, with an infinite number of possible screen sizes and zoom levels, will be very difficult.

Is there provision for your application to display the original facsimile image? Then you would not have to worry about reproducing the layout in Verovio -- you can show your users what the original looked like, while still allowing for things like dynamic playback and interaction through Verovio.

If you really want to try and preserve the look of the original, I would recommend bringing in the <surface>/<facsimile>/<zone> functions and aligning the musical content with the image using pixel-based co-ordinates. But that would be much more difficult to do manually.

-Andrew

> On 11 Jul 2018, at 14:27, Gulewycz, Paul <Paul.Gulewycz at oeaw.ac.at> wrote:
> 
> 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> 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
> 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