<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi, Andrew, Laurent, Johannes, all,<br>
<br>
Thanks for the replies. Sorry for the delay, but I've been away
for the last couple of days.<br>
<br>
First, I owe the list (and Andrew in particular) an apology: I was
so excited at having discovered MEI and its customizability, that
I forgot to introduce myself. I even managed to delete my
signature links! No wonder Andrew was a little taken aback!
Andrew: Thanks for our private exchange, I hope the following
helps you, and everyone else here, to understand my position
better.<br>
Also, apologies for my sometimes less than academic language
style. I'm coming from another world, and sometimes find it
difficult not to sound flippant. I've been trying to get this
penny to drop in the academic and software worlds for more than 30
years... Enough said. I forgive you all! :-))<br>
<br>
I've copied the complete replies to my original posting below.
I'll reply to Johannes' and Laurent's postings in that order. My
reply to Andrew's public posting is implicit.<br>
<br>
Johannes said:<br>
<blockquote type="cite"> JK: I believe that your definition is
clearly outside of CMN as perceived and utilized by composers
such as Bach, Beethoven, Bizet, Busoni or Borodin. </blockquote>
That's not quite right.<br>
What I really think is that MEI has inherited the <i>neo</i>-classical
interpretation of CWMN used by composers like Stravinsky during
the first half of the 20th century. Stravinsky, and other
neo-classical composers had no choice but to go back to using well
defined tempi. They were trying to avoid the notational chaos left
by late Romanticism (in which performance practice can no longer
be described in terms of fixed tempi).<br>
<br>
It seems a bit daring to include Bach in your list of composers
who use CWN! Did he use metronome marks? Nested tuplets? What
about his use of "dotted eighth" + "sixteenth" adding up to three
"eighths"? Baroque ornaments? Curvy beams... :-)<br>
I think you are over-simplifying by leaving out the composers who
don't fit your model. What about Chopin, Wagner, Bruckner,
Debussy? These are composers for whom living traditions of
performance practice are more important than what's on the paper
-- though they do, of course, try to be logical within their 19th
century context.<br>
In the 19th century, it was assumed that there are spatial and
temporal ethers. Tempo is the 19th century's temporal ether.
(There are also good commercial reasons for the rise of the
metronome in the 19th century.) There is, however, no such thing
as a temporal ether, (tempo is <i>not</i> fundamental) so the
notation conventions eventually collapsed (at about the same time
as the concept of a spatial ether).<br>
<br>
<blockquote type="cite">JK: Technically speaking, you seem to
overload the definition of CWMN in order to make it "broad"
enough for covering your approach. </blockquote>
That's also not quite right.<br>
A tempo-less customization of MEI should be regarded as a strict,
formal, (even academic) exercise, that has no <i>necessary</i>
relation to CWMN at all. <br>
<br>
And I am <i>not</i> just trying to be different. This is <i>not</i>
just my private problem -- though I've been working on it since I
was a student. The notation of tempo-less music is the central
problem that that was left for future generations to solve when
the<i> Avant Garde</i> gave up on their notational experiments in
1970. You are all ignoring 20th century music history! :-)<br>
<br>
I'm using CWMN symbols in my projects because they are the most
advanced, most <i>legible</i> set of such symbols available. But,
in principle, I could use any other glyphs or glyph combinations.
The <i>Avant-Garde</i>'s assumption that CWMN symbols have to be
reserved for "precisely defined" music (i.e. music having no
performance-practice tradition), and that a completely different
notation (or set of symbols) has to be invented for other kinds of
music, comes from neo-classicism, and is simply wrong. Staves,
clefs and chord symbols are also used in pre-classical music. <br>
<br>
When this tempo-less notation has been defined, we can see if
there are any consequences for the full CWMN customization. I
suspect, of course, that a MEI customization that can deal with
arbitrary durations, could be easily adapted for using the
restricted set of duration proportions available in (metronomic)
CWMN. Tuplets, grace-notes etc. will have to be treated
differently than they are at present, but I see no fundamental
obstacles to giving them strict, verifiable definitions related to
default, metronomically defined, performances.<br>
<br>
I also think that the existence of a tempo-less customization
would have consequences for the other kinds of notation defined by
MEI. Since the glyphs or glyph combinations can be freely chosen,
neumes are also in scope.<br>
<br>
Note that this proposal allows <i>multiple interpretations</i> of
the symbols to be stored, quite independently of the glyphs or
glyph combinations in use. It enables the storing of performance
practice traditions. Currently, this is being done outside scores,
using separate, unsynchronized recordings. Opera singers currently
learn their parts by listening to CDs. The revival of performance
practice traditions for Ancient Music would never have happened
without the use of <i>recordings</i>. I'd like to enable
something similar for New Music <i>that has not yet been
performed</i>. I want to be able to write new music that <i>breathes</i>.
Listen to the score, and imitate... using the symbols as an <i>aide
memoire</i>... that's what they have <i>always</i> been for...<br>
<br>
Laurent said:<br>
<blockquote type="cite">LP: Let me take the opportunity to clarify
the role of customizations in MEI, which are very flexible as
with many other things in MEI. One possible use is for
restricting MEI to a subset. This is achieved with the Tido's
customization, which acts as an application profile. It is also
the goal of the MEI Go! (or whatever it will be called) where we
would like to define the most essential components we need for
facilitating data exchange between projects.<br>
</blockquote>
I still don't really understand what MEI Go! is for, or whether it
really has anything to do with my project. <br>
<blockquote type="cite">
Now, the good news for you is that customization can also be
used for uncommon notation features, which is what it seems you
would like to do.</blockquote>
As I said above, I don't think this is just my private problem.<br>
<blockquote type="cite">This can also be used for correcting what
you think is a mistake in MEI. The other good news is that you
do not need to convince everybody on the list to do so. You can
do it on your own.</blockquote>
Or I only need to convince one person who knows MEI inside-out to
do it! I'm very willing and able to follow what that person would
be doing (and pointing out any problems that I see arising), but I
don't think I should be the person in charge. This might look as
if I'm chickening out, but here are my reasons:<br>
1. I'm currently working on a new piece for the web, in which I
want to try out some new, advanced data structures that are the
beginnings of "harmony and counterpoint" in tempo-less music. Yes,
I compose experimental music... :-)<br>
2. Even if I took the time to learn how to customize MEI, it looks
as if I'm going to run into non-trivial problems setting up the
framework. I program using Visual Studio (latest Community
edition) on Windows 10. Visual Studio has advanced support for
using schemas, so there shouldn't be any problem there.<br>
But <a class="moz-txt-link-freetext"
href="https://github.com/music-encoding/music-encoding">https://github.com/music-encoding/music-encoding
</a>says that<br>
"Building MEI requires the TEI Stylesheets. You should clone their
git repository, or download them in a packaged zip file",<br>
and <a class="moz-txt-link-freetext"
href="https://github.com/TEIC/Stylesheets">https://github.com/TEIC/Stylesheets</a>
says that its binaries will "run on Linux, OS X or other Unix
operating systems." I don't know if or how I can compile the
source code...<br>
3. I don't really need the tempo-less MEI customization myself. I
think you need it more than I do.<br>
4. There may well be consequences at a pretty deep level inside
the MEI code. Such consequences need to be dealt with by someone
who knows the code extremely well. I simply don't have that
experience. <br>
5. It would be really wonderful if someone else took up this
challenge. I'm pretty fed up with having to do everything myself.
:-)<br>
<br>
Any ideas?<br>
<br>
All the best,<br>
James<br>
<br>
<div class="moz-signature">-- <br>
<a class="moz-txt-link-freetext" href="http://james-ingram-act-two.de">http://james-ingram-act-two.de</a><br>
<a class="moz-txt-link-freetext" href="https://github.com/notator">https://github.com/notator</a> </div>
<br>
<hr size="2" width="100%"><br>
Am 25.05.2016 um 23:08 schrieb Johannes Kepper:<br>
</div>
<blockquote
cite="mid:77B8D95D-4F40-4B4A-B790-3B4595E08091@edirom.de"
type="cite"> <br>
Hi James,<br>
let me chime in as well. I believe that the uneasiness that is
almost tangible in Andrew's (excellent) response comes from your
understanding of CWMN. Actually, it seems to me that you have a
conception of CWMN that doesn't follow a more traditional
understanding, as implemented in MusicXML or MEI. While we all
know that CMN isn't as strictly defined as we sometimes pretend,
and despite the very free form of cadenzas and similar material, I
believe that your definition is clearly outside of CMN as
perceived and utilized by composers such as Bach, Beethoven,
Bizet, Busoni or Borodin. However, part of the game has always
been to stretch (and sometimes break) the rules of notation to
achieve novelty. At the same time, CWMN is about _notation_, and
is per se independent of any performance. Every generation had
it's own take on how to interpret these symbols, and this is what
makes performance practice such an interesting field.<br>
<br>
However, you seek to use an encoding scheme for your own
compositions. For this purpose, you utilize a set of symbols
borrowed from CWMN, and you use them in an *almost* compatible
way. However, while some constructs like tuplets may have no
special meaning / use in your approach, they are definitely a
crucial part of CWMN in its traditional meaning. Technically
speaking, you seem to overload the definition of CWMN in order to
make it "broad" enough for covering your approach. This motivation
seems valid, but I guess that I'm not the only one who feels that
this "stretching" costs too much of CWMN's specificity. Instead, I
tend to understand this as notational system in its own right,
which is (just) based on CWMN. If that's the case, it would be
perfectly possible to actually model this relation in an MEI
customization, which bases on the CMN module and adjusts it to
your specific needs, as Laurent pointed out. That might also give
an opportunity to document your concept of CWMN+ (or however this
thing should be called), and how it relates to "regular" CMN.<br>
<br>
I don't know if my analysis is correct or now, but maybe it helps
to get a clearer picture.<br>
<br>
All best,<br>
Johannes<br>
<br>
<blockquote type="cite">Am 25.05.2016 um 22:40 schrieb Laurent
Pugin <a class="moz-txt-link-rfc2396E" href="mailto:lxpugin@gmail.com"><lxpugin@gmail.com></a>: <br>
<br>
Hi James,<br>
<br>
Let me take the opportunity to clarify the role of
customizations in MEI, which are very flexible as with many
other things in MEI. One possible use is for restricting MEI to
a subset. This is achieved with the Tido's customization, which
acts as an application profile. It is also the goal of the MEI
Go! (or whatever it will be called) where we would like to
define the most essential components we need for facilitating
data exchange between projects.<br>
<br>
Now, the good news for you is that customization can also be
used for uncommon notation features, which is what it seems you
would like to do. This can also be used for correcting what you
think is a mistake in MEI. The other good news is that you do
not need to convince everybody on the list to do so. You can do
it on your own. Eventually, if your proposal seems to be a good
idea there is no reason for not having it integrated in MEI.<br>
<br>
Best,<br>
Laurent<br>
<br>
On Wed, May 25, 2016 at 4:51 PM, Andrew Hankinson
<a class="moz-txt-link-rfc2396E" href="mailto:andrew.hankinson@mail.mcgill.ca"><andrew.hankinson@mail.mcgill.ca></a> wrote:<br>
<br>
AH: I'll try to respond inline below.
<blockquote type="cite">JI: Hi Andrew, Zoltan,
JI: Zoltan: thanks for your answers to this thread on the W3C
CG list. This reply to Andrew (below) continues the thread
here, so its also a reply to what you said.
<blockquote type="cite">AH: For rhythm and duration we
differentiate between "@dur" (written duration) and
"@dur.ges" (performed duration). Both of these are available
on note and rest objects.
</blockquote>
JI: Yes, that's one of the problems -- see below. :-)
<blockquote type="cite">
<blockquote type="cite">JI: I want to make an MEI
customisation that uses most of the symbols that are used
by CWMN, but without assuming tempo. If there is no tempo,
then neither tuplets nor grace-notes make sense. It should
also be possible for the description of more than one
temporal instantiation to be stored inside the XML
elements that represent the score's graphics.
</blockquote>
AH: I'm not sure I understand this. Tempo is generally
expressed by a playback mechanism. It can be hinted at in
the encoding, but most systems have controls for overriding
it.
</blockquote>
JI: The @dur attribute describes both the shape of the symbol
and its meaning (the number of beats it represents in a
<measure>). Beats mean tempo, and that's a problem if
I'm trying to create a customisation that does without it.
I want to separate the meaning of each duration symbol from
its visual appearance by putting the temporal information in
an enclosed element. Lets call the enclosed element
<time>. Actually, I want (potentially) to have a list of
<time> elements inside each duration symbol, each
position in such lists containing the temporal information for
a different performance of the piece.
</blockquote>
AH: If you'll permit me a frank comment, it sounds like you have
a pretty good idea of your own encoding format, which is neither
MEI nor MNX.
Depending on how far down the rabbit hole you want to go, it is
completely possible to separate visual identity from durational
identity in MEI. We use '<note>' and '<rest>'
effectively as `time` elements -- that is, elements that record
the passing of time. One records a pitch, the other records
silence. Since @dur.ges accepts absolute durations, it
effectively acts exactly as you are expecting.
With the @headshape attribute you can precisely control the
visual appearance of the object, separate from its time. I
believe in the forthcoming release you can even use this to
include a SMuFL codepoint.
<blockquote type="cite">JI: [begin aside]
The first <time> element would describe the symbol's
default duration, which in MusicXML and MEI Go can be
calculated from the tempo, ppq, logical value of @dur. etc.
If used in CWMN, the <time> element would make all that
tempo, ppq, logical value @dur.ges stuff redundant.
Simplification is always a good idea! :-) Note that this
strategy means that @dur's logical value and @dur.ges are both
being treated as being in the same dimension (time).
Pretending that att.duration.musical and
att.duration.performed need to be treated differently is, I
think, a mistake.
Note also that the latest MIDI standard (the Web MIDI API) no
longer supports tempo. Including tempo in the 1981 MIDI
standard was a mistake, which has now been rectified. The Web
MIDI API just uses milliseconds.
Even CWMN scores should be allowed to contain descriptions of
additional temporal renderings, apart from the default,
metronomic one... This strategy makes metronomes redundant,
since scores can contain accurate temporal renderings of what
the composer really meant, not just an implied mechanical
realisation.
[end aside]
</blockquote>
AH: If you'll permit me another frank comment, it seems you have
very narrow needs that (in my experience) do not necessarily
apply to a much wider audience. This is absolutely fine --
figuring out how to encode narrow repertoires is something that
we welcome and encourage in the MEI community. My own experience
is that within MEI there is usually a way to express exactly
what you want to, but that way is not always obvious (unless
you're from West Virginia... :).
att.duration.musical and att.duration.performed are one of the
most reviewed and core components of MEI, and they are hardly a
'mistake' nor are they misguided efforts. They effectively model
a vast existing repertoire. If we are talking about new notation
systems then all bets are off, but saying things are
'unimportant' or 'mistakes' simply because they don't conform to
a narrow vision of notation is an equally problematic position.
If you have an existing absolute rendering (i.e., a recording)
you can use the <when>/@when/@data timepoint indications
to show how a symbolic rendering aligns with an absolute record
of the performance.
<blockquote type="cite">JI: The simplest case would be if the
<time> element simply had an @ms attribute which would
be its duration in milliseconds. But this element should also
be able to contain more complex temporal information. A
<note> or <chord> symbol can contain ornaments
that can be described using MIDI information. All MIDI info is
purely temporal. So the duration of the <time> elements
embedded in <note>s and <chord>s should really be
calculated from the durations in the contained MIDI sequence.
A <time> element in a <rest> might just have a
simple @ms attribute.
But lets forget about such refinements for the moment and just
note that the <time> element has a (or defines) a
duration.
I want to use <measure>, but here again, I want to
separate its graphical aspects from its meaning.
Question: Does setting measure@metcon to false do that? If
@metcon is false, can I then use arbitrary symbols in the
various contained <level>s, and ignore the logical
values of all the @dur attributes?
Graphically, a measure is just two vertical lines enclosing
<staff> elements that enclose <layer> elements
that enclose duration symbols (<note>s, <chord>s
and <rest>s) and other "events" in a left-right
sequence.
The duration symbols' left-right sequence in the measure
corresponds to their earlier-later sequence in time, so there
has to be a mechanism for describing the left-right sequence
of all the symbols in a <measure>.
</blockquote>
AH: Elements inside of layer are ordered. If they have a
duration, they are assumed to be processed in the order they are
listed.
<blockquote type="cite">JI: [begin aside]
My current solution for this, is to use the default
millisecond duration of the symbol's <time> element (an
integer) as a dimensionless number. The algorithm that creates
an (SVG) instantiation of the abstract XML info first uses
this number as a spatial unit (a number of pixels) in a space
wide enough to position the symbols so that they don't
overlap, then compresses the width of the system into the
actually available space. My algorithm is recursive, and
results in spacing that corresponds to what I think is the
best, (most legible) way to space music symbols. If the width
is too small for the symbols to be spaced proportionally to
their durations (the usual case), then less space is given to
the longer durations.
[end aside]
While the logical durations of the @dur attributes may not
have to add up in a tempoless <measure>, the
<measure> still imposes a restriction on the durations
of the <time> elements. The durations of the
<time> elements in each <layer> have to add up to
the same value in any particular performance. They don't, of
course, have to add up to the same value across different
performances. How can I express that in a schema? Maybe I
don't need to express that explicitly, but its still something
that can be validated automatically by software.
<blockquote type="cite">AH: I'm really not sure where you're
going with the duration symbols and fixed meanings, though.
Why would you be adding gracenotes and tuplets?
</blockquote>
JI: In a tempoless notation, there is no need to litter the
score with little numbers and brackets (tuplets) or to make
some symbols smaller in order to make it clear that some notes
are outside the counting scheme (grace-notes) or to add little
dots to the symbols to mean that they are longer than they
would be otherwise (augmentation dots). I think of all these
as annotations that can be added ad lib to a score, without
affecting the playback of the contained temporal information.
Tuplets and grace-notes only make sense in music that has
tempo (CWMN).
</blockquote>
AH: Again, I'm not sure where you're going with this.
Tempo means time. All music takes up time -- that's what makes
it music! There is no such thing as 'tempoless notation' since
that (essentially) means notation that is not meant to express
time. So I think you need to more clearly express this so that I
(we?) can understand it.
*You* can certainly write music that does not use "little
numbers and brackets" but your use case is really a very small
part of larger efforts. I can assure you that there are plenty
of people who *do* want little numbers and brackets, and they
want them to be a core part of the notation scheme. Thinking of
them as annotations is not adequate, since there are
non-absolute durational implications to having these elements
present.
<blockquote type="cite">JI: I'm not so sure about augmentation
dots -- which could be used as annotations in tempoless music
to imply that the note should be performed longishly... But a
tenuto articulation could do that just as well. Its probably
something that should be left to the composer to decide. Maybe
the composer wants to use tenuto to imply something else
(emphasis of some kind).
Apropos verification: Maybe there's some way in CWMN to ensure
that the default <time> durations inside a tuplet are as
equal as possible. But those durations must be integers in
order to prevent the endless hassle with rounding floating
point numbers. None of the durations in the default
(metronomic) performance should be allowed to be more than one
millisecond longer than any of the others. Grace notes inside
tuplets complicate things of course, but the problem should
not be insoluble.
<blockquote type="cite">
<blockquote type="cite">JI: Can you imagine such a hierarchy
of customisations? I'm also thinking of the container
hierarchy that could become part of the W3C standard for
describing any polyphonic music notation.
</blockquote>
AH: A customization is not arranged in a hierarchy. The
primary reason for a customization is to produce a schema
that will validate an encoding.
</blockquote>
JI: That's not a problem.
I was thinking more of another level: I think that all
polyphonic music notations could share the same container
hierarchy. The page->system->staff->layer hierarchy
is actually independent of the graphics. Notations can use the
same terms, even if they are read left to right, top to bottom
or round in circles. The graphic representation is really just
up to the software that instantiates the score. I just didn't
want to miss the chance of some more modularity.
Its probably not very important in polyphonic music, but it
might help the evolution of software for homophonic music, if
the developers always used the same names for their simplified
container hierarchy. For example: page->staff.
</blockquote>
AH: MEI has no particular affinity to rendering or graphical
layout. Many of us consider "rendering" to be sonic or analytic
as well -- i.e., a system that 'renders' notation for the
purpose of search and analysis.
In closing, I would encourage you to keep asking questions.
However, if I were to make a suggestion it would be that the
tone and tenor of your messages would skew towards trying to
learn about what we've done in the community before trying to
suggest fundamental changes. I think you'll find that there are
many people who know what they're talking about here, and who
have decades of experience with all types of music notation
efforts. Right now it seems that there is an assumption in your
messages that everyone is doing it wrong, and I don't think
that's a productive place to start our conversations. <br>
<br>
Cheers,<br>
Andrew
<blockquote type="cite">Hope that helps,<br>
James
</blockquote>
</blockquote>
</blockquote>
<br>
</body>
</html>