[MEI-L] How to use <ftrem>

Fri Jun 17 16:17:48 CEST 2011

While I'm sort of a Score devotee, I think that the repetition
frequency should definitely be derivable from @slash.  But thinking
about it a bit longer, it's really tricky.  As the visual appearance
is only uncertain for half notes, what would using @beam on notes
other than half notes mean?  That wouldn't make a lot of sense.  For
@dur=16, it would look as if one should set @beam=2, but that would be
very inconsistent with the meaning of n=@beam "n of the slashes are
written as beams".

Thomas Weber

2011/6/17 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>:
> To me, the inconsistency Thomas reports in the various ways of counting the number of beams vs. slashes indicates different rendering possibilities for the same semantic construct.  While it provides rendering "hints", in general, MEI leaves rendering to a down-stream process.  Perhaps, however, ftrem is a case where it would make sense to provide enhancements to the current hints; so, I'm not averse to adding a beam attribute on ftrem.
>
> Adding @beam is easy, but it forces us to formulate a convention for what counts as a "beam" and what counts as a "slash".  Assuming that beams are the things that connect stems and slashes are those things that are between the stems (but don't touch them) is the simplest solution.  But, then @slash can't be used to accurately calculate the repetition frequency in a sounded rendition.  So this must lead us to another attribute that will carry this information.  This might be an improvement as this new attribute could be placed in the gestural domain, leaving the others in the logical/visual domain.
>
> Another approach might be to count everything (whether it connects the stems or not) as a "slash", with @beams recording the subset of the slashes that actually connect the stems.  This will allow us to continue to calculate the repetition frequency based on the value of @slash.
>
> I can see advantages and disadvantages in both these solutions.  I think the literalists among us (OMRers, Score devotees, perhaps?) will prefer the first one, while those who are interested more in semantics than visualization might prefer the second.  I'm not attached to either one, but I think Thomas' arguments are convincing, so I lean toward the first option above.  Anyway, now is the time to make a change if we need to.  Comments here will help in the decision, so please speak up.
>
> BTW, I don't want to ignite a religious war over the terminology "beam" and "slash".  As always, if anyone has an idea for better names, I'm listening.
>
> --
> Perry
>
> __________________________
> Perry Roland
> Music Library
> University of Virginia
> P. O. Box 400175
> Charlottesville, VA 22904
> 434-982-2702 (w)
> pdr4h (at) virginia (dot) edu
> ________________________________________
> From: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of TW [zupftom at googlemail.com]
> Sent: Friday, June 17, 2011 4:45 AM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] How to use <ftrem>
>
> Hi Roland,
>
> thanks for your reply.  I have a handful of notation books on the
> shelf, among them Read.  The image that is reproduced in the
> documentation is from page 395.  But on many other occurences of
> fingered tremolos in his book (p. 235-236, p. 330, p. 371-372), using
> either one beam+slashes or only beams on half notes.  Does he make a
> distinction in notation between measured and unmeasured tremolo that I
> don't quite get?
>
> By the way, all of the books I checked seem to use the terminology
> "beam" in the context of fingered tremolos.  (Helene Wanske even talks
> about beams (Balken) if the slashes aren't fully connecting the
> stems.)
>
> Here's what my sources say:
> - Helene Wanske: Musiknotation, p. 117: half notes connected with full
> 32nd beams; I didn't see an alternative in the book [on p. 167 she
> says, quarter notes, although the "beam" doesn't entirely connect the
> stems, are regarded as "beamed"]
> - Brockhaus Riemann Musik-Lexikon: Abbreviaturen 4): half notes with
> one, two and three full beams, no alternatives
> - Herbert Chlapik: Die Praxis des Notengrafikers, p.46: there are half
> notes with one, two and three full beams on this page, no other
> notation with half notes
> - George Heussenstamm: The Norton Manual of Music Notation, p. 55:
> "Preferred Notation": half notes with one beam and two slashes,
> "Traditional Notation": half notes with three full beams,  "Possible
> Notation": half notes without full beams and three slashes.
> Interestingly, on p. 56 he only uses "Traditional Notation" instead of
> "Preferred Notation".
> - Ted Ross: The Art of Music Engraving and Processing, p. 199: there
> is an example of fully beamed half notes first, then "or" and the same
> example notated with one beam and two slashes.  Later on he uses the
> fully beamed notation for one example and the beams+slashes version
> for another example so his use is pretty balanced between the two
> notations.
>
> So the "no slashes, all beams" solution is given six times, the "one
> beam, rest slashes" solution is given three times (both numbers
> including Read) and Heussenstamm's "Possible Notation" is given once.
> Maybe someone can check what Faber Music's "Behind Bars" says - that's
> not yet part of my collection (and also pretty expensive).
>
> In my opinion there *should* be a convention for specifying the number
> of beams.  There doesn't seem to be a single correct solution.  It's
> probably best if the "repetition frequency" can directly be derived
> from @slash.  But <beam> doesn't allow specifying the number of beams,
> that's implicit.
>
> And yes, I meant @dur on ftrem, just like with chords.
>
> Thomas Weber
>
>
> 2011/6/17 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>:
>> Hi Thomas,
>>
>> One should never count beams separate from slashes -- count only slashes.  Treating tremolandi this way makes them uniform in the markup regardless of the note durations involved.  So, the way to encode your first example is
>>
>> <ftrem slash="4">
>>  <note pname="f" dur="32" oct="4"/>
>>  <note pname="a" dur="32" oct="4"/>
>> </ftrem>
>>
>> Your second example should be
>>
>> <ftrem slash="3">
>>  <note pname="f" dur="2" oct="4"/>
>>  <note pname="a" dur="2" oct="4"/>
>> </ftrem>
>>
>> In fact, all the tremolandi except the last are encoded exactly the same way (<ftrem slash="3">) except for the note durations.  Now, exactly *how* the slashes are drawn is left to the rendering process.
>>
>> What you're calling a "beam" isn't really.  Depending on the rhythmic values involved, one or more of the "slashes" are drawn connecting the notes (making it/them look "beam-like"), the rest are disconnected from the note stems.  Therefore, none of the notes in the example are "properly" or "improperly" beamed -- they're not "beamed" at all.
>>
>> I don't have access to Read at the moment, but the rules for tremolandi are covered there.  In fact, this example comes directly from Read, which is invaluable for answering notational questions.  I highly recommend that anyone working with CMN notation have a copy nearby.  And, no, I don't get any reward from the author or the publisher for the recommendation.
>>
>> I suppose that somewhere out in the "wild" there are 2-beat tremolos with "no beam and 3 slashes" (especially in manuscript), but that notation would just be incorrect.  If we set ourselves the goal of representing incorrect notation, then we'll be back to describing "lines and circles"; in other words, nothing more than the marks on the page.  If it's important, one can include a facsimile image to show the incorrect notation, using something like
>>
>> <ftrem slash="3" facs="idOfTheZoneContainingIncorrectNotation">.
>>
>> I think adding @dur on ftrem makes sense because it would allow the omission of it on the individual notes, just as on chord.  Is that what you were thinking?
>>
>> Yes, the documentation is an on-going effort.  Regrettably, I haven't had as much time to devote to it as it deserves. Any volunteers to mark up the notation in the Tag Library?
>>
>> --
>> p.
>>
>> __________________________
>> Perry Roland
>> Music Library
>> University of Virginia
>> P. O. Box 400175
>> Charlottesville, VA 22904
>> 434-982-2702 (w)
>> pdr4h (at) virginia (dot) edu
>> ________________________________________
>> From: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of TW [zupftom at googlemail.com]
>> Sent: Thursday, June 16, 2011 5:34 AM
>> To: Music Encoding Initiative
>> Subject: [MEI-L] How to use <ftrem>
>>
>> I'm not sure what's the proper way of using <ftrem>.  If I want to
>> encode the last <ftrem> from this image:
>>
>> http://www.music-encoding.org/pix/tagLibrary/meiTagLibrary2010-05_html_25c82644.png
>>
>> would I do it like this (assuming it's in treble clef):
>>
>> <beam>
>>  <ftrem slash="1">
>>    <note pname="f" dur="32" oct="4"/>
>>    <note pname="a" dur="32" oct="4"/>
>>  </ftrem>
>> </beam>
>>
>> i.e. this is a pair of properly beamed 32nd notes with an additional
>> stroke, or like this:
>>
>> <ftrem slash="4">
>>
>>  <note pname="f" dur="32" oct="4"/>
>>
>>  <note pname="a" dur="32" oct="4"/>
>>
>> </ftrem>
>>
>>
>> assuming that slash="4" and @dur="32" imply that we have three beams
>> and one slash?
>>
>> Analogously, how would I encode the second <ftrem>:
>>
>> <beam>
>>
>>  <ftrem slash="2">
>>
>>    <note pname="f" dur="2" oct="4"/>
>>
>>    <note pname="a" dur="2" oct="4"/>
>>
>>  </ftrem>
>>
>> </beam>
>>
>> i.e. a pair of "improperly" beamed half notes with an additional
>> slash?  I'm not sure, could there be half note heads with two or more
>> beams?  How do I tell how many beams?  Or like this:
>>
>> <ftrem slash="3">
>>
>>  <note pname="f" dur="2" oct="4"/>
>>
>>  <note pname="a" dur="2" oct="4"/>
>>
>> </ftrem>
>>
>>
>> and ftrem/@slash="3" and note/@dur="2" imply that I have one beam and
>> two slashes?  Could there be half notes without beam and only with
>> slashes?  And wouldn't it make sense to have an ftrem/@dur attribute,
>> analogously to chord/@dur?
>>
>> It would be great if the images in the documentation could be
>> supplemented with code examples (did I understand correctly that this
>> is work in progress?)
>>
>> Thanks!
>> Thomas Weber
>>
>> _______________________________________________
>> 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
>