GUIDELINES FOR MTO AUTHORS This document contains two sections: 1. MTO Editorial Policy 2. Guidelines for Authors 1. MTO EDITORIAL POLICY [1] The electronic journal Music Theory Online (MTO) welcomes submissions on any topic of interest to the music theory community. Authors may submit items for consideration at any time. All submissions to MTO will be read "blind" by reviewers selected by the MTO co-editorial board. To insure a blind reading, please submit your text to the MTO editor (address below), preferably via e-mail, though copies may be submitted on disk (in ASCII format). [Hard copy submissions will be accepted only by prior agreement and approval.] The editor will remove all email headers and other information which might disclose the identity of an author. Review of submissions will be completed as quickly as possible, normally within six weeks of receipt. [2] Guidlines for authors are available in the document "authors.txt" (the present document) which may be retrieved by addressing a message to mto-serv@husc.harvard.edu (or mto-serv@husc.bitnet). Leave the "Subject:" line blank, and as the body of the message include only the following two lines: path YourEmailAddress send authors.txt Replace "YourEmailAddress" with your *full* email address, including the ".bitnet" suffix for a Bitnet address. All questions concerning MTO editorial policy should be sent to mto-editor@husc.harvard.edu (or mto-editor@husc.bitnet). 2. GUIDELINES FOR AUTHORS [1] Articles, reviews, announcements, communications, etc., for MTO should be submitted for review to the General Editor. They may be sent on diskette, by regular mail, to: Music Theory Online, Music Department/Music Bldg., Harvard University, Cambridge, MA 02138; or submitted by email to one of the following two email addresses: Internet: mto-editor@husc.harvard.edu Bitnet: mto-editor@husc.bitnet All items should be prepared as pure ASCII text (no special paragraph or character formatting, i.e. no italics, underlining, or diacritical marks such as umlauts or other foreign-languge accents). Right and left margins should be set at 1.85" inches. [NOTE: see the Appendix to this document for more information regarding margins.] Articles should be from 400 to 600 (maximum) lines in length, including footnotes (ca. 8-12 single-spaced, typewritten pages), keeping on average to 500 lines. Shorter essays may be submitted as "works in progress." Reviews should be 200 to 300 lines (ca. 4-6 single-spaced pages). [2] Commentaries on MTO articles are divided into two categores: brief, immediate responses (up to 50 lines of text); longer, in-depth commentaries (more than 50 lines of text). Brief, immediate responses to MTO articles (or to other MTO commentaries) should be sent to the SMT Email Conference, at one of the two following addresses: smt-list@husc.harvard.edu (Internet) smt-list@husc.bitnet (Bitnet) Be sure to include your full name, institutional affiliation, and email address(es) at the end of the response. [NOTE: Those wishing to send brief responses to the smt-list but are not yet subscribers to it should send a message to the list manager, at the address smt-editor@husc.harvard.edu (or to smt-editor@husc.bitnet), and should ask to be added to the list. In the message, include your full name, institutional affiliation, and your connection with/interest in music theory.] Longer, in-depth responses to MTO articles (or to other responses) should be sent to one of the following addresses: mto-editor@husc.harvard.edu (Internet) mto-editor@husc.bitnet (Bitnet) Authors of longer responses should following the guidelines given below when preparing their electronic texts. [3] Every essay, review, and commentary must include: a) an indexing header (for database searches); and b) an author header (for identifying authors by name, institution, and email address). The indexing header should appear at the very beginning of every essay and review, and should be in the following form ([CR] = carriage return): AUTHOR: LastName, FirstName, MiddileInitial[CR] TITLE: ArticleTitle[CR] KEYWORDS: KeywordList[CR] <6-8, maximum, word-wrapped> REFERENCE: [BLANK LINE][CR] [BLANK LINE][CR] Keywords should be separated from one another with a comma followed by a space (e.g. KEYWORDS: form, sonata, Koch, C.P.E. Bach). Keywords should be either topical, or should be names of composers or theorists. If topical, they should be general in nature (e.g. rhythm, form, acoustics, etc.), or should identify a genre(s) discussed substantively in the article (e.g. sonata, symphony). A list of keywords that exceeds one word-processed line should not have carriage returns at the end of each line. Instead, each line should be allowed to wrap around, and there should be only *one* carriage return, at the end of the keyword list. The REFERENCE field should be included only by authors of commentaries on MTO articles. It should be filled in with the filename of the article being commented upon, as listed in the issue of MTO in which the article appeared. Following the second blank line after the indexing header, the author header should appear, in the following form: FirstName MiddleInitial LastName[CR] Institutional Affiliation[CR] Departmental Affiliation[CR] Street Address[CR] City, State Zipcode[CR] Email Address(es)[CR] [BLANK LINE][CR] ABSTRACT: AbstractText[CR] <100-words, single-spaced> [BLANK LINE][CR] ACCOMPANYING FILES: [BLANK LINE][CR] [BLANK LINE][CR] Lines of the abstract should *not* wrap around. Instead, each word-processed line of the abstract should end with a carriage return. The "ACCOMPANYING FILES:" section should be used to list the names of files containing musical examples or graphical (i.e. non-ASCII) figures, such as illustrations, tables, etc. All graphical files should be prepared as GIF files (Graphical Interchange Format; see paragrah 6 below). The text of the article should follow the second blank line after the author header. Below is an example of indexing and author headers: ======================================================= Schoenberg at the Movies: Dodecaphony and Film AUTHOR: Neumeyer, David, P. TITLE: Schoenberg at the Movies: Dodecaphony and Film KEYWORDS: twelve-tone, commutation test, Frankenstein, cinema, film music, Schoenberg David P. Neumeyer Indiana University School of Music Bloomington, IN 47405 neumeyer@ucs.indiana.edu ABSTRACT: Composers used the twelve-tone method in film scores from the 1950's and 60's. This essay focuses on a much earlier work: Schoenberg's *Begleitungsmusik zu einer Lichtspielszene,* Op. 34 (1930), which was, however, commissioned for a cinema-music library, not a specific film. I apply simple commutation tests to gauge how Opus 34 might actually function as background music, and I assess the implications of questions that arise about musical culture and class differences. ACCOMPANYING FILES: mto.93.0.1.neumeyer-1.gif mto.93.0.1.neumeyer-2.gif BEGINNING OF ARTICLE TEXT (starting with numbered paragraph [1]) ======================================================== If applicable, authors should add the "ACCOMPANYING FILES:" field. Items listed in this field are graphical files, to be prepared as GIF files (see paragrah 6 below). Authors need not name their example and figure files according to the MTO standard format (as shown above). They should send them by email, in UUencoded form, or should FTP them to the MTO mainframe (see paragraphs 7-8 below). The MTO staff will assign the proper filenames and fill in the ACCOMPANYING FILES field accordingly. David Neumeyer's pilot article, "Schoenberg at the Movies: Dodecaphony and Film," MTO 0.1 (1993), can be taken as a model for the format, style, and content of an MTO article. [4] Authors should adhere to conventions of scholarly writing and bibliographic form, as outlined in the latest edition of *The Chicago Manual of Style*. Paragraphs should be numbered with arabic numerals enclosed in square brackets. Footnote reference numbers should be enclosed in parentheses(1). All footnotes for a paragraph should appear immediately after that paragraph, set off from it by a blank line and a series of equal signs both above and below the footnote(s), as shown below.(2) ================================== 1. This is footnote number 1. 2. This is footnote number 2. ================================== The proper form for citing items published in MTO is as follows: A. In a bibliography: Neumeyer, David. "Schoenberg at the Movies: Dodecaphony and Film," Music Theory Online 0.1 (1993): 1-20. B. In a footnote (citing paragraph 3, for instance): David Neumeyer, "Schoenberg at the Movies: Dodecaphony and Film," Music Theory Online 0.1 (1993): 3. [5] Italics (for titles and emphasis) should be indicated with pairs of asterisks surrounding the title or word(s) to be *emphasized*, as shown above with *The Chicago Manual of Style*. Superscripting should be indicated with pairs of surrounding carets, for example ^2^. [6] Authors are encouraged to make the text of their essays as self-sufficient as possible by keeping musical examples and graphical figures to a minimum. Musical examples and figures, along with identifying captions, should be included at appropriate points in the text, for instance: Ex. 1 Chopin, op. 10, no. 6, mm. 1-8. Where no musical examples will appear, authors should: a) give precise citation of work titles, movement and measure numbers; b) describe as fully and as clearly possible the musical procedures and issues under discussion; c) use makeshift notation where possible, using common typewriter symbols (ASCII characters). [7] If musical examples are to appear, authors should prepare them as GIF files (Graphical Interchange Format) either by scanning and saving the image as a GIF file, or by creating the example themselves with a music notation program, and then choosing the GIF option to save the file. Authors should make a separate GIF file for each example. Authors who cannot create a GIF file by either of these methods may submit *camera-ready* examples by mail, and the MTO staff will prepare the GIF files. [8] GIF files may be sent over the Internet by means of anonymous FTP (File Transfer Protocol). At a mainframe prompt, type "ftp husc4.harvard.edu". At the login prompt, type "anonymous", and at the password prompt type "guest". Once connected, type "cd pub/smt/uploads". Before sending the file(s), type "binary" to prepare FTP for a binary transfer. Then, to send each GIF file, type "put ", replacing with the name of the GIF file for each transfer. When all files have been sent, type "bye" to terminate the FTP session. [NOTE: FTP procedures differ among mainframes. If the preceding instructions do not work, consult your local user services for assistance.] [9] Alternatively, authors can UUencode their GIF files with encoding software provided by MTO. UUencoding converts GIF files from their native (un-emailable) binary format to emailable, ASCII format. Once UUencoded, GIF files can be sent to one of the mto-editor addresses given above. [10] Items published in MTO, particularly revised and expanded versions of works in progress, may be republished by their authors in a print journal provided that a) at least one year has elapsed between the time the item appeared in MTO and its appearance in the print journal; and b) MTO is cited in full (vol., issue, year) as the original publisher of the item. [11] Any questions concerning the preparation, refereeing, publication, or republication of MTO articles should be addressed to the mto-editor. ===================================== APPENDIX Ensuring Compatibility Between Text Editors and Word Processors In order to be sure that MTO documents prepared with word processors display well in mainframe text editors (and email readers, and vice versa, authors should read the following explanation of how word processors and text editors determine how text fits between margins. Word processors place text between margins that either are preset or are explicitly set by the user. Text editors, on the other hand, do not have margins. They simply place text within the borders of the terminal being used. To exchange information between word processors and text editors without distorting the original text layout, something equivalent to line length must be specified for text prepared with a word processor and, conversely, something equivalent to margins must be specified for text prepared with a text editor. Text editors have no provisions for setting margins directly, but they do provide a way for setting the line length, which is equivalent to setting margins on a word processor. In a word processor, the equivalent of setting the line length is setting the margins to allow only a desired number of characters to fit across the page. Line length depends on the margin settings and the font used. To ensure compatibility between word processors and text editors, users of word processors should only use non-proportional fonts. The most common of these, Courier, is available on most word processors. Because the width of each character in Courier font is the same, the length of any line can always be predicted. Another characteristic of fonts is their POINT SIZE, a term used by printers to specify font traits. Word processors usually identify fonts by their point size. More important for line length, however, is a font's PITCH. The pitch number determines the number of characters per inch. Most word processors do not identify the pitch of a font. The default Macintosh font, 12-point Courier, is a 10-pitch font (ten characters per inch). The 10-point Courier font is approximately 12-pitch (twelve characters per inch). It is easy to determine the pitch of any point size of the Courier font: type a line of text, count the number of characters before the automatic word wrap, and divide by the page size minus the margins. For a 12-point, 10-pitch Courier font, the line lengths for different margins are as follows: Margins Useful Page Width Line Length 1" 6.5" 65 1.25" 6" 60 1.5" 5.5" 55 The number corresponding to the desired margin can be used to specify the line length in an editor. MTO documents should be prepared with a maximum line length of 65 characters. Following are the commands that set the line length for three widely used text editors: UNIX EMACS: C-u 60 C-x f M-x auto-fill-mode NOTE: 'C-u 60' means hold the "control" key down while typing the "u" key, releasing both and typing "60". 'C-x f' means hold the control key down while typing the "x" key, releasing both, and then typing the "f" key. M- means hold the "meta" key, OR hold the ESC key, while typing the next key, in this case, "x". ========================================== VAX EDT: *set wrap 60 NOTE: Do not type the "*". The command is everything following the "*". Then type *ch to change to full screen editing. A different number can be substituted for the "60" used in the examples. The auto-wrap feature of the text editor will insert end-of-line characters in the same way that a word processor would when a file is saved as a text-only file. ========================================= UNIX vi: In both of these examples, the number (60) corresponded with the line length. The Unix editor "vi" uses a different approach. The "wrapmargin" is set to the DIFFERENCE between the screen width and the line width. To get 60 characters per line on an 80-column terminal, the wrapmargin is set to 20: :set wm=20 Like any vi command, this command can only be issued from command mode. If you are inputting text, first press ESC to end insert mode, then issue the command. Appendix by Paul Dworak Univ. of N. Texas +++++++++++++++++++++++++++++++ END OF AUTHOR GUIDELINES