@c -*- coding: utf-8; mode: texinfo; documentlanguage: ja -*- @ignore Translation of GIT committish: 499a511d4166feaada31114e097f86b5e0c56421 When revising a translation, copy the HEAD committish of the version that you are working on. See TRANSLATION for details. @end ignore @c \version "2.13.4" @c Translators: Yoshiki Sawada @c Translation status: post-GDP @node 導入部 @chapter 導入部 @translationof Introduction この章では読者に LilyPond とこのドキュメントについての紹介を行います。 @menu * バックグラウンド:: * このドキュメントについて:: @end menu @node バックグラウンド @section バックグラウンド @translationof Background この節は LilyPond の最終目的とアーキテクチャについてカバーします。 @menu * 譜刻:: * 自動譜刻:: * 譜刻するシンボルは何か?:: * 音楽表記:: * 例用例:: @end menu @node 譜刻 @unnumberedsubsec 譜刻 @translationof Engraving @cindex engraving @cindex typography, music @cindex music typography @cindex plate engraving @cindex music engraving 楽譜印刷の技術は@emph{(プレート) 譜刻} (原文: engraving、版画などの印刷のこと@c ) と呼ばれています。この用語は伝統的な楽譜印刷のプロセスに由来します。ほんの@c 数十年前まで、楽譜は音楽記号を亜鉛やしろめ (錫と鉛の合金) の版に反転した@c イメージで彫り込んだり、刻印することによって作られていました。版にはインクが@c 塗られ、彫り込んだり刻印してくぼんだ部分にはインクが溜まります。版のイメージ@c はその版に紙が押し付けられることによって形になります。刻印と彫刻は完全に手作@c 業で行われていました。校正は可能だとしても厄介でした。なぜなら一から刻印と彫@c 刻のやり直しだったからです。譜刻は高度に専門的な技術でした。職人はマスター @c エングラーバ (譜刻を行う人) の称号を得るまで 5 年の修行を修めなければなら@c ず、本当に技術を習得するまでにはさらにもう 5 年の経験が必要だったのです。 今日では、コンピュータによってまったく新しい楽譜が出版されています。これには@c 明らかな利点があります。印刷は安く済み、編集したものを email で配ることが可@c 能です。不幸なことに、コンピュータが広く使われるようになって楽譜のグラフィカ@c ルな品質は低下しています。コンピュータによって出版された楽譜は味気無く、機械@c 的な見た目をしているため、その楽譜で演奏することに喜びを感じられません。 @c introduce illustrating aspects of engraving, font... 以下の図は伝統的な譜刻とコンピュータ出版の違いを描いたものであり、3 番目の図は LilyPond がどれくらい伝統的な見た目を模倣しているのかを示しています。左端の@c スキャンした図はコンピュータ出版の典型的な決定を示しています。縦棒は細く、フ@c ラット記号の太さは細線と一致していて、曲線はまっすぐなレイアウトになっていま@c す。対照的に、ベーレンライター (Barenreiter: ドイツの出版社) のフラットは太@c く、曲線は官能的です。我々のフラットは 2 つのもののうち後者を元にデザインさ@c れています。丸みを帯びていて、太さは縦棒の太さと調和していて、コンピュータに@c よるものよりも線が太くなっています。 @multitable @columnfractions .125 .25 .25 .25 .125 @item @tab @ifnotinfo @iftex @image{henle-flat-gray,,4cm} @end iftex @ifnottex @image{henle-flat-gray,,,png} @end ifnottex @tab @iftex @image{baer-flat-gray,,4cm} @end iftex @ifnottex @image{baer-flat-gray,,,png} @end ifnottex @tab @iftex @image{lily-flat-bw,,4cm} @end iftex @ifnottex @image{lily-flat-bw,,,png} @end ifnottex @end ifnotinfo @ifinfo @image{lilypond/henle-flat-bw,,,png} @image{lilypond/baer-flat-bw,,,png} @image{lilypond/lily-flat-bw,,,png} @end ifinfo @item @tab Henle (2000) @tab Bärenreiter (1950) @tab LilyPond Feta font (2003) @end multitable @cindex musical symbols @cindex font @cindex blackness @cindex balance @c introduce illustrating aspects of engraving, spacing... スペースの点では、スペースの配分は音符と音符の間の音の間隔を反映します。しか@c しながら、現代楽譜の多くは数学的な正確さを持った間隔に固執しています。このこ@c とはおもしろくない結果を生み出します。次の例では、2 度楽譜をプリントしていま@c す: 1 度目は正確に数学的なスペースを用いて、2 度目はそれに校正を加えていま@c す。違いを見分けられますか? @cindex optical spacing @c file spacing-optical. @c need to include it here, because we want two images. @lilypond \paper { ragged-right = ##t indent = #0.0 } music = { c'4 e''4 e'4 b'4 | \stemDown b'8[ e'' a' e''] \stemNeutral e'8[ e'8 e'8 e'8] } \score { \music \layout { \context { \Staff \override NoteSpacing #'stem-spacing-correction = #0.6 } } } @end lilypond @lilypond \paper { ragged-right = ##t indent = #0.0 } music = { c'4 e''4 e'4 b'4 | \stemDown b'8[ e'' a' e''] \stemNeutral e'8[ e'8 e'8 e'8] } \score { \music \layout { \context { \Staff \override NoteSpacing #'stem-spacing-correction = #0.0 \override NoteSpacing #'same-direction-correction = #0.0 \override StaffSpacing #'stem-spacing-correction = #0.0 } } } @end lilypond @cindex regular rhythms @cindex regular spacing @cindex spacing, regular 各小節には一定のリズムで演奏される音符だけがあります。スペースもそれを反映していま@c す。不幸なことに、我々の目は我々を少し惑わせます。音符の「玉」 (ノート ヘッド) の間@c 隔だけでなく、連続した棒 (ステム、音符から突き出る棒) の間隔も考慮します。結果とし@c て、アップ ステム/@/ダウン ステム (玉の上に突き出た棒/@/玉の下に突き出た棒) の組み@c 合わせは離すべきであり、ダウン ステム/アップステムの組み合わせは近づけるべきです、す@c べては音符の垂直方向の位置の組み合わせに次第です。上の 2 小節は音符のダウン ステム/@/アップ ステムの組み合わせを近づけるよう校正を加えたものであり、下の 2 小節@c はこの校正を加えていないものです。 通常、奏者は楽譜の見え方を勉強するよりも演奏をするほうに夢中ですので、印刷上@c の詳細にこだわることは形式尊重のように思えるかもしれません。しかしそうではあ@c りません。単調なリズムがずっと続くような場合、スペースの校正を行うことで各行@c のレイアウトに微妙な変化が加わり、それぞれが異なる視覚的特徴を持つようになり@c ます。この特徴が無ければすべての行は同じに見え、迷路のようになってしまいま@c す。奏者がちょっと目を逸らしたり、集中力を欠くと、それまで見ていた行はページ@c の中に埋もれてしまいます。 同様に、太い譜線 (音の高さを表す線。五線譜では 5 本) に描かれた太い記号は見@c た目が強く、楽譜から奏者が離れている場合 -- 例えば、楽譜が譜面台にある場合 -- に良く目立ちます。空白を注意深く配置することで、楽譜は記号が乱雑になることな@c く締まります。結果としてページをめくる回数は最小となり、これは大きな利点にな@c ります。 これは印刷において共通して言えることですが、レイアウトはこざっぱりとしている@c べきです。これは印刷自体のためであるだけでなく、特にその印刷物を読んでいる読@c み手の助けにもなるからです。楽譜のような演奏用の道具では、このことは 2 重に@c 重要性を持ちます: 奏者の注意力には限界があり、奏者が楽譜を読むことに払う注意@c 力が少なくて済めば済むほど、その奏者は演奏に集中することができます。言い換え@c ると、良い印刷は良い演奏につながるのです。 以上で挙げたことは、楽譜の印刷は微妙で複雑な技術であり、楽譜を印刷するには非@c 常な熟練 -- これは通常、奏者が持っているものではありません -- が必要であると@c いうことを示しています。LilyPond は、手作業で譜刻された楽譜のすばらしさをコ@c ンピュータ世代に提供しよう、すばらしい楽譜を普通の音楽家にも利用可能にしよう@c という我々の努力なのです。我々は、良く見てみたくなり、演奏したくなるような古@c い楽譜のクオリティに匹敵する楽譜を提供するために、アルゴリズム、フォント デ@c ザイン、プログラム設定を調整してきました。 @node 自動譜刻 @unnumberedsubsec 自動譜刻 @translationof Automated engraving @cindex engraving, automated @cindex automated engraving 我々はどのように譜刻を実現していくのでしょうか?職人が本当のマスターになるのに 10 年以上かかるのなら、単なるハッカーである我々がどうやったら職人の仕事を越@c えるプログラムを書けるのでしょうか? その答えは、我々には「できない」です。譜刻は人間的な状況判断に頼っているた@c め、判断を行う人間を完全にコンピュータに置き換えることはできません。しかしな@c がら、退屈な作業の多くを自動化することはできます。もし LilyPond が一般的な@c ケースの大半に対処できるなら、それは既存のソフトウェアよりも大きく前進するこ@c とになります。残りのケースは手作業で調整することができます。年数が経つにつれ@c て、このソフトウェアはより多くのことを自動的に行えるよう洗練されていき、手作@c 業による手直しはどんどん必要なくなっていくことでしょう。 我々が LilyPond の開発を始めたとき、我々は LilyPond プログラム全体を C++ プ@c ログラミング言語で書いていました。プログラムの機能は開発者によってかっちりと@c 決められていました。これはいくつかの理由で不満足なものであることがわかりました: @itemize @item LilyPond が失敗を犯したとき、ユーザはフォーマット判断 (どのような@c フォーマットにするかの判断) を上書きする必要があります。そのため、ユーザは@c フォーマット エンジンにアクセスしなければなりません。そのため、コンパイル時@c に我々 (開発者) によって規則と設定を固定することは無理があり、実行時 (LilyPond によって楽譜を作り出すとき) にユーザが規則と設定にアクセスできなければなりま@c せん。 @item 譜刻は視覚的判断の問題であり、そのために好みがあります。我々には知識が@c ありますが、ユーザは我々の個人的な判断に異を唱える可能性もあります。そのた@c め、譜刻様式の定義もまたユーザがアクセスできるものでなければなりません。 @item 最後に、我々は継続的にフォーマット アルゴリズムを改良させていくので、@c 我々には規則に対する自由度の高いアプローチが必要です。C++ 言語は音楽表記の作@c 業とはうまくマッチしない規則分類法を押し付けてきます。 @end itemize @cindex Scheme programming language これらの問題に対して、Scheme プログラミング言語のインタプリタを統合し、@c LilyPond の各部分を Scheme で書き直すという処置がとられてきました。現在の@c フォーマット アーキテクチャはグラフィカル オブジェクトという概念で構築されて@c いて、Scheme 変数と関数によって記述されています。このアーキテクチャは、@c フォーマット規則、譜刻スタイル、個々のフォーマットに関する判断を包含していま@c す。ユーザはこれらの制御の大半に直接アクセスする術を持ちます。 Scheme 変数はレイアウトに関する判断を制御します。例えば、多くのグラフィカル オブジェクトは上か下か (あるいは左か右か) の選択を決定する方向 (に関する) 変@c 数を持ちます。ここで、アクセントとアルペジオを持つ 2 つの和音を見てみます。@c 最初の和音では、すべてのグラフィカル オブジェクトは下向き (あるいは左向き) の方向を持っています。2 番目の和音では、すべてが上向き (あるいは右向き) の方@c 向を持っています。 @lilypond[quote,ragged-right] \new Score \with { \override SpacingSpanner #'spacing-increment = #3 \override TimeSignature #'transparent = ##t } \relative c' { \stemDown 4_>-\arpeggio \override Arpeggio #'direction = #RIGHT \stemUp 4^>-\arpeggio } @end lilypond @cindex score formatting @cindex formatting a score @cindex formatting rules @noindent 楽譜を形作るプロセスはグラフィカルオブジェクトの変数を読み込んだり、書き込ん@c だりすることからなります。いくつかの変数はプリセット値を持ちます。例えば、多@c くの線の太さ -- 印刷スタイルの特性 -- はプリセット値を持つ変数です。あなたは@c 自由にこの値を変更することができ、それによってあなたの楽譜は異なる印象を持つ@c ことになります。 @lilypond[quote,ragged-right] fragment = { \clef bass f8 as8 c'4-~ c'16 as g f e16 g bes c' des'4 } << \new Staff \fragment \new Staff \with { \override Beam #'beam-thickness = #0.3 \override Stem #'thickness = #0.5 \override Bar #'thickness = #3.6 \override Tie #'thickness = #2.2 \override StaffSymbol #'thickness = #3.0 \override Tie #'extra-offset = #'(0 . 0.3) } \fragment >> @end lilypond さらにフォーマット規則もプリセット変数です: 各オブジェクトはプロシージャを保@c 持している変数を持ちます。これらのプロシージャが実際のフォーマットを実行し、@c 異なるプロシージャを使用することによってオブジェクトの見た目を変えることがで@c きます。以下の例では、音符の玉 (ノート ヘッド) シンボルを印刷するのにどの音@c 符の玉オブジェクトを使用するかを決定する規則を楽譜の途中で変更しています。 @lilypond[quote,ragged-right] #(set-global-staff-size 30) #(define (mc-squared grob orig current) (let* ((interfaces (ly:grob-interfaces grob)) (pos (ly:grob-property grob 'staff-position))) (if (memq 'note-head-interface interfaces) (begin (ly:grob-set-property! grob 'stencil (grob-interpret-markup grob (make-lower-markup 0.5 (case pos ((-5) "m") ((-3) "c ") ((-2) (make-smaller-markup (make-bold-markup "2"))) (else "bla"))))))))) \new Voice \relative c' { \stemUp \set autoBeaming = ##f \time 2/4 4 \once \override NoteHead #'stencil = #note-head::brew-ez-stencil \once \override NoteHead #'font-size = #-7 \once \override NoteHead #'font-family = #'sans \once \override NoteHead #'font-series = #'bold 4 \once \override NoteHead #'style = #'cross 4 \applyOutput #'Voice #mc-squared 4 << { d8[ es-( fis^^ g] fis2-) } \repeat unfold 5 { \applyOutput #'Voice #mc-squared s8 } >> } @end lilypond @node 譜刻するシンボルは何か? @unnumberedsubsec 譜刻するシンボルは何か? @translationof What symbols to engrave? @cindex engraving @cindex typography @cindex engraver @cindex plug-in フォーマット プロセスはシンボルを置く場所を決定します。しかしながら、@c @emph{どの}シンボルを譜刻すべきかを決定する -- 言い換えると、使用する表記を@c 決定する -- と、シンボルを置く場所も決まります。 一般の音楽表記は音楽を記録するシステムであり、これは過去 1000 年以上にもわ@c たって進化してきました。現在の一般的な形式はルネッサンス前期にまでさかのぼり@c ます。基本的な形式 (すなわち、音符の玉が 5 本線の譜表上にあるというもの) は@c 変更されていませんが、細かな点は現代の表記の改革を表現するためにいまだに発展@c が続けられています。したがって、一般的な音楽表記はおよそ500年間の音楽を扱い@c ます。応用範囲は単旋律から大規模なオーケストラのための途方もない対位法にまで@c 及びます。 どうやったら我々はそのような多頭の獣を統率し、制限のあるコンピュータ プログ@c ラムに押し込めることができるでしょうか?我々の解決策は表記の問題 (譜刻とは対@c 照的にある、すなわち、活字学) を消化の良いプログラム可能な小さな塊に分解して@c いくことです: それぞれのシンボルのタイプは個々のモジュール -- いわゆるプラグ@c イン -- によって処理されます。各プラグインは完全にモジュール化されて独立して@c いて、それによりそれぞれを別個に開発、改良することができます。そのようなプラ@c グインは音楽的概念をグラフィック シンボルに変換する職人に例えて @code{engraver} (エングラーバ) と呼びます。 以下の例では、我々が音符の玉のためのプラグイン @code{Note_heads_engraver} か@c ら始めていく様子を見ていきます。 @lilypond[quote,ragged-right] \include "engraver-example.ily" \score { \topVoice \layout { \context { \Voice \remove "Stem_engraver" \remove "Phrasing_slur_engraver" \remove "Slur_engraver" \remove "Script_engraver" \remove "Beam_engraver" \remove "Auto_beam_engraver" } \context { \Staff \remove "Accidental_engraver" \remove "Key_engraver" \remove "Clef_engraver" \remove "Bar_engraver" \remove "Time_signature_engraver" \remove "Staff_symbol_engraver" \consists "Pitch_squash_engraver" } } } @end lilypond @noindent それから、@code{Staff_symbol_engraver} が譜表を加え @lilypond[quote,ragged-right] \include "engraver-example.ily" \score { \topVoice \layout { \context { \Voice \remove "Stem_engraver" \remove "Phrasing_slur_engraver" \remove "Slur_engraver" \remove "Script_engraver" \remove "Beam_engraver" \remove "Auto_beam_engraver" } \context { \Staff \remove "Accidental_engraver" \remove "Key_engraver" \remove "Clef_engraver" \remove "Bar_engraver" \consists "Pitch_squash_engraver" \remove "Time_signature_engraver" } } } @end lilypond @noindent @code{Clef_engraver} が譜表の参照位置を定義し @lilypond[quote,ragged-right] \include "engraver-example.ily" \score { \topVoice \layout { \context { \Voice \remove "Stem_engraver" \remove "Phrasing_slur_engraver" \remove "Slur_engraver" \remove "Script_engraver" \remove "Beam_engraver" \remove "Auto_beam_engraver" } \context { \Staff \remove "Accidental_engraver" \remove "Key_engraver" \remove "Bar_engraver" \remove "Time_signature_engraver" } } } @end lilypond @noindent @code{Stem_engraver} が棒 (ステム) を付け加えます。 @lilypond[quote,ragged-right] \include "engraver-example.ily" \score { \topVoice \layout { \context { \Voice \remove "Phrasing_slur_engraver" \remove "Slur_engraver" \remove "Script_engraver" \remove "Beam_engraver" \remove "Auto_beam_engraver" } \context { \Staff \remove "Accidental_engraver" \remove "Key_engraver" \remove "Bar_engraver" \remove "Time_signature_engraver" } } } @end lilypond @noindent @code{Stem_engraver} はやって来るすべての音符の玉 (ノート ヘッド) について知@c らされます。1 つの音符の玉 (あるいは和音の場合は複数の音符の玉) が現れるたび@c に、ステム オブジェクトが作成され、音符の玉に接続されます。さらにビーム (ス@c テムとステムをつなぐ横棒)、スラー、アクセント、臨時記号、小節線 (小節と小節@c を区切る縦線)、拍子記号、調号のためのエングラーバを付け加えるによって、我々@c は完全な楽譜を手に入れることができます。 @lilypond[quote,ragged-right] \include "engraver-example.ily" \score { \topVoice } @end lilypond @cindex polyphony @cindex engraving multiple voices @cindex contexts このシステムは単旋律の音楽に対してはうまく機能しますが、多声部音楽に対しては@c どうでしょうか?多声部表記では、多くの声部 (ボイス) が 1 つの譜表を共有します。 @lilypond[quote,ragged-right] \include "engraver-example.ily" \new Staff << \topVoice \\ \botVoice >> @end lilypond このような場合、臨時記号と譜表は共有されますが、ステム、スラー、ビームなどは@c 各声部が単独で持ちます。そのため、エングラーバはグループ化されるべきです。音@c 符の玉、ステム、スラーなどのためのエングラーバは @q{Voice context} (ボイス コンテキスト) と呼ばれるグループに入れられ、一方の調子、臨時記号、小節線など@c のためのエングラーバは @q{Staff context} (譜表コンテキスト) とグループに入れ@c られます。多声部音楽の場合、単一の譜表コンテキストには複数のボイス コンテキ@c ストが含まれます。同様に、複数の譜表コンテキストは単一の楽譜 (Score) コンテ@c キストになり得ます。楽譜コンテキストは最上位の表記コンテキストです。 @seealso 内部リファレンス: @rinternals{Contexts}. @lilypond[quote,ragged-right] \include "engraver-example.ily" \score { << \new Staff << \topVoice \\ \botVoice >> \new Staff << \pah \\ \hoom >> >> } @end lilypond @node 音楽表記 @unnumberedsubsec 音楽表記 @translationof Music representation @cindex syntax @cindex recursive structures 概念上、高レベル フォーマット システムのための入力フォーマットは内容を抽象的@c に記述するものになります。このケースでは、内容は音楽自体になります。これは手@c に負えない問題に見えます: どうやったら我々は音楽の本質を定義できるでしょう@c か?その答えを見つけようとする代わりに、我々はその問題を逆転させました。我々@c は楽譜を譜刻する能力を持つプログラムを書き、そのフォーマットができる限りすっ@c きりしたものになるよう調整します。これ以上フォーマットを減らすことができない@c という状態になったとき、当然のことながら我々に残されているのは内容自体になり@c ます。我々のプログラムは音楽ドキュメントの形式定義として機能します。 さらに、構文が LilyPond のユーザ インタフェイスになっているため、 @example @{ c'4 d'8 @} @end example とタイプだけで、4 分音符の C1 (ミドル C (=ド)) と 8 分音符の D1 (ミドル C の@c 上の D (=レ)) になります。 @lilypond[quote] { c'4 d'8 } @end lilypond @warning{訳者: C = ド, D = レ, E = ミ, F = ファ, G = ソ, A = ラ, B = シ で@c す。LilyPond では音符を「ドレミ〜」ではなく "CDE~" として捉えることが必須なの@c で、今後は音符をアルファべット表記にします。} 小さなスケールでは、そのような構文は簡単に使用できます。大きなスケールでは、@c 構文はさらに構造を持つ必要があります。そうしなければ、どうやったらあなたはシ@c ンフォニーやオペラのような複雑な楽譜に取り組めるでしょうか?構造は音楽表現法@c というコンセプトによって形成されます: 小さな音楽の断片を組み合わせて大きな音@c 楽にすることによって、より複雑な音楽を表すことができるようになります。例を挙@c げます。 @lilypond[quote,verbatim,fragment,relative=1] f4 @end lilypond @noindent 同時進行の音符はそれらを @code{<<} と @code{>>} で囲むことによって構築できます: @example <> @end example @lilypond[quote,fragment,relative=1] \new Voice { <> } @end lilypond @noindent この音楽表現を中括弧 @code{@{@tie{}@dots{}@tie{}@}} で囲むことによってシークエ@c ンスの中に入れることができます: @example @{ f4 <> @} @end example @lilypond[quote,relative=1,fragment] { f4 <> } @end lilypond @noindent 上記もまた音楽表現の 1 つなので、@code{<<}, @code{@bs{}@bs{}}, and @code{>>} を使ってそれを再び他の同時進行の音楽表現 (2 分音符) と組み合わせることもでき@c ます: @example @code{<< g2 \\ @{ f4 <> @} >>} @end example @lilypond[quote,fragment,relative=2] \new Voice { << g2 \\ { f4 <> } >> } @end lilypond このような再帰的な構造はさっぱりと、かつ、しっかりした形式でコンテキスト フ@c リー文法で記すことができます。コード解析もまたこの文法から生成されます。言い換@c えると、LilyPond の構文ははっきりと明快に定義されます。 ユーザが LilyPond に取り組むときに、ユーザがその時間の大半で見て、扱うものは@c ユーザ インタフェイスと構文です。それらのある部分は好みの問題であり、多くの議@c 論の対象にもなるものです。好みについて議論することは有意義なことですが、それほ@c ど生産的なことではありません。LilyPond という大きな世界の中で、入力構文の重要@c 性は小さいのです: さっぱりとした構文をでっちあげることは簡単ですが、見苦しくな@c いフォーマット コードを作成することはとても難しいのです。このことは、それぞれ@c のコンポーネントの行数をカウントすることによっても実証されます: 解析と表記のた@c めのコンポーネントはソース コード全体の 10 % にも達しません。 @node 例用例 @unnumberedsubsec 例用例 @translationof Example applications @cindex simple examples @cindex examples, simple 我々はどのように譜刻の技術をコンピュータ プログラムの中に凝縮するかという実験@c として LilyPond を開発してきました。重労働のおかげで、今やこのプログラムは有用@c な働きを行うのに使用できるようになりました。非常に簡単な利用例は音符を譜刻する@c ことです。 @lilypond[quote,relative=1] { \time 2/4 c4 c g'4 g a4 a g2 } @end lilypond @noindent コード ネームと歌詞を加えることによって、我々はリード譜を得ます。 @lilypond[quote,ragged-right] << \chords { c2 c f2 c } \new Staff \relative c' { \time 2/4 c4 c g' g a a g2 } \addlyrics { twin -- kle twin -- kle lit -- tle star } >> @end lilypond さらに、多声部表記とピアノ譜を譜刻することもできます。以下の例はいくつかのより@c 風変わりな構成を組み合わせています。 @lilypond[quote] \header { title = "Screech and boink" subtitle = "Random complex notation" composer = "Han-Wen Nienhuys" } \score { \context PianoStaff << \new Staff = "up" { \time 4/8 \key c \minor << { \revert Stem #'direction \change Staff = down \set subdivideBeams = ##t g16.[ \change Staff = up c'''32 \change Staff = down g32 \change Staff = up c'''32 \change Staff = down g16] \change Staff = up \stemUp \set followVoice = ##t c'''32([ b''16 a''16 gis''16 g''32)] } \\ { s4 \times 2/3 { d'16[ f' g'] } as'32[ b''32 e'' d''] } \\ { s4 \autoBeamOff d''8.. f''32 } \\ { s4 es''4 } >> } \new Staff = "down" { \clef bass \key c \minor \set subdivideBeams = ##f \override Stem #'french-beaming = ##t \override Beam #'beam-thickness = #0.3 \override Stem #'thickness = #4.0 g'16[ b16 fis16 g16] << \makeClusters { as16 } \\ { \override Staff.Arpeggio #'arpeggio-direction =#down 4\arpeggio } >> } >> \midi { \context { \Score tempoWholesPerMinute = #(ly:make-moment 60 8) } } \layout { \context { \Staff \consists Horizontal_bracket_engraver } } } @end lilypond 上で示した楽譜の断片はすべて手作業で作成されていました。しかしながら、必ずしも@c 手作業で行う必要はありません。フォーマット エンジンの大部分は自動化されている@c ため、その出力を音楽を操作する他のプログラムに供することができます。例えば、音@c 楽の断片のデータベースをウェブサイトやマルチメディア プレゼンテーションで使用@c する画像に変換するために使用することもできます。 このマニュアルも利用例です: 入力フォーマットはテキストなので、容易に他のテキスト ベースのフォーマット -- 例えば、@LaTeX{}, HTML, このマニュアルの場合は Texinfo -- に埋め込むことができます。ある特別なプログラムによって入力断片を音@c 楽イメージに置き換えることができ、それによって PDF や HTML の出力ファイルとい@c う結果を得ることができます。これはドキュメントの中で音楽とテキストを混在させる@c ことを容易にします。 @node このドキュメントについて @section このドキュメントについて @translationof About the documentation この節では、このドキュメントの各部分について説明します。 @cindex Learning Manual @cindex Music Glossary @cindex Notation Reference @cindex Application Usage @cindex Snippet List @cindex Internals Reference @c leave these lines wrapping around. It's some texinfo 4.12 thing. -gp @c This is actually a limitation of texi2html. -jm @menu * 学習マニュアルについて:: このマニュアルは表記を作成する方法について丁寧@c な説明をしながら LilyPond についての紹介を行います。 * 音楽用語集について:: このマニュアルは音楽用語についての説明を行い、そ@c れらの用語の他の言語への訳語を提供します。 * 表記リファレンスについて:: このマニュアルはこのドキュメントの主要部分で@c す。表記を作成する方法についての詳細な情報を提供します。このマニュアルは読者が@c 学習マニュアルでカバーされている基本的な内容を知っていて、音楽用語集に書かれて@c いる英語の音楽用語に馴染んでいるものと仮定しています。 * アプリケーション使用方法について:: ここでは実際のプログラムとオペレーティング シ@c ステム特有の問題について議論します。 * 断片集について:: これは短い LilyPond の例のコレクションです。 * 内部リファレンスについて:: このドキュメントは LilyPond の内部構造体に@c ついての参照情報を提供します。調整を行うのに LilyPond の内部構造体についての知@c 識が必要です。 * その他のドキュメント:: ここにはこのドキュメントの他の部分 -- ニュースやメール アーカイブなど -- がいくつかあります。 @end menu @node 学習マニュアルについて @unnumberedsubsec 学習マニュアルについて @translationof About the Learning Manual @cindex Learning Manual 本書は LilyPond の学習の始め方を説明し、同時にいくつかの鍵となるコンセプトを簡@c 単な用語で説明します。あなたは本書を一読すべきです。 各セクションの最後には@strong{参照}というパラグラフがあり、そこには他のセクシ@c ョンへの参照があります: 初めて本書を読むときはこれらの参照を追うべきではありま@c せん。あなたが学習マニュアルをすべて読み終えたとき、いくつかのセクションを読み@c 返し、さらに参照を追おうと思うかもしれません。 @itemize @item @ref{導入部}: LilyPond のバックグランドと最終目標について説明します。 @item @ref{チュートリアル}: 音楽を譜刻するためのやさしい入門を提供します。初めて LilyPond を使うユーザはここから始めるべきです。 @item @ref{基礎となるコンセプト}: LilyPond ファイル フォーマットについてのいくつかの@c 一般的なコンセプトを説明します。あるコマンドを置くべき場所がわからない場合は、@c この章を読んでください! @item @ref{出力を調整する}: LilyPond が作り出すデフォルトの譜刻を変更する方法を示し@c ます。 @item @ref{LilyPond プロジェクトに取り組む}: LilyPond の実際的な使用といくつかの一般的@c な問題を回避するための方法について議論します。大きなプロジェクトに取り組む前に@c この章を読んでください! @end itemize さらに、学習マニュアルは付録 -- 一読するのを推奨しない部分 -- も保持していま@c す。それらは後で読み直すときに有用になるかもしれません: @itemize @item @ref{テンプレート}: コンパイルの準備が整っている LilyPond 入力を示します。ある@c テンプレートをファイルにカット&ペーストし、表記を追加するだけで完了です! @item @ref{Scheme tutorial}: Scheme の簡単な紹介を提供します。Scheme は音楽関数が使@c 用するプログラミング言語です。この付録は高度な調整を行うための資料です。多くの@c ユーザは Scheme に触れる必要はまったくありません。 @end itemize @node 音楽用語集について @unnumberedsubsec 音楽用語集について @translationof About the Music Glossary @cindex Music Glossary @cindex idiom @cindex jargon @cindex terminology @cindex foreign languages @cindex language @rglosnamed{Top,Music glossary} は音楽用語についての説明を行い、それらの用語のさまざまな言語への訳語を提供しま@c す。あなたが音楽表記や音楽用語に馴れていないのなら (特にあなたが英語圏の人でな@c いのなら)、用語集を引くことはとても役に立ちます。 @node 表記リファレンスについて @unnumberedsubsec 表記リファレンスについて @translationof About the Notation Reference @cindex Notation Reference @cindex appendices @cindex reference charts @cindex charts, reference 本書は表記を作り出すすべての LilyPond コマンドについての説明を行います。本書@c は、読者が学習マニュアルを読み終えて、LilyPond のコンセプトに馴染みを持ってい@c るものと仮定しています。 @itemize @item @ruser{Musical notation}: は表記概念ごとにグループ化されたテーマについて議論します。このセクションでは、@c ほとんどすべての表記プロジェクトで有用な基本的な表記についての詳細を提供します。 @item @ruser{Specialist notation}: は表記概念ごとにグループ化されたテーマについて議論します。このセクションでは、@c ある特定の楽器 (またはボーカル) グループにとってのみ有用な特別な表記についての@c 詳細を提供します。 @item @ruser{General input and output}: は LilyPond 入力ファイルと出力の制御についての一般的な情報について議論します。 @item @ruser{Spacing issues}: は出力全般に影響を与える事柄 -- 用紙サイズの選択や改ページの指定など -- につ@c いて議論します。 @item @ruser{Changing defaults}: LilyPond があなたの望む表記を作り出すように調整する方法について説明します。 @item @ruser{Interfaces for programmers}: Scheme を用いて音楽関数を作成する方法について説明します。 @end itemize 表記リファレンスには有用な参照表を持つ付録もあります。 @itemize @item @ruser{Literature list}: には、表記や譜刻についてもっと知りたい人たち向けのリファレンス ブックのセット@c があります。 @item @ruser{Notation manual tables}: は、コード名、MIDI 命令、カラー名のリスト、Feta フォントについての表のセットで@c す。 @item @ruser{Cheat sheet}: は最も一般的な LilyPond コマンドの簡易リファレンスです。 @item @ruser{LilyPond command index}: すべての LilyPond @code{@bs{}command} のインデックスです。 @item @ruser{LilyPond インデックス}: すべてを網羅する完全なインデックスです。 @end itemize @node アプリケーション使用方法について @unnumberedsubsec アプリケーション使用方法について @translationof About the Application Usage @cindex Application Usage @cindex integrating LilyPond with other programs 本書はプログラムを実行する方法、LilyPond 表記を他のプログラムに統合する方法に@c ついて説明します。 @itemize @item @rprogram{インストール}: LilyPond をインストールする方法について、もし望むのならばコンパイルの仕方も含@c めて、説明します。 @item @rprogram{セットアップ}: あなたのコンピュータを LilyPond の使用に合わせて最適にコンフィグレーションする -- ある特定のテキスト エディタによって提供される特別な環境を使用するなど -- 方@c 法について説明します。 @item @rprogram{LilyPond を実行する}: LilyPond とその援助プログラムを実行する方法を示します。さらに、このセクション@c は入力ファイルを LilyPond の以前のバージョンからアップグレードする方法について@c 説明します。 @item @rprogram{LilyPond-book}: このマニュアルのような内部に音楽の例を持つドキュメントを作成する方法についての@c 詳細を説明します。 @c explains the details behind creating documents with in-line music @c examples, like this manual. @item @rprogram{Converting from other formats}: 変換プログラムを実行する方法について説明します。それらのプログラムは LilyPond パッケージで提供され、さまざまな音楽フォーマットを @code{.ly} フォーマットに変@c 換します。 @end itemize @node 断片集について @unnumberedsubsec 断片集について @translationof About the Snippet List @cindex snippets @cindex LSR @cindex Snippet List @cindex LilyPond Snippet Repository @rlsrnamed{Top,LilyPond Snippet List}: これは @uref{http://lsr@/.dsi@/.unimi@/.it,LilyPond Snippet Repository} (LSR) から選んだ LilyPond 断片のセットです。すべての断片はパブリック ドメイン@c の中にあります。 このドキュメントは LSR のサブセットそのものではないことに注意してください。LSR は安定板の LilyPond バージョンを使用するため、開発中の新しい機能を実演する断片は LSR とは別に追加されなければなりません。それらは LilyPond ソース ツリーの中の @file{input/new/} の中に保存されます。 表記リファレンスの各サブセクションのための断片のリストは @strong{参照}部分から@c もリンクされています。 @node 内部リファレンスについて @unnumberedsubsec 内部リファレンスについて @translationof About the Internals Reference @cindex Internals Reference @rinternalsnamed{Top,Internals Reference}: これは幾重にもリンクし合った HTML ページのセットです。本書はすべての LilyPond クラス、オブジェクト、関数について@c の具体的な詳細をドキュメント化しています。本書はソース コードの中にあるフォー@c マット定義から直接作り出されます。 内部的に使用されるフォーマット機能はほとんどすべてユーザが直接利用できます。例@c えば、太さや距離などを制御するたいていの変数は入力ファイルの中で変更することが@c できます。膨大な数のフォーマット オプションがあり、それらすべてがこのドキュメ@c ントの中で記述されています。表記リファレンスの各セクションには@b{参照}サブ セ@c クションがあり、本書を参照しています。HTML ドキュメントでは、@b{参照}サブ セク@c ションの中にクリック可能なリンクがあります。 @node その他のドキュメント @unnumberedsubsec その他のドキュメント @translationof Other documentation とても有益であるかもしれない他の情報源がいくつかあります。 @itemize @item @ifhtml @ifset bigpage @uref{../topdocs/NEWS.html,News}: @end ifset @ifclear bigpage @uref{../../topdocs/NEWS.html,News}: @end ifclear @end ifhtml @ifnothtml News: @end ifnothtml これは前のバージョンの LilyPond から後に付け加えられた重要な変更と新しい機能に@c ついての要約です。 @item @uref{http://lists.gnu.org/archive/html/lilypond-user/, lilypond-user メーリングリスト アーカイブ}: これはこれまでにユーザ リストに送@c られてきた email のコレクションです。多くの質問が何度も繰り返されています。疑@c 問を持った場合、その答えはこのアーカイブの中で見つかるかもしれません。 @item @uref{http://lists.gnu.org/archive/html/lilypond-devel/, lilypond-devel メーリングリスト アーカイブ}: これはこれまでに開発者のリストに@c 送られてきた email のコレクションです。ここでの議論はより専門的です。lilypond 内部についての高度な疑問を持った場合、その答えはこのアーカイブの中で見つかるか@c もしれません。 @item 埋め込まれている楽譜の断片: 楽譜の断片を埋め込まれたすべての HTML ドキュメント@c では、楽譜の画像をクリックすることによって、その画像を作り出すのに使用された LilyPond 入力を閲覧することができます。 @item 初期化ファイル: ここで言及しているドキュメント ファイルの置き場所はシステムに@c よってさまざまです。しばしばこのマニュアルは初期化ファイルと例のファイルを参照@c します。このマニュアルを通じて、ソース アーカイブのトップ ディレクトリ下にある@c 入力ファイルを参照します。@c @c Throughout this manual, we refer to input files relative to the top-directory @c of the source archive.@c 例えば、@file{input/@/lsr/@/dirname/@/bla@/.ly} はファイル @file{lilypond@/2.x.y/@/input/@/lsr/@/dirname/@/bla@/.ly} を参照するかもしれま@c せん。@c UNIX プラットフォーム向けのバイナリ パッケージでは、通常、このドキュメントと例は @file{/usr/@/share/@/doc/@/lilypond/} 下のどこかで見つかります。初期化ファイル -- 例えば、@file{scm/@/lily@/.scm} や @file{ly/@/engraver@/-init@/.ly} -- は、@c 通常、ディレクトリ @file{/usr/@/share/@/lilypond/} の中で見つかります。詳細は @ref{その他の情報源} を参照してください。 @end itemize