[MEI-L] Beat in 6/8

[Roland, Perry D. (pdr4h)]

I have a problem with how @tstamp and @tstamp2 are described with regard to the proposed <cpMark> element.  In every other case, these two attributes refer to *points in time*, not durations.  For example, when we say

<slur tstamp="1" tstamp2="3"/>

we mean that the slur begins on beat unit 1 and ends precisely on beat unit 3.  If we want it to end somewhere in the middle of beat unit 3, then we must use the value "3.5".  (But this still means it ends precisely on the & of 3 and doesn't describe how long it lasts.)  It is therefore inconsistent for <cpMark> to use these attributes to mean "get the stuff between beat units 1 and 3 *inclusive of beat unit 3*".  Either we must re-define how these attributes work (an onerous task that might break a lot of other things, I believe) or different attributes must be used on / defined for <cpMark>.

Returning to the example above, if we want to capture the *duration* of the slur, then we must write

<slur tstamp="1" dur="2."/>

Now *this* says that the slur begins on beat unit 1 and *lasts for a dotted half-note*; that is, inclusive of the endpoint of the dotted half-note.  The use of @dur instead of @tstamp2 resolves the inconsistency between the definition of @tstamp2 on <cpMark> and that used elsewhere.

I'd have to see more examples of the use of <cpMark> to speak definitively about @ref.offset and @ref.offset2, but I suspect that using a time point / @tstamp for the first and a duration (instead of a time point) for the second may work better; that is, retain consistency.

--
p.


> -----Original Message-----
> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of
> Roland, Perry D. (pdr4h)
> Sent: Friday, September 04, 2015 9:54 AM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] Beat in 6/8
> 
> 
> Yes, <beatRpt> should/must stay.  I think <cpMark> is a great idea, but
> adding all the attributes that more specific elements like <beatRpt> need
> would cause a great deal of confusion.  I'm concerned about the potential for
> confusion in the addressing system Jo proposes, but let's think about the
> possibility of creating a cpMark attribute class that provides this kind of
> addressing and make the <*Rpt> elements members of this new class.  This
> way, <*Rpt> elements may use the new addressing possibilities while
> retaining their specialized attributes.
> 
> Another alternative already present in MEI is the use of <choice> with <abbr>
> (containing <beatRpt>) and <expan> (containing the performed result) sub-
> elements.  This is another way to be explicit about what is written and its
> performance implications.  This is somewhat verbose, however, and not
> obvious to our classic "naive encoder" (otherwise known as OMR).  My
> suggestions yesterday were an attempt to locate all one might need to know
> about a <beatRpt> element in/on the element itself.
> 
> As for Z's example of complex time signatures, I can't ever recall seeing such
> usage.  This is not proof that such things don't exist, but it's my impression
> that users of such things eschew the use of traditional CMN approaches to
> repetition.  Just in case, however, @beatDef could use the
> data.DURATION.additive datatype that allows multiple, optionally dotted
> values, which taken together add up to the desired amount of time.
> 
> --
> 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Johannes
> Kepper [kepper at edirom.de]
> Sent: Friday, September 04, 2015 5:32 AM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] Beat in 6/8
> 
> Hi Zoltan,
> 
> 
> Am 03.09.2015 um 23:47 schrieb Kőmíves Zoltán <zolaemil at gmail.com>:
> 
> > Hi Jo,
> >
> > Interesting proposition! I am sure there are great use cases for this,
> especially for editorial purposes. My feeling is that the sugar of beatRpt
> would still be handy for a great deal of cases.
> >
> 
> By no means I'm in favor of removing all the specialized <*Rpt> elements, so
> <beatRpt> should definitely stay. It's just that the <cpMark> can be very
> explicit about what to copy in cases where the "beat" may be confusing.
> 
> 
> > I have couple of questions:
> > 1. tstamp="2" tstamp2="0m+2": it seems to me that a context is needed in
> order to determine how long this repetition lasts, i.e. it will last for as long as
> the material at tstamp="2" lasts for. Do I understand this correctly?
> 
> Well, afaik we didn't come across a beatRpt that would have been replaced
> by a <cpMark>. In essence, this is another occasion of the "ending tstamp"
> discussion Raffaele brought up with addressability proposal. My assumption
> with encoding this (in 4/4) was that the first beat holds a quarter note. If
> there were 8th notes, I would have written tstamp2="0m+2.5". I know this
> isn't absolutely satisfactory, but I believe it's a more general problem, which
> just surfaces in this situation. But yes, your understanding is correct.
> 
> > 2. What would the "target slot" addressed by the @ref.* attributes
> contain? <space> perhaps?
> 
> That's how we used it. Actually, we generated a <choice>, with an <abbr>
> containing a space, and an <expan> containing the copied material. This way,
> you can simply decide if you want to see the source as it is written or as it is
> performed. In addition, all "copied" notes etc. have a @corresp pointing to
> their original counterpart, which makes certain analytical approaches very
> simple.
> 
> > 3. ref.tstamp2 feels redundant. Is it mainly for convenience reasons?
> > (I could see why, especially when the target context has a different
> > meter...)
> 
> In most cases, it is redundant (and could be defaulted to the value of
> @tstamp2 in the documentation). However, if you try to encode a
> <halfmRpt> with the means of <cpMark> (which we did quite often), your
> origin sits in a different slot than the target. The complex meters you brought
> up in your other mail also require to have a separate attribute for this, I
> believe.
> 
> Thanks,
> jo
> 
> >
> > Best
> > Zoltan
> >
> >
> > 2015-09-03 21:49 GMT+01:00 Johannes Kepper <kepper at edirom.de>:
> > Hi all,
> >
> > sorry for coming to this discussion very late. Fwiw, I'd like to mention an
> element we came up with during the Freischütz project, which still lacks
> sufficient documentation to be implemented into general MEI – even though
> I strongly believe it's very useful for other projects as well. In essence, it's a
> more general approach to repeat symbols and other notational "shortcuts".
> We call it a "cpMark", where the "cp" may be read as "copy" and / or "colla
> parte". This element is a controlEvent (= it lives inside a measure, just like a
> slur or dir). In a 4/4 measure, a beatRpt on the second beat of the first staff
> could look like this:
> >
> > <cpMark staff="2" tstamp="2" tstamp2="0m+2" ref.offset="0m+1"
> > ref.offset2="0m+1">/</cpMark>
> >
> > The attribute pair @tstamp and @tstamp2 is used to delimit the "beats"
> that this element will say something about – just as in any other control
> event. "beats" in this context is clearly the numbers of the @meter.count.
> Then, the attribute pair @ref.offset and @ref.offset2 is used to say from
> where context is to be copied into this "empty" or "abbreviated" slot.
> @ref.offset uses the same data type as @tstamp2, with the only difference
> that the first number (the one before the "m+" part) may take negative
> values, that is, refer to preceding measures), and @ref.offset2 uses the exact
> same data type as @tstamp2 (it's value is relative to the origin defined by
> @ref.offset). These elements may be combined or replaced by @ref.staff
> (and @ref.layer), which allow to do a colla parte encoding ("…for the range
> defined by @tstamp and @tstamp2, just copy in the stuff in @ref.staff,
> potentially affected by @dis for an 'in ottava'…"). The cpMark may contain
> textual content (plus some editorial stuff) to grab what the source says – a
> simple slash, a verbal instruction, whatever.
> >
> > This is just a very brief introduction to this element, but I hope you get the
> idea. Like I said, I'm not sure if it really helps in this discussion of <beatRpt>,
> but I think it allows to be very explicit about the scope of a beat repetition
> symbol. In my understanding, <beatRpt>, <mRpt>, and all the other <*Rpt>
> elements are syntactic sugar for this <cpMark> element, which is really a
> more semantic solution for a specific type of <dir>. Would it be an option to
> use <cpMark> instead of <beatRpt> – just to be more explicit? I think this is
> more or less in line with Perry's second suggestion, or at least I believe we
> should coordinate the search for an additional attribute with our <cpMark>
> proposal.
> >
> > Hth,
> > jo
> >
> >
> >
> >
> >
> > Am 03.09.2015 um 21:15 schrieb Roland, Perry D. (pdr4h)
> <pdr4h at eservices.virginia.edu>:
> >
> > >
> > > Hi,
> > >
> > > Thanks for contributing to the discussion, Zoltán.  As usual, I too am in
> favor of multiple encoding methods, especially in the early phases of trying
> to figure out the best approach – we can deprecate all but one at the point
> where the “right” solution is obvious.
> > >
> > > That being said, and despite what I said earlier about the co-occurrence
> of @copyof and @plist, I think the two approaches here are:
> > >
> > > 1. add @plist to <beatRpt> to allow explicit referencing of the
> > > events to be repeated 2. add another attribute, yet to be named, to
> > > permit encoding of the amount of time to be repeated
> > >
> > > The first option is super easy – just make <beatRpt> a member of att.plist.
> The differentiation of @plist and @copyof must remain clear, however.
> @plist identifies the events to be repeated while @copyof identifies the
> element *which the beatRpt element is a copy of*.  The likelihood of any
> element being a copy of another one is rare, so the use of @copyof should
> also occur very infrequently.
> > >
> > > The second option is somewhat more complex, but still practical.  I just
> don’t think we can overload @dur or @dur.ges for this purpose.  I suggest
> that syntax similar to that of @dur.ges be used but another name selected,
> perhaps “beat” or “beatDef”, as its purpose is to define what constitutes a
> beat in a particular context.  Here, we *are* talking about metrical/musical
> beats, not MEI beat units.  So, in a measure of 6/8, @beatDef should take
> the value “4.r” (using Humdrum notation). This defines a repeated beat as a
> dotted quarter note.  Suggestions for a better name for this attribute are
> greatly appreciated.
> > >
> > > Adding these new attributes may help with automated resolution of a
> beatRpt sign, but their presence can’t be required, meaning that can’t rely on
> them entirely in the determination of how much time or which events should
> be repeated.  There always has to be a fallback approach that makes a
> reasonable guess based on the context.
> > >
> > > I’ve had a cursory look at where/how the term “beat” is used in
> descriptions and documentation and I think that simply replacing “beat” with
> “beat unit” won’t work well.  It probably would be better to look for places to
> insert new text about how MEI treats compound meters literally, for example
> in section 4.1.5 “Timestamps and Durations”.
> > >
> > > Sound good?
> > >
> > > --
> > > p.
> > >
> > >
> > >
> > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf
> > > Of Komíves Zoltán
> > > Sent: Tuesday, September 01, 2015 5:55 AM
> > > To: Music Encoding Initiative
> > > Subject: Re: [MEI-L] Beat in 6/8
> > >
> > > Hi All,
> > >
> > > As far as I understand there have been two suggestions to solve the
> problem of determining the material that is repeated by <beatRpt>:
> > > 1. use @dur attribute on beatRpt to indicate how much of the preceding
> material is repeated.
> > > 2. provide explicitly what material is repeated.
> > >
> > > I think both solutions make sense. The first one is concise, and has
> > > no complicated implications, while the second one provides more
> > > flexibility - I sense there could be situations when the (1) would
> > > not suffice, perhaps some multi-voice situation when only the
> > > material in one voice is repeated, but don't want to think about
> > > this too hard now... :)
> > >
> > > Could we perhaps allow both solutions, so encoders could chose
> whichever fits best their use case?
> > >
> > > Regarding the discussion of beat in compound meters, I also think it's
> perhaps best to stay away from defining the beat as such, but I also support
> to clarify terminology: using "beat unit" rigorously could be a good enough
> solution.
> > >
> > > Best
> > > Zoltan
> > >
> > >
> > > 2015-08-27 22:57 GMT+01:00 Roland, Perry D. (pdr4h)
> <pdr4h at eservices.virginia.edu>:
> > >
> > > Here are some possibilities for moving forward --
> > >
> > > Using @copyof on beatRpt makes it possible to indicate which events
> > > are to be repeated; for example --
> > >
> > > <measure>
> > >   <note dur="8" xml:id="n1"/>
> > >   <note dur="8" xml:id="n2"/>
> > >   <note dur="8" xml:id="n3"/>
> > >   <beatRpt copyof="#n1 #n2 #n3"/>
> > > </measure>
> > >
> > > or perhaps
> > >
> > > <measure>
> > >   <beam xml:id="beam1">
> > >     <note dur="8" xml:id="n1"/>
> > >     <note dur="8" xml:id="n2"/>
> > >     <note dur="8" xml:id="n3"/>
> > > </beam>
> > >   <beatRpt copyof="#beam1"/>
> > > </measure>
> > >
> > > In previous discussions about using the copyof attribute, it has been
> determined that the copy is a modified "deep" one; that is, that the result
> tree has the same structure as the designated node with certain attribute
> values removed or modified, like xml:id, for example.
> > >
> > > There's a slight problem with using @copyof, however, in that it doesn't
> allow multiple URIs. We could allow multiple values, but I'm not sure what it
> means to say that something is a copy of more than one thing.  That means
> it's a synthesis, doesn't it?  :-)  So, I'm a little reluctant to add @copyof and I
> lean more toward adding @plist instead.  Of course, this also gets us into a
> little trouble as both @copyof and @plist would be allowed.  As a work-
> around, a new @targets (notice the plural) could be added to beatRpt.
> > >
> > > Another option is to allow beatRpt to contain content -- either new
> > > events that duplicate those that the repetition sign refers to or
> > > <ptr> elements that reference the events; for example,
> > >
> > > <measure>
> > >   <note dur="8" xml:id="n1"/>
> > >   <note dur="8" xml:id="n2"/>
> > >   <note dur="8" xml:id="n3"/>
> > >   <beatRpt>
> > >     <note dur="8" xml:id="n4"/>
> > >     <note dur="8" xml:id="n5"/>
> > >     <note dur="8" xml:id="n6"/>
> > >   </beatRpt>
> > > </measure>
> > >
> > > or
> > >
> > > <measure>
> > >   <note dur="8" xml:id="n1"/>
> > >   <note dur="8" xml:id="n2"/>
> > >   <note dur="8" xml:id="n3"/>
> > >   <beatRpt>
> > >     <ptr target="#n1"/>
> > >     <ptr target="#n2"/>
> > >     <ptr target="#n3"/>
> > >   </beatRpt>
> > > </measure>
> > >
> > > Each one of these options allows an easy "toggling" between the
> repetition sign and the material inside.  The 2nd method may be more
> flexible because of the use of references.  The down-side for both of these
> possibilities is that they are more verbose than using an attribute.
> > >
> > > Yet another approach is to create a generic copy element, say, <copyOf>
> that represents a copy of any event.  That may be too general, however.  For
> example, the function of the copyOf (beatRpt, mRpt, etc.) would have to be
> placed in an attribute.  This could lead to mis-use and it would be more
> difficult to control where certain functions could occur.  But, Johannes has
> put this forward in the past, so he's better qualified to address this approach
> than I.
> > >
> > > --
> > > 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of
> > > Roland, Perry D. (pdr4h) [pdr4h at eservices.virginia.edu]
> > > Sent: Thursday, August 27, 2015 11:48 AM
> > >
> > > To: Music Encoding Initiative
> > > Subject: Re: [MEI-L] Beat in 6/8
> > >
> > >
> > > Ok, this gives us a place to start.  It seems to me, however, that rather
> than talking about how much time it repeats (as this reignites the confusion
> around "beat" and "beat unit"), it may be better to investigate ways to
> explicitly indicate which *events* are to repeated.
> > >
> > > --
> > > 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of
> > > Laurent Pugin [lxpugin at gmail.com]
> > > Sent: Thursday, August 27, 2015 11:18 AM
> > > To: Music Encoding Initiative
> > > Subject: Re: [MEI-L] Beat in 6/8
> > >
> > > The problem is that when I encounter a <beatRpt> in an encoding I would
> like to know how much time it repeats. I understand that it represent the
> repetition of the material that occur on a previous musical beat, as you say.
> However, since the duration of what the musical beat is not encoded
> explicitly (as far as I understand) it does not seem to be possible to know it
> (i.e., how much time it repeats.).
> > >
> > > Laurent
> > >
> > >
> > > On Thu, Aug 27, 2015 at 5:02 PM, Roland, Perry D. (pdr4h)
> <pdr4h at eservices.virginia.edu> wrote:
> > >
> > >
> > > Did you mean to say it is "unfortunate" that MEI doesn't use "beat" as an
> attribute?
> > >
> > > And how does one allow an attribute directly "in" <measure> or <staff>?
> > >
> > > We should stay away from determination of meter in MEI.  As we've
> already heard, it often introduces a lot of subjectivity and interpretation.
> That kind of thing is best left to a different, analytical layer.
> > >
> > > I still don't see the point -- what does this have to do with beatRpt?
> > >
> > > --
> > > 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of
> > > Laurent Pugin [lxpugin at gmail.com]
> > > Sent: Thursday, August 27, 2015 10:45 AM
> > > To: Music Encoding Initiative
> > > Subject: Re: [MEI-L] Beat in 6/8
> > >
> > > What seems fortunate to me is that "beat" is not used as attribute
> > > in MEI (yet?)
> > >
> > > Maybe we could use it when we need to specify a musical beat that is not
> the meter.unit. As I suggested with <beatRpt>, it would be assumed to be 1
> in most cases, but could be "3" in 6/8 (or similar) when the desired musical
> beat is 4. . In 5/8, we could imagine having an attribute value such as "2+3" if
> the beat is expected to be 4 - 4. . Along the same lines, it could be useful to
> allow the attribute directly in <measure> (or even <staff>?) when the beat
> structure is changing.
> > >
> > > Laurent
> > >
> > > On Thu, Aug 27, 2015 at 4:06 PM, Benjamin Wolff Bohl
> <bohl at edirom.de> wrote:
> > > Dear Craig,
> > >  many thanks for your always helpful advice!
> > >
> > > Am 27.08.2015 um 11:08 schrieb Craig Sapp:
> > >
> > > The problem is the ambiguous/conflicting terminology in this sentence:
> > >
> > > On 27 August 2015 at 01:19, Benjamin Wolff Bohl <bohl at edirom.de>
> wrote:
> > > meter.unit contains the number indicating the beat unit, that is, the
> bottom number of the meter signature.
> > >
> > > This is only ambiguous/conflicting if you are to smart and know too much
> about music! Regarding the term "beat" in the closed system of MEI
> everything is obvious an unambiguous.
> > >
> > >
> > >
> > > The problem is that in compound meters such as 6/8
> > >     https://en.wikipedia.org/wiki/Meter_(music)#Compound_meter
> > > The "musical beat" is a dotted quarter note, while the MEI "beat unit" is
> an eighth note.  Using the word "beat" in such a way is unfortunate as it can
> conflict with the musical definition of a beat, and this will continue to cause
> mis-interpretation of what a beat is.
> > >
> > > This then would promote using another term in MEI in order to avoid
> confusion, let's say "meter-unit-n".
> > >
> > >
> > >
> > > The duration of a beat is necessary for music analysis, since the
> treatment of dissonance and consonance is tied to the location of a note on
> or off of the beat.
> > >
> > > This could be a beating argument, if it is the purpose and intention of MEI
> to do musical analysis.
> > > Is it? I'd rather say it provides a basis for doing analysis, the logic of the
> analysis is not part of MEI, although the result of the analysis might be
> encoded in MEI.
> > >
> > >
> > > The musical beat is also needed to automatically beam notes.  Implicit
> interpretation of the musical beat can be done with 6/8 by assigning it to be a
> dotted quarter note, but there are exceptions to this definition which would
> require a way of assigning an explicit duration to the musical beat.
> > >
> > > "Automatically" beaming notes is not part of the encoding but of the
> rendering logic an thus will not be reflected in (pure-logical-domain-)MEI.
> > >
> > >
> > >
> > > For example, the middle slow movements in a piano sonata may be
> labeled as 6/8, with the beat actually assigned to the eighth note, in which
> case the "musical beat" and the MEI "beat unit" are the same.
> > >
> > > Another more common corner case would be time signatures such as
> 3/8.  Is that a compound meter with one beat in a measure, or a simple
> meter with three beats in the measure (a variant on a 3/4 meter also
> possible in slow movements)?
> > >
> > > And of course in modern music with irregular meters such as 5/8, the
> musical beats in the measure may may have two beats as 3+2 eighth notes,
> or 2+3 or a mixture of both in different measures.
> > >
> > > The two above are only a problem if we consider "beat" as being the
> "musical beat". If we consider it to be "meter-unit-n" instead, everything
> would work out fine.
> > >
> > >
> > >
> > > Compound meters resulted in a degeneration of mensural notation.
> Since modern rhythms are always "imperfect", to emulate a perfect
> mensuration dots are added to the notes (which would usually be implicit
> the mensural metric equivalent).  These are represented as compound
> meters in modern notation (who knows why they did not invent "2/4." time
> signatures instead of "6/8" for such cases). The problem is that modern time
> signatures are ambiguous, since 6/8 could be considered like C-dot, or it
> could be considered as a non-compound meter with 6 beat at the eighth-
> note level.
> > >
> > > Ok, air is getting thin for me...
> > > I've had a problem with modern transcription of mensural notation ever
> since I first encountered it, or more precisely I was whinig about modern
> notation being so restrictive due to having abandoned mensuration signs. I
> would prefer modern transcription sticking to mensuration signs and logic
> instead of adding dots, but I might not be able to change the world about
> this...
> > >
> > > But to bang the drum for "meter-unit-n": Couldn't this problem also be
> solved by <mensur> or some additional attribute on <scoreDef> or
> <staffDef>?
> > >
> > > Considering the case of a modern transcription of "perfect" mensural
> > > notation using <beatRpt> in terms of "meter-unit-n" would result in
> > > completely different applicable cases compared to using it in the
> > > sense of "musical beat". An there it is the again,
> > > ** ambiguous and conflicting**
> > >
> > > Just for the sake ofplaying advocatus diavoli  3;-) Benni
> > >
> > >
> > >
> > > I whine to Perry every once in a while about this, so we can wait for his
> reply on how to disambiguate such cases...
> > >
> > > -=+Craig
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
> >
> > _______________________________________________
> > 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