[MEI-L] Invisible staves and content

[Eleanor Selfridge-Field]

It may be that this question does not have a simple answer, because invisible staves come up in radically different contexts.  In our own work with MuseData, there are three situations where they may play a role:


1.      Ambiguous scoring (mainly early 18th century): a single written part modified with written cues to signal switches between a single timbre (violin), a different single timbre (oboe), or the two doubling one part.

2.      Dialogue set in recitative (18th-19th centuries): Role A and Role B (C, D) in rapid exchange on a single staff, but logically occupying more than one staff (all be empty when not in use).

3.      Facsimile of the sort Paul describes: the composer is sketching an idea and tracing the dominant part.  In Vivaldi it is common for the editor to supply the viola part, because often it is indicated only as as “colla parte” on a blank staff.

If a replica is desired, that may suggest one solution.

If the numbers or identities of singers or instruments is changing frequently, that may constitute a situation worth recognizing as sui generis.  To generate scores we use a Boolean switch: A and B, or A or B (a total of three states). The implementation works well.

Eleanor


Eleanor Selfridge-Field
Braun Music Center #129
541 Lasuen Mall
Stanford University
Stanford, CA 94305-3076
https://profiles.stanford.edu/eleanor-selfridge-field







From: mei-l <mei-l-bounces at lists.uni-paderborn.de> On Behalf Of Andrew Hankinson
Sent: Tuesday, July 10, 2018 10:27 AM
To: Music Encoding Initiative <mei-l at lists.uni-paderborn.de>
Subject: 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/bb4dc730/attachment.html>