From: fred Date: Sun, 24 Mar 2002 20:12:24 +0000 (+0000) Subject: lilypond-1.0.1 X-Git-Tag: release/1.5.59~3062 X-Git-Url: https://git.donarmstrong.com/?a=commitdiff_plain;h=1f6b907baba5abb95aeaa17b8e2a2fc6e3dd2cad;p=lilypond.git lilypond-1.0.1 --- diff --git a/Documentation/COPERTINA.in b/Documentation/COPERTINA.in new file mode 100644 index 0000000000..664aec837e --- /dev/null +++ b/Documentation/COPERTINA.in @@ -0,0 +1,7 @@ +LilyPond è il tipografo musicale del progetto GNU. Questo programma è +fatto per stampare belle partiture da un documento definito per musica. +Può anche suonare le prestazioni meccaniche ad un documento MIDI. Le +caratteristiche includono i personali multipli, tester, chiavi, suoni, +lirica, lingua potente dell' input, cadenze, fasci, archi, tripletti, +segni di formattazione, estrazione delle parte. È compresa una seria +completa di caratteri musicali. diff --git a/Documentation/COPERTINA.yo b/Documentation/COPERTINA.yo new file mode 100644 index 0000000000..b4e0e0acef --- /dev/null +++ b/Documentation/COPERTINA.yo @@ -0,0 +1,9 @@ +COMMENT(silly... DEFINEMACRO(pic)(1)(url(ARG1)(ARG1.gif))) +DEFINEMACRO(pic)(1)(verbinclude(ARG1.in)) + +nsect(LilyPond è il tipografo musicale del progetto GNU. ) + +includefile(COPERTINA.in) +nl() +pic(schermo) + diff --git a/Documentation/FLAPTEKST.in b/Documentation/FLAPTEKST.in new file mode 100644 index 0000000000..90ee5e5d21 --- /dev/null +++ b/Documentation/FLAPTEKST.in @@ -0,0 +1,7 @@ +LilyPond is de muziekzetter van het GNU Project. Dit programma drukt +prachtige bladmuziek volgens een muzikaal definitie bestand. Ook kan +het een mechanische uitvoering afspelen naar een MIDI bestand. +Bijzondere kunstjes zijn verscheidene notenbalken, maatsoorten, +sleutels, toonaarden, zangteksten, krachtige invoer taal, cadensa, +balken, boogjes, triolen, partituren, en uittreksels voor individuele +partijen. Een fraaie set muziektekens is inbegrepen. diff --git a/Documentation/FLAPTEKST.yo b/Documentation/FLAPTEKST.yo new file mode 100644 index 0000000000..4513c045e3 --- /dev/null +++ b/Documentation/FLAPTEKST.yo @@ -0,0 +1,9 @@ +COMMENT(silly...DEFINEMACRO(pic)(1)(url(ARG1)(ARG1.gif))) +DEFINEMACRO(pic)(1)(verbinclude(ARG1.in)) + +nsect(LilyPond -- De Muziek Zetter van het GNU Project) + +includefile(FLAPTEKST.in) +nl() +pic(scherm) + diff --git a/Documentation/scherm.in b/Documentation/scherm.in new file mode 100644 index 0000000000..005b6451c3 --- /dev/null +++ b/Documentation/scherm.in @@ -0,0 +1,16 @@ +18:46:03 mub ~/lelie$ lilypond twinkle +GNU LilyPond 0.1.78/FlowerLib 1.1.44. +Ontleden...[/home/fred/usr/src/lilypond/init/init.ly[/home/fred/usr/src/lilypond/init/declarations.ly[/home/fred/usr/src/lilypond/init/dynamic.ly][/home/fred/usr/src/lilypond/init/nederlands.ly][/home/fred/usr/src/lilypond/init/script.ly][/home/fred/usr/src/lilypond/init/paper20.ly[/home/fred/usr/src/lilypond/init/table20.ly][/home/fred/usr/src/lilypond/init/table13.ly][/home/fred/usr/src/lilypond/init/table16.ly][/home/fred/usr/src/lilypond/init/params.ly[/home/fred/usr/src/lilypond/init/a4.ly][/home/fred/usr/src/lilypond/init/paper.ly][/home/fred/usr/src/lilypond/init/engraver.ly]]][/home/fred/usr/src/lilypond/init/midi.ly[/home/fred/usr/src/lilypond/init/performer.ly]][/home/fred/usr/src/lilypond/init/property.ly]][/home/fred/usr/src/lilypond/input/twinkle.ly]] +Vertolken van muziek...[8][16][24][25] +duur: 1.34 seconden +Voorbewerken van elementen... [/home/fred/usr/src/lilypond/mf/out/feta20.afm] +Berekenen van kolomposities... [3][6][9][12][15][18][21][24][25] +geschat: 231 regels (van gemiddeld 21.4 kolommen) +exact berekend: 66 regels (van gemiddeld 25.5 kolommen) +duur: 6.11 seconden +Nabewerken van elementen... +TeX uitvoer naar twinkle.tex... + +Vertolken van muziek... +duur: 0.22 seconden +MIDI uitvoer naar twinkle.midi... diff --git a/Documentation/schermo.in b/Documentation/schermo.in new file mode 100644 index 0000000000..b4fb407537 --- /dev/null +++ b/Documentation/schermo.in @@ -0,0 +1,16 @@ +18:37:15 mub ~/lelie$ lilypond twinkle +GNU LilyPond 0.1.78/FlowerLib 1.1.44. +Analizzare...[/home/fred/usr/src/lilypond/init/init.ly[/home/fred/usr/src/lilypond/init/declarations.ly[/home/fred/usr/src/lilypond/init/dynamic.ly][/home/fred/usr/src/lilypond/init/nederlands.ly][/home/fred/usr/src/lilypond/init/script.ly][/home/fred/usr/src/lilypond/init/paper20.ly[/home/fred/usr/src/lilypond/init/table20.ly][/home/fred/usr/src/lilypond/init/table13.ly][/home/fred/usr/src/lilypond/init/table16.ly][/home/fred/usr/src/lilypond/init/params.ly[/home/fred/usr/src/lilypond/init/a4.ly][/home/fred/usr/src/lilypond/init/paper.ly][/home/fred/usr/src/lilypond/init/engraver.ly]]][/home/fred/usr/src/lilypond/init/midi.ly[/home/fred/usr/src/lilypond/init/performer.ly]][/home/fred/usr/src/lilypond/init/property.ly]][/home/fred/usr/src/lilypond/input/twinkle.ly]] +Interpretare musica...[8][16][24][25] +durata: 1.36 secondi +Preprocessare elementi... [/home/fred/usr/src/lilypond/mf/out/feta20.afm] +Calcolare posizioni di colonne... [3][6][9][12][15][18][21][24][25] +approssimato: 231 linee (con una media di 21 colonne): +calcolato esattamente: 66 linee (con una media di 25 colonne) +durata: 6.14 secondi +Postprocessare elementi... +Prodotto di TeX verso twinkle.tex... + +Interpretare musica... +durata: 0.21 secondi +Prodotto di MIDI verso twinkle.midi... diff --git a/Documentation/tex/computer-notation.bib b/Documentation/tex/computer-notation.bib new file mode 100644 index 0000000000..ca314247e2 --- /dev/null +++ b/Documentation/tex/computer-notation.bib @@ -0,0 +1,599 @@ +% +% TITLE=The music notation with computer bibliography +% AUTHOR=Han-Wen Nienhuys +% + +@String{CitH = {Computing and the Humanities}} +@String{CMJ = {Computer Music Journal}} + +@TechReport{roush88, + note = {Rules on formatting music formulated for use in computers. Mainly distilled from [Ross] HWN}, + year = {1988}, + title = {Music Formatting Guidelines}, + author = {D. Roush}, + number = {OSU-CISRC-3/88-TR10}, + institution = {Department of Computer and Information Science, The Ohio State University}, +} + + + +@InProceedings{assayaag86, + author = {G. Assayaag and D. Timis}, + title = {A Toolbox for music notation}, + booktitle = {Proceedings of the 1986 International Computer Music Conference}, + year = 1986 +} + +@PhdThesis {byrd85, + year = {1985}, + title = {Music Notation by Computer}, + author = {Donald Byrd}, + school = {Indiana University}, +} + +@Article{byrd94, + author = {Donald Byrd}, + title = {Music Notation Software and Intelligence}, + journal = {Computer Music Journal}, +year = 1994, +pages = {17--20}, + volume = 18, + number = 1, + + note = {Byrd (author of Nightinggale) shows four problematic +fragments of notation, and rants about notation programs that try to +exhibit intelligent behaviour. HWN} + +} + + + +@Article{erickson75, + author = {R. F. Erickson}, + title = {The DARMS Project: A status report}, + journal = {Computing in the humanities}, + year = 1975, + volume = 9, + number = 6, + pages = {291--298} +} + +c +@Article{field-richards93, + author = {H.S. Field-Richards}, + title = {Cadenza: A Music Description Language}, + journal = CMJ, + year = 1993, + volume = 17, + number = 4, + + note = {A description through examples of a music entry language. +Apparently it has no formal semantics. There is also no +implementation of notation convertor. HWN} + +} + + + +@Article{bielawa93, + author = {Herbert Bielawa}, + title = {Review of Sibelius 7}, + journal = CMJ, + year = {1993?}, + + note = {A raving review/tutorial of Sibelius 7 for Acorn. (And did +they seriously program a RISC chip in ... assembler ?!) HWN} + + +} + +@Article{sloan93, + author = {Donald Sloan}, + title = {Aspects of Music Representation in HyTime/SMDL}, + journal = CMJ, + year = 1993, + volume = 17, + number = 4, + +note = {An introduction into HyTime and its score description variant +SMDL. With a short example that is quite lengthy in SMDL} +} + +@Article{wiggins93, + author = {Geraint Wiggins and Eduardo Miranda and Alaaaan Smaill and Mitch Harris}, + title = {A Framework for the evaluation of music representation systems}, + journal = CMJ, + year = 1993, + volume = 17, + number = 3, + + note = {A categorisation of music representation systems (languages, +OO systems etc) splitted into high level and low level expressiveness. +The discussion of Charm and parallel processing for music +representation is rather vague. HWN} + +} + + + +@Article{dannenberg93, + author = {Roger B. Dannenberg}, + title = {Music Representation: Issues, Techniques, and Systems}, + journal = CMJ, + year = 1993, + volume = 17, + number = 3, + + note = {The title says it all. This article does not make any +statements, it points to some problems and solutions with music +representation. HWN}, + +} + +@Article{rothstein93, + author = {Joseph Rothstein}, + title = {Review of Passport Designs' Encore Music Notation Software}, + journal = CMJ, + year = {?}, + +note = {A no-science-here review of Encore. HWN} + +} + + + +@Article{belkin94, + author = {Alan Belkin}, + title = {Macintosh Notatino Software: Present and Future}, + journal = CMJ, + year = 1994, + volume = 18, + number = 1, + + note = {Some music notation systems are analysed for ease of use, MIDI + handling. No rocket science here. The article ends with a plea for a + standard notation format. HWN}, + +} + +@Article {byrd74, + year = {1974}, + title = {A System for Music Printing by Computer}, + author = {Donald Byrd}, + journal = {Computers and the Humanities}, + volume ={8}, + pages ={161-72}, +} + + +@Book {smith73, + note = {If I remember correctly, this was concerned more with an input language than with the typography. SP}, + year = {1973}, + title = {Editing and Printing Music by Computer}, + author = {Leland Smith}, + totalentry = {Journal of Music Theory}, + volume={17}, + pages ={292-309}, +} + + + + + +@InProceedings{montel97, + author = {Dominique Montel}, + title = {La gravure de la musique, lisibilit\'e esth\'etique, respect de l'oevre}, + booktitle = {Musique \& Notations}, + year = 1997, + address={Lyon}, + editors ={Genevois \& Orlarey} +} + +@PhdThesis {gomber75, + year = {1975}, + title = {A Computer-Oriented System for Music Printing}, + author = {David A Gomberg}, + school = {Washington University}, +} + + +@Book {CASR, + note = {Annual editions since 1985, many containing surveys of music typesetting technology. SP}, + title = {Directory of Computer Assisted Research in Musicology}, + author = {Walter B Hewlett and Eleanor Selfridge-Field}, + totalentry = {Menlo Park, CA: Center for Computer Assisted Research in the Humanities}, +} + + +@Book {gomberg, + title = {A Computer-oriented System for Music Printing}, + author = {David A. Gomberg}, + journal = CitH, + volume={11}, + pages = {63-80}, +} + + + +@Article{blostein94, + author = {Dorothea Blostein and Lippold Haken}, + title = {The Lime Music Editor: A Diagram Editor Involving Complex + Translations}, + journal = {Software Practice and Experience}, + year = {1994}, + volume = {24}, + number = {3}, + month = {march}, + pages = {289--306}, + note = {A description of various conversions, decisions and issues relating to this interactive editor HWN}, +} + +@InProceedings{bouzaiene98:_une, + author = {Nabil Bouzaiene and Lo\"ic Le Gall and Emmanuel Saint-James}, + title = {Une biblioth\`eque pour la notation musicale baroque}, + booktitle = {EP '98}, + year = 1998, + series = {LNCS}, + + note = {Describes ATYS, an extension to Berlioz, that can mimick + handwritten baroque style beams} +} + + + +@MastersThesis{gall97:_creat, + author = {Lo\"ic Le Gall}, + title = {Cr\'eation d'une police adapt\'ee \`a la notation musicale baroque}, +school = {\'Ecole Estienne}, +year = 1997, +} + +@InProceedings{balaban88, + author = {M. Balaban}, + title = {A Music Workstation Based on Multiple Hierarchical Views of Music}, + booktitle = {Proceedings of the 1988 International Computer Music Conference}, + year = 1988, + address = {San Francisco}, + organization = {International Computer Music Association} +} + +@TechReport {gourlay87-spacing, + note = {Algorithm for generating spacing in one line of (polyphonic) music, tailored for use with MusiCopy. LilyPond uses a variant of it (as of pl 76) HWN}, + year = {1987}, + title = {Spacing a Line of Music,}, + author = {John S. Gourlay}, + number = {OSU-CISRC-10/87-TR35}, + institution ={Department of Computer and Information Science, The Ohio State University}, +} + + +@TechReport {parish87, + note = {A brief overview of MusiCopy HWN}, + year = {1987}, + title = {MusiCopy: An automated Music Formatting System}, + author = {Allen Parish and Wael A. Hegazy and John S. Gourlay and Dean K. Roush and F. Javier Sola}, + totalentry = {OSU-CISRC-10/87-TR29}, + institution ={Department of Computer and Information Science, The Ohio State University}, +} + + +@TechReport {gourlay87-formatting, + +note = {This paper discusses the development of algorithms for the +formatting of musical scores (from abstract). It also appeared at +PROTEXT III, Ireland 1986}, + + year = {1987}, + title = {Computer Formatting of Music}, + author = {John S. Gourlay and A. Parrish +and D. Roush and F. Sola and Y. Tien}, + number = {OSU-CISRC-2/87-TR3}, + institution ={Department of Computer and Information Science, +The Ohio State University}, +} + + +@TechReport {hegazy87, + note = {Describes the "parser" which converts MusiCopy MDL to MusiCopy Simultaneities & columns HWN}, + year = {1987}, + title = {On the Implementation of the MusiCopy Language Processor,}, + author = {Wael A. Hegazy}, + number = {OSU-CISRC-10/87-TR34}, + institution={Department of Computer and Information Science, The Ohio State University}, +} + + +@TechReport {hegazy87-breaking, + note = {This generalizes \TeX's breaking algorithm to music. It also appeared in Document Manipulation and Typography, J.C. van Vliet (ed) 1988. HWN}, + year = {1987}, + title = {Optimal line breaking in music}, + author = {Wael A. Hegazy and John S. Gourlay}, + number = {OSU-CISRC-8/87-TR33}, + institution={Department of Computer and Information Science, The Ohio State University,}, +} + + +@TechReport {roush87, + note = {User manual of MusiCopy. Includes an impressive example piece. HWN}, + year = {1987}, + title = {Using MusiCopy}, + author = {Dean K. Roush}, + number = {OSU-CISRC-18/87-TR31}, + institution={Department of Computer and Information Science, The Ohio State University}, +} + + +@TechReport {parrish87-simultaneities, + note = {Placement of balls, stems, dots which occur at the same moment ("Simultaneity") HWN}, + year = {1987}, + title = {Computer Formatting of Musical Simultaneities,}, + author = {A. Parrish and John S. Gourlay}, + institution={Department of Computer and Information Science, The Ohio State University}, + number = {OSU-CISRC-10/87-TR28}, +} + + +@TechReport {sola87, + note = {Overview of a procedure for generating slurs HWN}, + year = {1987}, + title = {Computer Design of Musical Slurs, Ties and Phrase Marks,}, + author = {F. Sola}, + institution={Department of Computer and Information Science, The Ohio State University}, + number = {OSU-CISRC-10/87-TR32}, +} + + +@TechReport {sola87-beams, + institution={Department of Computer and Information Science, The Ohio State University}, + note = {Calculating beam slopes HWN}, + year = {1987}, + title = {Design of Musical Beams,}, + author = {F. Sola and D. Roush}, + number = {OSU-CISRC-10/87-TR30}, +} + + +@Article {gourlay86, + note = {This paper describes the MusiCopy musicsetting system and an input language to go with it. HWN}, + year = {1986}, + title = {A language for music printing}, + author = {John. S. Gourlay}, + journal = {Communications of the ACM}, + volume= {29}, + number ={5}, + pages = {388--401}, +} + +@Article {haken93, + note = {A description of Lime internals (which resemble older (before 0.0.68pre) LilyPond data structures somewhat) HWN}, + year = {1993}, + title = {The Tilia Music Representation: Extensibility, Abstraction, and Notation Contexts for the Lime Music Editor}, + author = {Lippold Haken and Dorothea Blostein}, + journal = {Computer Music Journal}, + volume= {17}, + number={3}, + pages = {43--58}, +} + +@InProceedings{haken95, + year = {1995}, + title = {A New Algorithm for Horizontal Spacing of Printed Music}, + author = {Lippold Haken and Dorothea Blostein}, + booktitle = {International Computer Music Conference}, + address={Banff}, + month={Sept}, + pages = {118-119}, + note = {This describes an algorithm which uses springs between adjacent columns. This algorithm is a "subclass" of the LilyPond algorithm. HWN}, +} + +@Article {blostein91, + note = {This paper provides a shallow overview of the algorithm used in LIME for spacing individual lines. HWN}, + year = {1991}, + title = {Justification of Printed Music}, + author = {Dorothea Blostein and Lippold Haken}, + journal = {Communications of the ACM}, + volume= {J34}, + number= {3}, + month= {March}, + pages = {88-99}, +} + + +@Article {rader96, + note = {Describes a system called MusicEase, and explains that it uses "constraints" (which go unexplained) to automatically position various elements. HWN}, + year = {1996}, + title = {Creating Printed Music Automatically}, + author = {Gary M. Rader}, + journal = {Computer}, + volume={29}, + number={6}, + month={June}, + pages = {61--69}, +} + + + + +@PhdThesis {page88, + note = {Don't ask Stephen for a copy. Write to the Bodleian Library, Oxford, or to the British Library, instead. SP}, + year = {1988}, + title = {Computer Tools for Music Information Retrieval}, + author = {Stephen Dowland Page}, + school ={Dissertation University of Oxford}, +} + +@MastersThesis{roelofs91, + note = {This dutch thesis describes a simplistic (monophonic) typesetting system, and focuses on the breaking algorithm, which is taken from Hegazy & Gourlay HWN}, + year = {1991}, + title = {Een Geautomatiseerd Systeem voor het Afdrukken van Muziek}, + author = {Ren\'e Roelofs}, + school={Erasmus Universiteit Rotterdam}, + number={45327}, + translation = {``An automated system for printing music'' Master's Thesis Managerial Computer Science.}, +} + + +@Article {filgueiras93, + year = {1993}, + title = {Representation and manipulation of music documents in SceX}, + author = {Miguel Filgueiras and Jos\'e Paulo Leal}, + journal= {Electronic Publishing}, + volume={6}, + number={4}, pages = {507--518}, + +} + + +@Article {foxley87, + note = {A paper on a TROFF preprocessor to typeset music. The output shown is not very sophisticated, and contains some typographical atrocities HWN}, + year = {1987}, + title = {Music --- A language for typesetting music scores}, + author = {Eric Foxley}, + journal = {Software --- Practice and Experience}, + volume = {17}, + number = {8}, + pages = {485-502}, +} + + +@Book {filgueiras96, + year = {1996}, + title = {Implementing a Symbolic Music Processing System}, + author = {Miguel Filgueiras}, + totalentry = {LIACC, Universidade do Porto, 1996; submitted}, +} + +@Book {filgueiras?, + title = {Some Music Typesetting Algorithms}, + author = {Miguel Filgueiras}, + totalentry = {Miguel Filgueiras. ``Some Music Typesetting Algorithms''. LIACC, Universidade do Porto, forthcoming}, +} + + +@Article {colorado-web, + author ={Alyssa Lamb}, + note = {Webpages about engraving (designed with finale users in mind) (sic) HWN}, + institution = {The University of Colorado}, + title ={The University of Colorado Music Engraving page.}, + HTML={http://obenamots.cc.colorado.edu/Musicpress/engraving.html}, + year={1996} +} + + + + +@Book {Langston90, + note = {This paper deals with some command-line tools for music editing and playback. It doesn't mention notation issues, but does come with the grand idea (not) of using music to monitor complex systems. Imagine your nuclear plant supervisor to use AC/DC for checking the reactor HWN}, + year = {1990}, + title = {Unix music tools at Bellcore}, + author = {Peter S. Langston}, + journal={Software --- Practice and Experience}, + volume={20}, + number={S1}, + pages={47--61}, +} + + + +@Article {tablature-web, + note = {FAQ (with answers) about TAB, the ASCII variant of Tablature. HWN}, + title = {how to read and write tab: a guide to tab notation}, + author = {Howard Wright}, + email={Howard.Wright@ed.ac.uk}, + HTML={http://wabakimi.carleton.ca/~phacket2/guitar/tabfaq.html}, +} + + +@Article {niff-web, + note = {Specs for NIFF, a reasonably comprehensive but binary (yuk) format for notation HWN}, + + year = {1995}, + title = {NIFF6a Notation Interchange File Format}, + author = {Cindy Grande}, + publisher={Grande Software Inc.}, + HTML= {http://www.jtauber.com/music/encoding/niff/}, + ftp = {ftp://blackbox.cartah.washington.edu} +} + + +@Article {smdl-web, + author={unknown}, + title = {SMDL, Standard Musical Description Language}, + pdf= {ftp://ftp.ornl.gov/pub/sgml/wg8/smdl/10743.pdf}, + note={ISO/IEC DIS 10743 + +SGML instance for describing music. Very comprehensive in music +definition, but no support for notation / performance whatsoever (They +basically say: "You can embed a NIFF or MIDI file") HWN} + +}, +} + +@TechReport{Ornstein83, + author={Ornstein, Severo M. and John Turner Maxwell III}, + title={Mockingbird: A Composer's Amanuensis}, + institution={Xerox Palo Alto Research Center}, + address={3333 Coyote Hill Road, Palo Alto, CA, 94304}, + number={CSL-83-2}, + month={January}, + year={1983} +} + +@PhdThesis{mueller90:_inter_bearb_musik, + author = {Giovanni M\"uller}, + title = {Interaktive Bearbeitung konventioneller Musiknotation}, + school = {Eidgen\"ossischen Technischen Hochschule Z\"urich}, + year = 1990, + +note = {This is about engraver-quality typesetting with computers. It +accepts the axiom that notation is too difficult to generate +automatically. The result is that a notation program should be a +WYSIWYG editor that allows one to tweak everything. + + + +The implementation therefore is quite "weak". The introductory +chapters on engraving and notation are well structured and clear, +though.} +} + +@TechReport{grover89-symbols, + author = {John Gr\/over}, + title = {A computer-oriented description of Music Notation. Part I. The Symbol Inventory}, + institution = {Department of informatics, University of Oslo}, + year = 1989, + number = 133, + +note = {The goal of this series of reports is a full description of +music formatting. As these largely depend on parameters of fonts, it +starts with a verbose description of music symbols. + + The subject is treated backwards: from general rules of typesetting +the author tries to extract dimensions for characters, whereas the +rules of typesetting (in a particular font) follow from the dimensions +of the symbols. His symbols do not match (the stringent) constraints +formulated by eg. \cite{wanske}} } + +@TechReport{grover89-twovoices, + author = {John Gr\/over}, + title = {A computer-oriented description of Music Notation. Part II: Two Voice Sharing a Staff, Leger Line Rules, Dot Positioning}, + + institution = {Department of informatics, University of Oslo}, + year = 1989, + number = 134, + + note = {A lot rules for what is in the title are formulated. The +descriptions are long and verbose. The verbosity shows that +formulating specific rules is not the proper way to approach the +problem. In stead, the formulated rules should follow from more +general rules, similar to\cite{parrish87-simultaneities}}, +} + +@TechReport{grover89-accidentals, + author = {John Gr\/over}, + title = {A computer-oriented description of Music Notation. Part III: Accidental Positioning}, + institution = {Department of informatics, University of Oslo}, + year = 1989, + number = 135, + note = {Placement of accidentals crystallised in an enormous set of rules. Same remarks as for \cite{grover89-twovoices} applies} +} diff --git a/Documentation/tex/computer.data b/Documentation/tex/computer.data new file mode 100644 index 0000000000..373209390c --- /dev/null +++ b/Documentation/tex/computer.data @@ -0,0 +1,88 @@ +assemble::::samenstellen:: +assembler::::samensteller:: +assert:::::: +binary::::tweetallig, binair:: +bit::::hapje:: +boot:::::: +bug::::luis:: +byte::::hapje:: +c(entral) p(rocessing) u(nit)::::c(entrale) v(erwerkings) e(enheid):: +character::::teken:carattere: +compile::::vertalen:compilare: +compiler::::vertaler:compilatore: +computer:ordinateur:rechner::rekentuig:comptatore: +debug::::ontluizen:: +debugger::::ontluizer:: +default::::verval:: +device::::apparaat:: +directory::inhaltsverzeichnis(urg)::index:: +drag and drop::::sleur en pleur(silly):: +(disk) drive::::(schijf) speler:: +edit::::redigeren, bewerken (hmm):: +editor::::redigeur, bewerker (hmm):: +exception::::uitzondering:eccezione: +f(requently) a(sked) q(uestions)::::v(eel) v(oorkomende) v(ragen):: +fatal::::noodlottig:fatale: +file::datei::bestand:documento: +float::::zweef:: +floating point::::zwevende komma:: +floppy disk::::schijfje:dischetto: +free software::::vrij bedenksel:: +hard disk::::harde schijf:: +hardware::::ijzer:: +hexadecimal::::zestientallig:: +home page::::volkstuintje(silly), thuispagina(urg):: +howto::::hoedan:: +hyper link::::super verbinding:: +identifier:::::: +inode:::::: +input::::invoer:: +int::::heel:: +integer::::geheel getal:: +interface::schnittstelle::tussensmoel(silly):: +interpret::::vertolken:interpretare: +interpreter::::vertolker:: +keyboard::tastatur::toetsenbord:: +lilypond:étang de lis:lilyteich:lily pond:lelievijver:stagno del giglio: +(hard) link::::(harde) verbinding:: +linux::::loes(silly):: +log in::::aanloggen:: +maintainer::::onderhouder:: +memory::::geheugen:: +menu:::::: +mirror::::spiegel:: +monitor::::beeldscherm:: +mouse::::muis:: +octal::::achttallig:: +open source software::::open-baar bedenksel:: +output::::uitvoer:: +(disk) partition::::(schijf) deel:: +patch::::lap:: +pixel::::puntje:: +pointer::::wijzer:: +printer::drucker::drukker:: +program::::programma:: +public domain::::publiek domein(urg):: +real (number)::::reeel getal:: +real time::::waartijds:: +reset:::::: +root (directory):::::: +root window:::::: +run::::draaien:girare: +script::::schrift:: +sector::::segment:: +shell::::schaal:: +shortcut::::afstekertje:: +signed (int):::::: +software::::bedenksel, programmatuur(spec), zachtwaar(silly):: +string::::snoer:corda: +swap(file)::::wisselbestand:: +symbolic link::::verwijz(ende verbind)ing:: +t(ape)ar(chive)::::b(and)ar(chief):: +tarball::::barbaal:: +template::::leest:: +terminal::::eindstation:: +track::::spoor:: +unsigned (int):::::: +void (pointer)::::leeg (wijzer):: +workstation::::werkstation:: diff --git a/lib/include/thank-you-cygnus.hh b/lib/include/thank-you-cygnus.hh new file mode 100644 index 0000000000..95d60bfc33 --- /dev/null +++ b/lib/include/thank-you-cygnus.hh @@ -0,0 +1,15 @@ +// +// windhoos-suck-suck-suck-thank-you-cygnus.hh +// +// mmap () should work now (cygnus beta 18), but let's keep it here +// for people using old cygnus releases +#if 0 //def _WINDOWS32 +#ifndef WINDHOOS_SUCK_SUCK_SUCK_HH +#define WINDHOOS_SUCK_SUCK_SUCK_HH + +caddr_t mmap (caddr_t addr, size_t len, int prot, int flags, int fd, off_t offset); + +int munmap (caddr_t addr, size_t len); + +#endif // WINDHOOS_SUCK_SUCK_SUCK_HH +#endif // _WINDOWS32 // diff --git a/lib/thank-you-cygnus.cc b/lib/thank-you-cygnus.cc new file mode 100644 index 0000000000..22cbb9d834 --- /dev/null +++ b/lib/thank-you-cygnus.cc @@ -0,0 +1,105 @@ +// +// windhoos.cc +// +// mmap () should work now (cygnus beta 18), but let's keep it here +// for people using old cygnus releases +#if 0 // def _WINDOWS32 + +#include +#include +#include +#include "thank-you-cygnus.hh" + +/* +HANDLE CreateFileMapping ( + HANDLE hFile, // handle to file to map + LPSECURITY_ATTRIBUTES lpFileMappingAttributes, // optional security attributes + DWORD flProtect, // protection for mapping object + DWORD dwMaximumSizeHigh, // high-order 32 bits of object size + DWORD dwMaximumSizeLow, // low-order 32 bits of object size + LPCTSTR lpName // name of file-mapping object +); + + +LPVOID MapViewOfFile ( + HANDLE hFileMappingObject, // file-mapping object to map into address space + DWORD dwDesiredAccess, // access mode + DWORD dwFileOffsetHigh, // high-order 32 bits of file offset + DWORD dwFileOffsetLow, // low-order 32 bits of file offset + DWORD dwNumberOfBytesToMap // number of bytes to map +); + + +io.h: +long _get_osfhandle (int filehandle); +*/ + +// cygnus's gnu-win32-b17.1 does not have _get_osfhandle +// however, after some hacking, it turns out that: + +static const int OSF_OFFSET_i = 72; +static const int OSF_BASE_i = -3; +static const int OSF_FACTOR_i = 8; +// let-s hope bill doesn-t change his mind any time soon :-) + +// so that, while waiting for cygnus's mmap, we can write: + +// #define HAVE_GET_OSFHANDLE // no we still cannot; works only with cl.exe +long +_get_osfhandle (int filedes_i) +{ + return (long)(OSF_OFFSET_i + (filedes_i + OSF_BASE_i) * OSF_FACTOR_i); +} + +#ifdef HAVE_GET_OSFHANDLE + +#include + +caddr_t +mmap (caddr_t addr, size_t len, int prot, int flags, int fd, off_t offset) +{ + (void)flags; + (void)prot; + (void)addr; + HANDLE osf = (HANDLE)_get_osfhandle (fd); + HANDLE file_handle = CreateFileMapping (osf, (void*)0, PAGE_READONLY, + 0, len, 0); + return (caddr_t)MapViewOfFile (file_handle, FILE_MAP_READ, 0, offset, len); +} + + +int +munmap (caddr_t addr, size_t len) +{ + (void)len; + return UnmapViewOfFile (addr); +} + +#else // ! HAVE_GET_OSFHANDLE // + +caddr_t +mmap (caddr_t addr, size_t len, int prot, int flags, int fd, off_t offset) +{ + (void)flags; + (void)prot; + (void)addr; + (void)offset; + char* ch_p = new char[ len ]; + if (ch_p) + read (fd, (void*)ch_p, len); + return ch_p; +} + + +int +munmap (caddr_t addr, size_t len) +{ + (void)len; + delete (char*)addr; + return 0; +} + +#endif // !HAVE_GET_OSFHANDLE // + + +#endif // _WINDOWS32 // diff --git a/lily/dimen.cc b/lily/dimen.cc index 5e85f4992d..d309241e23 100644 --- a/lily/dimen.cc +++ b/lily/dimen.cc @@ -1,5 +1,5 @@ #include -#include "dimen.hh" +#include "dimension.hh" #include "debug.hh" #include "string.hh" @@ -28,13 +28,19 @@ convert_dimen (Real quant, String unit) return quant*CM_TO_PT/10; if (unit == "in") return quant * INCH_TO_PT; - error (_("unknown length unit: `") + unit+"'"); + error (_f ("unknown length unit: `%s\'", unit)); } String print_dimen (Real r) { - String s (r, "%.3f"); + String s = to_str (r, "%.3f"); + if (s.index_i ("NaN") != -1) + { + warning (_ ("NaN")); + s = "0.0"; + } s += "pt "; return s; } + diff --git a/lily/include/dimension.hh b/lily/include/dimension.hh new file mode 100644 index 0000000000..ac8267f187 --- /dev/null +++ b/lily/include/dimension.hh @@ -0,0 +1,21 @@ +#ifndef DIMEN_HH +#define DIMEN_HH + +#include "real.hh" +#include "string.hh" + +const Real INCH_TO_PT=72.270; +const Real CM_TO_PT=INCH_TO_PT/2.54; +const Real MM_TO_PT=CM_TO_PT/10; +const Real PT_TO_PT =1.0; + +#define PT *PT_TO_PT +#define MM *MM_TO_PT +#define CM *CM_TO_PT +#define INCH *INCH_TO_PT + +Real parse_dimen (String); +String print_dimen (Real); +Real convert_dimen (Real, String); +#endif + diff --git a/lily/rod.cc b/lily/rod.cc index 6bbcbd6dcc..1b2ae4f824 100644 --- a/lily/rod.cc +++ b/lily/rod.cc @@ -3,14 +3,14 @@ source file of the GNU LilyPond music typesetter - (c) 1998 Han-Wen Nienhuys + (c) 1998 Han-Wen Nienhuys */ #include "rod.hh" #include "p-col.hh" #include "debug.hh" #include "single-malt-grouping-item.hh" -#include "dimen.hh" +#include "dimension.hh" Rod::Rod (Single_malt_grouping_item *l, Single_malt_grouping_item *r)