[MEI-L] Invisible staves and content
Laurent Pugin
lxpugin at gmail.com
Fri Jul 13 17:57:28 CEST 2018
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20180713/f1ff0ef8/attachment.html>
More information about the mei-l
mailing list