<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Thanks, Simon and Jo, for your responses,</p>
<p>@Simon: Please be patient, I'll come back to you, but I first
need to sort out some basics with Jo.</p>
<p>@Jo: Before replying to your posting, I first need to provide
some context so that you can better understand what I'm saying:</p>
<p>Context 1: Outline of the state of the debate in the MNX
Repository<br>
MNX is intended to be a set of next-generation, web-friendly music
notation encodings, related via common elements in their schemas.
The first format being developed is MNXcommon1900, which is
intended to be the successor to MusicXML. It does not have to be
backwardly compatible with MusicXML, so the co-chair wants to
provide documentation comparing the different ways in which
MNXcommon1900 and MusicXML encode a number of simple examples.
Unfortunately, they first need to revise the MusicXML
documentation in order to do that, so work on MNXcommon1900 has
temporarily stopped. The intention is to start work on it again as
soon as the MusicXML documentation revision is complete. After 5+
years of debate, MNXcommon1900 is actually in a fairly advanced
state.<br>
I have two MNX-related GitHub repositories (the best way to really
understand software is to write it):<br>
</p>
<ul>
<li>MNXtoSVG: A (C#) desktop application that converts MNX files
to SVG. This application is a test-bed for MNX's data
structures, and successfully converts the first completed
MusicXML-MNX comparison examples to (graphics only) SVG. When/if
MNX includes temporal info, it will do that too (using a special
namespace in the SVG). <br>
</li>
<li>A fork of the MNX repository: This contains (among other
things) the beginnings of a draft schema for MNXcommon1900. The
intention is to plunder that schema for other schemas...</li>
</ul>
<p>I'm looking for things that all event-based music notations have
in common, so that software libraries can be used efficiently
across all such notations. That's important if we want to develop
standards that are consistent all over the web.</p>
<p>Context 2: My background<br>
I'm a relic of the '60s <i>Avant-Garde</i>. Left college in the
early 1970s, and became K. Stockhausen's principal copyist
1974-2000. In the '60s, they were still trying to develop new
notations, but that project collapsed<i> </i>quite suddenly in
1970 when all the leading composers gave it up (without solving
anything), and reverted to using standard notation. In 1982,
having learned a lot from my boss, and having had a few years
practical experience pushing the dots around, I suddenly realised
what had gone wrong, and wrote an article about it that was
eventually published in 1985. The article contains a critical
analysis of CWMN...<br>
So I'm coming from a rather special niche in the practical world
of music publishing, not from the academic world. In 1982, I was
not aware of Maxwell (1981) [1], and I hadn't realised until
researching this post, how it relates to things like <i>metrical
time</i> in the (1985) MIDI 1.0 standard (see §5, §5.1.2 in
[3]).</p>
<p>***<br>
</p>
<p>MEI:<br>
The Background page [2] on the MEI website cites Maxwell (1981)
[1] as the source of the three principle domains <i>physical</i>,
<i>logical</i> and <i>graphical</i>. In contrast, my 1982 insight
was that the domains <i>space</i> and <i>time</i> are
fundamental, and need to be clearly and radically distinguished.
Maxwell himself says (at the beginning of §2.0 of his paper) that
his "classification is not the only way that music notation could
be broken up..." <br>
</p>
<p>So I'm thinking that Maxwell's domains are not as fundamental as
the ones I found, and that mine lead to simpler, more general and
more powerful results.</p>
<p>From my point of view, Maxwell's <i>logical</i> domain seems
particularly problematic:<br>
Understandably for the date (1981), and the other problems he was
coping with, I think Maxwell has a too respectful attitude to the
symbols he was dealing with. The then unrivalled supremacy of
CWMN1900 over all other notations leads him to think that he can
assign fixed relative values to the duration symbols. That could,
of course, also be explained in terms of him wanting to limit the
scope of his project but, especially when one looks at legitimate,
non-standard (e.g.Baroque) uses of the symbols (see §4.1.1 of
[3]), his<i> logical </i>domain still seems to be on rather shaky
ground. <br>
Being able to include notations containing <i>any</i> kind of
event-symbol in my model (see §4.2) is exactly what's needed in
order to create a consistent set of related schemas for all the
world's event-based music notations...</p>
<p>So, having said all that, MEI's @dur attribute subclasses look to
me like ad-hoc postulates that have been added to the paradigm to
shore it up, without questioning its underlying assumptions. The
result is that MEI has become over-complicated and unwieldy.
That's a common theme in ageing paradigms... remember Ptolemy?<br>
</p>
<p>Okay, maybe I'm being a bit provocative there. But am I
justified? :-)<br>
</p>
<p>Hope that helps,<br>
all the best,<br>
James<br>
</p>
<p>[1] Maxwell (1981): <a class="moz-txt-link-freetext"
href="http://dspace.mit.edu/handle/1721.1/15893">http://dspace.mit.edu/handle/1721.1/15893</a></p>
<p>[2] <a class="moz-txt-link-freetext"
href="https://music-encoding.org/resources/background.html">https://music-encoding.org/resources/background.html</a></p>
<p>[3] <a class="moz-txt-link-freetext"
href="https://james-ingram-act-two.de/writings/TickBasedTiming/tickBasedTiming.html">https://james-ingram-act-two.de/writings/TickBasedTiming/tickBasedTiming.html</a></p>
<p>-- <br>
</p>
<p><a class="moz-txt-link-freetext"
href="https://james-ingram-act-two.de">https://james-ingram-act-two.de</a><br>
<a class="moz-txt-link-freetext" href="https://github.com/notator">https://github.com/notator</a></p>
<br>
<div class="moz-cite-prefix">Am 16.04.2021 um 18:02 schrieb Johannes
Kepper:<br>
</div>
<blockquote type="cite"
cite="mid:7A76A059-A268-42A0-9553-A4E23D796F73@edirom.de">
<pre class="moz-quote-pre" wrap="">Dear all,
I’m not much into this discussion, and haven’t really investigated into the use cases behind this, so my answer may not be appropriate for the question asked. However, I believe that most of the requirements articulated here are safely covered by MEI. Looking at the attributes available on notes (see <a class="moz-txt-link-freetext" href="https://music-encoding.org/guidelines/v4/elements/note.html#attributes">https://music-encoding.org/guidelines/v4/elements/note.html#attributes</a>), there are plenty of different approaches available:
@dur – Records the duration of a feature using the relative durational values provided by the data.DURATION datatype.
@dur.ges – Records performed duration information that differs from the written duration.
@dur.metrical – Duration as a count of units provided in the time signature denominator.
@dur.ppq – Duration recorded as pulses-per-quarter note, e.g. MIDI clicks or MusicXML divisions.
@dur.real – Duration in seconds, e.g. '1.732‘.
@dur.recip – Duration as an optionally dotted Humdrum *recip value.
In addition, there is also
@tstamp – Encodes the onset time in terms of musical time, i.e., beats[.fractional beat part], as expressed in the written time signature.
@tstamp.ges – Encodes the onset time in terms of musical time, i.e., beats[.fractional beat part], as expressed in the written time signature.
@tstamp.real – Records the onset time in terms of ISO time.
@to – Records a timestamp adjustment of a feature's programmatically-determined location in terms of musical time; that is, beats.
@synch – Points to elements that are synchronous with the current element.
@when – Indicates the point of occurrence of this feature along a time line. Its value must be the ID of a when element elsewhere in the document.
They’re all for slightly different purposes, and surely many of those attributes are not (well) supported by existing software, but they seem to offer good starting points to find a model for the questions asked. It is important to keep in mind that music manifests in various forms – sound, notation, concepts (what _is_ a quarter?), and that MEI tries to treat those „domains“ as independently as possible. Of course, they’re all connected, but not being specific (enough) in that regard did no good to other formats…
Hope this helps,
jo
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Am 16.04.2021 um 15:35 schrieb Simon Wascher <a class="moz-txt-link-rfc2396E" href="mailto:bureau@tradmus.org"><bureau@tradmus.org></a>:
Hi alltogether,
Am 14.04.2021 um 21:49 schrieb James Ingram <a class="moz-txt-link-rfc2396E" href="mailto:j.ingram@netcologne.de"><j.ingram@netcologne.de></a>:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Last January, I raised an issue about Tick-based Timing in the W3C Music Notation Community Group's MNX Repository [1], but it was closed in February without my being satisfied that it had been sufficiently discussed.
I had the feeling that something important was being glossed over, so have been thinking hard about the subject over the past few weeks, and have now uploaded an article about it to my website [2].
[...]
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">Am 16.04.2021 um 11:06 schrieb James Ingram <a class="moz-txt-link-rfc2396E" href="mailto:j.ingram@netcologne.de"><j.ingram@netcologne.de></a>:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">First: Did you intend your reply just to be private, or did you want to send it to the public list as well. I'm not sure.
If you'd like this all to be public, I could send this to MEI-L as well...
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">I answered to James Ingram off list, but now move to MEI-L with my answer, as it seems it was the intention to get answers on the list.
My full first answer to James Ingram is down at the end of this mail, if someone is interested (I did not forward James Ingram's repy to me in full as I did not want to forward someone elses private answer to me to public.
Am 15.04.2021 um 01:03 schrieb Simon Wascher <a class="moz-txt-link-rfc2396E" href="mailto:bureau@tradmus.org"><bureau@tradmus.org></a>:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">I would like to point you at Lauge Dideriksens approach to notate music with CWMN symbols but positioned according to the musical timing. I suppose that is a compareable approach to yours.
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">Am 16.04.2021 um 11:06 schrieb James Ingram <a class="moz-txt-link-rfc2396E" href="mailto:j.ingram@netcologne.de"><j.ingram@netcologne.de></a>:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">I took a look at Lauge Dideriksens website, but can't see enough music examples to know quite what you mean by "positioned according to musical timing". I see that he (sometimes?) uses tuplets. Does he (sometimes?) position the symbols in (flat) space to represent (flat) time?
In either case, that's not quite what I'm saying. I'm talking about the underlying machine-readable encoding of notation, not just the way it looks on the surface.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">maybe there is still no material online of this. He is talking about this at European Voices VI in Vienna 27–30 September 2021.
It might be sensible to contact him direct.
Am 15.04.2021 um 01:03 schrieb Simon Wascher <a class="moz-txt-link-rfc2396E" href="mailto:bureau@tradmus.org"><bureau@tradmus.org></a>:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Do you consider tick based notation to be a way to represent phonemic and phonetic notation(interpretation) at the same time?
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">Am 16.04.2021 um 11:06 schrieb James Ingram <a class="moz-txt-link-rfc2396E" href="mailto:j.ingram@netcologne.de"><j.ingram@netcologne.de></a>:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Here again, I'm not quite sure what you mean. Perhaps it would help if I again emphasise the difference between the surface appearance of a notation and its machine-readable encoding.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">I see, your focus seems to be on machine-readability and the problem of the relation between CWMN and its machine-playback.
My focus is the problem of the relation between CWMN and real live-performance.
I am looking for tools to code real live performances, using the symbols of CWMN but allowing to include the _display_ of the real live durations of the real live-performance (the difference between real live-performance and CWMN).
Am 16.04.2021 um 11:06 schrieb James Ingram <a class="moz-txt-link-rfc2396E" href="mailto:j.ingram@netcologne.de"><j.ingram@netcologne.de></a>:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">You ask about emic and etic, and the problem of notating traditional Scandinavian Polska or jodling:
To get us on the same page, here's where I am: Transcriptions of music that is in an aural tradition always reflect what the transcriber thinks is important. Transcriptions often leave out nuances (timing, tonal inflexions etc.) that the original performers and their public would regard as essential.
I think that aural traditions correctly ignore machine time (seconds, milliseconds), but that if we use machines to record them, we ultimately have to use such timings (in the machines). I don't think that matters, providing that the transcribers don't try to impose machine time (in the form of beats per second) too literally on their interpretations of the original performances.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Well, to be precise: in transcribing music, there is (at least) three points of view (versions of notation):
1. the musician's "emic" intention
2. the machines "phonetic" protocol (which can be automatically transformed to a duration and pitch notation applying a certain level of accuracy, but which cannot know about light and heavy time and barlines, as these are cultural phenomenons. The level of accuracy is indeed already a cultural decission, but: If the transformation is not into CWMN but for example into a time/pitch chart of the fundamental frequencies the limits of readability of CWMN do not apply.
3. the transcribers intention, which usually is called "etic" but is in fact "emic" to the transcriber.
(emic and etic is not my favorite wording)
(I am not worring about the composer, as in my field music gets composed sounding, the composer is a musician here.)
Am 16.04.2021 um 11:06 schrieb James Ingram <a class="moz-txt-link-rfc2396E" href="mailto:j.ingram@netcologne.de"><j.ingram@netcologne.de></a>:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">"Stress programs" in abc-notation:
I can't find any references to "stress programs" at the abc site [2],
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Ah, you are right, that is a kind of de facto standard, which is weakly documented. It is interpreted by abc2midi and BarFly (and maybe other programs).
It makes use of the R:header of abc. Either the stress program is written there directly or in an external file.
Here is one of the stress programs I use:
* 37
Mazurka
3/4
3/4=35
6
120 1.4
100 0.6
110 1.2
100 0.8
115 1.32
100 0.67
so that is:
"*37" it starts with a number (that does not do anything).
"Mazurka" is the identifying string used in the R:header field connecting abc-file and stress program for the playback program.
"3/4" is the meter. The stress program only applies to abc-notation in this meter. So there may be stress programs with the same name, but for different meters.
"3/4=35" is the tempo indication.
"6" is the number of sections the bar is split up to in this stress program (a free choisse). So it should be followed by that number of describing lines.
"120 1.4" describes the first section of the bar. "120" is the volume (beteen 0-127), "1.4" is the multiplier, the core of the thing, so to say: It says the duration of the first sixt of the notated bar is to be played 1.4 times as long than it would be played considering the metronome tempo given.
"100 0.6" and so on.
I attached BarFly's "Stress Programs" file which also contains the descriptin provided by the author of "Barfly" Phil Taylor.
(I personally would prefer if this mechanism would not be limited to one single bar, but could be used to describe durations of a choosen number of bars/beats.)
So, thanks for the moment,
and feel free to tell me I shall not send this longish and maybe not very clever e-mails to this list.
Thanks,
Health,
Simon
Wascher
Anfang der weitergeleiteten Nachricht:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Von: Simon Wascher <a class="moz-txt-link-rfc2396E" href="mailto:bureau@tradmus.org"><bureau@tradmus.org></a>
Betreff: Aw: [MEI-L] Tick-based Timing
Datum: 15. April 2021 01:03:32 MESZ
An: James Ingram <a class="moz-txt-link-rfc2396E" href="mailto:j.ingram@netcologne.de"><j.ingram@netcologne.de></a>
Hello,
reading your post to MEI mailing list (I am not active in MEI) I started to read your text
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">[2] <a class="moz-txt-link-freetext" href="https://james-ingram-act-two.de/writings/TickBasedTiming/tickBasedTiming.html">https://james-ingram-act-two.de/writings/TickBasedTiming/tickBasedTiming.html</a>
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">and would like to just add my two cents of ideas about
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Ticks carry both temporal and spatial information.
In particular, synchronous events at the beginning of a bar have the same tick.time, so:
The (abstract) tick durations of the events in parallel voices in a bar, add up to the same value.
In other words:
Bars “add up” in (abstract) ticks.
The same is true for parallel voices in systems (that are as wide as the page allows) even when there are no barlines, so:
Systems also “add up” in (abstract) ticks.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">* First I would like to point you at Lauge Dideriksens approach to notate music with CWMN symbols but positioned according to the musical timing. I suppose that is a compareable approach to yours.
* About Barlines I would like to add, that barlines also represent human perception (the composer's, the musician's, the listener's or the transcriber's), as barlines do not exist in the audio-signal.
Barlines do not need to align. It is the music as a whole that keeps a common pace (the musicians stay together, but not necessarily at beats or barlines.
It is even possible to play along with completly different barlines in mind, that really happends, I experienced it myself.
* Do you consider tick based notation to be a way to represent phonemic and phonetic notation(interpretation) at the same time?
* In many musical styles of traditional music, also in Europe there are severe differences between emic and ethic music perception. Typical and well known examples are Polska-playing in Tradions of Scandinavia or the problems of scientific notation of Jodler/Jodel (Jodler interpretation has a very loose relation to beat). Looking for examples of perfect common pace in a music that treats the tension of timing between the ensemble members as a carrier of musical expression have a look at central polish traditional instrumental dance music.
* About notational approaches: are you aware of the "Stress Programs" used with abc-notation to describe microtiming? It is a method where the bar is split up into a freely choosen number of fractions described by multipiers (1 is the standardlenght of one fraction, so 0.76 is 0.76 times shorter and 1.43 is 1.43 times longer than standard)?
Not sure if this is meeting your intentions,
Thanks,
Health,
Simon Wascher, (Vienna; musician, transcriber of historical music notation; researcher in folk music)
Am 14.04.2021 um 21:49 schrieb James Ingram <a class="moz-txt-link-rfc2396E" href="mailto:j.ingram@netcologne.de"><j.ingram@netcologne.de></a>:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Last January, I raised an issue about Tick-based Timing in the W3C Music Notation Community Group's MNX Repository [1], but it was closed in February without my being satisfied that it had been sufficiently discussed.
I had the feeling that something important was being glossed over, so have been thinking hard about the subject over the past few weeks, and have now uploaded an article about it to my website [2].
My conclusions are that Tick-based Timing
• has to do with the difference between absolute (mechanical, physical) time and performance practice,
• is relevant to the encoding of all the world's event-based music notations, not just CWMN1900.
• needs to be considered for the next generation of music encoding formats
I would especially like to get some feedback from those working on non-western notations, so am posting this not only to the W3C MNCG's public mailing list, but also to MEI's.
All the best,
James Ingram
(notator)
[1] MNX Issue #217: <a class="moz-txt-link-freetext" href="https://github.com/w3c/mnx/issues/217">https://github.com/w3c/mnx/issues/217</a>
[2] <a class="moz-txt-link-freetext" href="https://james-ingram-act-two.de/writings/TickBasedTiming/tickBasedTiming.html">https://james-ingram-act-two.de/writings/TickBasedTiming/tickBasedTiming.html</a>
--
<a class="moz-txt-link-freetext" href="https://james-ingram-act-two.de">https://james-ingram-act-two.de</a>
<a class="moz-txt-link-freetext" href="https://github.com/notator">https://github.com/notator</a>
_______________________________________________
mei-l mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a>
<a class="moz-txt-link-freetext" href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a>
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap=""><Stress_Programs>
_______________________________________________
mei-l mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a>
<a class="moz-txt-link-freetext" href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a>
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Dr. Johannes Kepper
Wissenschaftlicher Mitarbeiter
Beethovens Werkstatt: Genetische Textkritik und Digitale Musikedition
Musikwiss. Seminar Detmold / Paderborn | Hornsche Straße 39 | D-32756 Detmold
<a class="moz-txt-link-abbreviated" href="mailto:kepper@beethovens-werkstatt.de">kepper@beethovens-werkstatt.de</a> | -49 (0) 5231 / 975669
<a class="moz-txt-link-abbreviated" href="http://www.beethovens-werkstatt.de">www.beethovens-werkstatt.de</a>
Forschungsprojekt gefördert durch die Akademie der Wissenschaften und der Literatur | Mainz
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
mei-l mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a>
<a class="moz-txt-link-freetext" href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a>
</pre>
</blockquote>
<div class="moz-signature"><br>
</div>
</body>
</html>