[MEI-L] clef as milestone element
Raffaele Viglianti
raffaeleviglianti at gmail.com
Tue May 31 09:35:40 CEST 2011
Dear all,
I agree that using clefchange and staffdef for courtesy clef repetitions is
a bit cumbersome, but I would advise against overweighting <pb/> and <sb/>.
In my opinion they should only signify the break and contain nothing. A
custos should occur *before* (or occasionally after) the system break and
not within the system break. If you think about it, that is what happens on
the page. In the same way, the clef repetition should not be attached to sb
or pb.
Moreover, I have come across clef repetitions that do not happen at system
or page break. This is quite common for orchestral works, where some
instruments may not play for a few pages and on reprise, the scribe writes
the clef for clarity. You can see how this can easily happen in the middle
of the page.
Best,
Raffaele
On Tue, May 31, 2011 at 8:21 AM, Andrew Hankinson, Mr <
andrew.hankinson at mail.mcgill.ca> wrote:
> Currently, <clef> isn't allowed directly in <layer>, which was what spurred
> the whole problem in the first place. And, although this was my first
> suggestion -- that we do allow <clef> in <layer> -- I think I'm now of the
> opinion that it could be made a part of <sb/>.
>
> <sb /> is, almost by definition, a child of a staff. A system is a page
> layout convention, because we can't fit staves on a single continuous piece
> of paper (unless we're encoding Piano Roll music, but I suspect that's a job
> for the PRMEI project. :). So we use <sb/> to encode where a system break
> occurs while still maintaining the music notation as a member of a given
> staff. So I definitely think that <sb> should be a child or descendent of
> <staff>.
>
> That, and we don't have measures in our music, so we can't assume a split
> over two measures.
>
> -Andrew
>
>
> On 2011-05-31, at 2:58 AM, Maja Hartwig wrote:
>
> > Hi Andrew!
> > What about this solution? There would be no need for a new <staffdef>.
> >
> > <sb/>
> > <measure>
> > <staff>
> > <layer>
> > <clef visible="true">
> > <layer>
> > </staff>
> > </measure>
> >
> > K and M
> >
> > Am 31.05.2011 um 08:46 schrieb Andrew Hankinson, Mr:
> >
> >> Thanks, Johannes,
> >>
> >> I guess I would still have a semantic problem with a particular
> <staffdef /> defining a staff property while it was a *child* of a given
> staff. If I understand correctly, you're suggesting:
> >>
> >> <staff>
> >> ...
> >> <sb />
> >> <staffdef clef.repeat="?true?" />
> >> ...
> >>
> >> In this case, the staffdef would define the properties of its parent,
> which is what I think I have the biggest semantic problem with. This, and
> for optimal parsing we would have to have some way of linking which clef it
> would repeat, which would be problematic (but certainly not impossible) if
> we were to go with the convention of pre-defining <staffdef>s outside of the
> "flow" of the notation.
> >>
> >> -A
> >>
> >>
> >>
> >> On 2011-05-31, at 2:36 AM, Johannes Kepper wrote:
> >>
> >>> Hi Andrew,
> >>>
> >>> what about solution d): add a new attribute to <staffdef> called
> @clef.repeat (or similar)? This could provide a rule of thumb which could
> then be overridden by staffdef/clef if necessary. Seems to be much simpler
> to me, and <staffdef> already captures defaults like this one.
> >>>
> >>> Best,
> >>> Johannes
> >>>
> >>>
> >>> Am 31.05.2011 um 08:11 schrieb Maja Hartwig:
> >>>
> >>>> Hi Andrew!
> >>>> We think you are right, that a clefchange makes no sense within this
> context.
> >>>> Did you already tried this solution?
> >>>>
> >>>> <measure>
> >>>> <staff>
> >>>> <layer>
> >>>> <note/>
> >>>> <sb/>
> >>>> <staffgrp>
> >>>
> >>> <!-- what's the reason for the extra <staffgrp> here? As we're in
> <layer>already, it should be clear that only this one staff is affected -->
> >>>
> >>>> <staffdef>
> >>>> <clef line="2" shape="G"/>
> >>>> </staffdef>
> >>>> </staffgrp>
> >>>> <note/>
> >>>> </layer>
> >>>> </staff>
> >>>> </measure>
> >>>>
> >>>> Nothing against crazy solutions ;-), but in our opinion, allowing
> <clef> within <sb> is not the best way to encode this, because <sb>
> applies only the layout as you said, but the <clef> should be regarded as
> an independent element. If the clef appears in the second measure after a
> systembreak e.g, you have to indicate that, too, but it has nothing to do
> with a <sb>.
> >>>>
> >>>> <measure n="1"/>
> >>>> <sb/>
> >>>> <measure n="2"/>
> >>>> <measure n="3">
> >>>> <staffgrp>
> >>>> <staffdef n="1" clef.line="2"
> clef.shape="G"/>
> >>>> </staffgrp>
> >>>> <staff n="1">
> >>>> <layer>
> >>>> <note/>
> >>>> </layer>
> >>>> </staff>
> >>>> </measure>
> >>>>
> >>>> We would prefer to keep it within <staffdef>.
> >>>>
> >>>> Best,
> >>>> Kristina and Maja
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Am 31.05.2011 um 01:18 schrieb Andrew Hankinson, Mr:
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> tl;dr Should clefs be considered a milestone element?
> >>>>>
> >>>>> The <clef> element in MEI is currently only allowed within
> <clefchange> and <staffdef> elements. I can understand why, since <staff> is
> supposed to reflect musical linearity and not be affected by system breaks,
> which is more a physical artifact of page layout. So, a <clef> should only
> occur if a) it's part of the staff definition, or b) it's changing.
> >>>>>
> >>>>> *However*, an interesting question comes up when encoding clefs at
> the beginning of systems. Currently, the only way to encode this is to wrap
> a <clef> in a <clefchange>, but for most of the time, it's not actually
> changing; it's only a "courtesy" clef.
> >>>>>
> >>>>> So, to give an example. Suppose the following:
> >>>>>
> >>>>> <staff n="1">
> >>>>> <layer n="1">
> >>>>> <sb n="1"/>
> >>>>> <clef line="3" shape="F"/>
> >>>>> <note pname="f" oct="3"/>
> >>>>> <note pname="g" oct="3"/>
> >>>>> ...
> >>>>> <sb n="2" />
> >>>>> <clef line="3" shape="F"/>
> >>>>> <note pname="c" oct="3"/>
> >>>>> <note pname="d" oct="3"/>
> >>>>>
> >>>>> ...etc...
> >>>>>
> >>>>> This is currently invalid MEI, but I'm not really sure how to capture
> the clefs at the beginning of each system without a) incorporating them into
> a <clefchange> (semantically wrong), b) allowing <clef> directly within
> layer, or (really crazy) c) changing <sb> to include clef information (e.g.,
> allow <clef> within <sb>, and/or add @clef.shape and @clef.line directly on
> <sb>.
> >>>>>
> >>>>> What I'd like to suggest is option b), but I'm sure there's a very
> good reason why I'm wrong. :)
> >>>>>
> >>>>> -Andrew
> >>>>> _______________________________________________
> >>>>> 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
>
>
> _______________________________________________
> 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/20110531/a49f84a3/attachment.htm>
More information about the mei-l
mailing list