[MEI-L] Invisible staves and content
Johannes Kepper
kepper at beethovens-werkstatt.de
Thu Sep 27 20:07:58 CEST 2018
Sorry for coming late to the party ;-)
after considering several options, I think that Laurent's second suggestion is the only solution that seems to have the right balance between encoding of a source and enabling a dynamically generated layout. I think all the problems that Laurent mentioned later on make it relatively clear that the first suggestion is leaving out too much. Another approach might have been to have a single scoreDef at the beginning of the file, which contains all staves. Each measure would then contain only staff elements for parts which are actually visible in that measure. However, this contradicts some discussions we had over the last few years, and it also complicates the encoding of multiple sources, which may not always "flatten" the score in the same way. Especially this requirement seems to forbid the use of an attribute on <staff> (or elsewhere in the measure): It's much easier to have multiple <scoreDef>s nested in an <app> / <rdg>, each capturing the specific situation for one (or more) source(s).
So I would suggest to allow @visible on <staffDef> and <staffGrp>, and require the presence of all <staffDefs> in a <scoreDef>. The only way around this would be a statement in the Guidelines saying that the absence of staffDef/@visible indicates that this staff is visible. If a <staffDef> is omitted, then this rule would still apply. That way, one could selectively modify the key (including transposing instruments) _and_ specify invisible staves at the same time. However, as that often has consequences on <staffGrp>s, it might still not be sufficient to encode only the changing staves. Therefore, I believe this "default behaviour" approach won't be as clear to interpret as it needs to be, and so we should not implement it. To make a long story short: I'm all in for Laurent's second proposal…
All best,
jo
> Am 13.07.2018 um 17:57 schrieb Laurent Pugin <lxpugin at gmail.com>:
>
> On way to handle this is to use a <scoreDef> for indicating a change in a system content. That is, if a system displays only a subset of the staves, then you need to have a <scoreDef> with the desired <staffGrp> and <staffDef>. One question is whereas we expect a <scoreDef> to have 1) only the <staffGrp/<staffDef> that are visible, or 2) always all of them and have a @visible="false" on the ones that needs to be hidden. Both are a valid approach, I think.
>
> So with :
>
> <scoreDef meter.sym="common" key.sig="4s">
> <staffGrp barthru="false">
> <staffGrp barthru="true" symbol="bracket">
> <staffDef n="1" label="Flute" key.sig="4s" />
> <staffDef n="2" label="Oboe" key.sig="4s" />
> <staffDef n="3" label="Clarinet in Bb" key.sig="6s" trans.semi="-2" trans.diat="-1" />
> </staffGrp>
> <staffGrp barthru="true" symbol="bracket">
> <staffDef n="4" label="Violin I" key.sig="4s" />
> <staffDef n="5" label="Violin II" key.sig="4s" />
> <staffDef n="6" label="Viola" key.sig="4s" />
> <staffDef n="7" label="Cello" key.sig="4s" />
> </staffGrp>
> </staffGrp>
> </scoreDef>
>
> We can then have when a system has only strings with 1):
>
> <scoreDef>
> <staffGrp>
> <staffGrp>
> <staffDef n="4" />
> <staffDef n="5" />
> <staffDef n="6" />
> <staffDef n="7" />
> </staffGrp>
> </staffGrp>
> </scoreDef>
>
> Or with 2)
>
> <scoreDef>
> <staffGrp>
> <staffGrp visible="false">
> <staffDef n="1" visible="false" />
> <staffDef n="2" visible="false" />
> <staffDef n="3" visible="false" />
> </staffGrp>
> <staffGrp>
> <staffDef n="4" />
> <staffDef n="5" />
> <staffDef n="6" />
> <staffDef n="7" />
> </staffGrp>
> </staffGrp>
> </scoreDef>
>
> With both cases we can also expect to have an empty <scoreDef> with no <staffGrp>/<staffDef> children to be used but with a slightly different meaning, typically for indicating a time signature or a key signature change. Changing from C to C/ would be just
>
> <scoreDef meter.sym="cut"/>
>
> Now this become a bit tricky with transposing instrument when changing the key signature because a key signature change cannot be specified globally. With solution 1) then you cannot do:
>
> <scoreDef key.sig="2s>
> <staffGrp>
> <staffGrp>
> <staffDef n="3" key.sig="4s" />
> </staffGrp>
> </staffGrp>
> </scoreDef>
>
> because this means that only the clarinet staff has to be shown. So I assume that here you would need to either use @visible too, or to have two consecutive <scoreDef>, one for the key signature change, and one for then specifying the staves to be shown. So something like:
>
> <scoreDef key.sig="2s>
> <staffGrp>
> <staffGrp>
> <staffDef n="3" key.sig="4s" />
> </staffGrp>
> </staffGrp>
> </scoreDef>
> <scoreDef>
> <staffGrp>
> <staffGrp>
> <staffDef n="4" />
> <staffDef n="5" />
> <staffDef n="6" />
> <staffDef n="7" />
> </staffGrp>
> </staffGrp>
> </scoreDef>
>
> Because of this maybe solution would actually more appropriate. Other opinions / ideas?
>
> Of course this is all for cases when the desired output is to render encoded page and system breaks, and not for dynamic rendering. With dynamic rendering, the content of the <scoreDef> for the part of the score rendered in a system has to be calculated by the application. One option is to dynamically hide staves that have only mRest in the corresponding scope. Similarly, a staffGrp will be hidden when all staves are empty.
>
> Laurent
>
>
>
> On Wed, Jul 11, 2018 at 5:03 PM, Gulewycz, Paul <Paul.Gulewycz at oeaw.ac.at> wrote:
> We adapted Verovio in such a way that zooming does not change the layout but enlarges or minimizes the score. So the layout will be displayed correctly. And yes, we also want to include the original manuscript next to the edition, that's why we want to keep the layout as close to the facsimile as possible, so the orientation will be enhanced for the users. It will be possible to select a single page or a composition or an exercise, which will produce the facsimile on the left side and the edition on the right side of the screen.
>
> I agree with your encoding-first approach, unfortunately all my ideas circle around changing the encoding for the sake of rendering it in the right way, e.g. cross-staff notation via @staff, which is why they are relatively useless. Our problem is very specific, but, needless to say, it would be great to find a solution, which others might also find useful for their encoding and displaying of data. I find condensing two staves quite interesting, but again, this would be handy for an/our adapted Verovio version and probably nothing much else, because of the zoom function, and also raises the question, where to put the information for doing so.
>
> -----Ursprüngliche Nachricht-----
> Von: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] Im Auftrag von Andrew Hankinson
> Gesendet: Mittwoch, 11. Juli 2018 15:51
> An: Music Encoding Initiative <mei-l at lists.uni-paderborn.de>
> Betreff: Re: [MEI-L] Invisible staves and content
>
> 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
>
> _______________________________________________
> 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
More information about the mei-l
mailing list