[MEI-L] ...brackets in orchestral scores: Finale shapes, etc.

[Raffaele Viglianti]

Let's assume that we add the extra attribute on scoreDef to specify the
presence/absence of this line. Shouldn't we then think of a way to specify
whether barlines are drawn continuously between staves or not? Or whether
stems are extended through beams or not (e.g. French beams)?

I still think that if the line means some sort of grouping (or if the
encoder thinks so), let there be an extra staffGrp. If it's only a
convention / editing house style, then it shouldn't matter for MEI, like
French beams don't matter at the moment. Though someone may want to study
the evolution of beam typesetting in Alsace-Lorraine and whether local
musicians switched between French and German style... I'm making things up
just to point out that any mark on the page is not "semantic" until we
decide it is.

Raf


On Mon, Dec 16, 2013 at 4:28 PM, Andrew Hankinson <
andrew.hankinson at mail.mcgill.ca> wrote:

> Two clarifying questions:
>
> 1) You wouldn’t be talking about eliminating all nested <staffGrp />,
> would you?
> 2) Why would you bump this up to <scoreDef />? How would that eliminate
> the need for schematron rules? (Keeping the symbol on <staffGrp /> seems a
> bit more explicit to me.)
>
> For reference, Sibelius refers to the first line as the “Initial barline”,
> not as a grouping symbol. You can en/disable showing this, but
> interestingly disabling the initial barline also hides any brackets
> associated with the group. If you re-enable the barline, it will show the
> bracket or brace.
>
>
> On Dec 16, 2013, at 10:09 AM, Roland, Perry (pdr4h) <
> pdr4h at eservices.virginia.edu> wrote:
>
> >
> > Thinking about Laurent's original question a little more, I've come to
> realize that my original thinking on staff grouping was, well, misguided.
> >
> > I now think that instead of reserving @symbol="line" for the left-hand,
> staff-connecting line, another attribute should be added to <staffGrp> (or
> even on <scoreDef>) to capture the presence of this line.  This eliminates
> the need for nested <staffGrp> elements as well as the need to change any
> existing software.
> >
> > This new attribute (I'm still casting about for a name) should take a
> value of true or false depending on the presence/absence of the connecting
> line.  Of course, this attribute can only make sense when it's on the
> outermost <staffGrp>.  This is a good argument for pushing it up a level to
> <scoreDef>.  Doing that eliminates the need for schematron rules or
> reliance on convention to enforce good practice.
> >
> > The existing @symbol attribute with a value of "line" can be used (as in
> MusicXML) to describe the presence of a wide line used as the grouping
> symbol.  Of course, the Guidelines will need to be changed to reflect these
> changes.
> >
> > I'm aware that changes like this, that is, keeping the same markup but
> changing its meaning, are dangerous.  But sometimes it's the simplest, and
> indeed the best, solution.
> >
> > Humbly,
> >
> > --
> > p.
> >
> >
> > __________________________
> > Perry Roland
> > Music Library
> > University of Virginia
> > P. O. Box 400175
> > Charlottesville, VA 22904
> > 434-982-2702 (w)
> > pdr4h (at) virginia (dot) edu
> > _______________________________________________
> > 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/20131216/487b02bd/attachment.html>