<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1250">
<style id="owaParaStyle" type="text/css">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1">
<div style="direction: ltr;font-family: Arial Unicode MS;color: #000000;font-size: 12pt;">
<br>
Then the recommendation is to allow fractions and rational numbers for beat divisions in data.BEAT, but only rational values that are divisible by 2 without remainder? Should we be concerned that this may break existing MEI files?<br>
<br>
--<br>
p.<br>
<div><br>
<div class="BodyFragment"><font size="2">
<div class="PlainText"><br>
__________________________<br>
Perry Roland<br>
Music Library</div>
<div class="PlainText">University of Virginia</div>
<div class="PlainText">P. O. Box 400175</div>
<div class="PlainText">Charlottesville, VA 22904<br>
434-982-2702 (w)<br>
pdr4h (at) virginia (dot) edu</div>
</font></div>
</div>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF964764"><font face="Tahoma" size="2" color="#000000"><b>From:</b> mei-l [mei-l-bounces@lists.uni-paderborn.de] on behalf of Byrd, Donald A. [donbyrd@indiana.edu]<br>
<b>Sent:</b> Wednesday, November 12, 2014 8:45 AM<br>
<b>To:</b> Music Encoding Initiative<br>
<b>Subject:</b> Re: [MEI-L] Music Addressability API draft; fractions in data.BEAT<br>
</font><br>
</div>
<div></div>
<div>
<div style="direction:ltr; font-family:Tahoma; color:#000000; font-size:10pt">What Craig says makes a lot of sense. I'm not sure I'd go quite so far, but I should have said allowing rational numbers, a.k.a. fractions, is _essential_, not just a very good idea!<br>
<br>
--DAB<br>
<br>
<div style="font-family:Times New Roman; color:rgb(0,0,0); font-size:16px">
<hr tabindex="-1">
<div id="divRpF3913" style="direction:ltr"><font face="Tahoma" size="2" color="#000000"><b>From:</b> mei-l [mei-l-bounces@lists.uni-paderborn.de] on behalf of Craig Sapp [craigsapp@gmail.com]<br>
<b>Sent:</b> Tuesday, November 11, 2014 11:39 AM<br>
<b>To:</b> Music Encoding Initiative<br>
<b>Subject:</b> Re: [MEI-L] Music Addressability API draft; fractions in data.BEAT<br>
</font><br>
</div>
<div></div>
<div>
<div dir="ltr">
<div>Hi everyone,</div>
<div><br>
</div>
<div>Don wrote:</div>
> Regarding Laurent's suggestion that fractions in data.BEAT might be useful, e.g.,referring to the second note of a tuplet, as "1+1/3" instead of "1.33": I think allowing rational numbers, a.k.a. fractions, is a very good idea.
<div><br>
</div>
<div>I agree. In fact, any fractional numbers describing rhythms which are rounded must be <blink><font color="#ff0000"><b><i><u>FORBIDDEN</u></i></b></font><font color="#000000"></blink></font><font color="#ff0000"> </font>for any sanity when processing of
musical data in the generalized case.</div>
<div><br>
</div>
<div>For computational processing of rhythms, I use two implementations:</div>
<div><br>
</div>
<div>(1) two integers representing the numerator and denominator. For example "1+1/3" is represented by the two integers (4, 3)</div>
<div>(2) a float and optionally two integers. For example "1+1/3" is represented by (1.3333, 1, 3) where 1.333 is the floating point equivalent, and the following two numbers are the numerator and denominator needed in order to calculate the fractional part
of the first number. Other examples are (1.5, 1, 2) for "1+1/2" and (2, 1, 1) or (2) for the integer "2".</div>
<div><br>
</div>
<div>#2 is good if you don't care for the most part about round-off error, but allows you to check for same if necessary.</div>
<div>#1 is equivalent, but involves more computation (i.e., time) to calculate the fractional number equivalent.</div>
<div><br>
</div>
<div>In textual form, <font color="#0000ff">"1+1/2"</font> and <font color="#0000ff">
"1.5"</font> are equivalent and would both be represented in #1 by (3, 2) and (1.5, 1, 2) in #2.</div>
<div><br>
</div>
<div><font color="#0000ff">"1+1/3"</font> and <font color="#0000ff">"1.333"</font> are not equivalent with the first being (1.333, 1, 3) and the second being (1.333, 333, 1000)</div>
<div><br>
</div>
<div>The point of the above two examples is to demonstrate that floating-point numbers (in text format) can be permitted, but not if the floating-point number is rounded. If you want to guarantee avoiding any confusion, forbidding floating-point numbers altogether
is good (but it is not really necessary if people read documentation :-).</div>
<div><br>
</div>
<div>> Roger Dannenberg pointed out long ago, with nested tuplets and short durations, you might end up with very large numbers, possibly requiring extended precision arithmetic.<br>
</div>
<div><br>
</div>
<div>I haven't analyzed Ferneyhough's music so I haven't come across that problem yet, but it is something to keep in mind when implementing a program. The largest denominator I have come across is 89760 divisions of the whole notes when calculating the smallest
rhythm quantum for Chopin's Prelude 28/18. It has a range of tuplets that use lots of prime numbers: 2^5 * 3 * 5 * 11 * 17.</div>
<div><br>
</div>
<div>
<p class="">2*3*5*7*11*13*17*19*23 is the largest multiplication of the first primes which fit into a 32-bit integer, so you would have to be using tuplets with all of those factors as well as one more approximately to break a 32-bit system. 2*3*5*7*11*13*17*19*23*29*31*37*41*43*47
should be handleable with 64-bit integers.</p>
</div>
<div><br>
</div>
<div>-=+Craig</div>
<div><br>
</div>
<div><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 11 November 2014 07:07, Byrd, Donald A. <span dir="ltr">
<<a href="mailto:donbyrd@indiana.edu" target="_blank">donbyrd@indiana.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
Regarding Laurent's suggestion that fractions in data.BEAT might be useful, e.g.,referring to the second note of a tuplet, as "1+1/3" instead of "1.33": I think allowing rational numbers, a.k.a. fractions, is a very good idea. In music like that of Brian Ferneyhough,
who has used _at least_ four levels of nested tuplets (cf. my CMN Extremes list), I don't know that two decimal places will always be enough; besides, it's less explicit a representation of the rhythm than a fraction. On the other hand, as Roger Dannenberg
pointed out long ago, with nested tuplets and short durations, you might end up with very large numbers, possibly requiring extended precision arithmetic.<br>
<br>
--Don<br>
<br>
________________________________________<br>
From: mei-l [<a href="mailto:mei-l-bounces@lists.uni-paderborn.de" target="_blank">mei-l-bounces@lists.uni-paderborn.de</a>] on behalf of Laurent Pugin [<a href="mailto:laurent@music.mcgill.ca" target="_blank">laurent@music.mcgill.ca</a>]<br>
Sent: Tuesday, November 11, 2014 3:15 AM<br>
To: Music Encoding Initiative<br>
Subject: Re: [MEI-L] Music Addressability API draft<br>
<br>
Hi,<br>
<br>
One remark on the @tstamp2 - points 5) and 6) in Jo's e-mail. I would<br>
avoid values such as "4.999". "5" seems better, even though I<br>
understand it might look awkward. Actually, I think one reason why<br>
this is unclear is that there is a mix of relative and absolute<br>
referencing in how @tstamp2 currently works ("xm+y"). "x" is relative<br>
to @tstamp, while "y" is absolute in the measure.<br>
<br>
Another way of representing this could be to have something like a<br>
@timespan to encode the extend of the event. We would end up with<br>
something like:<br>
<br>
<hairpin tstamp="1" timespan="4"/> for a harpin up to the end of the measure.<br>
<br>
This would be equivalent to<br>
<br>
<hairpin tstamp="1" timespan="0m+4"/><br>
<br>
Or to<br>
<br>
<hairpin tstamp="1" timespan="1m"/><br>
<br>
The latter could be used to indicate that the event needs to cross the<br>
barline (see the top example in Behind Bars p. 105) even though in<br>
terms of musical duration there is not difference.<br>
<br>
A question I have in this timestamp context concerns the data.BEAT<br>
type. Do we have the possibility to use fractions? For example, for a<br>
timestamp referring to the second note of a tuplet, is "1+1/3"<br>
possible? This would probably be better than something like "1.33".<br>
Any thoughts?<br>
<br>
I haven't had the time to look at the EMA repository yet, but this<br>
looks quite useful!<br>
<br>
Laurent<br>
<br>
On Tue, Nov 4, 2014 at 2:09 PM, Kőmíves Zoltán <<a href="mailto:zolaemil@gmail.com" target="_blank">zolaemil@gmail.com</a>> wrote:<br>
> Hi Raff,<br>
><br>
> My comment was more about the ambiguity that is created by the implicit<br>
> nature of the actual cut-off mode (and this is vaguely related to the MEI<br>
> tstamp2 problem).<br>
><br>
> If the definition of the "cut" mode is that the end value is the absolute<br>
> end, that is nothing can extend longer than the end value, you can still<br>
> chose to discard or actually cut the events that would extend longer, but<br>
> the point is that this position is defined by then end value explicitly,<br>
> rather than implicitly (by applying ceil or +1).<br>
><br>
> So in 4/4 the if the URL ended something like "../1-3/cut" and there's a<br>
> half-note starting on the second beat, it will be qualified as a non-fit<br>
> (while according the original system, it would be qualified as a fit.) This<br>
> would also allow you to specify an interval shorter than a beat (e.g.<br>
> 1-1.5/cut).<br>
><br>
> I wasn't trying to suggest anything about what to do with the non-fitters<br>
> though. I guess it is very much application dependent; perhaps would be a<br>
> good idea to allow three options here: drop, keep, cut?<br>
><br>
> Z<br>
><br>
><br>
> 2014-11-04 14:46 GMT+00:00 Raffaele Viglianti <<a href="mailto:raffaeleviglianti@gmail.com" target="_blank">raffaeleviglianti@gmail.com</a>>:<br>
>><br>
>> Hi Zoltan,<br>
>><br>
>> Thanks for your email!<br>
>><br>
>> I think we agree entirely on the tstamp2 issue. Your more sophisticated<br>
>> example matches my expectations. I would definitely keep the same behavior<br>
>> also for percussive/plucked instruments and other borderline scenarios like<br>
>> an eight for double bass that is to be played both pizzicato and crescendo<br>
>> (I guess in this case the bass becomes a plucked instrument).<br>
>><br>
>> I also struggle to think of a reasonable example for slurs, but notation<br>
>> doesn't always match a physical gesture or real sound effect. So I would<br>
>> keep the same tstamp2 behavior for phrase marks too.<br>
>><br>
>> About EMA, I see your point. I think ceil(end) is what I mean now for<br>
>> "cut" mode. If you have an end beat of 1, you consider the whole of beat 1.<br>
>> If you have 1.2 you consider the whole of beat 1 and .2 of the following.<br>
>> This forces a processor to alter the notation to fit the beat limit. Are you<br>
>> suggesting that event that do not end within the range should be dropped<br>
>> entirely in "cut" mode? That may be easier to implement, but then a<br>
>> selection of beat 1 to 1 where only a whole note is encoded, would return an<br>
>> empty set.<br>
>><br>
>> Raff<br>
>><br>
>><br>
>> On Tue, Nov 4, 2014 at 4:14 AM, Kőmíves Zoltán <<a href="mailto:zolaemil@gmail.com" target="_blank">zolaemil@gmail.com</a>> wrote:<br>
>>><br>
>>> Hi Raff,<br>
>>><br>
>>> I'm glad to see you're making great progress with the EMA project! Let me<br>
>>> chip in to the discussion with some casual comments.<br>
>>><br>
>>> I like your description of the thought-process of transcribing a hairpin<br>
>>> from a source document. I think there may be room for some more<br>
>>> sophistication here: for example if a performer sees a hairpin ending<br>
>>> roughly on the last beat of the measure, or perhaps slightly after it, they<br>
>>> could argue that the crescendo needs to continue right to the end of the<br>
>>> measure, (they would especially inclined to do so, if in the next measure a<br>
>>> diminuendo starts at beat one). I think it is necessary to distinguish<br>
>>> between this and the case, when the crescendo would actually stop at the<br>
>>> beginning of the last beat, and the performer would keep the volume for the<br>
>>> duration of the last beat. Based on the logic you describe, I would<br>
>>> transcribe the full-length crescendo with tstamp2="5" or "4.999", as Jo<br>
>>> suggests. Then it could be up to there renderer to decide whether to draw<br>
>>> the hairpin right up to the barline or somewhere between the last note and<br>
>>> the barline.<br>
>>><br>
>>> In short, my penny is on tstamp2 meaning the absolute end.<br>
>>><br>
>>> N.B. the above problem only arises in situations when an event can<br>
>>> feasibly start/end between other time positions than beginning of notes;<br>
>>> such a situation is a crescendo performed on a non-percussive(e.g. piano)<br>
>>> and non-plucked instrument. Well, even on these instruments, the full-length<br>
>>> crescendo may be the "artistic intention" and should be kept intact, even<br>
>>> though it is never going to be executed. However, I cannot think of any<br>
>>> problematic case for slurs, for example (off the top of my head I cannot<br>
>>> think of any example when the a slur starting or ending in between notes is<br>
>>> particularly meaningful...)<br>
>>><br>
>>> As far as I can see, when it comes to EMA, it all boils down to the<br>
>>> definition of the end of the range. By default, the range is flexible on the<br>
>>> right hand side: it includes everything that start within the base range,<br>
>>> defined by start and end positions. But it's not clear what the cut-off<br>
>>> point is when you apply "cut"? Is it end+1 or ceil(end)? If it is ceil(end),<br>
>>> is it not too restrictive that you cannot cut off at other positions than<br>
>>> integer beat positions? If it is end+1 it may not be very intuitive to use<br>
>>> when end isn't an integer value.<br>
>>><br>
>>> It seems to me that a more explicit definition of the end of the range<br>
>>> could be more easy to deal with: by default the range as defined now, but in<br>
>>> "cut" mode nothing should extend longer than the end position. Then the user<br>
>>> could have more control over the actual cut-off point.<br>
>>><br>
>>> Best<br>
>>> Zoltan<br>
>>><br>
>>> 2014-11-03 22:15 GMT+00:00 Raffaele Viglianti<br>
>>> <<a href="mailto:raffaeleviglianti@gmail.com" target="_blank">raffaeleviglianti@gmail.com</a>>:<br>
>>>><br>
>>>> Hi Jo,<br>
>>>><br>
>>>> Thank you for your reply! Very interesting question.<br>
>>>><br>
>>>> To help me explain my view on the problem you pose, let's consider your<br>
>>>> example 3 and 4 as if they were on two different staves of the same piece.<br>
>>>> Time is 4/4.<br>
>>>><br>
>>>> On staff 1 we'd have a whole note with a crescendo, and we're debating<br>
>>>> whether tstamp2 should be 1 or 4:<br>
>>>> <hairpin tstamp="1" tstamp2="0m+1" form="cres" /> or<br>
>>>> <hairpin tstamp="1" tstamp2="0m+4" form="cres" /><br>
>>>><br>
>>>> On staff 2 we'd have three quarters and two eights, with an hairpin<br>
>>>> going to the last note<br>
>>>> <hairpin tstamp="1" tstamp2="0m+4.5" form="cres" /><br>
>>>><br>
>>>> If I were encoding a source document, I would use tstamp2 to specify<br>
>>>> were I think the crescendo ends in relationship to the beat. I justify this<br>
>>>> by imagining a performer performing the MEI (heh): I would prefer a<br>
>>>> tstamp2=4 to indicate that the performer is expected to hold the volume<br>
>>>> around beat 4. I would do this because if the hairpin were shorter, that<br>
>>>> would be meaningful musically. For example, if it were stopping around what<br>
>>>> would seem, as a performer, closer to beat 3 than 4.<br>
>>>><br>
>>>> What is less evident to me, instead, is how I would encode this when the<br>
>>>> staff below has the hairpin stretching to 4.5 because of the eights. Is it<br>
>>>> ok to have the hairpins on each staff ending at different tstamps (4 and<br>
>>>> 4.5)? If the source document aligns them, should the tstamp2s be aligned<br>
>>>> too? Or should the alignment be left to a rendering system. I may lean<br>
>>>> towards adjusting both tstamp2s to match, but I can also see why the<br>
>>>> opposite could be argued.<br>
>>>><br>
>>>> EMA is relative unaffected by this problem. The API, as it is now,<br>
>>>> specifies that any notational element occurring *on* the final beat is<br>
>>>> considered in its entirety, regardless of how its dur or tstamp2 are<br>
>>>> expressed. So a selection on the example above of staff 1, beat 1, would<br>
>>>> return the whole note *and* the hairpin with its tstamp2 unaltered.<br>
>>>><br>
>>>> This default behavior can be overridden by raising the "cut" flag, which<br>
>>>> will force the returned notation to be altered to stay within the range<br>
>>>> specified. So a selection on the example above of staff 1, beat 1, would<br>
>>>> return *a quarter* note and the hairpin with its tstamp2 changed to 1.<br>
>>>><br>
>>>> I'm more than happy to discuss whether this is a good idea, etc.<br>
>>>><br>
>>>> Thanks again! Best,<br>
>>>> Raff<br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Mon, Nov 3, 2014 at 4:33 PM, Johannes Kepper <<a href="mailto:kepper@edirom.de" target="_blank">kepper@edirom.de</a>><br>
>>>> wrote:<br>
>>>>><br>
>>>>> Hi Raff,<br>
>>>>><br>
>>>>> it's great to hear about EMA again, and it seems like you've made a lot<br>
>>>>> of progress (congrats!). There is one question I stumbled upon recently in<br>
>>>>> the Freischütz context, which clearly falls into the scope of EMA as well,<br>
>>>>> and I would like to hear your opinion about it. Since it (in my opinion) is<br>
>>>>> an MEI question, I prefer to discuss it over here, instead of Github. Let's<br>
>>>>> see where it leads us…<br>
>>>>><br>
>>>>> Let's assume we're in a simple 4/4 meter, and we want to encode a slur<br>
>>>>> that ranges from the first to the last note in that measure. Now let's look<br>
>>>>> at different examples in this setup.<br>
>>>>><br>
>>>>> 1)<br>
>>>>> We have four quarter notes. Our slur is<br>
>>>>> <slur tstamp="1" tstamp2="0m+4"/><br>
>>>>><br>
>>>>> 2)<br>
>>>>> Let's consider we have a hairpin instead, which ranges from the first<br>
>>>>> to the last quarter:<br>
>>>>> <hairpin tstamp="1" tstamp2="0m+4"/><br>
>>>>><br>
>>>>> 3)<br>
>>>>> Let's consider our hairpin stretches across the full measure, which<br>
>>>>> contains just a whole note:<br>
>>>>> <hairpin tstamp="1" tstamp2="0m+4"/><br>
>>>>><br>
>>>>> 4)<br>
>>>>> Let's go back to a slur which stretches to the second of two eighth<br>
>>>>> notes on the last beat. Our slur is<br>
>>>>> <slur tstamp="1" tstamp2="0m+4.5"/><br>
>>>>><br>
>>>>> 5)<br>
>>>>> What does this mean to 3)? Should it be<br>
>>>>> <hairpin tstamp="1" tstamp2="0m+4.5"/><br>
>>>>> instead, to indicate that the hairpin really goes to the end of the<br>
>>>>> measure? By definition, in MEI a tstamp="5" (in 4/4) denotes the right<br>
>>>>> barline, so should we use something like "5", or perhaps "4.999" in this<br>
>>>>> situation?<br>
>>>>><br>
>>>>> 6)<br>
>>>>> To my understanding, a musical range in MEI should include all events<br>
>>>>> which have an onset (=tstamp) that is between the range's starting tstamp<br>
>>>>> and it's ending tstamp2.<br>
>>>>><br>
>>>>> 7)<br>
>>>>> If 6) is true, a valid encoding for 3) would be<br>
>>>>> <hairpin tstamp="1" tstamp2="0m+1"/><br>
>>>>> This hairpin would cover all notes that start at tstamp="1", which is<br>
>>>>> obviously true for a whole note.<br>
>>>>><br>
>>>>> 8)<br>
>>>>> However, this encoding obviously does not address the (graphical)<br>
>>>>> aspect of the hairpin stretching the whole measure. I'm not sure if this is<br>
>>>>> a problem – it could be addressed with other (more graphical) attributes<br>
>>>>> instead.<br>
>>>>><br>
>>>>> ----<br>
>>>>><br>
>>>>> It all comes down to the question if 6) is correct, or if a tstamp2<br>
>>>>> denotes the absolute end of a range. In other words: Does the crescendo stop<br>
>>>>> at the onset of the note at which hairpin/@tstamp2 is pointing, or does it<br>
>>>>> also include the duration of that note (which would make it context<br>
>>>>> dependent…)? In terms of EMA: Would you include the notes that start at the<br>
>>>>> specified ending beat, or would you drop them, since they don't completely<br>
>>>>> fit into the specified range?<br>
>>>>><br>
>>>>> I think MEI isn't clear enough on this, on EMA seems to be a perfect<br>
>>>>> opportunity to discuss how people would interpret it, and if we should try<br>
>>>>> to be more explicit on this.<br>
>>>>><br>
>>>>> Best,<br>
>>>>> jo<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> Am 03.11.2014 um 17:11 schrieb Raffaele Viglianti<br>
>>>>> <<a href="mailto:raffaeleviglianti@gmail.com" target="_blank">raffaeleviglianti@gmail.com</a>>:<br>
>>>>><br>
>>>>> > Dear List,<br>
>>>>> ><br>
>>>>> > The idea behind the Enhancing Music Notation Addressability (EMA)<br>
>>>>> > project is to investigate ways to make it possible to link to specific parts<br>
>>>>> > of a music document available online. Being able to do so could be useful to<br>
>>>>> > quote passages, express analytical statements and annotations, or passing a<br>
>>>>> > selection of music notation on to another process for rendering,<br>
>>>>> > computational analysis, etc.<br>
>>>>> ><br>
>>>>> > As part of the project, I've been working on a URL specification to<br>
>>>>> > express a selection of music notation based on measure, staves, and beats. I<br>
>>>>> > am also writing an API that describes how to process the URL and the music<br>
>>>>> > notation.<br>
>>>>> ><br>
>>>>> > You can find the URL specification and the API documentation here:<br>
>>>>> > <a href="https://github.com/umd-mith/ema/blob/master/docs/api.md" target="_blank">
https://github.com/umd-mith/ema/blob/master/docs/api.md</a><br>
>>>>> ><br>
>>>>> > I am now working on an implementation of the API that works with MEI<br>
>>>>> > files. If you have used an image server before, you can imagine how this<br>
>>>>> > will work: given a URL specifying a zoom level and a region of an image, the<br>
>>>>> > server returns an image of the selected region. Likewise, this MEI-based<br>
>>>>> > implementation would return the region of an MEI file, according to the<br>
>>>>> > selection specified by the URL.<br>
>>>>> ><br>
>>>>> > I would be very interested in hearing any comments and suggestions<br>
>>>>> > that you might have at this stage. Can you imagine that this system may be<br>
>>>>> > useful for your projects? Is the URL specification expressive enough? Are<br>
>>>>> > there other parameters that you would want the API to include?<br>
>>>>> ><br>
>>>>> > If you are interested, I would encourage you to fork the GitHub<br>
>>>>> > repository and contributing!<br>
>>>>> ><br>
>>>>> > Many thanks and all the best,<br>
>>>>> > Raff<br>
>>>>> > _______________________________________________<br>
>>>>> > mei-l mailing list<br>
>>>>> > <a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a><br>
>>>>> > <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">
https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
>>>>><br>
>>>>> [---- SNIP ----]<br>
>>><br>
>>> _________________________________________<br>
><br>
_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a><br>
<a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>