bradr@SUN.COM (Brad Rubenstein) (12/18/87)
Music-Research Digest Thu, 17 Dec 87 Volume 2 : Issue 30
Today's Topics:
ANSI Standard Music Representation Language Project
*** Send contributions to Music-Research@uk.ac.oxford.prg.sevax
*** Send administrative requests to Music-Research-Request
*** Overseas users should reverse UK addresses and give gateway if necessary
*** e.g. Music-Research@prg.oxford.ac.uk
*** or Music-Research%prg.oxford.ac.uk@nss.cs.ucl.ac.uk
----------------------------------------------------------------------
Date: Thu, 17 Dec 87 13:20:09 EST
From: "Steven R. Newcomb" <cmr!srn@edu.ufl.cis.ufcsv>
Subject: ANSI Standard Music Representation Language Project
To: Music-Research <Music-Research%uk.ac.oxford.prg@uk.ac.ucl.cs.nss>
GENERAL INFORMATION ABOUT THE
X3V1.8M STANDARD MUSIC REPRESENTATION LANGUAGE WORK GROUP
(formerly known as the "Music Information Processing Standards [MIPS] Committee")
Accredited Standards Committee,
X3 -- INFORMATION PROCESSING SYSTEMS, Operating under the procedures of the American
National Standards Institute (ANSI). Technical committee.
V1 -- Text processing: Office and Publishing Systems. Task Group.
.8 -- Languages for Text Processing and Interchange. Ad hoc task group.
M -- Standard Music Representation Language Work Group
Please address inquiries to:
X3V1.8M Secretariat
c/o Craig R. Harris
The Computer Music Association
P. O. Box 1634
San Francisco, California 94101-1634 USA
Charles F. Goldfarb, Chairman Steven R. Newcomb, Vice Chairman
IBM Almaden Research Laboratory Center for Music Research
Laboratory, K84/803 214 Music School South
650 Harry Road Florida State University
San Jose, CA 95120 Tallahassee, FL 32306-2098
tel: 408/927-2577 tel: 904/644-5786
uucp: {gould,akgua}!ufcsv!cmr!srn
arpa: cmr!srn@bikini.cis.ufl.edu
The purpose of the ANSI X3V1.8M Standard Music Representation Language Work
Group is to create a standard language for music description for adoption
by the appropriate committee operating under the rules and procedures of
the American National Standards Institute (ANSI).
The X3V1.8M Work Group has been organized to address the following needs:
(1) Publishers need a way of representing musical examples within a docu-
ment file (e.g. a music textbook), so that no additional typesetting
or formatting cost is incurred, and no paste-ups need be done when
either the text or music portions of the document are edited.
(2) Makers of computer-mediated business presentations need to integrate
music into their productions, and their productions need to be port-
able. Those who create business presentations, especially those who
create business presentations of the kind that are now commonly done
with a PC and a video projector, want to incorporate music in such
presentations, and they want to be in a position to have the music
reformatted (i.e., rearranged) for different performing resources "on
the fly." The business of business presentations is a large one and
it can be expected to contribute considerable demand for computer
music products, and, of course, for music itself.
(3) Computer assisted instruction which employs music as a reinforcer, or
which actually teaches music, needs to be portable in order to maxim-
ize its marketability. The people who create the instruction need to
be able to call upon databases of music written by other people who
wrote or transcribed the music using perhaps incompatible hardware
and/or software systems.
(4) Electronic distributors of information (via videotex, etc.) need to be
able to include music as part of their product mix.
(5) It is perhaps too obvious to mention that composers, performers, and
arrangers would be better able to exploit the market for their
creativity, and their market would be better served and have a wider
variety of product to choose from, given the existence of a lingua
franca for music--a single representation which is able to encompass
the kind of information which is available from printed music, as well
as the kind of information (gesture, nuance) which performers add in
any given performance.
(6) Fill in your own need which would be addressed by a standard language
for music representation.
The first meeting was held in July, 1986, in Half Moon Bay, California.
Meetings are held about four times per year, and they are held in various
locations throughout the continental United States (e.g. San Jose, Minneap-
olis, Washington D.C., New York City). Meetings are four days long.
The Standard Music Representation Language Work Group is known as X3V1.8M.
X3 is the Information Processing Systems organization operating under the
procedures of ANSI; V1 is the task group of X3 whose purpose is to create
standards for text processing in office and publishing systems; X3V1.8 is
an ad hoc task group whose purpose is to create standard languages for text
processing and interchange. In X3V1 parlance, the word "text" has an
extremely broad definition which includes all kinds of information.
The ANSI entity to which the X3V1.8M Standard Music Representation Language
Work Group will propose the language it devises is X3V1.8 Ad Hoc Task
Group. X3V1.8's focus has been on creating a Standard Generalized Markup
Language (SGML) for documents, which has turned out to have evolved from
IBM's Generalized Markup Language (GML). (Dr. Charles Goldfarb led the
team which developed GML at IBM's Cambridge Research Laboratory in 1969;
today he is a participant in X3V1.8 and serves as Chairman of X3V1.8M.)
GML is already the format of 90% of the documents published by IBM, and the
IRS's use of GML for tax form preparation is a kind of testimonial to its
power and flexibility. X3V1.8's cooperating opposite number in the Inter-
national Organization for Standardization (ISO), is known as Technical Com-
mittee 97, Subcommittee 18, Working Group 8. SGML became an ISO standard
in October 1986. The U. S. Department of Defense has approved SGML as a
standard for procurement documents, and the Association of American Pub-
lishers has adopted SGML and has published an application of the language
for journals, books, and mathematical formulae.
Both SGML and its forebear, GML, allow a document to describe itself in
terms of its logical parts, or elements. For example, the title of a
chapter might appear as:
<chaptitl>How Dorothy Returned to Oz</chaptitl>
and the first paragraph might appear as:
<p>When Dorothy returned to her room, there was a tiny cameo lying on
her dresser. She picked it up, and it began to glow, while the tiny
face on it seemed to come to life.</p>
The above instances of elements are the p (paragraph) element and the chap-
titl (chapter title) element. In SGML, each element may have attributes,
or information which may be either required or optional for that element,
depending on the declaration of the element itself in the document type
definition in effect for the document. The document type definition also
makes explicit how the elements are related to each other hierarchically,
i.e., which elements can contain which elements.
While all this may seem trivial, the beauty of GML (or SGML) is that a
document need not contain any formatting instructions, but all the informa-
tion about a document needed to format it automatically (by means of an
application designed to do that) can be placed within the document itself.
Having created a document expressed in SGML, the author or editor can
instruct a formatting program that, for example, all chapter titles appear
centered on new pages, one third of a page down, and that they are followed
by a specified amount of blank space. Thus, if the document is reprinted
in a journal or anthology with different formatting conventions, no one
needs to edit the document itself, because the formatter simply works
according to the new rules. SGML documents can contain normal text charac-
ters, graphics, images, mathematical formulae, and other specialized nota-
tions.
The task of the X3V1.8M Standard Music Representation Language Work Group
is to extend SGML into the realm of music, thus incorporating musical
information into the mainstream of information processing. In view of the
fact that SGML's facilities are well-adapted to the problem of expressing
how a particular information set's internal relationships are set up,
perhaps the best way of understanding the task confronting X3V1.8M is to
think of it as the creation of an SGML document type definition for musical
works.
X3 convened a study group in 1985, whose purpose was to consider the scope
and mission of a proposed Standard Music Representation Language Work
Group. The study group's report is brief; the gist of it is that the stan-
dard should be able to convey both the specific kinds of information which
performers generate (play THIS pitch THIS loud at THIS millisecond with
THIS timbre, etc.), and the specific kinds of information which are needed
by engravers of common music notation (beam these notes together, slur
those notes together, this is an A-sharp half note, etc.). Another way to
understand the study group's recommendation is to think of the language
envisioned by the study group as a fusion of (perhaps a superset of) the
information present in a time-tagged MIDI stream with (perhaps a superset
of) the information present in a music manuscript.
There are three distinct ways in which music information could be
represented within an SGML document. The choice will be made by the Work
Group whether to represent music as:
(1) A pure application of SGML. This would be desirable for several rea-
sons, including the fact that any textual information in the music
could be handled in the same way as any other text, and there would be
the least likelihood of conflict between the formatting conventions
for the text outside the music portion of a document and the format-
ting conventions for the text and music inside the music portion. On
the other hand, the "pure application" method may prove to be imprac-
tical for one reason or another. This is a technical issue which must
be decided by the Work Group.
(2) A character encoded representation (in SGML jargon, a specialized
"data content notation"). SGML documents might include portions con-
taining data in a language specific to music. DARMS, MUSTRAN, OPAL,
or some other coding scheme, or a new coding scheme devised by Work
Group participants, might form the basis for such a data content
notation. One advantage of this kind of representation (over #3,
below) is that it can be typed at a non-graphics terminal and printed
in the form of a listing by non-graphics printers.
(3) A binary encoded representation. SGML documents have the ability to
contain binary data, e.g., photographs. To a software developer, this
may appear, at first blush, to be the easiest method of dealing with
the problem of music representation. It may turn out to be the method
selected by the Work Group, but it is important for applications-
minded Work Group participants to be cognizant of the distinction
between an X3V1.8M representation and a representation which is inter-
nal to an application. The X3V1.8M representation will be for the
purpose of allowing applications with dissimilar internal representa-
tions to communicate with one another. A binary encoded representa-
tion will not necessarily be more convenient for a given application
to handle than an SGML application (#1 above) or a data content nota-
tion (#2 above).
The participants in the X3V1.8M Standard Music Representation Language Work
Group represent industrial, artistic, and academic interests. Large and
small business concerns, independent software developers, hardware manufac-
turers, music publishers, librarians, composers, and academic researchers
have attended and have been represented at X3V1.8M Standard Music Represen-
tation Language Work Group meetings. The meetings are open to the public-
-both to those who simply want to observe and to those who want to partici-
pate. Knowledgable participants who will faithfully attend meetings and
contribute their expertise in both oral and written form, and who will con-
structively interact with the other participants, are always very welcome.
The Computer Music Association serves as the Secretariat of the Work Group
as one of several activities designed to promote the exchange of informa-
tion about the use of computers and digital hardware and software for musi-
cal purposes. Anyone who wants information on the Work Group, or copies of
the documents submitted to the Work Group, or the "standing documents" of
the Work Group (the list of participants, the most recent register of docu-
ments, etc.), can contact the CMA for those things. Requesters of docu-
ments are charged according to the expenses incurred in filling the
requests (duplication, handling, and postage). Rates are $0.05 per page
(which amounts to $0.10 per sheet) + $2.50 per order + actual postage.
Requesters will be invoiced for the amounts they owe; the invoice will be
included in the package. Amounts will be payable in U. S. dollars, but
please do not send cash. All materials requested will be mailed first
class (or air mail to overseas addresses). A new alternative X3V1.8M Sub-
scription Service is soon to be available which we hope will meet the needs
of most interested parties: for a flat fee of $10.00/year, payable in
advance, we will send four issues. Each issue will contain the announce-
ment of the next meeting, an updated document register, the most recent
edition of Journal of Technical Development (which eventually will eventu-
ally evolve into the draft standard), and the most recent minutes.
Those who wish to submit documents relevant to the issues under considera-
tion by X3V1.8M may do so at any time; the CMA will be happy to put them on
the document register and make them available to the participants and to
the public by the procedure outlined above. If the material is protected
by copyright, a letter from the copyright holder must be included, saying
that the copyright holder waives all royalties and allows duplication of
the document(s) for purposes of X3V1.8M business. Please be informed that
there is no point in submitting documents to the Work Group for limited
circulation among certain participants; the Work Group must operate "in the
sunshine," and therefore all documents must either be placed in the
document register for public consumption, or they cannot be distributed
through Work Group channels at all. Documents containing confidential or
trade secret information MUST NOT BE SUBMITTED, AND THEY WILL NOT BE KNOW-
INGLY ACCEPTED FOR DISTRIBUTION.
Work Group participants are those who have made substantive contributions
to the work either by mail ("corresponding" participants) and/or by attend-
ing the meetings ("attending" participants). Within the limits of the gen-
erosity of corporate meeting hosts and other sponsors, mailings are made to
all participants of all documents added to the document register. Because
of the high cost of duplication and mailing, participants are narrowly
defined as those who have attended one or both of the previous two meet-
ings, or who, within the timeframe of the previous two meetings, have sub-
mitted written responses to the substance of the meetings themselves as
expressed in the Journal of Technical Development (e.g. X3V1.8M/87-12).
By creating an American National Standard Music Representation Language
now, we can avoid a considerable amount of chaos and wasted/duplicated
effort later. If we fail to create a such a standard soon, it could cost
music researchers many man-years, it could cost the computer and music
instrument industries much lost revenue, and it could negatively affect the
careers of an unknowable number of musicians. There are some who say that
it is premature to develop a music representation standard at this time.
There are others (including the participants in the present endeavor) who
say that setting such a standard is timely and perhaps overdue. There are
some who claim that standardizing the representation of music will stifle
creativity, or that the creation of music databases from the works of the
masters will create additional layers of misunderstanding and serious com-
munications failures between composers, performers, and audiences. Some
claim that musical scores, as the only tangible form of the composer's art,
would necessarily be misrepresented in any language intended to convey
musical meaning--there would have to be some interpretation of the score in
order to perform the translation, and, at the very least, the "eye music"
would be lost. Regardless of these concerns, it is undeniable that music
is going to be represented in computer-readable form, whether we like it or
not, and that if we do not take the initiative to create a standard openly,
we will either not have one (a wasteful, sorry situation), or there will
eventually be a de facto standard, arrived at in a haphazard and market-
driven fashion, which will not necessarily address the needs of significant
areas in the music field. If we do create a standard, it can be as good,
as flexible, as meaningful, and as reverent as we want it to be. Those who
care about the result, but do not participate in the process, have only
themselves to blame if the result does not meet their needs. The need for
a cooperative effort by all interested parties cannot be overemphasized.
It is not very helpful, for example, simply to advise the group of an
expert who ought to be present, or a paper that ought to be read. If you
know of persons who ought to be participants, you should recruit them.
Feel free to send them copies of this brochure or any other Work Group
papers. If you know of a document that should be considered by the group,
please contact its owner and request that it be contributed.
These are the standing documents of the X3V1.8M Standard Music Representa-
tion Language Work Group:
X3V1.8M/SD-0 This brochure.
X3V1.8M/SD-1 Proposal for Project to Develop a New X3 Standard
Generalized Music Representation for Information
Processing, an ANSI proposal dated 11/22/85. 4
pp.
X3V1.8M/SD-2 Document register. Variable number of pages.
Always order a fresh copy of this with any docu-
ment order; this is the only way to know about the
new documents.
X3V1.8M/SD-3 Participants and Officers. Variable number of
pages.
X3V1.8M/SD-4 Mailing list. Variable number of pages.
X3V1.8M/SD-0 87/12/16
------------------------------
End of Music-Research Digest
******************************