1 @c -*- coding: utf-8; mode: texinfo; documentlanguage: ja -*-
2 @c This file is part of lilypond-learning.tely
4 Translation of GIT committish: 499a511d4166feaada31114e097f86b5e0c56421
6 When revising a translation, copy the HEAD committish of the
7 version that you are working on. See TRANSLATION for details.
12 @c Translators: Sawada, Yoshiki
13 @c Translation status: post-GDP
18 この章では読者に LilyPond とこのドキュメントについての紹介を行います。
22 * About the documentation::
29 この節は LilyPond の最終目的とアーキテクチャについてカバーします。
33 * Automated engraving::
34 * What symbols to engrave?::
35 * Music representation::
36 * Example applications::
41 @unnumberedsubsec Engraving
44 @cindex typography, music
45 @cindex music typography
46 @cindex plate engraving
47 @cindex music engraving
49 楽譜印刷の技術は @emph{(プレート) 譜刻} (原文: engraving、版画などの印刷のこと) と呼ばれています。この用語は伝統的な楽譜印刷のプロセスに由来します。ほんの数十年前まで、楽譜は音楽記号を亜鉛やしろめ (錫と鉛の合金) の版に反転したイメージで彫り込んだり、刻印することによって作られていました。版にはインクが塗られ、彫り込んだり刻印してくぼんだ部分にはインクが溜まります。版のイメージはその版に紙が押し付けられることによって形になります。刻印と彫刻は完全に手作業で行われていました。校正は可能だとしても厄介でした。なぜなら一から刻印と彫刻のやり直しだったからです。譜刻は高度に専門的な技術でした; 職人はマスター エングラーバ (譜刻を行う人) の称号を得るまで 5 年の修行を修めなければならず、本当に技術を習得するまでにはさらにもう 5 年の経験が必要だったのです。
51 今日では、コンピュータによってまったく新しい楽譜が出版されています。これには明らかな利点があります; 印刷は安く済み、編集したものを email で配ることが可能です。不幸なことに、コンピュータが広く使われるようになって楽譜のグラフィカルな品質は低下しています。コンピュータによって出版された楽譜は味気無く、機械的な見た目をしているため、その楽譜で演奏することに喜びを感じられません。
53 @c introduce illustrating aspects of engraving, font...
54 以下の図は伝統的な譜刻とコンピュータ出版の違いを描いたものであり、3 番目の図は LilyPond がどれくらい伝統的な見た目を模倣しているのかを示しています。左端のスキャンした図はコンピュータ出版の典型的な決定を示しています; 縦棒は細く、フラット記号の太さは細線と一致していて、曲線はまっすぐなレイアウトになっています。対照的に、ベーレンライター (Barenreiter: ドイツの出版社) のフラットは太く、曲線は官能的です。我々のフラットは 2 つのもののうち後者を元にデザインされています。丸みを帯びていて、太さは縦棒の太さと調和していて、コンピュータによるものよりも線が太くなっています。
56 @multitable @columnfractions .125 .25 .25 .25 .125
60 @image{henle-flat-gray,,4cm}
63 @image{henle-flat-gray,,,png}
68 @image{baer-flat-gray,,4cm}
71 @image{baer-flat-gray,,,png}
76 @image{lily-flat-bw,,4cm}
79 @image{lily-flat-bw,,,png}
83 @image{lilypond/henle-flat-bw,,,png} @image{lilypond/baer-flat-bw,,,png}
84 @image{lilypond/lily-flat-bw,,,png}
92 LilyPond Feta font (2003)
97 @cindex musical symbols
102 @c introduce illustrating aspects of engraving, spacing...
103 スペースの点では、スペースの配分は音符と音符の間の音の間隔を反映します。しかしながら、現代楽譜の多くは数学的な正確さを持った間隔に固執しています。このことはおもしろくない結果を生み出します。次の例では、2 度楽譜をプリントしています: 1 度目は正確に数学的なスペースを用いて、2 度目はそれに校正を加えています。違いを見分けられますか?
105 @cindex optical spacing
106 @c file spacing-optical.
107 @c need to include it here, because we want two images.
128 \override NoteSpacing #'stem-spacing-correction = #0.6
153 \override NoteSpacing #'stem-spacing-correction = #0.0
154 \override NoteSpacing #'same-direction-correction = #0.0
155 \override StaffSpacing #'stem-spacing-correction = #0.0
161 @cindex regular rhythms
162 @cindex regular spacing
163 @cindex spacing, regular
165 各小節には一定のリズムで演奏される音符だけがあります。スペースもそれを反映しています。不幸なことに、我々の目は我々を少し惑わせます。音符の「玉」 (ノート ヘッド) の間隔だけでなく、連続した棒 (ステム、音符から突き出る棒) の間隔も考慮します。結果として、アップ ステム/@/ダウン ステム (玉の上に突き出た棒/@/玉の下に突き出た棒) の組み合わせは離すべきであり、ダウン ステム/アップステムの組み合わせは近づけるべきです、すべては音符の垂直方向の位置の組み合わせに次第です。上の 2 小節は音符のダウン ステム/@/アップ ステムの組み合わせを近づけるよう校正を加えたものであり、下の 2 小節はこの校正を加えていないものです。
168 通常、奏者は楽譜の見え方を勉強するよりも演奏をするほうに夢中ですので、印刷上の詳細にこだわることは形式尊重のように思えるかもしれません。しかしそうではありません。単調なリズムがずっと続くような場合、スペースの校正を行うことで各行のレイアウトに微妙な変化が加わり、それぞれが異なる視覚的特徴を持つようになります。この特徴が無ければすべての行は同じに見え、迷路のようになってしまいます。奏者がちょっと目を逸らしたり、集中力を欠くと、それまで見ていた行はページの中に埋もれてしまいます。
170 同様に、太い譜線 (音の高さを表す線。五線譜では 5 本) に描かれた太い記号は見た目が強く、楽譜から奏者が離れている場合 -- 例えば、楽譜が譜面台にある場合 -- に良く目立ちます。空白を注意深く配置することで、楽譜は記号が乱雑になることなく締まります。結果としてページをめくる回数は最小となり、これは大きな利点になります。
172 これは印刷において共通して言えることですが、レイアウトはこざっぱりとしているべきです。これは印刷自体のためであるだけでなく、特にその印刷物を読んでいる読み手の助けにもなるからです。楽譜のような演奏用の道具では、このことは 2 重に重要性を持ちます: 奏者の注意力には限界があり、奏者が楽譜を読むことに払う注意力が少なくて済めば済むほど、その奏者は演奏に集中することができます。言い換えると、良い印刷は良い演奏につながるのです。
174 以上で挙げたことは、楽譜の印刷は微妙で複雑な技術であり、楽譜を印刷するには非常な熟練 -- これは通常、奏者が持っているものではありません -- が必要であるということを示しています。LilyPond は、手作業で譜刻された楽譜のすばらしさをコンピュータ世代に提供しよう、すばらしい楽譜を普通の音楽家にも利用可能にしようという我々の努力なのです。我々は、良く見てみたくなり、演奏したくなるような古い楽譜のクオリティに匹敵する楽譜を提供するために、アルゴリズム、フォント デザイン、プログラム設定を調整してきました。
177 @node Automated engraving
178 @unnumberedsubsec Automated engraving
180 @cindex engraving, automated
181 @cindex automated engraving
183 我々はどのように譜刻を実現していくのでしょうか?職人が本当のマスターになるのに 10 年以上かかるのなら、単なるハッカーである我々がどうやったら職人の仕事を越えるプログラムを書けるのでしょうか?
185 その答えは、我々には「できない」です。譜刻は人間的な状況判断に頼っているため、判断を行う人間を完全にコンピュータに置き換えることはできません。しかしながら、退屈な作業の多くを自動化することはできます。もし LilyPond が一般的なケースの大半に対処できるなら、それは既存のソフトウェアよりも大きく前進することになります。残りのケースは手作業で調整することができます。年数が経つにつれて、このソフトウェアはより多くのことを自動的に行えるよう洗練されていき、手作業による手直しはどんどん必要なくなっていくことでしょう。
187 我々が LilyPond の開発を始めたとき、我々は LilyPond プログラム全体を C++ プログラミング言語で書いていました。プログラムの機能は開発者によってかっちりと決められていました。これはいくつかの理由で不満足なものであることがわかりました:
190 @item LilyPond が失敗を犯したとき、ユーザはフォーマット判断 (どのようなフォーマットにするかの判断) を上書きする必要があります。そのため、ユーザはフォーマット エンジンにアクセスしなければなりません。そのため、コンパイル時に我々 (開発者) によって規則と設定を固定することは無理があり、実行時 (LilyPond によって楽譜を作り出すとき) にユーザが規則と設定にアクセスできなければなりません。
192 @item 譜刻は視覚的判断の問題であり、そのために好みがあります。我々には知識がありますが、ユーザは我々の個人的な判断に異を唱える可能性もあります。そのため、譜刻様式の定義もまたユーザがアクセスできるものでなければなりません。
193 @item 最後に、我々は継続的にフォーマット アルゴリズムを改良させていくので、我々には規則に対する自由度の高いアプローチが必要です。C++ 言語は音楽表記の作業とはうまくマッチしない規則分類法を押し付けてきます。
197 @cindex Scheme programming language
199 これらの問題に対して、Scheme プログラミング言語のインタプリタを統合し、LilyPond の各部分を Scheme で書き直すという処置がとられてきました。現在のフォーマット アーキテクチャはグラフィカル オブジェクトという概念で構築されていて、Scheme 変数と関数によって記述されています。このアーキテクチャは、フォーマット規則、譜刻スタイル、個々のフォーマットに関する判断を包含しています。ユーザはこれらの制御の大半に直接アクセスする術を持ちます。
201 Scheme 変数はレイアウトに関する判断を制御します。例えば、多くのグラフィカル オブジェクトは上か下か (あるいは左か右か) の選択を決定する方向 (に関する) 変数を持ちます。ここで、アクセントとアルペジオを持つ 2 つの和音を見てみます。最初の和音では、すべてのグラフィカル オブジェクトは下向き (あるいは左向き) の方向を持っています。2 番目の和音では、すべてが上向き (あるいは右向き) の方向を持っています。
203 @lilypond[quote,ragged-right]
205 \override SpacingSpanner #'spacing-increment = #3
206 \override TimeSignature #'transparent = ##t
208 \stemDown <e g b>4_>-\arpeggio
209 \override Arpeggio #'direction = #RIGHT
210 \stemUp <e g b>4^>-\arpeggio
214 @cindex score formatting
215 @cindex formatting a score
216 @cindex formatting rules
219 楽譜を形作るプロセスはグラフィカルオブジェクトの変数を読み込んだり、書き込んだりすることからなります。いくつかの変数はプリセット値を持ちます。例えば、多くの線の太さ -- 印刷スタイルの特性 -- はプリセット値を持つ変数です。あなたは自由にこの値を変更することができ、それによってあなたの楽譜は異なる印象を持つことになります。
221 @lilypond[quote,ragged-right]
224 c'4-~ c'16 as g f e16 g bes c' des'4
229 \override Beam #'thickness = #0.3
230 \override Stem #'thickness = #0.5
231 \override Bar #'thickness = #3.6
232 \override Tie #'thickness = #2.2
233 \override StaffSymbol #'thickness = #3.0
234 \override Tie #'extra-offset = #'(0 . 0.3)
240 さらにフォーマット規則もプリセット変数です: 各オブジェクトはプロシージャを保持している変数を持ちます。これらのプロシージャが実際のフォーマットを実行し、異なるプロシージャを使用することによってオブジェクトの見た目を変えることができます。以下の例では、音符の玉 (ノート ヘッド) シンボルを印刷するのにどの音符の玉オブジェクトを使用するかを決定する規則を楽譜の途中で変更しています。
242 @lilypond[quote,ragged-right]
243 #(set-global-staff-size 30)
245 #(define (mc-squared grob orig current)
246 (let* ((interfaces (ly:grob-interfaces grob))
247 (pos (ly:grob-property grob 'staff-position)))
248 (if (memq 'note-head-interface interfaces)
250 (ly:grob-set-property! grob 'stencil
251 (grob-interpret-markup grob
252 (make-lower-markup 0.5
256 ((-2) (make-smaller-markup (make-bold-markup "2")))
259 \new Voice \relative c' {
261 \set autoBeaming = ##f
264 \once \override NoteHead #'stencil = #ly:note-head::brew-ez-stencil
265 \once \override NoteHead #'font-size = #-7
266 \once \override NoteHead #'font-family = #'sans
267 \once \override NoteHead #'font-series = #'bold
269 \once \override NoteHead #'style = #'cross
271 \applyOutput #'Voice #mc-squared
274 { d8[ es-( fis^^ g] fis2-) }
275 \repeat unfold 5 { \applyOutput #'Voice #mc-squared s8 }
281 @node What symbols to engrave?
282 @unnumberedsubsec What symbols to engrave?
290 フォーマット プロセスはシンボルを置く場所を決定します。しかしながら、@emph{どの}シンボルを譜刻すべきかを決定する -- 言い換えると、使用する表記を決定する -- と、シンボルを置く場所も決まります。
292 一般の音楽表記は音楽を記録するシステムであり、これは過去 1000 年以上にもわたって進化してきました。現在の一般的な形式はルネッサンス前期にまでさかのぼります。基本的な形式 (すなわち、音符の玉が 5 本線の譜表上にあるというもの) は変更されていませんが、細かな点は現代の表記の改革を表現するためにいまだに発展が続けられています。したがって、一般的な音楽表記はおよそ500年間の音楽を扱います。応用範囲は単旋律から大規模なオーケストラのための途方もない対位法にまで及びます。
294 どうやったら我々はそのような多頭の獣を統率し、制限のあるコンピュータ プログラムに押し込めることができるでしょうか?我々の解決策は表記の問題 (譜刻とは対照的にある、すなわち、活字学) を消化の良いプログラム可能な小さな塊に分解していくことです: それぞれのシンボルのタイプは個々のモジュール -- いわゆるプラグイン -- によって処理されます。各プラグインは完全にモジュール化されて独立していて、それによりそれぞれを別個に開発、改良することができます。そのようなプラグインは音楽的概念をグラフィック シンボルに変換する職人に例えて @code{engraver} (エングラーバ) と呼びます。
296 以下の例では、我々が音符の玉のためのプラグイン @code{Note_heads_engraver} から始めていく様子を見ていきます。
298 @lilypond[quote,ragged-right]
299 \include "engraver-example.ily"
306 \remove "Stem_engraver"
307 \remove "Phrasing_slur_engraver"
308 \remove "Slur_engraver"
309 \remove "Script_engraver"
310 \remove "Beam_engraver"
311 \remove "Auto_beam_engraver"
315 \remove "Accidental_engraver"
316 \remove "Key_engraver"
317 \remove "Clef_engraver"
318 \remove "Bar_engraver"
319 \remove "Time_signature_engraver"
320 \remove "Staff_symbol_engraver"
321 \consists "Pitch_squash_engraver"
328 それから、@code{Staff_symbol_engraver} が譜表を加え
330 @lilypond[quote,ragged-right]
331 \include "engraver-example.ily"
338 \remove "Stem_engraver"
339 \remove "Phrasing_slur_engraver"
340 \remove "Slur_engraver"
341 \remove "Script_engraver"
342 \remove "Beam_engraver"
343 \remove "Auto_beam_engraver"
347 \remove "Accidental_engraver"
348 \remove "Key_engraver"
349 \remove "Clef_engraver"
350 \remove "Bar_engraver"
351 \consists "Pitch_squash_engraver"
352 \remove "Time_signature_engraver"
359 @code{Clef_engraver} が譜表の参照位置を定義し
361 @lilypond[quote,ragged-right]
362 \include "engraver-example.ily"
369 \remove "Stem_engraver"
370 \remove "Phrasing_slur_engraver"
371 \remove "Slur_engraver"
372 \remove "Script_engraver"
373 \remove "Beam_engraver"
374 \remove "Auto_beam_engraver"
378 \remove "Accidental_engraver"
379 \remove "Key_engraver"
380 \remove "Bar_engraver"
381 \remove "Time_signature_engraver"
388 @code{Stem_engraver} が棒 (ステム) を付け加えます。
390 @lilypond[quote,ragged-right]
391 \include "engraver-example.ily"
398 \remove "Phrasing_slur_engraver"
399 \remove "Slur_engraver"
400 \remove "Script_engraver"
401 \remove "Beam_engraver"
402 \remove "Auto_beam_engraver"
406 \remove "Accidental_engraver"
407 \remove "Key_engraver"
408 \remove "Bar_engraver"
409 \remove "Time_signature_engraver"
416 @code{Stem_engraver} はやって来るすべての音符の玉 (ノート ヘッド) について知らされます。1 つの音符の玉 (あるいは和音の場合は複数の音符の玉) が現れるたびに、ステム オブジェクトが作成され、音符の玉に接続されます。さらにビーム (ステムとステムをつなぐ横棒)、スラー、アクセント、臨時記号、小節線 (小節と小節を区切る縦線)、拍子記号、調号のためのエングラーバを付け加えるによって、我々は完全な楽譜を手に入れることができます。
418 @lilypond[quote,ragged-right]
419 \include "engraver-example.ily"
424 @cindex engraving multiple voices
427 このシステムは単旋律の音楽に対してはうまく機能しますが、多声部音楽に対してはどうでしょうか?多声部表記では、多くの声部 (ボイス) が 1 つの譜表を共有します。
429 @lilypond[quote,ragged-right]
430 \include "engraver-example.ily"
431 \new Staff << \topVoice \\ \botVoice >>
434 このような場合、臨時記号と譜表は共有されますが、ステム、スラー、ビームなどは各声部が単独で持ちます。そのため、エングラーバはグループ化されるべきです。音符の玉、ステム、スラーなどのためのエングラーバは @q{Voice context} (ボイス コンテキスト) と呼ばれるグループに入れられ、一方の調子、臨時記号、小節線などのためのエングラーバは @q{Staff context} (譜表コンテキスト) とグループに入れられます。多声部音楽の場合、単一の譜表コンテキストには複数のボイス コンテキストが含まれます。同様に、複数の譜表コンテキストは単一の楽譜 (Score) コンテキストになり得ます。楽譜コンテキストは最上位の表記コンテキストです。
438 内部リファレンス: @rinternals{Contexts}.
441 @lilypond[quote,ragged-right]
442 \include "engraver-example.ily"
445 \new Staff << \topVoice \\ \botVoice >>
446 \new Staff << \pah \\ \hoom >>
452 @node Music representation
453 @unnumberedsubsec Music representation
455 概念上、高レベル フォーマット システムのための入力フォーマットは内容を抽象的に記述するものになります。このケースでは、内容は音楽自体になります。これは手に負えない問題に見えます: どうやったら我々は音楽の本質を定義できるでしょうか?その答えを見つけようとする代わりに、我々はその問題を逆転させました。我々は楽譜を譜刻する能力を持つプログラムを書き、そのフォーマットができる限りすっきりしたものになるよう調整します。これ以上フォーマットを減らすことができないという状態になったとき、当然のことながら我々に残されているのは内容自体になります。我々のプログラムは音楽ドキュメントの形式定義として機能します。
457 さらに、構文が LilyPond のユーザ インタフェイスになっているため、
465 とタイプだけで、4 分音符の C1 (ミドル C (=ド)) と 8 分音符の D1 (ミドル C の上の D (=レ)) になります。
473 @warning{C = ド, D = レ, E = ミ, F = ファ, G = ソ, A = ラ, B = シ です。LilyPond では音符を「ドレミ〜」ではなく "CDE~" として捉えることが必須なので、今後は音符をアルファべット表記にします。}
475 小さなスケールでは、そのような構文は簡単に使用できます。大きなスケールでは、構文はさらに構造を持つ必要があります。そうしなければ、どうやったらあなたはシンフォニーやオペラのような複雑な楽譜に取り組めるでしょうか?構造は音楽表現法というコンセプトによって形成されます: 小さな音楽の断片を組み合わせて大きな音楽にすることによって、より複雑な音楽を表すことができるようになります。例を挙げます。
477 @lilypond[quote,verbatim,fragment,relative=1]
482 同時進行の音符はそれらを @code{<<} と @code{>>} で囲むことによって構築できます:
489 @lilypond[quote,fragment,relative=1]
490 \new Voice { <<c4 d4 e>> }
494 この音楽表現を中括弧 @code{@{@tie{}@dots{}@tie{}@}} で囲むことによってシークエンスの中に入れることができます:
497 @{ f4 <<c4 d4 e4>> @}
500 @lilypond[quote,relative=1,fragment]
505 上記もまた音楽表現の 1 つなので、@code{<<}, @code{\\}, and @code{>>} を使ってそれを再び他の同時進行の音楽表現 (2 分音符) と組み合わせることもできます:
508 @code{<< g2 \\ @{ f4 <<c4 d4 e4>> @} >>}
512 @lilypond[quote,fragment,relative=2]
513 \new Voice { << g2 \\ { f4 <<c d e>> } >> }
516 このような再帰的な構造はさっぱりと、かつ、しっかりした形式でコンテキスト フリー文法で記すことができます。コード解析もまたこの文法から生成されます。言い換えると、LilyPond の構文ははっきりと明快に定義されます。
518 ユーザが LilyPond に取り組むときに、ユーザがその時間の大半で見て、扱うものはユーザ インタフェイスと構文です。それらのある部分は好みの問題であり、多くの議論の対象にもなるものです。好みについて議論することは有意義なことですが、それほど生産的なことではありません。LilyPond という大きな世界の中で、入力構文の重要性は小さいのです: さっぱりとした構文をでっちあげることは簡単ですが、見苦しくないフォーマット コードを作成することはとても難しいのです。このことは、それぞれのコンポーネントの行数をカウントすることによっても実証されます: 解析と表記のためのコンポーネントはソース コード全体の 10 % にも達しません。
527 @node Example applications
528 @unnumberedsubsec Example applications
530 @cindex simple examples
531 @cindex examples, simple
533 我々はどのように譜刻の技術をコンピュータ プログラムの中に凝縮するかという実験として LilyPond を開発してきました。重労働のおかげで、今やこのプログラムは有用な働きを行うのに使用できるようになりました。非常に簡単な利用例は音符を刻譜することです。
535 @lilypond[quote,relative=1]
543 コード ネームと歌詞を加えることによって、我々はリード譜を得ます。
545 @lilypond[quote,ragged-right]
547 \chords { c2 c f2 c }
553 \addlyrics { twin -- kle twin -- kle lit -- tle star }
557 さらに、多声部表記とピアノ譜を刻譜することもできます。以下の例はいくつかのより風変わりな構成を組み合わせています。
561 title = "Screech and boink"
562 subtitle = "Random complex notation"
563 composer = "Han-Wen Nienhuys"
567 \context PianoStaff <<
572 \revert Stem #'direction
574 \set subdivideBeams = ##t
586 \set followVoice = ##t
587 c'''32([ b''16 a''16 gis''16 g''32)]
589 s4 \times 2/3 { d'16[ f' g'] } as'32[ b''32 e'' d'']
591 s4 \autoBeamOff d''8.. f''32
597 \new Staff = "down" {
600 \set subdivideBeams = ##f
601 \override Stem #'french-beaming = ##t
602 \override Beam #'thickness = #0.3
603 \override Stem #'thickness = #4.0
610 \override Staff.Arpeggio #'arpeggio-direction =#down
611 <cis, e, gis, b, cis>4\arpeggio
618 tempoWholesPerMinute = #(ly:make-moment 60 8)
624 \consists Horizontal_bracket_engraver
630 上で示した楽譜の断片はすべて手作業で作成されていました。しかしながら、必ずしも手作業で行う必要はありません。フォーマット エンジンの大部分は自動化されているため、その出力を音楽を操作する他のプログラムに供することができます。例えば、音楽の断片のデータベースをウェブサイトやマルチメディア プレゼンテーションで使用する画像に変換するために使用することもできます。
632 このマニュアルも利用例です: 入力フォーマットはテキストなので、容易に他のテキスト ベースのフォーマット -- 例えば、@LaTex{}, HTML, このマニュアルの場合は Texinfo -- に埋め込むことができます。ある特別なプログラムによって入力断片を音楽イメージに置き換えることができ、それによって PDF や HTML の出力ファイルという結果を得ることができます。これはドキュメントの中で音楽とテキストを混在させることを容易にします。
642 @node About the documentation
643 @section About the documentation
645 この節では、このドキュメントの各部分について説明します。
647 @cindex Learning Manual
648 @cindex Music Glossary
649 @cindex Notation Reference
650 @cindex Application Usage
652 @cindex Internals Reference
654 @c leave these lines wrapping around. It's some texinfo 4.12 thing. -gp
655 @c This is actually a limitation of texi2html. -jm
657 * About the Learning Manual:: このマニュアルは表記を作成する方法について丁寧な説明をしながら LilyPond についての紹介を行います。
658 * About the Music Glossary:: このマニュアルは音楽用語についての説明を行い、それらの用語の他の言語への訳語を提供します。
659 * About the Notation Reference:: このマニュアルはこのドキュメントの主要部分です。表記を作成する方法についての詳細な情報を提供します。このマニュアルは読者が学習マニュアルでカバーされている基本的な内容を知っていて、音楽用語集に書かれている英語の音楽用語に馴染んでいるものと仮定しています。
660 * About the Application Usage:: ここでは実際のプログラムとオペレーティング システム特有の問題について議論します。
661 * About the Snippet List:: これは短い LilyPond の例のコレクションです。
662 * About the Internals Reference:: このドキュメントは LilyPond の内部構造体についての参照情報を提供します。調整を行うのに LilyPond の内部構造体についての知識が必要です。
663 * Other documentation:: ここにはこのドキュメントの他の部分 -- ニュースやメール アーカイブなど -- がいくつかあります。
667 @node About the Learning Manual
668 @unnumberedsubsec About the Learning Manual
670 @cindex Learning Manual
672 本書は LilyPond の学習の始め方と、いくつかのキーとなるコンセプトをわかりやすい言葉で説明します。あなたは本書を一読すべきです。
674 各節の最後にある @strong{参照} には、他の節への参照が含まれています: 初めて本書を読むときはこれらの参照を追うべきではありません。あなたが学習マニュアルをすべて読み終えたとき、いくつかの節を読み返し、さらに参照を追おうと思うかもしれません。
678 @node About the Music Glossary
679 @unnumberedsubsec About the Music Glossary
684 @node About the Notation Reference
685 @unnumberedsubsec About the Notation Reference
690 @node About the Application Usage
691 @unnumberedsubsec About the Application Usage
696 @node About the Snippet List
697 @unnumberedsubsec About the Snippet List
702 @node About the Internals Reference
703 @unnumberedsubsec About the Internals Reference
708 @node Other documentation
709 @unnumberedsubsec Other documentation
715 @c -- SKELETON FILE --