Documentation/ja/usage/suggestions.itely

   1 @c -*- coding: utf-8; mode: texinfo; documentlanguage: ja -*-
   2
   3 @ignore
   4     Translation of GIT committish: 9a65042d49324f2e3dff18c4b0858def81232eea
   5
   6     When revising a translation, copy the HEAD committish of the
   7     version that you are working on.  For details, see the Contributors'
   8     Guide, node Updating translation committishes..
   9 @end ignore
  10
  11 @c \version "2.12.0"
  12
  13 @c Translators: Yoshiki Sawada
  14 @c Translation status: post-GDP
  15
  16
  17 @node LilyPond 入力ファイルの記述に対する提案
  18 @chapter LilyPond 入力ファイルの記述に対する提案
  19 @translationof Suggestions for writing LilyPond input files
  20
  21 今やあなたはもっと大きな LilyPond 入力ファイル -- チュートリアルにあるような@c
  22 小さな例ではなく、楽曲全体 -- を書き始める準備が整っています。@c
  23 しかしながら、どのように書き進めていくべきなのでしょうか？
  24
  25 LilyPond があなたの入力ファイルを理解でき、望みの出力を作り出している限り、@c
  26 あなたの入力ファイルがどのようなものであるかは問題になりません。@c
  27 しかしながら、LilyPond 入力ファイルを書いているときに考慮すべきことが@c
  28 他にもいくつかあります。
  29
  30 @itemize
  31 @item あなたがミスをしたとしたらどうでしょうか？@c
  32 LilyPond ファイルの構造はエラーを見つけ出すことを@c
  33 より容易に (あるいはより困難に) します。
  34
  35 @item あなたがあなたの入力ファイルを誰か他の人と共有したいとしたら@c
  36 どうでしょうか？@c
  37 実際には、あなたが数年前のあなた自身の入力ファイルを変更したいとしたら@c
  38 どうでしょうか？@c
  39 一読して理解可能な LilyPond 入力ファイルがある一方で、@c
  40 あなたを 1 時間も悩ます入力ファイルもあるかもしれません。
  41
  42 @item あなたがあなたの LilyPond ファイルを最近のバージョンの LilyPond のために@c
  43 アップグレードしたいとしたらどうでしょうか？@c
  44 入力構文は LilyPond の改良に合わせてしばしば変更されます。@c
  45 たいていの変更は @code{convert-ly} で自動的に変換できますが、@c
  46 いくつかの変更は手動での援助を必要とするかもしれません。@c
  47 LilyPond 入力ファイルはより容易に (あるいはより困難に)
  48 アップグレードできるように構成することができます。
  49 @end itemize
  50
  51 @menu
  52 * 一般的な提案::
  53 * 既存の音楽を譜刻する::
  54 * 大きなプロジェクト::
  55 @end menu
  56
  57
  58 @node 一般的な提案
  59 @section 一般的な提案
  60 @translationof General suggestions
  61
  62 ここで、あなたが問題を回避したり修正する手助けになる@c
  63 可能性がある提案をいくつか挙げます:
  64
  65 @itemize
  66 @item @strong{すべてのファイルに @code{@bs{}version} 番号を含めます}。@c
  67 テンプレートはすべて @code{@bs{}version} 情報を保持しているということに@c
  68 注意してください。@c
  69 常に @code{@bs{}version} を含めること -- ファイルの大小にかかわらず --
  70 を強く推奨します。@c
  71 個人的な経験から言って、数年前に使っていた LilyPond のバージョンを@c
  72 思い出そうとすることは大変なことです。@c
  73 @command{convert-ly} は使用した LilyPond のバージョンを宣言することを@c
  74 必要とします。
  75
  76 @item @strong{チェックを含めます}: @ruser{Bar and bar number checks},
  77 @ruser{Octave checks}。@c
  78 時々チェックを入れておけば、ミスをしたときに素早くそれを@c
  79 見つけ出すことができます。@c
  80 @q{時々} とはどれくらいの頻度なのでしょうか？@c
  81 それはその音楽の複雑さ次第です。@c
  82 とても簡単な音楽であれば、たぶん 1 回か 2 回です。@c
  83 とても複雑な音楽であれば、おそらく各小節にチェックを入れます。
  84
  85 @item @strong{テキスト 1 行につき 1 小節にします}。@c
  86 音楽自体や望みの出力が複雑である場合、1 行に 1 小節だけを記述すると@c
  87 良い場合が多いです。@c
  88 画面スペースを節約するために 1 行に 8 小節も詰め込むことは、@c
  89 入力ファイルを @q{デバッグ} しなければならない場合に、@c
  90 そうするだけの価値はありません。
  91
  92 @item @strong{入力ファイルにコメントをつけます}。@c
  93 コメントとして小節番号 (時々) や音楽テーマへの参照
  94 (@q{second theme in violins}, @q{fourth variation}
  95 (@q{ヴァイオリンの第 2 テーマ}, @q{第 4 ヴァイオリン})
  96 など) を使用します。@c
  97 初めて楽曲を書いているときはコメントをつける必要は無いかもしれません。@c
  98 しかしながら、数年後に何か変更を加えたいと思った場合や、@c
  99 ソースを友人に渡す場合、あなたがファイルにコメントをつけていなければ、@c
 100 あなたの意図やファイルがどのように構成されているのかを特定することは@c
 101 ずっと大変になります。
 102
 103 @item @strong{波括弧にインデントを入れる}。@c
 104 多くの問題は @code{@{} と @code{@}} の数が食い違うことによって生じます。
 105
 106 @item セクションや変数の開始時に@strong{明示的に演奏時間を付け加える}。@c
 107 フレーズの開始時に @code{c4 d e} (@code{c d e} ではなく) と記述しておけば、@c
 108 後になって音楽を再編成する場合に問題の発生を免れる可能性があります。
 109
 110 @item 音楽定義から@strong{調整を分離します}。@c
 111 @rlearning{変数と関数を用いて入力の手間を省く} と
 112 @rlearning{スタイル シート} を参照してください。
 113
 114 @end itemize
 115
 116
 117 @node 既存の音楽を譜刻する
 118 @section 既存の音楽を譜刻する
 119 @translationof Typesetting existing music
 120
 121 既存の楽譜からの音楽を入力している
 122 (つまり、既存の楽譜の楽曲を譜刻している) のなら、
 123
 124 @itemize
 125
 126 @item 1 回につき 1 つのシステム
 127 (訳者: システムとは譜の集まりのこと。例えば、ピアノ譜での 1 システムとは、@c
 128 右手譜 1 小節とそれに対応する左手譜 1 小節)
 129 を入力し (しかし、それでもテキスト 1 行につき 1 小節だけにします)、@c
 130 それを終えたときに各システムをチェックします。@c
 131 処理をスピード アップさせるために @code{showLastLength} プロパティや
 132 @code{showFirstLength} プロパティを使うことになるかもしれません --
 133 @ruser{Skipping corrected music} を参照してください。
 134
 135 @item @code{mBreak = @{ @bs{}break @}} を定義して、写している楽譜が@c
 136 改行するたびに @code{@bs{}mBreak} を入力ファイルに挿入します。@c
 137 これにより、LilyPond の音楽とオリジナルの音楽を比較することが@c
 138 ずっと容易になります。@c
 139 入力した楽譜の校正が終わったときに、それらの改行すべてを削除するために
 140 @code{mBreak = @{ @}} を定義することになるかもしれません。@c
 141 これにより、LilyPond は LilyPond が最適と思う場所に@c
 142 改行を入れることができるようになります。
 143
 144 @item 移調楽器のパートは変数に入力します。@c
 145 移調楽器の音符は以下で囲むことを推奨します:
 146
 147 @example
 148 \transpose c natural-pitch @{...@}
 149 @end example
 150 (@code{natural-pitch} はその楽器のオープン ピッチです)
 151 これにより、変数の中の音楽は C で効率的に記述することができます。@c
 152 変数を使用していれば、必要なときに移調しなおすこともできます
 153 (例えば、楽譜をコンサート ピッチで譜刻したり、@c
 154 トロンボーン パートをト音記号からヘ音記号に変換したり、など)。@c
 155 音楽をすべて変数の中に首尾一貫したピッチで記述しておけば、@c
 156 移調のミスは起こりにくくなります。
 157
 158 また、移調が C との間で行われるだけ
 159 -- つまり、他に使用する調が楽器のナチュラル ピッチだけ:
 160 B-フラット トランペットなら bes、@c
 161 A-フラット クラリネットなら aes --
 162 であるとしても、音楽を変数に格納しておくべきです。@c
 163
 164 @end itemize
 165
 166
 167 @node 大きなプロジェクト
 168 @section 大きなプロジェクト
 169 @translationof Large projects
 170
 171 大きなプロジェクトに取り組んでいるとき、@c
 172 LilyPond 入力ファイルの構造をすっきりさせておくことが不可欠です。
 173
 174 @itemize
 175
 176 @item @strong{各ボイスに対して変数を使用して}、@c
 177 定義の中の構造を最小限にします。@c
 178 @code{@bs{}score} セクションの構造が最も変更される可能性が高い箇所です。@c
 179 一方、@code{violin} 定義は LilyPond のバージョンが新しくなっても@c
 180 変更される可能性はまずありません。
 181
 182 @example
 183 violin = \relative c'' @{
 184 g4 c'8. e16
 185 @}
 186 ...
 187 \score @{
 188   \new GrandStaff @{
 189     \new Staff @{
 190       \violin
 191     @}
 192   @}
 193 @}
 194 @end example
 195
 196 @item @strong{調整を音楽定義から分離します}。@c
 197 このことは前にも触れましたが、大きなプロジェクトでは絶対に不可欠なことです。@c
 198 @code{fthenp} の定義を変更する必要が生じた場合、変更は 1 回で済み、@c
 199 @code{violin} の内部にはまったく手を触れる必要がありません。
 200
 201 @example
 202 fthenp = _\markup@{
 203   \dynamic f \italic \small @{ 2nd @} \hspace #0.1 \dynamic p @}
 204 violin = \relative c'' @{
 205 g4\fthenp c'8. e16
 206 @}
 207 @end example
 208
 209 @end itemize